GCC Bugzilla Bug 37584

Unfortunately there is no simple testcase for this,
but compiling mplayer I get a lot of crashes related to
stack corruption

i.e. a function allocates in the stack 80000 bytes
and later gdb says that it cannot access to a byte that instead is bound

I've tested with --stack-size on the linker but nothing changes
gcc version 4.4.0 20080916 (experimental)
does the same thing

while gcc 4.2 is ok

it can be reproduced compiling mplayer/mencoder with gcc >= 4.3
and doing a simple encoding using snow codec:

mencoder -oac faac -faacopts br=64  -ovc lavc -lavcopts
vcodec=snow:vstrict=-2:vqscale=3:pred=0:cmp=1:subcmp=1:mbcmp=1:qpel a.mpg -o
a.avi

Please tell me if I can provide more infos

We really need a testcase.  And I really doubt -ftree-ch is causing any issues,
there must be a latent bug in the back-end.

adding -fno-tree-ch avoid crashing in mencoder, so I filled the bug on this,
but it can be a side effect of something else

I have run into what I believe is the same bug in build of of cc1plus.exe, with
miscompilation of cp/pt.c
When exercising cp/pt.c:process_partial_specialization (eg, when compiling
libstdc++'s mt_allocator.cc) I get a segfault in cygwin.asm (used in w32
implementation  of __builtin_alloca)  
Adding -fno-tree-ch to CFLAGS for pt.c fixes build of libstdc++ and testsuite
results  

I will try to reduce a testcase when time permits.
Danny

I've also seen crashes in alloca(), at least according to gdb backtrace

*** This bug has been marked as a duplicate of 37750 ***