https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105358
Bug ID: 105358 Summary: [12 Regression] scan* fails on targets without aligned memory allocators. Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- r12-4529-gc7abdf46fb7ac9a0c37 introduces a change to make use of efficient allocators where they are available. On i686/powerpc-darwin9 there are no such allocators (not even posix_memalign) and so the GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC flags is false. the following change: struct gomp_work_share { /* This member records the SCHEDULE clause to be used for this construct. @@ -324,7 +348,12 @@ struct gomp_work_share are in a different cache line. */ /* This lock protects the update of the following members. */ +#ifdef GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC gomp_mutex_t lock __attribute__((aligned (64))); +#else + char pad[64 - offsetof (struct gomp_work_share_1st_cacheline, pad)]; + gomp_mutex_t lock; +#endif causes struct gomp_work_share to become less aligned than 'long long' on the 32b host, which leads to wrong code in work.c which manipulates offsets with __alignof__(long long). So the underlying issue is that the target does guarantee malloc aligned to a cache line [64 bytes on x86] (but only to the size of the largest vector supported by the target [16 bytes]). I'm not clear what the change above is implementing (since i'm not familiar with how this interacts with the rest of the library) so I'm probably missing some subtlety. ... but ISTM that we could omit that change, and the structure would always claim 64 byte alignment (with the lock correctly at offset of 64 bytes). Of course, on these older targets, malloc only returns something guaranteed to be 16 byte aligned - but that *is* sufficient that any use of vector operations to manipulate the content should see suitable alignment. We could also just force the gomp_work_share struct to be aligned to __alignof__(long long). I guess we also have __BIGGEST_ALIGNMENT__ which would at least mean we could align it suitably for the target default. At present, I'm not proposing any patch - since I do not understand the subtleties of how these objects interact with the library. ==== The reason that the fail is not seen on later versions (e.g. i686-darwin17) is because posix_memalign () was introduced in Darwin10.