Differences From Artifact [ea05d80823]:
- File
src/OFObject.h
— part of check-in
[7f304f573b]
at
2023-11-03 00:16:18
on branch trunk
— OFMatrix4x4: SSE4.1 for -[transformVectors:count:]
This requires the vectors to be 16 byte aligned. In order to achieve
this, the OFVector4D type is changed to have an alignment of 16 bytes.
However, this does *not* break ABI because the only method actually
requiring 16 byte alignment is -[transformVectors:count:], which was not
in ObjFW 1.0. Hence binaries compiled for ObjFW 1.0 have no 16 byte
alignment for OFVector4D, but also cannot ever call into any code that
needs it. (-[transformedVector:] calls into -[transformVectors:count:],
but creates a properly aligned copy that it passes.) (user: js, size: 43115) [annotate] [blame] [check-ins using]
To Artifact [53e8f943e6]:
- File
src/OFObject.h
— part of check-in
[7e1dbda4b4]
at
2023-11-03 01:07:38
on branch trunk
— OFMatrix4x4: Remove SSE4.1 due to Clang bugs
Clang fails to correctly align the _values ivar in 32 bit mode, despite
OF_ALIGN(16). Trying to force it to align it properly by creating a new
typedef or putting it into an aligned struct instead makes Clang's
builtin memcpy fail in another, entirely unrelated method (that has no
inline assembly), as the inlined memcpy will then try to use movaps on
unaligned data, probably because Clang still assumes the data to be
unaligned there and tries to memcpy using SSE after adding an offset
that would make it aligned - but now makes it unaligned. (user: js, size: 43115) [annotate] [blame] [check-ins using]
︙ | |||
345 346 347 348 349 350 351 | 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 | - + | } /** * @struct OFVector4D OFObject.h ObjFW/OFObject.h * * @brief A vector in 4D space. */ |
︙ |