[Bug fortran/39893] gfortran ICE on invalid program

--- Comment #5 from sgk at troutmask dot apl dot washington dot edu 2009-04-26 03:29 --- Subject: Re: gfortran ICE on invalid program On Sat, Apr 25, 2009 at 08:47:19PM -, kargl at gcc dot gnu dot org wrote: > > > --- Comment #4 from kargl at gcc dot gnu dot org 2009-04-25

[Bug c/39903] ICE in tmpdir-gcc.dg-struct-layout-1/t026 c_compat_(x,y)_tst.o compile at -m64

--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-04-26 01:35 --- I forgot to add that the compiler is built as... Using built-in specs. Target: x86_64-apple-darwin10 Configured with: ../gcc-4.4.0/configure --prefix=/sw --prefix=/sw/lib/gcc4.4 --mandir=/sw/share/man --in

[Bug c++/39905] static downcast through protectedly inherited base class rejected

--- Comment #2 from fang at csl dot cornell dot edu 2009-04-26 00:52 --- Subject: Re: static downcast through protectedly inherited base class rejected > --- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-26 00:42 > --- > Comment #1 in Bug 12265, explains exactly wh

[Bug c++/39905] static downcast through protectedly inherited base class rejected

--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-26 00:42 --- Comment #1 in Bug 12265, explains exactly why this code is invalid. Protected base classes are non accessible in other clases besides in derived and derived classes of derived. -- pinskia at gcc dot gnu dot org

[Bug c++/39905] New: static downcast through protectedly inherited base class rejected

The following test case was accepted in g++-4.3.x and earlier, but rejected by 4.4.0. Code is possibly invalid, can any standard-fluent experts comment? // prNEW.cc -- test case class base { protected: void foo(void) const; }; class derived : protected base { public: void bar(void) const {

[Bug middle-end/39904] Loop is completely skipped

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c++ |middle-end h

[Bug c++/39904] New: Loop is completely skipped

The following simple program produces some very unusual results in gcc 4.3.2: #include int n = 5; int main () { int m = 0; for (int i = 0; i < n; i++) { m++; m++; } printf ("m is %d.\n", m); for (int i = 0; i < m; i++) printf ("i is %d.\n", i);

[Bug c/39903] ICE in tmpdir-gcc.dg-struct-layout-1/t026 c_compat_(x,y)_tst.o compile at -m64

--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-04-25 23:40 --- Created an attachment (id=17697) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17697&action=view) assembly code generated from t026_y.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39903

[Bug c/39903] ICE in tmpdir-gcc.dg-struct-layout-1/t026 c_compat_(x,y)_tst.o compile at -m64

--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-04-25 23:39 --- Created an attachment (id=17696) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17696&action=view) preprocessed source for t026_y.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39903

[Bug c/39903] ICE in tmpdir-gcc.dg-struct-layout-1/t026 c_compat_(x,y)_tst.o compile at -m64

--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-04-25 23:38 --- Created an attachment (id=17695) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17695&action=view) assembly code generated from t026_x.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39903

[Bug c/39903] ICE in tmpdir-gcc.dg-struct-layout-1/t026 c_compat_(x,y)_tst.o compile at -m64

--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-04-25 23:38 --- Created an attachment (id=17694) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17694&action=view) preprocessed source for t026_x.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39903

[Bug c/39903] New: ICE in tmpdir-gcc.dg-struct-layout-1/t026 c_compat_(x,y)_tst.o compile at -m64

The tmpdir-gcc.dg-struct-layout-1/t026 c_compat_x_tst.o compile and tmpdir-gcc.dg-struct-layout-1/t026 c_compat_y_tst.o compile test on x86_64-apple-darwin10 produces internal compiler errors of the form... Executing on host: /sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fin

[Bug testsuite/39807] [4.3/4.4/4.5 Regression] Reporting of testsuite failures are messed up when using -j

