[Bug fortran/23420] ICE on invalid print statement

--- Comment #12 from pault at gcc dot gnu dot org 2006-07-07 05:17 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/28237] print call()

--- Comment #7 from pault at gcc dot gnu dot org 2006-07-07 05:16 --- Fixedon trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/28237] print call()

--- Comment #6 from pault at gcc dot gnu dot org 2006-07-07 05:09 --- Subject: Bug 28237 Author: pault Date: Fri Jul 7 05:08:57 2006 New Revision: 115247 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115247 Log: 2006-07-07 Paul Thomas <[EMAIL PROTECTED]> PR fortran/

[Bug fortran/23420] ICE on invalid print statement

--- Comment #11 from pault at gcc dot gnu dot org 2006-07-07 05:09 --- Subject: Bug 23420 Author: pault Date: Fri Jul 7 05:08:57 2006 New Revision: 115247 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115247 Log: 2006-07-07 Paul Thomas <[EMAIL PROTECTED]> PR fortran

[Bug fortran/28237] print call()

--- Comment #5 from pault at gcc dot gnu dot org 2006-07-07 04:47 --- Subject: Bug 28237 Author: pault Date: Fri Jul 7 04:47:24 2006 New Revision: 115246 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115246 Log: 2006-07-07 Paul Thomas <[EMAIL PROTECTED]> PR fortran/

[Bug fortran/23420] ICE on invalid print statement

--- Comment #10 from pault at gcc dot gnu dot org 2006-07-07 04:47 --- Subject: Bug 23420 Author: pault Date: Fri Jul 7 04:47:24 2006 New Revision: 115246 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115246 Log: 2006-07-07 Paul Thomas <[EMAIL PROTECTED]> PR fortran

[Bug c++/28279] [4.2 Regression] ICE in finish_static_data_member_decl, at cp/decl2.c:716

--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-07 04:20 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug other/28297] GCC 4.1.1 fails to build on Mac OS X 10.4.6

--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-07 02:05 --- Can you look into config.log and see why it is failing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug libstdc++/28297] GCC 4.1.1 fails to build on Mac OS X 10.4.6

--- Comment #2 from craigwd2000 at gmail dot com 2006-07-07 01:58 --- I just now tried make bootstrap. Now I'm getting a new error: make[1]: *** No rule to make target `bootstrap'. Stop. make: *** [bootstrap] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28297

[Bug libstdc++/28297] GCC 4.1.1 fails to build on Mac OS X 10.4.6

--- Comment #1 from pinskia at physics dot uc dot edu 2006-07-07 01:32 --- Subject: Re: New: GCC 4.1.1 fails to build on Mac OS X 10.4.6 > > GCC 4.1.1 fails to build on Mac OS X 10.4.6. > 1. Extract source code. > 2. Open Terminal. > 3. Run ./configure --enable-threads --x-include

Re: [Bug libstdc++/28297] New: GCC 4.1.1 fails to build on Mac OS X 10.4.6

> > GCC 4.1.1 fails to build on Mac OS X 10.4.6. > 1. Extract source code. > 2. Open Terminal. > 3. Run ./configure --enable-threads --x-includes=/usr/X11R6 > --x-libraries=/usr/X11R6 --with-cpu=powerpc --with-mpfr=/usr/local/lib > --with-gmp=/usr/local/lib. > 4. Run make. > 5. The following err

[Bug libstdc++/28297] New: GCC 4.1.1 fails to build on Mac OS X 10.4.6

GCC 4.1.1 fails to build on Mac OS X 10.4.6. 1. Extract source code. 2. Open Terminal. 3. Run ./configure --enable-threads --x-includes=/usr/X11R6 --x-libraries=/usr/X11R6 --with-cpu=powerpc --with-mpfr=/usr/local/lib --with-gmp=/usr/local/lib. 4. Run make. 5. The following error appears halting

[Bug target/27968] gcc emits (undefined) ffreep opcode which is not understood by Solaris' /usr/ccs/bin/as when tuning for Athlon or Opteron CPUs

