[Bug target/39678] complex type isn't passed correctly

--- Comment #28 from rguenther at suse dot de 2009-04-09 07:58 --- Subject: Re: C++ empty struct is passed incorrectly On Wed, 8 Apr 2009, hjl dot tools at gmail dot com wrote: > --- Comment #23 from hjl dot tools at gmail dot com 2009-04-08 23:41 > --- > This looks like an

[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada

--- Comment #24 from ebotcazou at gcc dot gnu dot org 2009-04-09 08:07 --- > Would that be what "we" refer to as "hpux-ia64" ? No, IA-64 and PA-RISC are different things. > "GNAT Pro is the natural Ada solution for HP’s Alpha server and Integrity > server (I64) platforms" or is "gcc's

[Bug fortran/39692] New: f95: conflict between EXTERNAL and PROCEDURE

In the Fortran95 standard, section 5.1, one finds: Constraint: If the POINTER attribute is specified, the TARGET, INTENT, EXTERNAL, or INTRINSIC attribute shall not be specified. Thus, the following should be rejected with -std=f95: external f pointer f And consequently also something like th

[Bug fortran/39692] f95: conflict between EXTERNAL and POINTER

--- Comment #1 from dominiq at lps dot ens dot fr 2009-04-09 08:39 --- After removing the comment in the line ! f => sin I get on powerpc-apple-darwin9, revision 145779: [karma] f90/bug% gfc pr39692.f90 pr39692.f90:3.11: external f 1 Error: EXTERNAL attribute conflicts w

[Bug c/39693] New: Warning about uninitialized local variable use

Hi, there are lots of bugs concerning the issue that uninitialized local variable uses are not always reported. See 10539 or 19099. I think the restriction to optimized builds is particularly unfortunate, since a dev is more likely to actually look at a debug build. I'm not everybody, but assumin

[Bug target/32431] [4.3/4.4/4.5 Regression][m68hc11] ICE in df_refs_verify, at df-scan.c:4066

--- Comment #11 from bonzini at gnu dot org 2009-04-09 10:34 --- *** Bug 35655 has been marked as a duplicate of this bug. *** -- bonzini at gnu dot org changed: What|Removed |Added --

[Bug target/35655] [m68hc11] Segmentation fault when compiling libgcc2.c

--- Comment #3 from bonzini at gnu dot org 2009-04-09 10:34 --- *** This bug has been marked as a duplicate of 32431 *** -- bonzini at gnu dot org changed: What|Removed |Added --

[Bug other/6588] throw() takes 20,000 cycles : is it expected ?

--- Comment #9 from sylvain dot pion at sophia dot inria dot fr 2009-04-09 10:06 --- There seems to have been some progress : it now takes 6000-9000 cycles instead of 2. This is 6000 with g++ 4.3.1 on a Fedora 10 x86_64 box, and 9000 on a MacBook Pro with various g++ versions up to

[Bug target/14202] [arm] Thumb __builtin_setjmp not interworking safe

--- Comment #12 from ramana at gcc dot gnu dot org 2009-04-09 11:31 --- For the record here's some more info on the problem. One part of the problem is as described in comment #1 about labels having the right bit and the correct instruction being generated which I've achieved by a met

[Bug target/39694] New: -print-file-name doesn't work on mingw in 100%.

on mingw target i can't get libgcc_s.a path. the path to libgcc.a is returned correctly: $ i686-pc-mingw32-gcc -print-file-name=libgcc.a /local/devel/toolchain44/i686-pc-mingw32.host64/lib/gcc/i686-pc-mingw32/4.4.0/libgcc.a but the libgcc_s.a case doesn't work. it returns: $ i686-pc-mingw32-gcc

[Bug c/39693] Warning about uninitialized local variable use

--- Comment #1 from manu at gcc dot gnu dot org 2009-04-09 12:08 --- The bugs you mention are fixed. In GCC 4.4, some uninitialized uses are reported even at -O0. If you have specific testcases not covered by any PR linked in bug 24639, then open a new PR and attach the preprocessed tes

[Bug target/17551] m68hc11: ICE: unrecognizable insn

--- Comment #4 from bonzini at gnu dot org 2009-04-09 10:36 --- seems to be fixed on trunk. -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSI

[Bug fortran/36704] Procedure pointer as function result

--- Comment #8 from janus at gcc dot gnu dot org 2009-04-09 09:41 --- Fixed by r145815. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/36704] Procedure pointer as function result

--- Comment #7 from janus at gcc dot gnu dot org 2009-04-09 09:39 --- Subject: Bug 36704 Author: janus Date: Thu Apr 9 09:39:09 2009 New Revision: 145815 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145815 Log: 2009-04-09 Janus Weil PR fortran/36704 * decl

[Bug middle-end/39685] ICE: in copyprop_hardreg_forward_1, at regrename.c:1603

--- Comment #3 from MR dot Swami dot Reddy at nsc dot com 2009-04-09 11:00 --- This issue is not reproduced with gcc-4.3.3 sources (ie released sources). Only obsereved with gcc-4.5.0 trunk sources. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39685

[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

--- Comment #16 from bonzini at gnu dot org 2009-04-09 11:00 --- On i686 to spu cross, for -O2 45 minutes were not enough. -- bonzini at gnu dot org changed: What|Removed |Added --

[Bug fortran/39695] New: ProcPtr function results: wrong name in error message

For procedure pointer results without an explicit RESULT statement, error messages may contain the wrong name (since a hidden result variable named 'ppr@' is added). Examples: function f() pointer :: f interface integer function f(x) bind(c) ! "may not be a C interoperable kind" i

[Bug middle-end/39696] New: gcc.dg/tree-ssa/ssa-ccp-25.c scan-tree-dump doesn't work on Linux/ia32

On Linux/ia32, I got FAIL: gcc.dg/tree-ssa/ssa-ccp-25.c scan-tree-dump ccp1 "&a\[D\." FAIL: gcc.dg/tree-ssa/ssa-ccp-25.c scan-tree-dump forwprop1 "= a\[D\." -- Summary: gcc.dg/tree-ssa/ssa-ccp-25.c scan-tree-dump doesn't work on Linux/ia32 Product: gcc

[Bug c/39693] Warning about uninitialized local variable use

--- Comment #2 from simon dot thum at gmx dot de 2009-04-09 13:11 --- Sorry for the noise; I didn't check the developer docs (just latest release)... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39693

[Bug c/39693] Warning about uninitialized local variable use

--- Comment #3 from simon dot thum at gmx dot de 2009-04-09 13:15 --- BTW in developer docs, -Wextra still mentions -Wuninitialized; it seems to me this is not intentional. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39693

[Bug c++/39691] union warnings using -Weffc++ flag

--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-09 13:24 --- Confirmed. [-Weffc++ is basically unmaintained though] -- rguenth at gcc dot gnu dot org changed: What|Removed |Added -

[Bug c/39693] Warning about uninitialized local variable use

--- Comment #4 from manu at gcc dot gnu dot org 2009-04-09 13:25 --- (In reply to comment #3) > BTW in developer docs, -Wextra still mentions -Wuninitialized; it seems to me > this is not intentional. > Both -Wall and -Wextra enable Wuninitialized. I guess this is historical. Please,

[Bug middle-end/39696] gcc.dg/tree-ssa/ssa-ccp-25.c scan-tree-dump doesn't work on Linux/ia32

--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-09 13:32 --- Interesting. On 64bit we gimplify to p = &a[0]; D.1596 = (long unsigned int) i; D.1597 = D.1596 * 4; D.1598 = p + D.1597; while on 32bit we get p = &a[0]; i.0 = (unsigned int) i; D.1253 = i.0 * 4;

[Bug testsuite/39696] gcc.dg/tree-ssa/ssa-ccp-25.c scan-tree-dump doesn't work on Linux/ia32

--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-09 13:37 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug middle-end/39696] gcc.dg/tree-ssa/ssa-ccp-25.c scan-tree-dump doesn't work on Linux/ia32

--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-09 13:37 --- Subject: Bug 39696 Author: rguenth Date: Thu Apr 9 13:36:57 2009 New Revision: 145839 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145839 Log: 2009-04-09 Richard Guenther PR testsuite/39696

[Bug c/39697] New: internal compiler error

147] uname -a FreeBSD fbsd.lokal.biz 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Mon Aug 4 14:54:03 CEST 2008 r...@fbsd.lokal.biz:/usr/src/sys/i386/compile/BSD70EV i386 148] 148] gcc -v Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model

