https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #48 from Wilco <wilco at gcc dot gnu.org> --- (In reply to Douglas Mencken from comment #44) > I got assembly of pr78468.c from various versions of GCC > > • 7.3 produces absolutely the same as patched 8.2 > • 6.4 produces slightly different assembly with stmw & lmw and different > sequence of instructions, but numbers like in “addi r2,r1,103” are the same > • 4.2.1 can’t compile it at all pr78468.c:9: error: expected ‘=’, ‘,’, ‘;’, > ‘asm’ or ‘__attribute__’ before ‘uintptr_t’ > > (In reply to Wilco from comment #43) > > No the problem is not in this code. It's STACK_DYNAMIC_OFFSET which is > > wrong. > > I can’t get where is the value of STACK_DYNAMIC_OFFSET in published assembly > and why do you think it is wrong The value is used to create the alloca pointer which has to be r1 + STACK_DYNAMIC_OFFSET aligned to at least STACK_BOUNDARY. > It seems that the problem is in fact that your version of > get_dynamic_stack_size from explow.c (introduced with r251713) gives out too > small values, for example in _t1_a8 it is fifteen “addi r3,r3,15” while ages > before that it worked as being “addi r3,r3,22” > > - addi r3,r3,15 > + addi r3,r3,22 No my version uses exactly the correct size (adding 15 and clearing the bottom 4 bits rounds up to a multiple of 16). > And aligning looks okay, it is then handled by code for > > #define RS6000_ALIGN(n,a) ROUND_UP ((n), (a)) > #define ROUND_UP(x,y) (((x) + (y) - 1) & ~((y) - 1)) > > part of which is rlwinm and such > > (16 + 15) & ~15 = 16 > (16 + 22) & ~15 = 32 > > Thus for your version of get_dynamic_stack_size that size is 16 here, but > for previous ones it is 32. And eventually this leads to fail for such > built-ins as acos, floor, &c. 16 is correct - an alloca of 16 should allocate 16 bytes, not 32. If the size were incorrect it would fail on all targets, and not only when STACK_DYNAMIC_OFFSET is not correctly aligned. What happens is that the extra padding due to adding 22 rather than 15 helps to hide the bug.
