On Fri, Mar 13, 2015 at 11:36:47PM +0300, Max Filippov wrote: > >> 2. alloca seems to make an additional 16-bytes padding to each stack > >> allocation: alloca(1) results in moving sp down by 32 bytes, alloca(17) > >> moves it by 48 bytes, etc. > > > > This sounds like PR 50938, 47353, 34548, maybe more? Happens on most > > targets. > > Exactly! (And I was wrong about 1 byte, it needs at least 2 for 32 > bytes result).
Yeah, same bug :-) > But...those PRs are marked as duplicates of a fixed PR 34548. > Looks like it's not fixed or there's a regression? It's not fixed. Removing the STACK_POINTER_OFFSET check from allocate_dynamic_stack_check fixes it, but is probably not good for all targets ;-) 50938 is still open. Segher
