re: port-macppc/54827: alloca() is broken in gcc 8 on powerpc

[matthew green <mrg%eterna.com.au@localhost>]

The following reply was made to PR port-macppc/54827; it has been noted by GNATS.

From: matthew green <mrg%eterna.com.au@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: port-macppc-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
    netbsd-bugs%netbsd.org@localhost, uwe%stderr.spb.ru@localhost
Subject: re: port-macppc/54827: alloca() is broken in gcc 8 on powerpc
Date: Sun, 19 Jan 2020 19:47:05 +1100

 a quick look at what -maltivec does that our STACK_BOUNDARY
 does, and it seems that maybe there are some hard coded 16
 vs 8 cases.. eg, rs6000.c:25131 in -current:
 
   save_align = (TARGET_ALTIVEC_ABI || DEFAULT_ABI == ABI_DARWIN) ? 16 : 8;
 
 looks like the the one that matters.  there are a few of
 these type of conditionals in the code, though the others
 seem to all generate warnings, and this one is in the
 rs6000_stack_info() function.
 
 as a hack test, can you see if making that always 16 fixes
 the problem?  if so, i can figure out a less stupid way.
 if not, i'll configure my own test setup for it and see
 what else i can figure out.
 
 
 i remember why we do this.  the idea is that any code that
 is built with this compiler will work with altivec code
 intermingled with non altivec option code.
 
 thanks.
 
 
 .mrg.