https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to r...@cebitec.uni-bielefeld.de from comment #16) > Same here: > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > [...] > TLS 0x00c3d0 0x0806c3d0 0x00000000 0x00000 0x00024 RW 0x10 If both linkers reproduce the problem and the PT_TLS is 16-byte aligned and thr.1 in it is at offset 0 (or multiple of 16), then I'd think that points to the dynamic linker. The TLS transitions are performed by the linker. > > But the question is if in > > struct __attribute__((aligned (32))) S { long long buf[4]; }; > > __thread struct S s; > > S *foo (void) { return &s; } > > it won't return not properly 32-byte aligned pointer too (and is that in all > > threads or just some (initial vs. other threads)? > > I've wrapped that in a small test programming, calling foo both from the > initial thread and a new one: in all cases, the return value from foo > was 32-byte aligned as expected. Perhaps the problem only shows when the PT_TLS size is not a multiple of the alignment? Or depends on other PT_TLS segments in shared libraries in the same process. The pointer2.f90 testcase will link against libgomp which uses TLS as well. So perhaps try: struct __attribute__((aligned (16))) S { char buf[0x24]; }; __thread struct S s; __attribute__((noipa)) S *foo (void) { return &s; } int main () { #pragma omp parallel __builtin_printf ("%p\n", foo ()); return 0; } ?