https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102628
--- Comment #1 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:342aedf0e5f324cc2fb026466a8cc5cc7f839183 commit r12-4341-g342aedf0e5f324cc2fb026466a8cc5cc7f839183 Author: Jakub Jelinek <ja...@redhat.com> Date: Tue Oct 12 09:30:41 2021 +0200 libgomp: alloc* test fixes [PR102628, PR102668] As reported, the alloc-9.c test and alloc-{1,2,3}.F* and alloc-11.f90 tests fail on powerpc64-linux with -m32. The reason why it fails just there is that malloc doesn't guarantee there 128-bit alignment (historically glibc guaranteed 2 * sizeof (void *) alignment from malloc). There are two separate issues. One is a thinko on my side. In this part of alloc-9.c test (copied to alloc-11.f90), we have 2 allocators, a with pool size 1024B and alignment 16B and default fallback and a2 with pool size 512B and alignment 32B and a as fallback allocator. We start at no allocations in both at line 194 and do: p = (int *) omp_alloc (sizeof (int), a2); // This succeeds in a2 and needs 4+overhead bytes (which includes the 32B alignment) p = (int *) omp_realloc (p, 420, a, a2); // This allocates 420 bytes+overhead in a, with 16B alignment and deallocates the above q = (int *) omp_alloc (sizeof (int), a); // This allocates 4+overhead bytes in a, with 16B alignment q = (int *) omp_realloc (q, 420, a2, a); // This allocates 420+overhead in a2 with 32B alignment q = (int *) omp_realloc (q, 768, a2, a2); // This attempts to reallocate, but as there are elevated alignment // requirements doesn't try to just realloc (even if it wanted to try that // a2 is almost full, with 512-420-overhead bytes left in it), so it // tries to alloc in a2, but there is no space left in the pool, falls // back to a, which already has 420+overhead bytes allocated in it and // 1024-420-overhead bytes left and so fails too and fails to default // non-pool allocator that allocates it, but doesn't guarantee alignment // higher than malloc guarantees. // But, the test expected 16B alignment. So, I've slightly lowered the allocation sizes in that part of the test 420->320 and 768 -> 568, so that the last test still fails to allocate in a2 (568 > 512-320-overhead) but succeeds in a as fallback, which was the intent of the test. Another thing is that alloc-1.F90 seems to be transcription of libgomp.c-c++-common/alloc-1.c into Fortran, but alloc-1.c had: q = (int *) omp_alloc (768, a2); if ((((uintptr_t) q) % 16) != 0) abort (); q[0] = 7; q[767 / sizeof (int)] = 8; r = (int *) omp_alloc (512, a2); if ((((uintptr_t) r) % __alignof (int)) != 0) abort (); there but Fortran has: cq = omp_alloc (768_c_size_t, a2) if (mod (transfer (cq, intptr), 16_c_intptr_t) /= 0) stop 12 call c_f_pointer (cq, q, [768 / c_sizeof (i)]) q(1) = 7 q(768 / c_sizeof (i)) = 8 cr = omp_alloc (512_c_size_t, a2) if (mod (transfer (cr, intptr), 16_c_intptr_t) /= 0) stop 13 I'm changing the latter to 4_c_intptr_t because other spots in the testcase do that, Fortran sadly doesn't have c_alignof, but strictly speaking it isn't correct, __alignof (int) could be on some architectures smaller than 4. So probably alloc-1.F90 etc. should also have ! { dg-additional-sources alloc-7.c } ! { dg-prune-output "command-line option '-fintrinsic-modules-path=.*' is valid for Fortran but not for C" } and use get__alignof_int. 2021-10-12 Jakub Jelinek <ja...@redhat.com> PR libgomp/102628 PR libgomp/102668 * testsuite/libgomp.c-c++-common/alloc-9.c (main): Decrease allocation sizes from 420 to 320 and from 768 to 568. * testsuite/libgomp.fortran/alloc-11.f90: Likewise. * testsuite/libgomp.fortran/alloc-1.F90: Change expected alignment for cr from 16 to 4.
