[Bug tree-optimization/17679] [4.0 Regression] Aliasing problem with ivopts

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz 2004-10-18 06:46 --- Subject: Re: [4.0 Regression] Aliasing problem with ivopts > Zdenek are you going to apply the patch, it has been approved? the patch was approved, but after thinking about it more, I

[Bug c++/17743] dependent expressions in attributes

--- Additional Comments From bkoz at redhat dot com 2004-10-18 05:23 --- Subject: Re: dependent expressions in attributes >Is this a showstopper for tr1 work? Not that I can see. From what I can tell, tr1::array is going to require default-constructable types. I think the library h

[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding

--- Additional Comments From bkorb at veritas dot com 2004-10-18 05:06 --- Subject: Re: Bug in vendor /usr/include/net/if.h needs fixincluding giovannibajo at libero dot it wrote: > > --- Additional Comments From giovannibajo at libero dot it 2004-10-16 03:30 > --- > CC'i

[Bug libgcj/17903] Incorrect SHA result

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-18 04:36 --- Hmm, these tests fail on powerpc-darwin7.4.0, see and but they don't fail on po

[Bug regression/17919] [4.0 Regression] ICE at /cgraphunit.c:2907

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-18 04:31 --- I see that this looks fixed: except that the testsuite looks in bad shape. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17919

[Bug rtl-optimization/17752] Hot/cold basic block partitioning optimization has problems

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-18 04:21 --- I pinged them, hopefully someone will look into them soon :). -- What|Removed |Added Targe

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

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

[Bug other/10270] gccbug's echo displays '-n' instead of no-line-break

--- Additional Comments From dberlin at dberlin dot org 2004-10-18 04:08 --- Subject: Re: gccbug's echo displays '-n' instead of no-line-break On Mon, 2004-10-18 at 04:03 +, pinskia at gcc dot gnu dot org wrote: > --- Additional Comments From pinskia at gcc dot gnu dot o

[Bug other/10270] gccbug's echo displays '-n' instead of no-line-break

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-18 04:05 --- Just to tell you the GNATs 4.0 regression does not have this patch in it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10270

[Bug other/10270] gccbug's echo displays '-n' instead of no-line-break

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-18 04:03 --- Hmm, this file really comes from GNU GNATS, maybe we should update it from there and you should submit the patch to there if it is not already changed. -- What|Removed

[Bug middle-end/17549] [4.0 Regression] 15% increase in codesize with C code

--- Additional Comments From giovannibajo at libero dot it 2004-10-18 03:57 --- With today's mainline: 3.4.1 -Os: textdata bss dec hex filename 17971 0 0 179714633 susan.o 4.0.0 -Os: textdata bss dec hex filename 21213 0

[Bug tree-optimization/17679] [4.0 Regression] Aliasing problem with ivopts

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-18 03:55 --- Zdenek are you going to apply the patch, it has been approved? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17679

[Bug c++/17743] dependent expressions in attributes