--- Comment #11 from ebotcazou at gcc dot gnu dot org 2009-04-25 22:57 --- > Does this work too? Yes, it does, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39807

[Bug testsuite/39807] [4.3/4.4/4.5 Regression] Reporting of testsuite failures are messed up when using -j

--- Comment #10 from jakub at gcc dot gnu dot org 2009-04-25 22:47 --- Created an attachment (id=17693) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17693&action=view) gcc45-pr39807.patch Does this work too? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39807

[Bug tree-optimization/39612] [4.4/4.5 Regression] Incorrect warning issued Re variable *is* used uninitialized in this function

--- Comment #3 from rakdver at gcc dot gnu dot org 2009-04-25 22:44 --- I cannot reproduce this in 4.5; all the unnecessary loads are removed. > The fix is to avoid the load part of load-store-motion of course. I've considered this, but it seems much easier to just let the unnecessary

[Bug c/39902] New: x * 1.0DF gets wrong value

Multiplication by a decimal floating-point (DFP) value of one appears to be "optimized" away, thereby producing the wrong value. In DFP, the value one has many representations. Only one of them (1.DF) results in no change to values for multiplication; the others change the quantum exponent. /* D

[Bug c++/39901] [C++0x] Initializer list not allowed in []

--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-25 22:30 --- Jason, can you have a look? Thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added --

[Bug tree-optimization/36188] missed CCP

--- Comment #8 from steven at gcc dot gnu dot org 2009-04-25 22:24 --- Re. comment #5 -- what doesn't work very well, i.e. what massive breakage does your patch cause? Maybe you can treat static locals optimistically if they are only stored to once? -- http://gcc.gnu.org/bugzilla/s

[Bug c++/39901] New: [C++0x] Initializer list not allowed in []

fix /Users/cougar/local/gcc45 --enable-languages=c,c++ --no-create --no-recursion Thread model: posix gcc version 4.5.0 20090425 (experimental) (GCC) -- Summary: [C++0x] Initializer list not allowed in [] Product: gcc Version: 4.5.0 Status: UNCONFIR

[Bug c/39582] bad errors for some uses of [*] arrays

--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-04-25 21:21 --- Fixed for 4.5. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW

[Bug c/39582] bad errors for some uses of [*] arrays

--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-04-25 21:19 --- Subject: Bug 39582 Author: jsm28 Date: Sat Apr 25 21:19:09 2009 New Revision: 146787 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146787 Log: PR c/39582 * c-typeck.c (c_expr_sizeof_type): Cre

[Bug fortran/39893] gfortran ICE on invalid program

--- Comment #4 from kargl at gcc dot gnu dot org 2009-04-25 20:47 --- I have a patch. -- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unas

[Bug testsuite/39807] [4.3/4.4/4.5 Regression] Reporting of testsuite failures are messed up when using -j

--- Comment #9 from ebotcazou at gcc dot gnu dot org 2009-04-25 20:27 --- > Anyway, can you try > sed -i -e 's,/==,/.=,' contrib/dg-extract-results.sh > or > sed -i -e 's,/==,/[=]=,' contrib/dg-extract-results.sh > or > sed -i -e 's,/==,/^.*==,' contrib/dg-extract-results.sh > ? I gues

[Bug target/39897] [4.5 Regression] Revision 146761 caused libgomp.fortran/omp_atomic1.f90

--- Comment #2 from uros at gcc dot gnu dot org 2009-04-25 20:11 --- Subject: Bug 39897 Author: uros Date: Sat Apr 25 20:11:01 2009 New Revision: 146784 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146784 Log: PR target/39897 * config/i386/i386.c (print_operand

[Bug testsuite/39807] [4.3/4.4/4.5 Regression] Reporting of testsuite failures are messed up when using -j

--- Comment #8 from jakub at gcc dot gnu dot org 2009-04-25 19:22 --- Very useful awk implementation. Not. Anyway, can you try sed -i -e 's,/==,/.=,' contrib/dg-extract-results.sh or sed -i -e 's,/==,/[=]=,' contrib/dg-extract-results.sh or sed -i -e 's,/==,/^.*==,' contrib/dg-extract-r

[Bug libstdc++/24196] Using string instances to pass arguments to dlls fails

--- Comment #19 from paolo dot carlini at oracle dot com 2009-04-25 19:16 --- Sorry, but at this point in history, it's unlikely that we are going to do much to the current std::string, given all the ABI implications. When we'll break the ABI, for C++1x, a completely different implement

[Bug libstdc++/24196] Using string instances to pass arguments to dlls fails

--- Comment #18 from ktietz at gcc dot gnu dot org 2009-04-25 19:10 --- (In reply to comment #16) > Ok. Hopefully, before the end of this week I can tell you something > trustworthy > about binary compatibility. > Have you found a solution for it? On w64 target 4.4 (and 4.5) the probl

[Bug testsuite/39807] [4.3/4.4/4.5 Regression] Reporting of testsuite failures are messed up when using -j

--- Comment #7 from ebotcazou at gcc dot gnu dot org 2009-04-25 19:02 --- Another nit on Solaris 9: === acats Summary === # of expected passes773 # of unexpected failures0 gmake[1]: Leaving directory `/nfs/nile/nile.build/botcazou/gcc-head/sparc-sun-

[Bug libstdc++/39882] error_code constructor and assignment postconditions not met

--- Comment #3 from paolo at gcc dot gnu dot org 2009-04-25 19:02 --- Subject: Bug 39882 Author: paolo Date: Sat Apr 25 19:02:17 2009 New Revision: 146781 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146781 Log: 2009-04-25 Paolo Carlini PR libstdc++/39880 P

[Bug libstdc++/39881] error_condition constructor and assignment postconditions not met

--- Comment #3 from paolo at gcc dot gnu dot org 2009-04-25 19:02 --- Subject: Bug 39881 Author: paolo Date: Sat Apr 25 19:02:17 2009 New Revision: 146781 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146781 Log: 2009-04-25 Paolo Carlini PR libstdc++/39880 P

[Bug libstdc++/39880] Specialisation is_error_code_enum should not exist

--- Comment #6 from paolo at gcc dot gnu dot org 2009-04-25 19:02 --- Subject: Bug 39880 Author: paolo Date: Sat Apr 25 19:02:17 2009 New Revision: 146781 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146781 Log: 2009-04-25 Paolo Carlini PR libstdc++/39880 P

[Bug libstdc++/39880] Specialisation is_error_code_enum should not exist

--- Comment #5 from paolo at gcc dot gnu dot org 2009-04-25 19:01 --- Subject: Bug 39880 Author: paolo Date: Sat Apr 25 19:00:52 2009 New Revision: 146780 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146780 Log: 2009-04-25 Paolo Carlini PR libstdc++/39880 P

[Bug libstdc++/39881] error_condition constructor and assignment postconditions not met

--- Comment #2 from paolo at gcc dot gnu dot org 2009-04-25 19:01 --- Subject: Bug 39881 Author: paolo Date: Sat Apr 25 19:00:52 2009 New Revision: 146780 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146780 Log: 2009-04-25 Paolo Carlini PR libstdc++/39880 P

[Bug libstdc++/39882] error_code constructor and assignment postconditions not met

--- Comment #2 from paolo at gcc dot gnu dot org 2009-04-25 19:01 --- Subject: Bug 39882 Author: paolo Date: Sat Apr 25 19:00:52 2009 New Revision: 146780 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146780 Log: 2009-04-25 Paolo Carlini PR libstdc++/39880 P

[Bug c/39564] variably modified function return types not always diagnosed

--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-04-25 18:56 --- Fixed for 4.5. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW

[Bug c/39564] variably modified function return types not always diagnosed

--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-04-25 18:56 --- Subject: Bug 39564 Author: jsm28 Date: Sat Apr 25 18:55:50 2009 New Revision: 146778 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146778 Log: PR c/39564 * c-decl.c (grokdeclarator): Diagnose

[Bug preprocessor/39559] constants too large for intmax_t need pedwarns

--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-04-25 18:52 --- Fixed for 4.5. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW

[Bug preprocessor/39559] constants too large for intmax_t need pedwarns

--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-04-25 18:46 --- Subject: Bug 39559 Author: jsm28 Date: Sat Apr 25 18:46:03 2009 New Revision: 146777 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146777 Log: libcpp: PR preprocessor/39559 * expr.c (cpp_inter

[Bug fortran/39879] [4.3/4.4/4.5 Regression] double free or corruption abort with gfortran

--- Comment #7 from pault at gcc dot gnu dot org 2009-04-25 18:06 --- (In reply to comment #6) With the pointer initialization, the assignment u%model = u%design is translated to: { struct tao_lattice_struct D.1667; D.1667 = *u->design; tao_lat_equal_tao_lat (u->model,

[Bug c/39900] New: ICE on nested function returning pointer to VLA

int a; void f (void) { int (*g (void))[a] { return 0; } } gets an ICE: t.c: In function 'f': t.c:5: internal compiler error: in put_pending_sizes, at stor-layout.c:108 Please submit a full bug report, with preprocessed source if appropriate. See for instructions.

[Bug fortran/39890] Link of a large application fails with spurious multiple symbol definition

--- Comment #5 from craig dot powers at gmail dot com 2009-04-25 17:23 --- (In reply to comment #4) > > Also, I omitted the link invocation: > > gfortran -O3 -o (exe_name) (big honkin' list of object files) > > Can you double check that in the "big honkin' list of object files" the fil

[Bug fortran/39896] ICE with -fwhole-file

--- Comment #4 from dominiq at lps dot ens dot fr 2009-04-25 17:20 --- This may also be related to some failures I have seen with the polyhedron tests, see: http://gcc.gnu.org/ml/fortran/2009-04/msg00031.html I particular for [ibook-dhum] lin/test% gfc -O1 -fwhole-file gas_dyn.f90 gas

[Bug fortran/39896] ICE with -fwhole-file

--- Comment #3 from dfranke at gcc dot gnu dot org 2009-04-25 17:16 --- Here's a testcase (doesn't "work" without the extra subroutine): $> cat goto.for i = 1 DO CALL inc(i) IF (i == 5) GOTO 100 END DO 100 PRINT *, "done" END SUBROUTINE

[Bug fortran/39896] ICE with -fwhole-file

--- Comment #2 from dfranke at gcc dot gnu dot org 2009-04-25 17:02 --- It may be worth noting that there are no warnings in the application about labels not being in the same block as the corresponding GOTO if compiled without -fwhole-file, but if compiled with -fwhole-file some of thes

[Bug fortran/39894] memory corruption with array section assignment of arrays with different shape

--- Comment #5 from kargl at gcc dot gnu dot org 2009-04-25 16:37 --- The Fortran 95 standard states: 7.5.1.4Intrinsic assignment conformance rules For an intrinsic assignment statement, variable and expr shall conform in shape, and if expr is an array, variable shall also be

[Bug fortran/39894] memory corruption with array section assignment of arrays with different shape

--- Comment #4 from dominiq at lps dot ens dot fr 2009-04-25 16:30 --- > But bounds checking on the other compilers I have access to doesn't show any > problem Are you sure about that? If you use bound-checking on any compiler supporting it, you should get an error (at least a warning)

[Bug target/39897] [4.5 Regression] Revision 146762 caused libgomp.fortran/omp_atomic1.f90

--- Comment #1 from dominiq at lps dot ens dot fr 2009-04-25 15:52 --- > Revision 146762 caused: You probably mean 146761: Author: uros Date: Sat Apr 25 08:10:51 2009 UTC (7 hours, 40 minutes ago) Log Message: PR target/39590 * configure.ac (HAVE_AS_IX86_FILDQ): O

[Bug libgcj/39899] New: gjdoc in 4.4.0 fails to build the libgcj documentation

gjdoc in 4.4.0 fails to build the libgcj documentation. WARNING: System.setProperty("java.class.path", "/usr/share/java/antlr.jar"); How do we pass the classpath to the VM? gjdoc \ -use \ -classpath "/usr/share/java/antlr.jar" \ -sourcepath "/scratch/packa

[Bug fortran/39894] memory corruption with array section assignment of arrays with different shape

--- Comment #3 from deji_aking at yahoo dot ca 2009-04-25 15:32 --- (In reply to comment #2) > If you compile the code in comment #1 with '-fbounds-check', you get: > > At line 32 of file pr39894.f90 > Fortran runtime error: Array bound mismatch, size mismatch for dimension 2 of > array

[Bug middle-end/39898] New: [4.5 regression] Revision 146763 caused g++.dg/tree-ssa/ehcleanup-1.C

Revision 146763: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01405.html caused: FAIL: g++.dg/tree-ssa/ehcleanup-1.C scan-tree-dump-times ehcleanup1 "Empty EH handler" 1 on x86. -- Summary: [4.5 regression] Revision 146763 caused g++.dg/tree- ssa/ehcleanup-1.C

[Bug target/39897] New: [4.5 Regression] Revision 146762 caused libgomp.fortran/omp_atomic1.f90

Revision 146762 caused: Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ /export/gnu/import/gcc/libgomp/testsuite/libgomp.fortran/omp_atomic1.f90 -B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libgomp/ -I/

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

--- Comment #12 from rguenther at suse dot de 2009-04-25 14:29 --- Subject: Re: gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3 On Sat, 25 Apr 2009, pinskia at gmail dot com wrote: > --- Comment #10 from pinskia at gmail dot com 2009

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

--- Comment #11 from rguenther at suse dot de 2009-04-25 14:28 --- Subject: Re: gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3 On Sat, 25 Apr 2009, edwintorok at gmail dot com wrote: > --- Comment #9 from edwintorok at gmail dot com

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

--- Comment #10 from pinskia at gmail dot com 2009-04-25 14:25 --- Subject: Re: gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3 On Sat, Apr 25, 2009 at 7:22 AM, edwintorok at gmail dot com wrote: > Hmm, looks like the only way ou

Re: [Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

On Sat, Apr 25, 2009 at 7:22 AM, edwintorok at gmail dot com wrote: > Hmm, looks like the only way out is for me to put #if defined(__GNUC__) && > (__GNUC__ > 4) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) and use memcpy. > Either that or add a configure rule to add -fno-strict-aliasing. GCC has b

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

--- Comment #9 from edwintorok at gmail dot com 2009-04-25 14:22 --- (In reply to comment #6) > No, not if it is inlined (and if not you can as well use memcpy). > > You can also do (GCC extension) > > union union_t { > unsigned un; > char c[4]; > }; > > unsigned bar(char *x)

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

--- Comment #8 from rguenther at suse dot de 2009-04-25 14:20 --- Subject: Re: gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3 On Sat, 25 Apr 2009, edwintorok at gmail dot com wrote: > > > > * an aggregate or union type that includes

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

--- Comment #7 from edwintorok at gmail dot com 2009-04-25 14:18 --- (In reply to comment #5) > > > "An object shall have its stored value accessed only by an lvalue > > > expression > > > that has one of the following types: > > > > > > * a type compatible with the effective type

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

--- Comment #6 from rguenther at suse dot de 2009-04-25 14:17 --- Subject: Re: gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3 On Sat, 25 Apr 2009, edwintorok at gmail dot com wrote: > --- Comment #4 from edwintorok at gmail dot com

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

--- Comment #5 from rguenther at suse dot de 2009-04-25 14:12 --- Subject: Re: gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3 On Sat, 25 Apr 2009, Richard Guenther wrote: > On Sat, 25 Apr 2009, edwintorok at gmail dot com wrote: > > >

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

--- Comment #4 from edwintorok at gmail dot com 2009-04-25 14:12 --- (In reply to comment #3) > > The above is properly optimized. Why do you think that an inline > function taking void * would fix anything? I can't know if memcpy will be inlined, it may just be a function call on cer

[Bug fortran/39896] ICE with -fwhole-file

--- Comment #1 from dominiq at lps dot ens dot fr 2009-04-25 14:10 --- Confirmed. You don't need the infinite loop to get the bus error, the following block triggers it also: 456 CONTINUE go to 500 GO TO 456 500 continue -- http://gcc.gnu.org/bugzilla/show_bug.cgi?i

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

--- Comment #3 from rguenther at suse dot de 2009-04-25 14:06 --- Subject: Re: gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3 On Sat, 25 Apr 2009, edwintorok at gmail dot com wrote: > > > --- Comment #2 from edwintorok at gmail dot

[Bug fortran/39893] gfortran ICE on invalid program

--- Comment #3 from dominiq at lps dot ens dot fr 2009-04-25 13:57 --- Reduced test case: SUBROUTINE XAUTOGET() CHARACTER*(*) DICBA DATA DICBA /"CLIP" / RETURN END The line "DATA DICBA /"CLIP" /" is needed to get the ICE. -- http://gcc.gnu.org/bugzill

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

--- Comment #2 from edwintorok at gmail dot com 2009-04-25 13:49 --- (In reply to comment #1) > Casting through a union (2) > > describes an invalid way of doing type-punning. There is also a citation from C99 on that page: "An object shall have its stored value accessed only by an lva

[Bug fortran/39893] gfortran ICE on invalid program

--- Comment #2 from dominiq at lps dot ens dot fr 2009-04-25 13:45 --- Confirmed for gfortran 4.2.3, 4.3.3, 4.4.0, and trunk: pr39893.f:13.25: CHARACTER*(*) DICBA 1 Error: Entity with assumed character length

[Bug bootstrap/39877] stage2 error in sparc.c

--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-04-25 13:39 --- 2009-04-20 Ian Lance Taylor Fix enum conversions which are invalid in C++: * auto-inc-dec.c (attempt_change): Change 0 to SET in function call. * calls.c (store_one_arg): Change 0 to EX

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-25 13:38 --- Casting through a union (2) describes an invalid way of doing type-punning. The only conforming and portable way is unsigned bar(char *x) { unsigned un; memcpy (&un, x, sizeof (un)); return un; } I ha

[Bug fortran/39894] memory corruption with array section assignment of arrays with different shape

--- Comment #2 from dominiq at lps dot ens dot fr 2009-04-25 13:38 --- If you compile the code in comment #1 with '-fbounds-check', you get: At line 32 of file pr39894.f90 Fortran runtime error: Array bound mismatch, size mismatch for dimension 2 of array 'listgeonm' (18/999) (off by o

[Bug bootstrap/39645] uninitialized variable in genattrtab.c

--- Comment #7 from ebotcazou at gcc dot gnu dot org 2009-04-25 13:36 --- This should compile now. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added

[Bug bootstrap/39645] genattrtab.c does not compile under sparc Linux

--- Comment #6 from ebotcazou at gcc dot gnu dot org 2009-04-25 13:32 --- Subject: Bug 39645 Author: ebotcazou Date: Sat Apr 25 13:32:43 2009 New Revision: 146772 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146772 Log: PR bootstrap/39645 * config/sparc/sparc.

[Bug fortran/39896] New: ICE with -fwhole-file

The code below (extracted from a large application) gives an ICE if compiled with -fwhole-file. $> cat ice.for PROGRAM xxx implicit Real*8 (a-h,o-z) PARAMETER ( NU= 512*101 + 10*101 + 2*512 ) DIMENSIONAJ(2048) DIMENSIONAIS(512), ER1(512) DIMENSI

[Bug middle-end/39887] g++ incorrectly reports type error when calling spu_promote()

--- Comment #2 from jadamcze at utas dot edu dot au 2009-04-25 13:31 --- So it was - and it was me that reported it in bug 36837. (in this case, I'm building with a Gentoo 4.3.3 compiler) As you can see (amongst the noise) in the other bug, I was able to reproduce the bug using fsf gc

[Bug target/36837] x86_64 linux-gnu gcc miscompiles spu-elf gcc (4.4)

--- Comment #11 from jadamcze at utas dot edu dot au 2009-04-25 13:31 --- *** Bug 39887 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36837

[Bug middle-end/39895] New: gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

Considering this code: void dummy(void *x); union union_t { unsigned un; char c; } __attribute__((packed)); unsigned foo() { char x[4]; dummy(x); return ((union union_t*)x)->un; } unsigned bar(char *x) { return ((union union_t*)x)->un; } With gcc-4.4 -Wstrict-aliasing=1 i

[Bug bootstrap/39645] genattrtab.c does not compile under sparc Linux

--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-04-25 13:13 --- Testing a fix. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Assigne

[Bug fortran/39894] memory corruption with array section assignment of arrays with different shape

--- Comment #1 from deji_aking at yahoo dot ca 2009-04-25 12:32 --- Created an attachment (id=17692) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17692&action=view) Test program gfortran work fine if I change the line; 'listgeonm(1,:) = geonm(:,1)' to 'listgeonm(1,:) = geonm(1:p

[Bug objc/35165] Massive failures of objc on i686-apple-darwin9

--- Comment #5 from developer at sandoe-acoustics dot co dot uk 2009-04-25 12:32 --- AFAICT there are a number of factors causing this and darwin8 is also affected. A (certainly non-comprehensive) list of issues: Darwin 8 (OSX 10.4.11) (Objc) There is no 64 bit NeXT runtime. (Obj-c++

[Bug fortran/39894] New: memory corruption with array section assignment of arrays with different shape

The attached program produce memory corruption at runtime because of an expression between 2 arrays of different shape using array section. I'm not sure if it is standard conforming or not, so I'm reporting it as a bug; the program executes OK with pgf90 and ifort (on Linux) and xlf90 (on AIX). -

[Bug c/39892] -fno-function-cse not working

--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-25 12:22 --- MOUSE.function.print_field is not a constant function. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --

[Bug fortran/39893] gfortran ICE on invalid program

--- Comment #1 from deji_aking at yahoo dot ca 2009-04-25 12:16 --- Created an attachment (id=17691) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17691&action=view) invalid program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39893

[Bug fortran/39893] New: gfortran ICE on invalid program

The attached program produce an internal compiler error when compiled with gfortran-4.4.0. -- Summary: gfortran ICE on invalid program Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component

[Bug c/39892] New: -fno-function-cse not working

The function MOUSE.function.print_field() is not always called directly but its pointer is copied in a register and a call to the content of the register is done. The register is not reused at all. Causes problems with an assembler post-processor. $ /home/etienne/projet/toolchain/bin/gcc -v Using

[Bug fortran/39890] Link of a large application fails with spurious multiple symbol definition

--- Comment #4 from burnus at gcc dot gnu dot org 2009-04-25 11:18 --- > Also, I omitted the link invocation: > gfortran -O3 -o (exe_name) (big honkin' list of object files) Can you double check that in the "big honkin' list of object files" the file "nucleation.o" is listed only once?

[Bug libstdc++/39882] error_code constructor and assignment postconditions not met

--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-25 11:14 --- On it. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedT

[Bug libstdc++/39881] error_condition constructor and assignment postconditions not met

--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-25 11:14 --- On it. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedT

[Bug middle-end/39891] Bogus location given for warning, no warning at real location: dereferencing pointer �� does break strict-aliasing rules

--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-25 11:13 --- The location is also "correct" in the sense that we try to warn with the location of the _dereference_. And that is indeed in APSInt& APSInt::operator=(const APSInt&): (void) (((struct APSInt *) this)->D.1723 = *(

[Bug libstdc++/39880] Specialisation is_error_code_enum should not exist

--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-25 11:13 --- Ok, then it's easy. -- paolo dot carlini at oracle dot com changed: What|Removed |Added

[Bug libstdc++/39880] Specialisation is_error_code_enum should not exist

--- Comment #3 from chris_kohlhoff at internet-mail dot org 2009-04-25 11:03 --- It's the intended behaviour that the conversion constructor and assignment operator be disabled. That is, the std::errc type should not be implicitly convertible to error_code, only to error_condition. If

[Bug middle-end/39891] Bogus location given for warning, no warning at real location: dereferencing pointer �� does break strict-aliasing rules

--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-25 10:41 --- Thanks for the short testcase. I'll try to improve the location information. The compiler at the point of the warning sees D.1756_5 = (struct APSInt &) &Val.Data; AdditionalOffset.D.1723 = D.1756_5->D.1723; a

[Bug libstdc++/39880] Specialisation is_error_code_enum should not exist

--- Comment #2 from paolo dot carlini at oracle dot com 2009-04-25 09:52 --- If we do this, I don't see how the error_code constructor and assignment operator taking an ErrorCodeEnum can be made to work, that this how they can actually accept a std::errc (I'm referring to n2723 and n279

[Bug middle-end/39891] Bogus location given for warning, no warning at real location: dereferencing pointer �� does break strict-aliasing rules

--- Comment #1 from edwintorok at gmail dot com 2009-04-25 09:39 --- Created an attachment (id=17690) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17690&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39891

[Bug middle-end/39891] New: Bogus location given for warning, no warning at real location: dereferencing pointer �� does break strict-aliasing rules

Compile attached testcase using: $ g++-4.4 -c -O1 -fstrict-aliasing -Wstrict-aliasing foo.i foo.i: In function ‘bool foo()’: foo.i:8: warning: dereferencing pointer ‘’ does break strict-aliasing rules foo.i:26: note: initialized from here Line 8 has this: 7: APSInt &operator=(const APSInt &RHS

[Bug middle-end/39887] g++ incorrectly reports type error when calling spu_promote()

--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-25 09:27 --- What compiler is running on x86-64? The last time I looked into a bug like this, it was a bug in the native compiler. -- pinskia at gcc dot gnu dot org changed: What|Removed |

[Bug libstdc++/39880] Specialisation is_error_code_enum should not exist

--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-25 09:13 --- Agreed. This is going to change a lot with concepts, of course, but in the old n2521 for instance the specialization doesn't exist indeed. -- paolo dot carlini at oracle dot com changed: What

[Bug inline-asm/39590] inline asm %z on amd64 says "ll" instead of "q"

--- Comment #13 from ubizjak at gmail dot com 2009-04-25 08:23 --- Fixed for 4.5.0. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRME

[Bug fortran/39688] IMPORT of derived type fails

--- Comment #4 from janus at gcc dot gnu dot org 2009-04-25 08:13 --- Fixed in r146762. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/39688] IMPORT of derived type fails

--- Comment #3 from janus at gcc dot gnu dot org 2009-04-25 08:12 --- Subject: Bug 39688 Author: janus Date: Sat Apr 25 08:11:48 2009 New Revision: 146762 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146762 Log: 2009-04-25 Janus Weil PR fortran/39688 * decl

[Bug inline-asm/39590] inline asm %z on amd64 says "ll" instead of "q"

--- Comment #12 from uros at gcc dot gnu dot org 2009-04-25 08:11 --- Subject: Bug 39590 Author: uros Date: Sat Apr 25 08:10:51 2009 New Revision: 146761 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146761 Log: PR target/39590 * configure.ac (HAVE_AS_IX86_FILDQ