[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
wilco at gcc dot gnu.org
Fri Oct 26 12:22:00 GMT 2018
--- 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.
More information about the Gcc-bugs