[Bug c++/42159] app compiled with 4.4.2 SIGABRTs after a trivial nested throw/stack unwinding

2009-11-23 Thread vlad at demoninsight dot com
--- Comment #2 from vlad at demoninsight dot com 2009-11-24 01:37 --- I also have 32 bit gcc 4.4.1 on a MacBook Pro (Snow Leopard 10.6.2 as well) obtained outside of darwinports: >gcc -v Using built-in specs. Target: i386-apple-darwin9.7.0 Configured with: ./configure --enable-languages

[Bug objc++/42156] Hundreds of objc++ testsuite regressions

2009-11-23 Thread howarth at nitro dot med dot uc dot edu
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-11-24 01:49 --- On x86_64-apple-darwin10, these show up as failures like... /sw/src/fink.build/gcc45-4.4.999-20091123/darwin_objdir/gcc/testsuite/obj-c++/../../g++ -B/sw/src/fink.build/gcc45-4.4.999-20091123

[Bug middle-end/42160] New: [4.5 Regression]: cris-elf gcc.c-torture/execute/va-arg-22.c

2009-11-23 Thread hp at gcc dot gnu dot org
With revision 154431 this test passed. >From revision 154433 and on, this test has failed as follows: Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/execute.exp ... FAIL: gcc.c-torture/execute/va-arg-22.c execution, -O1 FAIL: gcc.c-torture/execute/va-arg-22.c execution, -O2

[Bug middle-end/42160] [4.5 Regression]: cris-elf gcc.c-torture/execute/va-arg-22.c

2009-11-23 Thread pinskia at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-24 02:47 --- Happens on x86-linux also: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg02287.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug middle-end/42160] [4.5 Regression]: cris-elf gcc.c-torture/execute/va-arg-22.c

2009-11-23 Thread hp at gcc dot gnu dot org
--- Comment #2 from hp at gcc dot gnu dot org 2009-11-24 02:57 --- (In reply to comment #1) > Happens on x86-linux also: > http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg02287.html Oh "good", thanks! Then I retract my implied offer to reduce the case and attach assembly diff. (I tho

[Bug middle-end/42160] [4.5 Regression]: cris-elf gcc.c-torture/execute/va-arg-22.c

2009-11-23 Thread hp at gcc dot gnu dot org
--- Comment #3 from hp at gcc dot gnu dot org 2009-11-24 03:10 --- test, please ignore. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42160

[Bug fortran/42008] Wrongly rejected derived types with default initializers in PURE procedures

2009-11-23 Thread jvdelisle at gcc dot gnu dot org
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-11-24 04:32 --- This seems to do the trick: Index: decl.c === --- decl.c (revision 154430) +++ decl.c (working copy) @@ -1865,7 +1865,7 @@ variable_decl (

Re: [Bug testsuite/42135] New: FAIL: libgomp.graphite/force-parallel-2.c execution test

2009-11-23 Thread Sebastian Pop
On Sat, Nov 21, 2009 at 14:57, dominiq at lps dot ens dot fr wrote: > Since revision 150792, the test libgomp.graphite/force-parallel-2.c > (introduced > in revision 150755) fails on *-apple-darwin9. AFAICT the array x[1][1] > is allocated in stack and is too big for the 64Mb hard limit o

[Bug testsuite/42135] FAIL: libgomp.graphite/force-parallel-2.c execution test

2009-11-23 Thread sebpop at gmail dot com
--- Comment #1 from sebpop at gmail dot com 2009-11-24 06:51 --- Subject: Re: New: FAIL: libgomp.graphite/force-parallel-2.c execution test On Sat, Nov 21, 2009 at 14:57, dominiq at lps dot ens dot fr wrote: > Since revision 150792, the test libgomp.graphite/force-parallel-2.

[Bug fortran/42008] Wrongly rejected derived types with default initializers in PURE procedures

2009-11-23 Thread burnus at gcc dot gnu dot org
--- Comment #8 from burnus at gcc dot gnu dot org 2009-11-24 06:59 --- (In reply to comment #7) > + if (gfc_pure (NULL) && gfc_state_stack->state != COMP_DERIVED) Looks OK. > None of the examples have any save attributes set, implied or otherwise. Probably not in decl.c - but

[Bug testsuite/42135] FAIL: libgomp.graphite/force-parallel-2.c execution test

2009-11-23 Thread jakub at gcc dot gnu dot org
--- Comment #2 from jakub at gcc dot gnu dot org 2009-11-24 07:17 --- 4000 is still too much. The usual stack size limit on Linux is 8MB, on cygwin it is I think even just 2MB. So it would need to be 500 instead of 1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42135

<    1   2