[Bug c++/25185] deep typedef substitution in error message

--- Comment #31 from dave at boost-consulting dot com 2009-04-09 13:58 --- OK, I don't get what it's controlling then, but maybe that's not important. Still, I suggest you choose a more specific name to leave the door open for "prettier" template printing in the future. If you did int

[Bug target/39678] complex type isn't passed correctly

--- Comment #29 from hjl dot tools at gmail dot com 2009-04-09 14:17 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00700.html -- hjl dot tools at gmail dot com changed: What|Removed |Added -

[Bug tree-optimization/39698] New: wrong types for vectorized reduction

On x86_64 for gcc.dg/vect/pr34591.c I see with type checking enabled /space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/vect/pr34591.c:3: error: Incompatible types in PHI argument 1 vector int vector short int vect_var_.49_81 = PHI which is because vect_var_.49_81 is V4SI, not V8HI as the vec

[Bug c++/39639] no diagnostic for ill-formed pack expansion

--- Comment #1 from dodji at gcc dot gnu dot org 2009-04-09 14:59 --- Confirmed in trunk. -- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|

[Bug libfortran/39665] [4.5 Regression] Fortran IO using unaligned accesses to read/write doubles.

--- Comment #9 from sje at cup dot hp dot com 2009-04-09 14:59 --- The proposed patch fixed my failures on IA64-hp-hpux11.23. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39665

