https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119325
--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> --- Some more testing: Copying gfx908/libm.a of the 'failing' build directory to the install directory + re-compiling will make the binary fail, copying from the 'working' build directory, it will work. Thus, despite 'omp parallel' playing some role, libm.a (not 'libgomp.a') causes the working/failing swap. * * * I tried to dig deeper by compiling libm_a-v64sf_fmod.s with either compiler. -O0 does not help, but switching compiler makes the difference. The source file is: https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libm/machine/amdgcn/v64sf_fmod.c;h=7302420ad382a62fb3f4a3f3f024bf938de5336e;hb=HEAD Having no real idea about the fine print, but I just noticed ('-' = working, '+' = failing): For libm_a-v64sf_fmod.s @@ -2064 +2064 @@ - ; local vars size: 1024 + ; local vars size: 1032 And for libm_a-v64sf_fmod.c.270r.expand: @@ -4705,7 +4705,7 @@ (insn 33 32 34 2 (parallel [ (set (reg/f:DI 706) (plus:DI (reg/f:DI 678 virtual-stack-vars) - (const_int 1016 [0x3f8]))) + (const_int 1024 [0x400]))) (clobber (scratch:BI)) (clobber (scratch:DI)) ...... (plus:DI (reg/f:DI 678 virtual-stack-vars) - (const_int 1016 [0x3f8]))) + (const_int 1080 [0x438]))) Those seem to have to something to do with the failure, given that the patch that caused the fail is labelled: middle-end/118684 - wrongly aligned stack local during expansion
