[Bug pch/14940] PCH largefile test fails on various platforms

--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-04 07:09 --- > + #elif defined(__sparc__) > + # define TRY_EMPTY_VM_SPACE 0x6000 > > Also works for sparc-linux and largefile.c on sparc64-linux. Unfortunatly, > there are other pch failures on sparc64-linux. I

[Bug rtl-optimization/17428] [4.0 Regression] internal compiler error: in spill_failure, at reload1.c:1880

--- Additional Comments From rakdver at gcc dot gnu dot org 2004-11-04 07:06 --- Patch for the other problem: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00260.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17428

[Bug tree-optimization/18009] [4.0 Regression] ICE in vect_transform_stmt, at tree-vectorizer.c:2625 (testcase included)

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-04 05:27 --- Subject: Bug 18009 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-04 05:26:55 Modified files: gcc: ChangeLog tree-vectorizer.h tree-vect

[Bug rtl-optimization/18295] ICE

--- Additional Comments From ralf_corsepius at rtems dot org 2004-11-04 05:16 --- Thanks, yes, 15342 looks very similar. And yes, it does not ice at -O2 (This is what I had meant by writing "it does not ice at optimization levels < 3"). -- http://gcc.gnu.org/bugzilla/show_bug.cgi

[Bug pch/14940] PCH largefile test fails on various platforms

--- Additional Comments From phython at gcc dot gnu dot org 2004-11-04 04:57 --- + #elif defined(__sparc__) + # define TRY_EMPTY_VM_SPACE 0x6000 Also works for sparc-linux and largefile.c on sparc64-linux. Unfortunatly, there are other pch failures on sparc64-linux. -- http:

[Bug java/18190] [4.0 regression] primitive array optimization is gone

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 04:53 --- Some of the code from java_expand_expr should be moved into java_gimplify_new_array_init. And maybe fix up libjava code or maybe just storing the array's vtable by using a store. I might look into doing

[Bug rtl-optimization/18295] ICE

--- Additional Comments From ralf_corsepius at rtems dot org 2004-11-04 04:42 --- Created an attachment (id=7470) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7470&action=view) *.i of a real world source files triggering the ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=

[Bug rtl-optimization/18295] ICE

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 04:41 --- This looks close to PR 15342, I am going to assume it works at -O2. -- What|Removed |Added

[Bug rtl-optimization/18295] ICE

-- What|Removed |Added Component|target |rtl-optimization Keywords||ice-on-valid-code http://gcc.gnu.org/bugzill

[Bug target/18295] New: ICE

. See http://gcc.gnu.org/bugs.html> for instructions. It does not ice with optimization levels < 3. # arm-rtems4.7-gcc --version arm-rtems4.7-gcc (GCC) 3.4.3 20041103 (prerelease) This is a regression against gcc-3.2.3 which compiles the code without error. -- S

[Bug libstdc++/18277] [4.0 Regression] libsupc++/guard.cc:62: error: 'RECURSIVE_ERRORCHECKMUTEX' was not declared in this scope

-- What|Removed |Added Summary|libsupc++/guard.cc:62: |[4.0 Regression] |error: |libsupc++/guard.cc:62: |'RE

[Bug rtl-optimization/16088] [4.0 Regression] Generates wrong code

--- Additional Comments From lucier at math dot purdue dot edu 2004-11-04 03:31 --- Subject: Re: [4.0 Regression] Generates wrong code I tried again, I'm having the same problems with today's 4.0. I also have the same problems on sparc-sun-solaris2.9. I tried debugging it with gdb 6

[Bug libfortran/18284] BACKSPACE broken

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 03:20 --- Patch here: . -- What|Removed |Added

[Bug target/18230] SPARC VIS instructions are not generated by GCC

--- Additional Comments From phython at gcc dot gnu dot org 2004-11-04 03:10 --- It seems that sparc{,64} is not supported in host-linux.c so the tests may be passing by accident. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18230