[Bug target/39678] complex type isn't passed correctly

--- Comment #30 from diepen at astron dot nl 2009-04-09 15:08 --- I'm glad that the time I invested in writing the rather extensive test program for the casacore ArrayMath pays off, although I had not expected to find this problem. Luckily it was not too hard to write a workaround in my

[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada

--- Comment #25 from rob1weld at aol dot com 2009-04-09 15:16 --- That is good news, (that "hppa2.0w-hp-hpux11.11" ("PA-RISC 2.0."), which we claim is supported, is not the same/similar to "hpux-ia64", which has two "ZCX = False" entries). We don't want to break that. Nice machine. Is

[Bug c/39697] internal compiler error

--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-09 15:24 --- Fixed in 4.2.2. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|

[Bug target/39678] complex type isn't passed correctly

-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678

[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada

--- Comment #26 from charlet at gcc dot gnu dot org 2009-04-09 15:40 --- << Is the (small amount of ?) code in "Gnat Pro" going to be available (someday) for "gcc Ada". That may fix these problems. >> There's still confusion I'm afraid. GCC Ada is just an Ada compiler. GNAT Pro is a c

[Bug c++/10039] [macosx] gcc hangs at a c++-Constructor with switch "-Os"

--- Comment #6 from hjl at gcc dot gnu dot org 2009-04-09 15:44 --- Subject: Bug 10039 Author: hjl Date: Thu Apr 9 15:44:05 2009 New Revision: 145842 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145842 Log: 2009-04-09 H.J. Lu PR gas/10039 * configure.ac: R

[Bug target/39678] complex type isn't passed correctly

--- Comment #31 from rguenth at gcc dot gnu dot org 2009-04-09 15:46 --- Non-regressions should not have a target milestone until they are fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --

[Bug fortran/30146] Redefining do-variable in excecution cycle

--- Comment #5 from dfranke at gcc dot gnu dot org 2009-04-09 16:03 --- (In reply to comment #4) > This of cause fails if you change i. As the program is invalid and as I don't > see any possibility to fix this in gfortran, I regard the problem of comment 3 > as INVALID/WONTFIX. In the

[Bug c++/39480] generated memcpy causes trouble in assignment

--- Comment #25 from jason at gcc dot gnu dot org 2009-04-09 16:05 --- The C++ front end bit of this needs 22488 to be fixed before we can remove the explicit call to the builtin and go back to using a MODIFY_EXPR. But in the meantime we can test for pointer equality before the call.

[Bug c++/39699] New: No error reporting when function and variable have the same name

Hello, no error reporting when function and variable have the same name in class. Please do this check and show this error. -- Summary: No error reporting when function and variable have the same name Product: gcc Version: 4.3.4 St

[Bug libobjc/36610] objc_msg_sendv is broken for targets which pass argument via registers

--- Comment #14 from janis at gcc dot gnu dot org 2009-04-09 17:01 --- Subject: Bug 36610 Author: janis Date: Thu Apr 9 17:00:57 2009 New Revision: 145850 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145850 Log: PR libobjc/36610 * objc/execute/forward-1.x: New

[Bug fortran/39700] New: miscompilation with -fwhole-file

The testcase of PR30668 is miscompiled with -fwhole-file: $> gfortran-svn -Wall -W pr30668.f90 && ./a.out 2.000 4 $> gfortran-svn -Wall -W pr30668.f90 -fwhole-file && ./a.out 0.000 4 Expected output for the latter: 2.000...8 The dump

[Bug fortran/39700] miscompilation with -fwhole-file

--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-09 17:15 --- Actually this code is invalid as explained by that PR :). So just marking this as a dup of bug 30668. The whole issue is that the front-end should be rejecting the code before it gets to the middle-end. *** This b

[Bug fortran/30668] catch function of wrong type

--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-09 17:15 --- *** Bug 39700 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug libobjc/36610] objc_msg_sendv is broken for targets which pass argument via registers