--- Additional Comments From giovannibajo at libero dot it 2004-10-18 03:51 --- Subject: Re: dependent expressions in attributes >> template >> struct A { >> char foo __attribute__((aligned(__alignof__(T; >> }; > > I do care. Is this a showstopper for tr1 work? Giovanni Baj

[Bug target/15286] ICE cause by reload

--- Additional Comments From dje at watson dot ibm dot com 2004-10-18 01:50 --- Subject: Re: ICE cause by reload (subreg:SI (reg:DI)) normally isn't a problem, except when reg:DI is assigned to an FPR. If reg:DI was assigned to an FPR, CLASS probably is NON_SPECIAL_REGS (enco

[Bug bootstrap/16865] False alarm about use of uninitialized variable breaks bootstrap at -O3

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-18 00:26 --- Here is some more with --enable-intermodule which means a huge amount more inlining: /Users/pinskia/src/local/gcc/gcc/cfgbuild.c: In function 'make_edges': /Users/pinskia/src/local/gcc/gcc/cfgbuild.c:289: wa

[Bug tree-optimization/17656] [4.0 Regression] internal compiler error: in replace_immediate_uses, at tree-ssa.c:1041

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-18 00:09 --- *** Bug 18043 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug tree-optimization/18043] ICE in replace_immediate_uses

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-18 00:09 --- *** This bug has been marked as a duplicate of 17656 *** -- What|Removed |Added

Re: inline of inline

> > In this example > > static inline int f (int x) { return x + 1; } > > static inline int g (int x, inline int f (int x)) > { return 1 + f (x); } > > int h (int x) > { return g (x, f); } > > is h supposed to optimize to return x + 2 or supposed to actually call > f. Here

inline of inline

In this example static inline int f (int x) { return x + 1; } static inline int g (int x, inline int f (int x)) { return 1 + f (x); } int h (int x) { return g (x, f); } is h supposed to optimize to return x + 2 or supposed to actually call f. Here's what I get with current

[Bug tree-optimization/18043] New: ICE in replace_immediate_uses

char buf[64]; void bar (int); void foo (void) { int i; const char *ext = 0; for (i = 1; i < 3; i++) { if (i == 1) ext = "extern "; bar (i); __builtin_strcpy (buf, ext); bar (i); } } ICEs at -O2 on x86_64-redhat-linux (but likely any other target). In:

[Bug middle-end/17967] [4.0 Regression] Expand is considered slower? (remove_useless_stmts is considered part of expand)

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-17 22:55 --- As said before this patch fixes this regression but cause some optimizations regression because fold does not fold &a[0] + 1 into &a[1] but only fold_stmt (I might be able to remove the fold_stmt on the

[Bug tree-optimization/17529] [4.0 Regression] ICE in get_indirect_ref_operands

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-17 22:53 --- The patch fixes this regressions but causes other because some of the infrastructor in GCC rejects &variable[0] is not a constant when it is. -- What|Removed |Added ---

[Bug tree-optimization/18040] [4.0 Regression] ICE in for_each_index, at tree-ssa-loop-im.c:178

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-17 22:19 --- Here is another example which works: int PyObject_IsTrue(); struct object_base { void ptr() const; }; struct object : public object_base { void ptr1() const; typedef void (object::*bool_type)() const

[Bug tree-optimization/18040] [4.0 Regression] ICE in for_each_index, at tree-ssa-loop-im.c:178

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-17 22:17 --- The front-end is doing something funny for this example where there should be no cast, it is still creating a "void (object_base::*)() const" type. int PyObject_IsTrue(); struct object_base { void ptr(

[Bug tree-optimization/18040] [4.0 Regression] ICE in for_each_index, at tree-ssa-loop-im.c:178

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-17 22:06 --- Could someone tell me why the cast is there for the testcase in the first place it seems wrong (except that we are converting between void (object_base::*)() and void (object::*)(). ) -- http://gcc.gnu

[Bug tree-optimization/17529] [4.0 Regression] ICE in get_indirect_ref_operands

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-17 22:02 --- I reverted the patch which fixed this so reopening. -- What|Removed |Added Statu

[Bug c/18042] [4.0 regression] does not handle struct initializer

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-17 22:00 --- I reverted the patch which caused this. -- What|Removed |Added Status|ASSIGNED

[Bug c/18042] [4.0 regression] does not handle struct initializer

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-17 21:53 --- I caused it, fixing it right now. -- What|Removed |Added AssignedTo|unassigned at gc

[Bug c/18042] [4.0 regression] does not handle struct initializer

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2004-10-17 21:51 --- Created an attachment (id=7369) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7369&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18042

[Bug c/18042] New: [4.0 regression] does not handle struct initializer

The testcase is rejected with > gcc -c const.c const.c:25: error: initializer element is not constant the testcase is fine with any previous version of gcc. This is mainline from 20041017, a version from about two month ago was ok. -- Summary: [4.0 regression] does not han

[Bug tree-optimization/17133] [4.0 Regression] wrong code with -ftree-lim

--- Additional Comments From giovannibajo at libero dot it 2004-10-17 20:29 --- Zdenek, maybe it's time to ping this patch? -- What|Removed |Added AssignedTo|unassig

[Bug tree-optimization/17790] [4.0 Regression] Significant compile time increases for sixtrack with tree LICM and IV optimization

--- Additional Comments From rakdver at gcc dot gnu dot org 2004-10-17 20:16 --- IM problem seems to be caused by some inefficiency in store motion (I suspect scanning loop repeatedly for various insignificant virtual operands). Anyway, the patch for PR 17133 (complete rewrite of store

[Bug middle-end/17925] [4.0 Regression] Gotos loses their locations

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-17 20:08 --- Fixed. This is one of the last regressions caused by the tree-ssa merge. -- What|Removed |Added -

[Bug middle-end/17925] [4.0 Regression] Gotos loses their locations

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-17 20:07 --- Subject: Bug 17925 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-10-17 20:07:36 Modified files: gcc: ChangeLog cfgexpand.c Log message:

[Bug target/16884] [3.4 Regression] [fweb related] bug while initialising variables

.4-branc (version 3.4.3 20041017 (prerelease)). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16884

[Bug middle-end/17549] [4.0 Regression] 25% increase in codesize (3.3.4 -> 4.0.0 20040917)

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-17 19:55 --- The IV-OPT part is fixed now but there was another regression size regression here IIRC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17549

[Bug tree-optimization/17790] [4.0 Regression] Significant compile time increases for sixtrack with tree LICM and IV optimization

--- Additional Comments From dberlin at gcc dot gnu dot org 2004-10-17 19:44 --- the ivopts stuff may have been fixed by your ivopts patch for important candidates. i'll try maincr again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17790

[Bug tree-optimization/17790] [4.0 Regression] Significant compile time increases for sixtrack with tree LICM and IV optimization

--- Additional Comments From rakdver at gcc dot gnu dot org 2004-10-17 19:20 --- Actually mainrc.f does not run out of memory, but causes segfault during garbage collection (infinite recursion). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17790

[Bug tree-optimization/17607] [4.0 Regression] Segfault on a gimmicky case label with -Os

--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-17 19:19 --- Indeed fixed by the patch that fixes PR 17560. -- What|Removed |Added BugsThisDependsOn|1

[Bug tree-optimization/18040] [4.0 Regression] ICE in for_each_index, at tree-ssa-loop-im.c:178

--- Additional Comments From rakdver at gcc dot gnu dot org 2004-10-17 19:18 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01398.html -- What|Removed |Added

[Bug tree-optimization/17607] [4.0 Regression] Segfault on a gimmicky case label with -Os

-- Bug 17607 depends on bug 17552, which changed state. Bug 17552 Summary: [4.0 Regression] Infinite recursion in analyze_scalar_evolution http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17552 What|Old Value |New Value --

[Bug tree-optimization/17704] [4.0 Regression] Infinite recursion in tree-scalar-evolution with -Os

-- Bug 17704 depends on bug 17552, which changed state. Bug 17552 Summary: [4.0 Regression] Infinite recursion in analyze_scalar_evolution http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17552 What|Old Value |New Value --

[Bug tree-optimization/17883] [4.0 Regression] segfault on hashtab insert in scalar evolution

-- Bug 17883 depends on bug 17552, which changed state. Bug 17552 Summary: [4.0 Regression] Infinite recursion in analyze_scalar_evolution http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17552 What|Old Value |New Value --

[Bug tree-optimization/17560] [4.0 Regression] Infinite recursion in tree-scalar-evolution with -Os

--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-17 19:16 --- *** Bug 17552 has been marked as a duplicate of this bug. *** -- What|Removed |Added BugsT

[Bug tree-optimization/17552] [4.0 Regression] Infinite recursion in analyze_scalar_evolution

--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-17 19:16 --- This is indeed fixed by the patch that fixes PR 17560. *** This bug has been marked as a duplicate of 17560 *** -- What|Removed |Added -

[Bug tree-optimization/17790] [4.0 Regression] Significant compile time increases for sixtrack with tree LICM and IV optimization

--- Additional Comments From rakdver at gcc dot gnu dot org 2004-10-17 19:05 --- I cannot reproduce the ivopts problem on daten.f (ivopts are <2% for me, which is not great, but also not so terrible). IM problem reproduces. mainrc.f currently runs out of memory for me. -- http://gc

[Bug middle-end/18008] [4.0 Regression] Duplicate mask on bitfield insertion

--- Additional Comments From roger at eyesopen dot com 2004-10-17 19:02 --- There are clearly a number of problems exposed by this PR (constant folding issues, x86 backend issues, RTL simplification issues, etc...) My personal pick of which is the worst of these is that get_inner_referen

[Bug c++/16301] [3.4 regression] ICE with strong using

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-17 17:41 --- Subject: Bug 16301 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-10-17 17:41:01 Modified files: gcc/testsuite : Change

[Bug c++/16301] [3.4 regression] ICE with strong using

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-17 17:40 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug tree-optimization/17672] [4.0 Regression] ICE in build_classic_dist_vector

--- Additional Comments From dberlin at gcc dot gnu dot org 2004-10-17 17:38 --- Patch here http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01360.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17672

[Bug tree-optimization/17529] [4.0 Regression] ICE in get_indirect_ref_operands

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-17 17:25 --- Subject: Bug 17529 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-10-17 17:25:00 Modified files: gcc/testsuite : ChangeLog Added files: gcc/t

[Bug tree-optimization/17529] [4.0 Regression] ICE in get_indirect_ref_operands

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-17 17:24 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED

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

--- Additional Comments From dorit at il dot ibm dot com 2004-10-17 17:13 --- Subject: Re: [4.0 Regression] ICE in vect_transform_stmt, at tree-vectorizer.c:2625 (testcase included) I'm testing a patch that fixes this problem - will submit it later today ( the problem is related to up

[Bug middle-end/18041] OR of two single-bit bitfields is inefficient

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-17 17:05 --- Confirmed about the extra and (I don't know why the extra load is in x86). -- What|Removed |Added

[Bug middle-end/18041] OR of two single-bit bitfields is inefficient

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-17 17:01 --- Hmm, there is only one load on PPC (with either side): same bit layout as below: lwz r0,0(r3) rlwinm r2,r0,0,31,31 rlwinm r9,r0,31,31,31 or r2,r2,r9 rlwimi r0,r2,0,31,

[Bug middle-end/18038] addition in a multibit bitfield is inefficient

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-17 16:58 --- Again for PPC: struct B { unsigned :30; unsigned b : 2; }; Confirmed. -- What|Removed |Added

[Bug middle-end/18041] New: OR of two single-bit bitfields is inefficient

Consider: struct B { unsigned bit0 : 1; unsigned bit1 : 1; }; void foo (struct B *b) { b->bit0 = b->bit0 | b->bit1; } ./cc1 -O2 -fomit-frame-pointer -mregparm=3 generates foo: movb(%eax), %dl <- one load movb%dl, %cl shrb%cl orl %edx, %ecx

[Bug tree-optimization/18040] [4.0 Regression] ICE in for_each_index, at tree-ssa-loop-im.c:178

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-17 16:29 --- Here is something which is slightly smaller: int PyObject_IsTrue(); struct object_base { void ptr() const; }; struct object : public object_base { typedef void (object::*bool_type)() const; inline op

[Bug target/16884] [3.4 Regression] [fweb related] bug while initialising variables

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-17 16:24 --- *** Bug 18039 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug target/18039] ICE w/ -O3

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-17 16:24 --- This was fixed two days after you downloaded the 3.4 branch :). This is a dup of bug 16884. *** This bug has been marked as a duplicate of 16884 *** -- What|Removed |Ad

[Bug tree-optimization/18040] [4.0 Regression] ICE in for_each_index, at tree-ssa-loop-im.c:178

--- Additional Comments From rakdver at gcc dot gnu dot org 2004-10-17 16:23 --- The problem is that is_gimple_addressable uses handled_component_p that allows casts. I am testing a patch for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18040

[Bug tree-optimization/18040] [4.0 Regression] ICE in for_each_index, at tree-ssa-loop-im.c:178

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-17 16:17 --- The bug shows up in .sra: :; ! D.1674 = (struct { object:: * __pfn; int __delta; ! }) iftmp.0; ! D.1675_16 = D.1674.__pfn; if (D.1675_16 != 0B) goto ; else goto ; :; --- ...

[Bug tree-optimization/18040] [4.0 Regression] ICE in for_each_index, at tree-ssa-loop-im.c:178

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-17 16:11 --- Here is the reduced testcase to make your investigation easier: typedef struct _object PyObject; int PyObject_IsTrue(PyObject *); class object; typedef PyObject* (object::*bool_type)() const; struct object

[Bug tree-optimization/18040] [4.0 Regression] ICE in for_each_index, at tree-ssa-loop-im.c:178

--- Additional Comments From rakdver at gcc dot gnu dot org 2004-10-17 16:01 --- Does not seem to be directly caused by ivopts. The statement on that ivopts fail looks like x_1 = ((cast) variable).field which is not a valid gimple. I am investigating further. -- http://gcc.gnu.or

[Bug c++/9230] Friend functions defined within template class definitions are injected into the namespace scope at template instantiation time even if there is no declaration.

--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-10-17 15:52 --- Working on friend class name injection. It's very likely the fix also applies to friend function. -- What|Removed |Added -

[Bug c++/17122] Unable to compile friend operator within template

--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-10-17 15:21 --- Will look at it while fixing friend class lookup. -- What|Removed |Added AssignedTo

getting memory errors when natively bulding native gnu gcc 3.3.2 compiler on PQ2FADS-VR with 32 MB DRAM memory

Hi, I am trying to natively build native gnu gcc 3.3.2 compiler from the source tar ball on PQ2FADS-VR (MPC 8275) with 32 MB DRAM memory, running "vanilla" Linux 2.6.8-rc4 kernel (built by me) with NFS mounted root file system ("/fadsroot") and getting memory errors (see listing below). For such

[Bug c++/17122] Unable to compile friend operator within template

--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-10-17 15:19 --- Reopen this bug since friend class and friend function bugs will be addressed separately. PR1016 is likely to be fixed before this one. -- What|Removed |Added -

[Bug c++/1016] [DR 166] friend class declarations not observing namespace rules.

--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-10-17 15:17 --- With patches: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01321.html http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01372.html GCC gives: pr1016.C:8: error: field 'b_' has incomplete type which is s

[Bug tree-optimization/18040] [4.0 Regression] ICE in for_each_index, at tree-ssa-loop-im.c:178

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-17 14:47 --- This is a bug in the IV-OPTS (reducing the testcase right now). -- What|Removed |Added

[Bug c++/7874] [3.3/3.4/4.0 regression] g++ finds friend functions defined in class-definition but not declared in the enclosing namespace

--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-10-17 14:41 --- Working on friend class name injection. It's very likely the fix also applies to friend function. -- What|Removed |Added --

[Bug c++/15410] Wrong template signature accepted in friend declaration

--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-10-17 14:09 --- Patches submitted. Both patches are required to fix this bug. http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01321.html http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01372.html -- What|

[Bug c++/14513] Friend name injection problem (implicit declaration)

--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-10-17 14:08 --- Patches submitted. Both patches are required to fix this bug. http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01321.html http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01372.html -- What|

[Bug middle-end/18040] [4.0 Regression] ICE in for_each_index, at tree-ssa-loop-im.c:178

--- Additional Comments From giovannibajo at libero dot it 2004-10-17 13:34 --- Kazu, make sure the fill the missing fields when confirming a bug. Especially the regression status is very important. -- What|Removed |Added

[Bug middle-end/18040] ICE in for_each_index, at tree-ssa-loop-im.c:178

--- Additional Comments From kazu at cs dot umass dot edu 2004-10-17 13:06 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Eve

[Bug middle-end/18040] ICE in for_each_index, at tree-ssa-loop-im.c:178

--- Additional Comments From aj at gcc dot gnu dot org 2004-10-17 12:37 --- Created an attachment (id=7368) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7368&action=view) Preprocessed and compressed source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18040

[Bug middle-end/18040] New: ICE in for_each_index, at tree-ssa-loop-im.c:178

Compiling boost I get the following ICE: /usr/lib/gcc/i586-suse-linux/4.0.0/cc1plus -fpreprocessed function.ii -quiet -dumpbase function.cpp -mtune=pentium -auxbase-strip bin/boost/libs/python/build/libboost_python.so/gcc/release/shared-linkable-true/function.o -O3 -Wall -Wno-inline -version -ftem

[Bug middle-end/18030] OR is inefficient in 2-bit bitfield

--- Additional Comments From giovannibajo at libero dot it 2004-10-17 11:26 --- Approved for 4.1. -- What|Removed |Added OtherBugsDependingO||1765

[Bug middle-end/18029] an xor of a single bit bitfield is inefficient

--- Additional Comments From giovannibajo at libero dot it 2004-10-17 11:26 --- Approved for 4.1. -- What|Removed |Added OtherBugsDependingO||1765

[Bug c++/15172] [3.3/3.4 regression] Copy constructor optimization in aggregate initialization

--- Additional Comments From giovannibajo at libero dot it 2004-10-17 11:21 --- > There is a recent posting to comp.lang.c++.moderated about the same problem, > with the subject "Bitwise copy during aggregate initialization (a compiler > bug?)". ... which is here: http://tinyurl.com/4

[Bug target/18039] ICE w/ -O3

--- Additional Comments From ralf_corsepius at rtems dot org 2004-10-17 09:09 --- Created an attachment (id=7367) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7367&action=view) Stripped down, preprocessed source code to trigger the ICE. -- http://gcc.gnu.org/bugzilla/show_bug

[Bug target/18039] New: ICE w/ -O3

The following ICE occurs for gcc-3.4.3pre when using -O3. It does not occur with -O2 or below: # avr-rtems4.7-gcc -v -Wall -O3 -otmp.o -c ata.i Reading specs from /opt/rtems-4.7/lib/gcc/avr-rtems4.7/3.4.3/specs Configured with: ../gcc-3.4.3/configure --prefix=/opt/rtems-4.7 --mandir=/opt/rtems-4.7

[Bug libgcj/18036] Bad interaction between interpreter and Class.forName()

--- Additional Comments From mark at gcc dot gnu dot org 2004-10-17 08:52 --- Created an attachment (id=7366) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7366&action=view) Small ClassLoader test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18036

[Bug c++/17743] dependent expressions in attributes

--- Additional Comments From gdr at cs dot tamu dot edu 2004-10-17 07:50 --- Subject: Re: dependent expressions in attributes On Sat, 17 Oct 2004, giovannibajo at libero dot it wrote: | OK, I fixed part of this for 4.0. The missing part is when the expression in | attributes is depende