[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h

--- Additional Comments From peter at the-baradas dot com 2004-11-04 02:17 --- Chris Johns <[EMAIL PROTECTED]> asked me: >Is the Coldfire aligned to a 2 byte boundary or a 4 byte boundary ? The Colfire operates the same as the x86 in that the cache/bus unit will automagically handle una

[Bug rtl-optimization/18294] [4.0 Regression] ICE in rtl_verify_flow_info during bootstrap

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 00:58 --- Hmm, we are putting code after the loop and after function end, I don't know why. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18294

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

--- Additional Comments From steven at gcc dot gnu dot org 2004-11-04 00:29 --- - -- What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc d

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

--- Additional Comments From stevenb at suse dot de 2004-11-04 00:28 --- Subject: Re: [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases > However, there's clearly an algorithmic problem in this code. There is. The loop predictors are quadra

[Bug rtl-optimization/18294] [4.0 Regression] ICE in rtl_verify_flow_info during bootstrap

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 00:24 --- This is caused during .jump -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18294

[Bug rtl-optimization/18294] [4.0 Regression] ICE in rtl_verify_flow_info during bootstrap

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 00:20 --- Confirmed: t.c: In function 'adjust_field_type': t.c:14: error: insn outside basic block (insn 91 82 0 (set (reg/f:DI 381) (reg/f:DI 328 sfp)) -1 (nil) (nil)) t.c:14: internal compiler error: in

[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h

--- Additional Comments From schwab at suse dot de 2004-11-03 23:44 --- Even the 68020 should already show slight improvement when using 4 byte aligment due to the 32 bit data bus (the 68000/010 only have a 16 bit data bus). Adding an aligned attribute to the _Atomic_int type doesn't

[Bug rtl-optimization/18294] [4.0 Regression] ICE in rtl_verify_flow_info during bootstrap

-- What|Removed |Added Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18294

[Bug rtl-optimization/18294] [4.0 Regression] ICE in rtl_verify_flow_info during bootstrap

-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords|

[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h

--- Additional Comments From joel at oarcorp dot com 2004-11-03 23:25 --- Subject: Re: M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h cjohns at cybertec dot com dot au wrote: > --- Additional Comments From cjohns at cybertec dot com dot au 2004-11-03 23:05 > --- >

[Bug rtl-optimization/18294] New: ICE in rtl_verify_flow_info during bootstrap

I get an ICE when bootstrapping the latest GCC on ia64-hp-hpux11.20. It dies when compiling adjust_field_type in gengtype.c. Attached is a small test case to reproduce the problem. The test case only fails in ILP32 mode (the default), it cannot be reproduced in LP64 mode (-mlp64) and it cannot b

[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h

--- Additional Comments From cjohns at cybertec dot com dot au 2004-11-03 23:05 --- Does this mean the instruction in question (cas) in atomicity.h cannot be used on the 68060 if the stack can be aligned to a 2 byte boundary ? Would a stack aligned this way cause a slow down if the call

[Bug middle-end/18293] Redundant copy operation introduced by expand

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-03 22:58 --- Confirmed. This is related to casts somehow. Also this happens on 3.3 which is even more funny and just show the deficiencies in the expanders which no one noticed before. -- What|Removed

[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h

--- Additional Comments From joel at oarcorp dot com 2004-11-03 22:56 --- Subject: Re: M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h schwab at suse dot de wrote: > --- Additional Comments From schwab at suse dot de 2004-11-03 22:25 --- > On the m68k the biggest ali

[Bug bootstrap/18288] remaking existing build after cvs update gives configure recheck problems

--- Additional Comments From schwab at suse dot de 2004-11-03 22:32 --- You can also just remove the Makefile from the subdirectory to trigger reconfiguring from the toplevel. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18288

[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h

--- Additional Comments From schwab at suse dot de 2004-11-03 22:25 --- On the m68k the biggest alignment has traditionally only been 2 bytes (inherited from the Sun compiler, AFAIK), and it's only overridden on NetBSD (and previously on some configurations that are removed now) or when

[Bug middle-end/18293] New: Redundant copy operation introduced by expand

Given this piece of code, struct deferred_access; extern struct deferred_access *D25481; struct deferred_access * foo (void) { return (struct deferred_access *) ((long unsigned int) D25481 * 16); } which generates on i686 in .00.expand (-fdump-rtl-expand-details): ;; return (st

[Bug c/18292] Cannot use function name within function.

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-03 21:57 --- Use -Wshadow: -WshadowWarn when one local variable shadows another -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18292

[Bug c/18292] Cannot use function name within function.

--- Additional Comments From deepak at despammed dot com 2004-11-03 21:50 --- (In reply to comment #4) > Not a bug, you have a variable called signal which shadows the global function: > sig(int signal) { Agree. Is it possible to change the error message to say exactly this? For instan

[Bug c/18292] Cannot use function name within function.

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-03 21:41 --- Not a bug, you have a variable called signal which shadows the global function: sig(int signal) { -- What|Removed |Added -

[Bug c/18292] Cannot use function name within function.

--- Additional Comments From deepak at despammed dot com 2004-11-03 21:38 --- (In reply to comment #1) > I cannot reproduce this, can you attach the preprocessed source? Here is the plain source: #include extern volatile sig_atomic_t pe_connection_BAD; void sig(int signal) { int

[Bug tree-optimization/18270] [4.0 Regression] internal compiler error: in tree_redirect_edge_and_branch, at tree-cfg.c:4146

--- Additional Comments From lucier at math dot purdue dot edu 2004-11-03 21:31 --- Subject: Re: [4.0 Regression] internal compiler error: in tree_redirect_edge_and_branch, at tree-cfg.c:4146 Was a new test case added with this patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?

[Bug tree-optimization/18291] [4.0 Regression]: ICE in merge_alias_info

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|NEW

[Bug target/18106] Weak symbols are unimplemented on Windows

--- Additional Comments From aaronavay62 at aaronwl dot com 2004-11-03 21:12 --- For what its worth, the issue in comment #2 was resolved. This patch can again be safely applied. It is awaiting review. -- What|Removed |Added

[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h

--- Additional Comments From joel at oarcorp dot com 2004-11-03 21:09 --- Subject: Re: M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h bkoz at gcc dot gnu dot org wrote: > --- Additional Comments From bkoz at gcc dot gnu dot org 2004-11-03 00:12 > --- > > Joel, you

[Bug bootstrap/17383] [4.0 Regression] Building in src dir fails

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-03 21:08 --- *** Bug 18290 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug bootstrap/18290] Build failure: ansidecl.h not found (?)

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-03 21:08 --- *** This bug has been marked as a duplicate of 17383 *** -- What|Removed |Added

[Bug c/18292] Cannot use function name within function.

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-03 21:06 --- I cannot reproduce this, can you attach the preprocessed source? -- What|Removed |Added

[Bug c++/18289] GCC3.4.2 selects incorrect function overload when an ellipsis overload is available

--- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-03 21:03 --- This is not a bug. [13.3.3.2]/2 says that a standard conversion sequence is better than an ellipsis conversion sequence. The note in [13.3]/1 says: The function selected by overload resolution is not guar

[Bug tree-optimization/18291] [4.0 Regression]: ICE in merge_alias_info

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-03 21:02 --- Confirmed. -- What|Removed |Added CC||pinskia at

[Bug c++/18289] GCC3.4.2 selects incorrect function overload when an ellipsis overload is available

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-03 20:57 --- Note ICC 8.0 also rejects this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18289

[Bug c/18292] New: Cannot use function name within function.

Under the said version of gcc, I cannot say something like: void foo(int bar) { extern void foo(int); /* do_something. */ /* Reinstate handler. */ signal(SIGINT, foo); } Output is something like: foo.c:750: error: called object is not a function foo.c:751: error: called object i

[Bug tree-optimization/18291] New: 4.0: ICE in merge_alias_info

g++ 4.0 gives an ICE compiling the source below with -O1: $ ./cc1plus -quiet -O1 x.cc x.cc: In function 'void writeDigi()': x.cc:10: internal compiler error: in merge_alias_info, at tree-ssa-copy.c:217 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.o

[Bug bootstrap/18290] New: Build failure: ansidecl.h not found (?)

version is 4.0.0 20041103 (experimental). $ ./configure --prefix=$HOME --enable-languages="c,f95" creating cache ./config.cache checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking build system type... i686-pc-linux-gnu checking

[Bug bootstrap/18288] remaking existing build after cvs update gives configure recheck problems

-- What|Removed |Added CC||fitzsim at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18288

[Bug bootstrap/18288] remaking existing build after cvs update gives configure recheck problems

--- Additional Comments From mark at gcc dot gnu dot org 2004-11-03 20:37 --- Another workaround (just told to me on irc, and verified) is to rerun you configure statement in the top level build directory before doing a make in the top level build dir. -- http://gcc.gnu.org/bugzilla/s

[Bug c++/18289] New: GCC3.4.2 selects incorrect function overload when an ellipsis overload is available

GCC 3.4.2 selects an overload that requires an inaccessible conversion when an ellipsis function overload is available Platform is Cygwin on Windows 2000. See the example below. class A {}; class B : public A {}; class C : private A {}; void f(...); void f(A*); void error() { f(static_cast(0)

[Bug bootstrap/18288] New: remaking existing build after cvs update gives configure recheck problems

When updating a source try (through contrib/gcc_update) and typing make in the build directory configure recheck fails often for the runtime libraries (libc++-v3, libjava, boehmgc, libffi, etc.) Here is an example for libmudflap: make[1]: Entering directory `/home/mark/src/gcc-obj/i686-pc-linux-gn

[Bug c/18287] Unaligned access to fields inside packed records

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-03 19:57 --- There is another example of this in PR 17949 where the tree-optimizations cause something werid to happen only because the middle-end does not know that they are unaligned loads. -- http://gcc.gnu.org/

[Bug middle-end/18231] [4.0 regression] Nested inline function not inlined

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-03 19:56 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug middle-end/18231] [4.0 regression] Nested inline function not inlined

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-03 19:55 --- Subject: Bug 18231 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-03 19:55:31 Modified files: gcc: ChangeLog tree.c Log message:

[Bug tree-optimization/18270] [4.0 Regression] internal compiler error: in tree_redirect_edge_and_branch, at tree-cfg.c:4146

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-03 19:28 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED

[Bug tree-optimization/18270] [4.0 Regression] internal compiler error: in tree_redirect_edge_and_branch, at tree-cfg.c:4146

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-03 18:56 --- Subject: Bug 18270 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-03 18:56:36 Modified files: gcc: ChangeLog tree-outof-ssa.c Log mess

[Bug c/18287] Unaligned access to fields inside packed records

he bus error (not bug error!) happens with 4.0.0 20041103. But, you're right, probably another problem there. The compiler should not pass the adress of &dt->Time to Assign_Hour_Of if it can't prove that the field is at least as aligned as its type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18287

[Bug rtl-optimization/14237] suboptimal comparison between long and long long

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-03 18:14 --- For PPC, we have: cmplw cr7,r0,r9 cmpw cr6,r0,r9 bgtlr- cr7 beq- cr6,L6 equality test can be done logically or arthimaticly so we don't need both cmp*'s. -- What

[Bug c/18287] Unaligned access to fields inside packed records

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-03 18:03 --- t->Hour = 44; /* unaligned word access */ is unaligned word access if t is not word aligned in the first place, correct which is where the problem comes in right? -- http://gcc.gnu.org/bugzilla/show

[Bug c/18287] Unaligned access to fields inside packed records

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-03 18:02 --- Are you sure that 4.0.0 does not work, as it no longer does the transformation for &(a->b) into a + offsetof(a,b). >From the last tree dump for 4.0.0: ;; Function Assign_Hour_Of (Assign_Hour_Of) Assign_Ho

[Bug c/18287] Unaligned access to fields inside packed records

--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-03 17:53 --- Created an attachment (id=7467) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7467&action=view) Testcase. To be compiled with -O0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18287

[Bug c/18287] New: Unaligned access to fields inside packed records

The testcase I'm about to attach generates a bug error at runtime on the SPARC (and very likely on any other STRICT_ALIGNMENT target). Verified with 2.95.3, 3.3.x, 3.4.x and 4.0pre. I think the front-end wrongly turns ADDR_EXPR> into PLUS_EXPR whatever the alignment of the field. For reference,

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

--- Additional Comments From s dot bosscher at student dot tudelft dot nl 2004-11-03 16:52 --- Subject: RE: [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases > No you don't know it's size or density in advance. We're not looking > a

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

--- Additional Comments From kazu at cs dot umass dot edu 2004-11-03 16:51 --- Jeff, Oops, you're right! Kazu Hirata -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

--- Additional Comments From law at redhat dot com 2004-11-03 16:46 --- Subject: Re: [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases On Wed, 2004-11-03 at 16:33 +, kazu at cs dot umass dot edu wrote: > --- Additional Comments

[Bug libstdc++/10606] uncaught_exception() returns false too early

--- Additional Comments From sebor at roguewave dot com 2004-11-03 16:42 --- (In reply to comment #10) I think it's clear that gcc is wrong in not returning true in the initializer of the exception object in the catch handler (the second invocation of the copy ctor in the test case). Wha

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

--- Additional Comments From kazu at cs dot umass dot edu 2004-11-03 16:33 --- Richard, My patches to expand_case does not change its asymptotic behavior. Jeff, You might want to use SBITMAP instead of BITMAP in your patch to expand_case because the bitmap you construct will be dense,

[Bug tree-optimization/18184] [4.0 Regression] Tree optimizers ignore pointer modes

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-03 16:02 --- New patch: . -- What|Removed |Added

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

--- Additional Comments From richard dot guenther at gmail dot com 2004-11-03 15:44 --- Subject: Re: [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases On Wed, 3 Nov 2004 10:07:58 -0500, Andrew Pinski <[EMAIL PROTECTED]> wrote: > > On Nov 3,

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

--- Additional Comments From law at redhat dot com 2004-11-03 15:43 --- Subject: Re: [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases On Wed, 2004-11-03 at 15:08 +, pinskia at physics dot uc dot edu wrote: > --- Additional Com

[Bug target/16457] PowerPC - Combine two rldicr instructions into a single rlwinm.

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-03 15:41 --- What is happening is the following instruction is being split up: (insn:HI 14 13 15 0 (parallel [ (set (reg:DI 123) (and:DI (reg/v:DI 118 [ x ]) (const_int 429

[Bug target/17108] Missed opportunity for strength reduction

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-03 15:33 --- Corresponding code which gives what is wantted here is: void foo(float *data, float d) { long i; data--; for (i = 0; i < 8; i++) { data[1] = d; data++; } } -- Wha

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

--- Additional Comments From pinskia at physics dot uc dot edu 2004-11-03 15:08 --- Subject: Re: [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases On Nov 3, 2004, at 10:03 AM, Jeffrey A Law wrote: > > With loop bounds recording no longer c

[Bug target/16457] PowerPC - Combine two rldicr instructions into a single rlwinm.

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|NEW

[Bug libstdc++/10606] uncaught_exception() returns false too early

--- Additional Comments From giovannibajo at libero dot it 2004-11-03 14:48 --- (In reply to comment #10) > If the issue is still under the C++ committee, this bug should be suspended. > Unless there is something which is *surely* wrong with C++ and that can be > fixed meanwhile. I m

[Bug libstdc++/10606] uncaught_exception() returns false too early

--- Additional Comments From giovannibajo at libero dot it 2004-11-03 14:47 --- If the issue is still under the C++ committee, this bug should be suspended. Unless there is something which is *surely* wrong with C++ and that can be fixed meanwhile. -- http://gcc.gnu.org/bugzilla/sh

[Bug tree-optimization/16797] Opportunity to remove unnecessary load instructions

--- Additional Comments From nathan at gcc dot gnu dot org 2004-11-03 14:40 --- ug. This bug falls between a number of stools. 1) on ppc-64 ints are returned correctly sign extended to 64 bits 2) the tree-ssa optimizers are blind to parameter marshalling, so the necessary sign extension

Re: GCC3.4.2 selects incorrect function overload when an ellipsis overload is available

Lee-Thorp, Andrew wrote: > GCC 3.4.2 selects an 'unavailable' function overload. > Platform is Cygwin on Windows 2000. Please, submit a bug report through our Bugzilla interface (http://gcc.gnu.org/bugzilla). Thanks. Giovanni Bajo

[Bug libfortran/18284] BACKSPACE broken

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-03 14:36 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW E

[Bug target/18230] SPARC VIS instructions are not generated by GCC

--- Additional Comments From phython at gcc dot gnu dot org 2004-11-03 14:28 --- Re-running the libjava tests there are no new failures. I suspect the load on my machine was higher was higher when those tests originally ran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18230

GCC3.4.2 selects incorrect function overload when an ellipsis overload is available

GCC 3.4.2 selects an 'unavailable' function overload. Platform is Cygwin on Windows 2000. See the example below. class A {}; class B : public A {}; class C : private A {}; void f(...); void f(A*); void error() { f(static_cast(0)); f(static_cast(0)); // <- Line 42 } Conversion.cc: In functio

[Bug libstdc++/17664] [3.4 only] Crash in std::map when using _GLIBCXX_DEBUG with multithreading

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-03 12:24 --- Fixed on the mainline, queued for 3.4.4. -- What|Removed |Added Known to work|

[Bug c++/18123] [3.4/4.0 regression] ICE on templated enum

--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-11-03 12:22 --- Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00194.html -- What|Removed |Added ---

[Bug c++/18285] [4.0 regression] multiple types in typedef not rejected

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-03 12:18 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW E

[Bug c++/18286] templates with multipile inheritence fail compile

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-03 12:17 --- Read the release notes on why this is invalid C++ and why this changed. -- What|Removed |Added ---

[Bug rtl-optimization/16802] PowerPC - Unnecessary extsw

--- Additional Comments From nathan at gcc dot gnu dot org 2004-11-03 11:29 --- I believe this is a problem with the tree optimizers being ABI blind. on 64bit ppc integral parameters and return values are correctly extended to 64 bits. This sign extension is inserted during the tree->rt

[Bug other/17108] Missed opportunity for strength reduction

--- Additional Comments From nathan at gcc dot gnu dot org 2004-11-03 11:25 --- The situation has improved, as the biv has now been spotted, and the loop turned into, .foo: li 0,8 mtctr 0 .align 4 .L2: stfs 1,0(3) addi 3,3,4 bdnz .L2

[Bug rtl-optimization/16456] PowerPC - redundant subtract involving pointer types

--- Additional Comments From nathan at gcc dot gnu dot org 2004-11-03 11:20 --- What is happening is that convert_to_integer, which is used to convert the subtraction result to the type of 'x', reassociates the cast from (int)((long)ptr1 - (long)ptr2) to (int)ptr1 - (int)ptr2 As it t

[Bug c++/18286] New: templates with multipile inheritence fail compile

There seems to be a problem with multipile inheritence and template the attached code compile on gcc 3.2.2 and fail on gcc 3.4.2 the same code with only one inheritace (delete class c) pass compile compiler version c++ -v Reading specs from /insightix/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.2/s

[Bug debug/18280] [3.4 regression] ICE in output_die, at dwarf2out.c:6702

--- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-03 11:07 --- Confirmed. Reduced testcase (compile with "-g"): = namespace N { struct A {} a; typedef A B; void foo() { struct C { C(B) {} } c

[Bug other/17108] Missed opportunity for strength reduction

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|NEW

[Bug c++/18285] New: [4.0 regression] multiple types in typedef not rejected

The following invalid line of code is accepted by mainline's C++ frontend: == typedef void int char void double X; == The regression was introduced in June: : Search converges between 2004-06-24-trunk (#471) and 2004-06-26-tr

[Bug c++/7740] builtins, and functions marked as extern "C++" with incorrect "C" linkage

--- Additional Comments From joerg dot richter at pdv-fs dot de 2004-11-03 08:20 --- In a recent discussion on comp.lang.c++.moderated was this example to give bar "C++" linkage and foo "C" linkage. But g++ gives them both "C" linkage. It might be anonther instance of this problem. e

[Bug c/17913] [4.0 Regression] ICE jumping into statement expression

--- Additional Comments From loki at inf dot u-szeged dot hu 2004-11-03 08:17 --- I made some changes in the patch. I hope that it will be satisfying. http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00130.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913