--- Comment #13 from janis at gcc dot gnu dot org 2009-04-09 16:58 --- Subject: Bug 36610 Author: janis Date: Thu Apr 9 16:58:34 2009 New Revision: 145849 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145849 Log: PR libobjc/36610 * objc/execute/forward-1.x: New

[Bug fortran/39700] miscompilation with -fwhole-file

--- Comment #2 from dfranke at gcc dot gnu dot org 2009-04-09 17:34 --- OMG! I was so puzzled with the results, I didn't read to the end of the original PR :( However, if the function TWO is declared INTEGER, the outcome is even worse, even if -Wconversion is specified. So, there defini

[Bug libfortran/39665] [4.5 Regression] Fortran IO using unaligned accesses to read/write doubles.

--- Comment #10 from jb at gcc dot gnu dot org 2009-04-09 17:44 --- Subject: Bug 39665 Author: jb Date: Thu Apr 9 17:44:23 2009 New Revision: 145852 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145852 Log: 2009-04-09 Janne Blomqvist PR fortran/39665 * io/i

[Bug middle-end/39701] New: [4.5 Regression] Many test failures

On Linux/ia32, revision 145849 gives: FAIL: g++.dg/tree-ssa/pr31146-2.C scan-tree-dump forwprop1 "Replaced .* != 0B. with .1" FAIL: gcc.dg/pr36901-1.c (test for excess errors) FAIL: gcc.dg/pr36901-2.c (test for excess errors) FAIL: gcc.dg/pr36901-3.c (test for excess errors) FAIL: gcc.dg/pr36901-4

[Bug c++/13389] sizeof in template:unimplemented: call_expr cannot be mangled due to a defect in the C++ ABI

--- Comment #6 from jason at gcc dot gnu dot org 2009-04-09 20:29 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug c++/14912] Do not print default template arguments in error messages

--- Comment #51 from jason at gcc dot gnu dot org 2009-04-09 20:30 --- Patch applied for 4.5. -- jason at gcc dot gnu dot org changed: What|Removed |Added Sta

[Bug libfortran/39702] New: [4.5 Regression] Unaligned access in Fortran testcases

On Linux/ia64, revision 145853 gave default_format_(9000): unaligned access to 0x6fff8338, ip=0x201cc370 default_format_(9000): unaligned access to 0x6fff8338, ip=0x201cc370 default_format_(9000): unaligned access to 0x6fff8338, ip=0x201cc370 default

[Bug libfortran/39702] [4.5 Regression] Revision 145852 caused unaligned access in Fortran testcases

--- Comment #1 from hjl dot tools at gmail dot com 2009-04-09 20:58 --- It is caused by revision 145852: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00476.html -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

[Bug libfortran/39702] [4.5 Regression] Unaligned access in Fortran testcases

--- Comment #2 from hjl dot tools at gmail dot com 2009-04-09 21:00 --- I took it back. The unaligned access started on Apr. 5 and revision 145852 doesn't fix them. -- hjl dot tools at gmail dot com changed: What|Removed |Added

[Bug objc/29200] %s substituted with "methods"/"selectors" can't be properly translated

--- Comment #3 from ayers at gcc dot gnu dot org 2009-04-09 21:08 --- Subject: Bug 29200 Author: ayers Date: Thu Apr 9 21:08:18 2009 New Revision: 145857 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145857 Log: gcc/ 2009-04-09 David Ayers PR objc/29200 * o