--- Comment #4 from sayle at gcc dot gnu dot org 2006-07-07 00:13 --- Subject: Bug 27968 Author: sayle Date: Fri Jul 7 00:13:14 2006 New Revision: 115237 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115237 Log: PR target/27968 * configure.ac (HAVE_AS_IX86_FFR

[Bug libgomp/28296] libgomp fails to configure on Tru64 UNIX

--- Comment #1 from ro at gcc dot gnu dot org 2006-07-06 23:39 --- Eric, could you please have a look? Your patch broke this (and probably other platforms as well). Thanks. Rainer -- ro at gcc dot gnu dot org changed: What|Removed |Added --

[Bug libgomp/28296] New: libgomp fails to configure on Tru64 UNIX

libgomp just doesn't configure any more on Tru64 UNIX V5.1B: configure: error: Pthreads are required to build libgomp This is due to the last configure.ac change: 2006-07-05 Eric Christopher <[EMAIL PROTECTED]> * configure.ac: Depend addition of -pthread on host OS. * configu

[Bug libgcj/13139] gcj throws exception with faulty stacktrace with freenet

--- Comment #7 from mckinlay at redhat dot com 2006-07-06 23:06 --- Verified that freenet-0.5.2.1 now produces valid stack traces running under gcj. -- mckinlay at redhat dot com changed: What|Removed |Added

[Bug libgcj/1907] symbol demangling by Throwable.printStackTrace

--- Comment #8 from mckinlay at redhat dot com 2006-07-06 22:56 --- Fixed. libgcj no longer needs to do symbol demangling. -- mckinlay at redhat dot com changed: What|Removed |Added --

[Bug target/28232] Wrong aligned load is generated with -m4a on sh-*

--- Comment #2 from patchapp at dberlin dot org 2006-07-06 22:35 --- Subject: Bug number PR target/28232 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00266.html -- http://gcc.gnu.org/bug

[Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B

--- Comment #9 from ro at gcc dot gnu dot org 2006-07-06 22:21 --- The ICE is a duplicate, but the compile failure before is not (though it could be the same issue as libstdc++/28265). -- ro at gcc dot gnu dot org changed: What|Removed |Added -

[Bug c++/28217] [4.2 regression] ICE in tree_int_cst_sgn

--- Comment #7 from pinskia at gcc dot gnu dot org 2006-07-06 22:17 --- *** Bug 28290 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B

--- Comment #8 from pinskia at gcc dot gnu dot org 2006-07-06 22:17 --- *** This bug has been marked as a duplicate of 28217 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B

--- Comment #7 from pinskia at physics dot uc dot edu 2006-07-06 22:16 --- Subject: Re: [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B > > > > --- Comment #6 from ro at techfak dot uni-bielefeld dot de 2006-07-06 > 22:04 --- > Subject: Re: [4.2 R

Re: [Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B

> > > > --- Comment #6 from ro at techfak dot uni-bielefeld dot de 2006-07-06 > 22:04 --- > Subject: Re: [4.2 Regression] ICE during extc++.h pch generation on Tru64 > UNIX > V5.1B > > The same ICE happens on Solaris 10/x86 (i386-pc-solaris2.10). On x86-linux-gnu with FC4 I hear, I

[Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B

--- Comment #6 from ro at techfak dot uni-bielefeld dot de 2006-07-06 22:04 --- Subject: Re: [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B The same ICE happens on Solaris 10/x86 (i386-pc-solaris2.10). Rainer -- http://gcc.gnu.org/bugzilla/show_b

[Bug libgcj/28244] [4.2 regression] missing dependency causes build failure

--- Comment #5 from fitzsim at redhat dot com 2006-07-06 21:14 --- I fixed the missing dependency on trunk. The hppa-unknown-linux-gnu problem should probably be a separate bug. I'm closing this one. -- fitzsim at redhat dot com changed: What|Removed

[Bug c++/28294] [4.0/4.1/4.2 regression] ICE with invalid use of __builtin_offsetof

-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28294

[Bug c++/28294] New: [4.0/4.1/4.2 regression] ICE with invalid use of __builtin_offsetof

The following invalid code snippet triggers an ICE since at GCC 4.0.0: struct A { static int foo(); }; int i = __builtin_offsetof(A, foo[0]); bug.cc:6: error: pointer to a function used in arithmetic bug.

[Bug c++/28293] New: ICE on invalid typedef

The following invalid code snippet triggers an ICE since at least GCC 2.95.3: == template void foo(); struct A { typedef void foo<0>(); }; == bug.cc:5: internal compiler error: tree check: expected identifier_node, have template_id_expr in grokfield, at

[Bug fortran/25271] gfortran fails to pad lines in format statements to 72 characters.

--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-07-06 21:00 --- Unless I'm severely mistaken, this is not library issue but a front-end issue. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added -

[Bug c++/28292] [4.2 regression] ICE in acceptable_java_type

-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28292

[Bug c++/28292] New: [4.2 regression] ICE in acceptable_java_type

The following invalid code snippet triggers an ICE on mainline: == extern "Java" { struct A { void foo(void; }; } == bug.cc:5: error: expected `)' before ';' token bug.cc:5: error: '' has incomplete type bug.cc:5: error: invalid use of 'void' bug.

[Bug c++/28291] [4.1/4.2 regression] ICE on invalid designated initializer

-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28291

[Bug c++/28291] New: [4.1/4.2 regression] ICE on invalid designated initializer

The following invalid code snippet triggers an ICE since GCC 4.1.0: == struct A { static int i; int j; }; A a = { i:0 }; == bug.cc:7: error: 'A' has no non-static data member named 'i' bug.cc:7: internal compiler error: in process_init_constructor_reco

[Bug fortran/28129] gfortran -fbounds-check: Shows invalid array out of bounds error

--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-07-06 20:37 --- Subject: Bug 28129 Author: fxcoudert Date: Thu Jul 6 20:37:36 2006 New Revision: 115231 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115231 Log: PR fortran/28129 * trans-array.c (gfc_t

[Bug fortran/27874] [4.1 only] Bad interaction between bounds checking, forall and derived types

-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.2 Known to work||4.2.0

[Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B

--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2006-07-06 20:19 --- Subject: Re: [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B falk at debian dot org writes: > Can you give the .ii for that? Sure, done. Rainer -- http://gcc.gnu.org

[Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B

--- Comment #4 from ro at gcc dot gnu dot org 2006-07-06 20:18 --- Created an attachment (id=11848) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11848&action=view) -save-temps output with iconv.h hack and -O0 gcc -save-temps output that compiles (due to iconv.h inclusion in extc+

[Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B

--- Comment #3 from falk at debian dot org 2006-07-06 20:14 --- (In reply to comment #2) > Even if I add directly to extc++.h (a complete hack), the > compilation errors about iconv_t missing are gone, but the ICE remains, > even at -O0. Can you give the .ii for that? -- http://gc

[Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B

--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2006-07-06 20:10 --- Subject: Re: [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B Even if I add directly to extc++.h (a complete hack), the compilation errors about iconv_t missing are gone, but the IC

[Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B

--- Comment #1 from ro at gcc dot gnu dot org 2006-07-06 20:03 --- Created an attachment (id=11847) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11847&action=view) -save-temps output Output from gcc -save-temps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28290

[Bug libstdc++/28290] New: [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B

Bootstrapping current mainline as of 20060705 fails on Tru64 UNIX V5.1B when trying to genererate the PCH file for extc++.h: /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/./gcc/xgcc -shared-libgcc -B/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/./gcc -nostdinc++ -L/vol/gccsrc/obj/gcc-4.2.0-20

[Bug middle-end/28283] SuperH: Very unoptimal code generated for 64-bit ints

--- Comment #6 from joern dot rennecke at st dot com 2006-07-06 19:59 --- Subject: Re: SuperH: Very unoptimal code generated for 64-bit ints roger at eyesopen dot com wrote: >--- Comment #5 from roger at eyesopen dot com 2006-07-06 19:47 --- >No the rtx_costs for a DImode sh

[Bug middle-end/28283] SuperH: Very unoptimal code generated for 64-bit ints

--- Comment #5 from roger at eyesopen dot com 2006-07-06 19:47 --- No the rtx_costs for a DImode shift really are wrong. The use of the constant 1 in sh.c:shift_costs instructs the middle-end to avoid using DImode shifts at all costs. The semantics of rtx_costs is that it is expect

[Bug middle-end/28283] SuperH: Very unoptimal code generated for 64-bit ints

--- Comment #4 from amylaar at gcc dot gnu dot org 2006-07-06 19:32 --- (In reply to comment #2) > Investigating... I suspect that the SH backend's rtx_costs are parameterized > incorrectly, such that a 64-bit shift by the constant 32, looks to be at least > 32 times more expensive than

[Bug middle-end/28283] SuperH: Very unoptimal code generated for 64-bit ints

--- Comment #3 from amylaar at gcc dot gnu dot org 2006-07-06 19:30 --- When I disable the offending code (by altering add_cost[DImode] at the right moment), I get the right result for little endian. However, compiling for big endian gives wrong code: _expand64: mov #0,r5

[Bug middle-end/28283] SuperH: Very unoptimal code generated for 64-bit ints

--- Comment #2 from roger at eyesopen dot com 2006-07-06 19:17 --- Investigating... I suspect that the SH backend's rtx_costs are parameterized incorrectly, such that a 64-bit shift by the constant 32, looks to be at least 32 times more expensive than a 64-bit addition. The middle-end

[Bug middle-end/28283] SuperH: Very unoptimal code generated for 64-bit ints

--- Comment #1 from amylaar at gcc dot gnu dot org 2006-07-06 19:08 --- This patch has added code that is nonsentical when the operation can be synthesized cheaply in a narrower mode: r83956 | sayle | 2004-07-01 05:27:09 +0100 (Thu, 01 Jul 2004) | 6 lines * expmed.c (expand_sh

[Bug target/28170] [4.1/4.2 Regression] Wrong result after swap byte in one word when compiled in 64-bit mode

--- Comment #13 from dje at gcc dot gnu dot org 2006-07-06 19:00 --- Subject: Bug 28170 Author: dje Date: Thu Jul 6 18:59:58 2006 New Revision: 115229 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115229 Log: 2006-07-06 David Edelsohn <[EMAIL PROTECTED]> PR target/2

[Bug target/28150] ICE in reload_cse_simplify_operands, at postreload.c:394

--- Comment #8 from dje at gcc dot gnu dot org 2006-07-06 19:00 --- Subject: Bug 28150 Author: dje Date: Thu Jul 6 18:59:58 2006 New Revision: 115229 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115229 Log: 2006-07-06 David Edelsohn <[EMAIL PROTECTED]> PR target/28

[Bug c++/28279] [4.2 Regression] ICE in finish_static_data_member_decl, at cp/decl2.c:716

--- Comment #2 from jason at gcc dot gnu dot org 2006-07-06 18:39 --- Subject: Bug 28279 Author: jason Date: Thu Jul 6 18:39:39 2006 New Revision: 115228 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115228 Log: PR c++/28279 * decl2.c (finish_static_data_member

[Bug target/27922] final link failed: Nonrepresentable section on output

--- Comment #2 from kristoffer_e1 at hotmail dot com 2006-07-06 18:34 --- Created an attachment (id=11846) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11846&action=view) Log of osb-jscore build -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27922

[Bug target/28170] [4.1/4.2 Regression] Wrong result after swap byte in one word when compiled in 64-bit mode

--- Comment #12 from bergner at vnet dot ibm dot com 2006-07-06 18:00 --- Mainline with Alan's changed bootstrapped, but showed a few regressions. David's suggested fix from comment #7 (using mainline) bootstrapped and is currently in the middle of running the test suite. -- http:

[Bug c/28289] New: composite_types called to do two different things

composite_types is called in c-decl.c to merge function declarations, but in c-typeck.c to merge the types of two arms of a COND_EXPR. The former should result in a union of traits of the inputs, which composite_types computes, but the latter should give the intersection of traits unless the C sta

[Bug target/28285] [4.2 Regression] duplicate case value in alpha_swapped_comparison operator

--- Comment #2 from ro at gcc dot gnu dot org 2006-07-06 17:18 --- Fixed for 4.2.0. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRM

[Bug target/28285] [4.2 Regression] duplicate case value in alpha_swapped_comparison operator

--- Comment #1 from ro at gcc dot gnu dot org 2006-07-06 17:16 --- Subject: Bug 28285 Author: ro Date: Thu Jul 6 17:16:48 2006 New Revision: 115225 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115225 Log: PR target/28285 * config/alpha/predicates.md (alpha_swa

[Bug fortran/27874] Bad interaction between bounds checking, forall and derived types

--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-07-06 17:12 --- Subject: Bug 27874 Author: fxcoudert Date: Thu Jul 6 17:12:25 2006 New Revision: 115224 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115224 Log: PR fortran/27874 * trans-stmt.c (compute

[Bug c++/28288] [4.0/4.1/4.2 regression] ICE with min/max operator

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-06 16:57 --- This is why they are deprecated :). Anyways this is PR 14556 is the PR about removing them, I don't know why they have not been removed yet. -- pinskia at gcc dot gnu dot org changed: What|Remove

[Bug c++/28236] wrong "control reaches" warning with enums.

--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-06 16:55 --- Values in enums that are out of range are undefined in C++ (while defined in C). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/28288] [4.0/4.1/4.2 regression] ICE with min/max operator

-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28288

[Bug c++/28288] New: [4.0/4.1/4.2 regression] ICE with min/max operator

The following invalid code snippet triggers an ICE since GCC 4.0.0: = void foo(int i) { (i++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28288

[Bug fortran/28176] FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (ICE)

--- Comment #3 from danglin at gcc dot gnu dot org 2006-07-06 16:49 --- There seem to be more files now but they might be new tests. See . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28176

[Bug c/28287] [4.1/4.2 regression] ICE with misplaced attribute weak

-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28287

[Bug c/28287] New: [4.1/4.2 regression] ICE with misplaced attribute weak

The following invalid code snippet triggers an ICE since GCC 4.1.0: = void foo(int __attribute__((weak))); = bug.c:1: error: weak declaration of '({anonymous})' must be public bug.c:1: internal compiler error:

[Bug c/28286] [4.0/4.1/4.2 regression] ICE with invalid value in #pragma pack

-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28286

[Bug c/28286] New: [4.0/4.1/4.2 regression] ICE with invalid value in #pragma pack

The following invalid code snippet triggers an ICE since GCC 3.3: = #pragma pack(0..) = bug.c:1:14: error: too many decimal points in number bug.c:1: internal compiler error: tree check: expected integer_cst,

[Bug target/28285] New: [4.2 Regression] duplicate case value in alpha_swapped_comparison operator

Bootstrapping current mainline on Tru64 UNIX fails in stage1 as of 20060705: gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I/vol/gcc/src/gcc/

[Bug c++/28284] [4.2 regression] ICE with invalid static const variable

-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28284

[Bug c++/28284] New: [4.2 regression] ICE with invalid static const variable

The following invalid code snippet triggers an ICE on mainline: = template struct A { static const int i=x, j, k; }; template const int A::j = i; template const int A::k = j; A<0> a; = bug.cc:3: error: 'x'

[Bug fortran/28237] print call()

--- Comment #4 from patchapp at dberlin dot org 2006-07-06 16:20 --- Subject: Bug number PR28237 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00245.html -- http://gcc.gnu.org/bugzilla/sh

[Bug target/28126] gcc moves an expensive instruction outside of a conditional

--- Comment #3 from anemo at mba dot ocn dot ne dot jp 2006-07-06 16:20 --- Subject: Re: gcc moves an expensive instruction outside of a conditional One note: I think "rdhwr $v1, $29" should not be placed in delay slot anyway. The instruction always generate an exception, so if it w

[Bug fortran/28167] ICE: in fold_binary, at fold-const.c:8239 (temporary character array?)

--- Comment #8 from pault at gcc dot gnu dot org 2006-07-06 15:38 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/28174] Corruption of multiple character arrays when passing array sections

--- Comment #8 from pault at gcc dot gnu dot org 2006-07-06 15:37 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/28174] Corruption of multiple character arrays when passing array sections

--- Comment #7 from pault at gcc dot gnu dot org 2006-07-06 15:35 --- Subject: Bug 28174 Author: pault Date: Thu Jul 6 15:35:24 2006 New Revision: 115222 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115222 Log: 2006-07-06 Paul Thomas <[EMAIL PROTECTED]> PR fortran/

[Bug fortran/28167] ICE: in fold_binary, at fold-const.c:8239 (temporary character array?)

--- Comment #7 from pault at gcc dot gnu dot org 2006-07-06 15:35 --- Subject: Bug 28167 Author: pault Date: Thu Jul 6 15:35:24 2006 New Revision: 115222 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115222 Log: 2006-07-06 Paul Thomas <[EMAIL PROTECTED]> PR fortran/

[Bug rtl-optimization/28283] New: SuperH: Very unoptimal code generated for 64-bit ints

NetBSD has recently imported gcc 4.1.2 prerelease. I've noticed that for sh3 there's a serious degradation in the quality of the generated code for long long handling. While generally the generated code is more compact, as soon as 64-bit ints come into play, the size increases, e.g. softfloat.o e

[Bug target/27991] [4.2 regression] ICE in reload_cse_simplify_operands

--- Comment #3 from pbrook at gcc dot gnu dot org 2006-07-06 15:26 --- It looks like this is a latent bug. My patch allows negxf to operate on integer registers (previously it was only implemented on FP regs). This causes the register allocator to make different register choices, and rel

[Bug c++/28279] [4.2 Regression] ICE in finish_static_data_member_decl, at cp/decl2.c:716

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

[Bug c++/26905] default-visibility class symbol improperly resolved as hidden-visibility

--- Comment #6 from jason at gcc dot gnu dot org 2006-07-06 15:21 --- I'm afraid it's too large a patch to go into the FSF 4.0/1 branches, though Red Hat will apply include it in our 4.1 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26905

[Bug c/28280] [4.2 regression] bogus "statement with no effect" warning with VLA and typeof

--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-06 15:13 --- Most likely caused by: 2006-05-18 Mike Stump <[EMAIL PROTECTED]> Fix up vla, vm and [*] sematics. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug c/28280] [4.2 regression] bogus "statement with no effect" warning with VLA and typeof

--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-06 15:12 --- We are warning inside the typeof. Here is a shorter testcase: void f(__SIZE_TYPE__ d) { typedef int t[d]; t *g = (__typeof(g))d; } -- pinskia at gcc dot gnu dot org changed: What|Removed

[Bug tree-optimization/28238] [4.1/4.2 regression] verify_stmts failed (invalid operand to unary operator)

--- Comment #8 from patchapp at dberlin dot org 2006-07-06 14:55 --- Subject: Bug number PR28238 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00226.html -- http://gcc.gnu.org/bugzilla/sh

[Bug tree-optimization/28238] [4.1/4.2 regression] verify_stmts failed (invalid operand to unary operator)

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker Target Milestone|4.2.0 |4.1.2 http:

[Bug target/28281] gcc uses the wrong segment register for TLS access for -fstack-protector in kernel mode

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Component|c |target

[Bug c/28280] [4.2 regression] bogus "statement with no effect" warning

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-06 14:51 --- This is not a debug issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/28170] [4.1/4.2 Regression] Wrong result after swap byte in one word when compiled in 64-bit mode

--- Comment #11 from dje at gcc dot gnu dot org 2006-07-06 14:37 --- The original code could not be "totally broken" unless Alan's code also is totally broken because he computes many of the same tests. Also, Alan does not include an important test from the original code, so his code is

[Bug target/28170] [4.1/4.2 Regression] Wrong result after swap byte in one word when compiled in 64-bit mode

--- Comment #10 from bergner at vnet dot ibm dot com 2006-07-06 14:32 --- I used Alan's code changes from comments #8 and #9 on the 4.1 branch and it bootstrapped and regression tested (32-bit and 64-bit) fine. Mainline bootstraps and regression tests are still running. -- http://

[Bug fortran/28237] print call()

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

[Bug tree-optimization/28238] [4.1/4.2 regression] verify_stmts failed (invalid operand to unary operator)

--- Comment #7 from rguenth at gcc dot gnu dot org 2006-07-06 12:38 --- I have a fix. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|un

[Bug java/28153] Under Windows Xp the generated JNI headers need to have a '_' prepended for each function.

--- Comment #7 from bcmpinc at hotmail dot com 2006-07-06 12:37 --- extern JNIEXPORT void JNICALL Java_JavaSide_sayHello (JNIEnv *env, jobject); After preprossesing this becomes: __attribute__((dllexport)) void __attribute__((__stdcall__)) Java_sample_myNative (JNIEnv *, jobject, js

[Bug c/28281] gcc uses the wrong segment register for TLS access for -fstack-protector in kernel mode

--- Comment #3 from arjan at linux dot intel dot com 2006-07-06 11:08 --- Created an attachment (id=11844) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11844&action=view) updates with Jakub's comments updates with jakubs comments -- http://gcc.gnu.org/bugzilla/show_bug.cgi?

[Bug tree-optimization/28238] [4.1/4.2 regression] verify_stmts failed (invalid operand to unary operator)

--- Comment #6 from rguenth at gcc dot gnu dot org 2006-07-06 10:55 --- 4.1.2 also fails. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fai

[Bug middle-end/28268] [4.2 regression] ICE with simple vector operations

--- Comment #2 from patchapp at dberlin dot org 2006-07-06 10:20 --- Subject: Bug number PR28268 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00203.html -- http://gcc.gnu.org/bugzilla/sh

[Bug rtl-optimization/28221] [4.1 regression] ICE in add_insn_before, at emit-rtl.c:3479

--- Comment #7 from rguenth at gcc dot gnu dot org 2006-07-06 10:11 --- Really looks like a dup of PR27291, but the patch for that doesn't apply to the 4.1 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28221

[Bug rtl-optimization/28221] [4.1 regression] ICE in add_insn_before, at emit-rtl.c:3479

--- Comment #6 from rguenth at gcc dot gnu dot org 2006-07-06 10:10 --- ICE is after rtl loop2 optimizer, looks like it requires a doloop target. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug rtl-optimization/28221] [4.1 regression] ICE in add_insn_before, at emit-rtl.c:3479

--- Comment #5 from rguenth at gcc dot gnu dot org 2006-07-06 10:07 --- The reduced testcases are with checking only. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug rtl-optimization/28221] [4.1 regression] ICE in add_insn_before, at emit-rtl.c:3479

--- Comment #4 from rguenth at gcc dot gnu dot org 2006-07-06 10:02 --- So, confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|U

[Bug rtl-optimization/28221] [4.1 regression] ICE in add_insn_before, at emit-rtl.c:3479

--- Comment #3 from rguenth at gcc dot gnu dot org 2006-07-06 10:01 --- Created an attachment (id=11843) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11843&action=view) testcase reduced C++ testcase attached. C testcase: void foo(void) { int value47D2367, valueD2287; unsign

[Bug c/28281] gcc uses the wrong segment register for TLS access for -fstack-protector in kernel mode

--- Comment #2 from arjan at linux dot intel dot com 2006-07-06 09:49 --- Created an attachment (id=11842) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11842&action=view) updated patch updated patch; it helps if I send the non-test version of the testsuite test so that it actual

[Bug rtl-optimization/26945] [4.0/4.1 regression] Attempt to delete prologue/epilogue insn

--- Comment #4 from ted at midg3t dot net 2006-07-06 09:38 --- I came across a similar error, but because the test case attached to this report did not trigger on my machine I filed a separate report, bug #28282. It looks like it's probably related. -- http://gcc.gnu.org/bugzilla/sh

[Bug rtl-optimization/28282] Attempt to delete prologue/epilogue insn, again

--- Comment #3 from ted at midg3t dot net 2006-07-06 09:35 --- For clarity, when not run via ccache the first line of the preprocessed source output is: // /usr/lib/gcc/i486-linux-gnu/4.1.2/cc1 -quiet bug.c -quiet -dumpbase bug.c -mtune=i686 -auxbase bug -O1 -o - -frandom-seed=0 --

  1   2   >