[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]

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.