[Bug libfortran/39702] [4.5 Regression] Unaligned access in Fortran testcases

--- Comment #3 from jb at gcc dot gnu dot org 2009-04-09 21:14 --- HJ, can you check if the patch at http://gcc.gnu.org/ml/fortran/2009-04/msg00103.html fixes your problems? It is the alternative way of solving the problem that IMHO was not as clean as r145852, but if that one doesn't

[Bug objc/29200] %s substituted with "methods"/"selectors" can't be properly translated

--- Comment #4 from ayers at gcc dot gnu dot org 2009-04-09 21:15 --- Fixed in 4.5. -- ayers at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGN

[Bug c++/39699] No error reporting when function and variable have the same name

--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-09 21:17 --- We need a testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39699

[Bug c/39613] gcc 20090331 produces an error at mce64.c in kernel 2.6.29

--- Comment #11 from hjl at gcc dot gnu dot org 2009-04-09 21:19 --- Subject: Bug 39613 Author: hjl Date: Thu Apr 9 21:19:29 2009 New Revision: 145858 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145858 Log: 2009-04-09 H.J. Lu Backport from mainline: 2009-

[Bug middle-end/39614] [4.5 regression] Internal error compiling CSiBE

--- Comment #7 from hjl at gcc dot gnu dot org 2009-04-09 21:19 --- Subject: Bug 39614 Author: hjl Date: Thu Apr 9 21:19:29 2009 New Revision: 145858 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145858 Log: 2009-04-09 H.J. Lu Backport from mainline: 2009-0

[Bug middle-end/39673] [4.5 regression] internal compiler error: in fold_binary, at fold-const.c:9642

--- Comment #8 from hjl at gcc dot gnu dot org 2009-04-09 21:19 --- Subject: Bug 39673 Author: hjl Date: Thu Apr 9 21:19:29 2009 New Revision: 145858 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145858 Log: 2009-04-09 H.J. Lu Backport from mainline: 2009-0

[Bug libfortran/39702] [4.5 Regression] Unaligned access in Fortran testcases

--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-04-09 21:25 --- Did the 145852 fix Steve's original problems or are they the same as HJ reports here? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39702

[Bug target/36800] va_arg for _Decimal128 on 32-bit Power mishandled in certain cases

--- Comment #2 from bje at gcc dot gnu dot org 2009-04-09 21:26 --- Subject: Bug 36800 Author: bje Date: Thu Apr 9 21:26:44 2009 New Revision: 145859 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145859 Log: PR target/36800 PR target/36800 * config/rs6000/rs60

[Bug debug/39703] New: GCC produces single locations instead of location lists for some formal parameters

In generating DWARF debugging information, GCC produces a single location for some formal parameters instead of a location list. This location is not valid until the function prologue copies the parameter from the location where it exists at function entry into the assigned location. A debugger wou

[Bug target/36800] va_arg for _Decimal128 on 32-bit Power mishandled in certain cases

--- Comment #3 from bje at gcc dot gnu dot org 2009-04-09 21:29 --- Should this be backported to 4.4?g -- bje at gcc dot gnu dot org changed: What|Removed |Added

[Bug debug/39703] GCC produces single locations instead of location lists for some formal parameters

--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-09 21:33 --- IIRC at -O0, variable tracking is not enabled so it only produces single locations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39703

[Bug bootstrap/39704] New: [4.5 Regression] Revision 145841 breaks bootstrap on powerpc-apple-darwin9

Revision 145841 breaks bootstrap on powerpc-apple-darwin9: /opt/gcc/darwin_buildw/./gcc/xgcc -B/opt/gcc/darwin_buildw/./gcc/ -B/opt/gcc/gcc4.5w/powerpc-apple-darwin9/bin/ -B/opt/gcc/gcc4.5w/powerpc-apple-darwin9/lib/ -isystem /opt/gcc/gcc4.5w/powerpc-apple-darwin9/include -isystem /opt/gcc/gcc4.5w

[Bug bootstrap/39704] [4.5 Regression] Revision 145841 breaks bootstrap on powerpc-apple-darwin9

--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-09 21:48 --- Simple typo: * . */ */ Just either remove "*/" and it will work. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug bootstrap/39704] [4.5 Regression] Revision 145841 breaks bootstrap on powerpc-apple-darwin9

--- Comment #2 from dominiq at lps dot ens dot fr 2009-04-09 22:00 --- Subject: Re: [4.5 Regression] Revision 145841 breaks bootstrap on powerpc-apple-darwin9 > Just either remove "*/" and it will work. Thanks. This is exactly what I am trying. However someone will have to fix it in

[Bug bootstrap/39704] [4.5 Regression] Revision 145841 breaks bootstrap on powerpc-apple-darwin9

--- Comment #3 from dominiq at lps dot ens dot fr 2009-04-09 22:21 --- The following patch fixes this pr: --- ../_gcc_clean/gcc/config/rs6000/darwin-vecsave.asm 2009-04-09 18:06:26.0 +0200 +++ ../gcc-4.5-work/gcc/config/rs6000/darwin-vecsave.asm2009-04-09 23:47:51.0

[Bug middle-end/39701] [4.5 Regression] Revision 145846 caused many test failures

--- Comment #1 from hjl dot tools at gmail dot com 2009-04-09 22:50 --- Revision 145846: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00470.html is the cause. I got /export/gnu/import/rrs/145846/src/gcc/testsuite/gfortran.dg/alloc_comp_basics_2.f90:7: internal compiler error: verify_gimpl

[Bug target/39678] complex type isn't passed correctly

--- Comment #32 from hjl at gcc dot gnu dot org 2009-04-09 22:59 --- Subject: Bug 39678 Author: hjl Date: Thu Apr 9 22:58:51 2009 New Revision: 145865 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145865 Log: gcc/ 2009-04-09 H.J. Lu PR target/39678 * confi

[Bug libstdc++/39629] [4.5 Regression] Revision 145483 caused many libstdc++ failures

--- Comment #15 from paolo at gcc dot gnu dot org 2009-04-09 23:37 --- Subject: Bug 39629 Author: paolo Date: Thu Apr 9 23:37:08 2009 New Revision: 145867 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145867 Log: 2009-04-09 Paolo Carlini PR libstdc++/39629 (final b

[Bug debug/39705] New: enum constants don't appear in debug_pubnames

enum constants don't appear in .debug_pubnames. It seems like perhaps they should, because they are global (in a sense). -- Summary: enum constants don't appear in debug_pubnames Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: norm

[Bug libstdc++/39629] [4.5 Regression] Revision 145483 caused many libstdc++ failures

--- Comment #16 from paolo dot carlini at oracle dot com 2009-04-09 23:47 --- Fixed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Stat

[Bug debug/39706] New: namespaces represented incorrectly in debug_pubnames

Compile this with -g: namespace x { int x; } class y { public: static int x; }; int y::x; int main() { return x::x; } Now examine the debug_pubnames section with readelf. I see: 70 main 119 x 130 y::x However, I expected "x::x"; "y::

[Bug debug/39707] New: gcc does not emit debug_pubtypes

gcc does not emit debug_pubtypes, except on Darwin. It seems like it ought to do this unconditionally, given that it is part of dwarf. -- Summary: gcc does not emit debug_pubtypes Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: nor

[Bug debug/39708] New: add a debug_privnames section

In response to a request like "break function", gdb will currently search all objfiles for "function" -- and the request will succeed even if "function" is private. This means that gdb cannot start using the debug_pubnames index without also exhibiting different behavior. So, it might be nice to

[Bug libfortran/39702] [4.5 Regression] Unaligned access in Fortran testcases

--- Comment #5 from hjl dot tools at gmail dot com 2009-04-09 23:59 --- (In reply to comment #3) > HJ, > > can you check if the patch at > > http://gcc.gnu.org/ml/fortran/2009-04/msg00103.html > > fixes your problems? It is the alternative way of solving the problem that This patch

[Bug testsuite/35621] gcc.target/i386/ssse3-*.c violates C/C++ aliasing rules

--- Comment #16 from hjl at gcc dot gnu dot org 2009-04-10 00:31 --- Subject: Bug 35621 Author: hjl Date: Fri Apr 10 00:30:50 2009 New Revision: 145871 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145871 Log: 2009-04-09 H.J. Lu PR testsuite/35621 * gcc.targ

[Bug testsuite/35621] gcc.target/i386/ssse3-*.c violates C/C++ aliasing rules

--- Comment #17 from hjl at gcc dot gnu dot org 2009-04-10 00:32 --- Subject: Bug 35621 Author: hjl Date: Fri Apr 10 00:32:12 2009 New Revision: 145872 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145872 Log: 2009-04-09 H.J. Lu PR testsuite/35621 * gcc.targ

[Bug libfortran/39709] New: [4.5 Regression] Revision 145852 breaks libgfortran

On Linux/x86-64, revision 145852: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00476.html gave At line 13 of file /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/f2003_io_1.f03 (unit = 10, file = 'mydata') Fortran runtime error: Bad DECIMAL parameter in data transfer statement FAIL: gfo

[Bug testsuite/39710] New: gcc.misc-tests/help.exp doesn't work when configured with --enable-checking=assert

opts.c has /* What to print when a switch has no documentation. */ #ifdef ENABLE_CHECKING static const char undocumented_msg[] = N_("This switch lacks documentation"); #else static const char undocumented_msg[] = ""; #endif When gcc is configured with --enable-checking=assert, "gcc --help=undocu

[Bug libfortran/39709] [4.5 Regression] Revision 145852 breaks libgfortran

--- Comment #1 from jvdelisle at gcc dot gnu dot org 2009-04-10 01:49 --- This issue is still being worked on 39702, no need for new bug report *** This bug has been marked as a duplicate of 39702 *** -- jvdelisle at gcc dot gnu dot org changed: What|Removed

[Bug libfortran/39702] [4.5 Regression] Unaligned access in Fortran testcases

--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-04-10 01:49 --- *** Bug 39709 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39702

[Bug c++/39699] No error reporting when function and variable have the same name

--- Comment #2 from alpha dot super-one at laposte dot net 2009-04-10 04:47 --- class toto { enum e {a,b}; e test_example(); e test_example; }; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39699

[Bug c/39671] solaris 10 with gcc 3.4.3

--- Comment #8 from abhinav dot dubey at hcl dot in 2009-04-10 05:29 --- I changed the compiler and its works.. thanks a lot for your advice -- abhinav dot dubey at hcl dot in changed: What|Removed |Added --

[Bug testsuite/39710] gcc.misc-tests/help.exp doesn't work when configured with --enable-checking=assert

-- rwild at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rwild at gcc dot gnu dot org |dot org

[Bug c++/39711] New: fail to use template template parameter with default values

$g++ -v -save-temps test1.cpp Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.3-7' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch

[Bug c++/39711] fail to use template template parameter with default values

--- Comment #1 from urykhy at gmail dot com 2009-04-10 06:11 --- Created an attachment (id=17610) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17610&action=view) source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39711

[Bug c++/39711] fail to use template template parameter with default values

--- Comment #2 from urykhy at gmail dot com 2009-04-10 06:12 --- Created an attachment (id=17611) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17611&action=view) preprocessed code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39711

[Bug testsuite/39710] gcc.misc-tests/help.exp doesn't work when configured with --enable-checking=assert

--- Comment #1 from rwild at gcc dot gnu dot org 2009-04-10 06:12 --- patch at -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39710

[Bug c++/39711] fail to use template template parameter with default values

--- Comment #3 from urykhy at gmail dot com 2009-04-10 06:15 --- please, let me know if you need more information. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39711

[Bug middle-end/39701] [4.5 Regression] Revision 145846 caused many test failures

--- Comment #2 from bonzini at gnu dot org 2009-04-10 06:42 --- The Fortran problem is a real bug in the front-end that was masked by folding. The problem is that we're folding less than without my patch. I'll prepare a patch to both fix the Fortran problem and reestablish the folding.

[Bug c/39712] New: type mismatch in address expression

-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-bootstrap --disable-multilib Thread model: posix gcc version 4.5.0 20090409 (experimental) (GCC) bash-4.0$ pwd /home/user/d/mplayer/libavcodec bash-4.0$ cc -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I.. -I.. -Wundef

[Bug c/39712] type mismatch in address expression

--- Comment #1 from happyarch at gmail dot com 2009-04-10 06:50 --- Created an attachment (id=17612) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17612&action=view) preprocessed output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39712

[Bug middle-end/39701] [4.5 Regression] Revision 145846 caused many test failures

--- Comment #3 from bonzini at gnu dot org 2009-04-10 06:55 --- The pr36901-* are correct to fail IMO -- they now give an "initializer is not constant" error which they weren't giving before -- because you cannot know in principle that &sc > 0 at compile-time, you have to wait for linkin