[Bug preprocessor/20356] [4.0/4.1 Regression] New #include_next behaviour breaks limits.h

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-30 06:36 --- Subject: Bug 20356 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-30 06:35:45 Modified files: libcpp : Change

[Bug preprocessor/20348] [4.0/4.1 Regression] File not included when file with same name is included before

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-30 06:35 --- Subject: Bug 20348 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-30 06:35:45 Modified files: libcpp : Change

[Bug preprocessor/20348] [4.0/4.1 Regression] File not included when file with same name is included before

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-30 06:28 --- Subject: Bug 20348 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-30 06:28:22 Modified files: libcpp : ChangeLog gcc/testsuite : C

[Bug preprocessor/20356] [4.0/4.1 Regression] New #include_next behaviour breaks limits.h

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-30 06:28 --- Subject: Bug 20356 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-30 06:28:22 Modified files: libcpp : ChangeLog gcc/testsuite : C

[Bug rtl-optimization/23579] [4.1 regression] rtl-optimization/23478 breaks Ada for ia64

-- What|Removed |Added CC||phython at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/sh

[Bug rtl-optimization/23601] [4.1 Regression] reload may drop non-call exception information

-- What|Removed |Added CC||phython at gcc dot gnu dot ||org Summary|reload may d

[Bug rtl-optimization/23601] reload may drop non-call exception information

--- Additional Comments From phython at gcc dot gnu dot org 2005-08-30 05:59 --- This is happening for me as well. -- What|Removed |Added Status|UNCONFIRMED

[Bug target/23602] [4.1 regression] 1081 test failures in libjava, when configured for i486-linux

--- Additional Comments From rth at gcc dot gnu dot org 2005-08-30 02:46 --- That said, I can't get any test to fail when run by hand. libtool compile and link line pasted out of the log, as well as the associated LD_LIBRARY_PATH. What am I missing? -- http://gcc.gnu.org/bugzilla/sh

[Bug target/23602] [4.1 regression] 1081 test failures in libjava, when configured for i486-linux

--- Additional Comments From rth at gcc dot gnu dot org 2005-08-30 02:09 --- Confirmed. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot

[Bug libgcj/23495] java.lang.String.equals is suboptimal

--- Additional Comments From greenrd at greenrd dot org 2005-08-30 01:17 --- (In reply to comment #7) > This seems like something glibc's memcmp should be doing also, could > you report a bug to glibc about this comparison? Actually I was wrong - it's not glibc's memcmp that's being use

[Bug c++/23296] Combination of -finstrument-functions and -O3 produces incorrect results

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-30 00:39 --- *** Bug 23629 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug c/23629] -finstrument-functions + -finline-functions produces incorrect output.

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-30 00:39 --- *** This bug has been marked as a duplicate of 23296 *** -- What|Removed |Added

[Bug c/23629] New: -finstrument-functions + -finline-functions produces incorrect output.

When a function is inlined, the corresponding calls to __cyg_profile_func_{enter,exit} are passed the address of caller. Below is an example. Addresses shown in "Enter"/"Exit" messages all point to main(). If you add -fno-inline-functions, then this problem goes away. - Makefile -- CC=gc

[Bug c++/23608] -Wsign-compare and const propagation

--- Additional Comments From gdr at integrable-solutions dot net 2005-08-30 00:09 --- Subject: Re: -Wsign-compare and const propagation "bangerth at dealii dot org" <[EMAIL PROTECTED]> writes: | As annoying as this is, I don't consider this a bug. It may be classified | as an enhance

[Bug c++/23608] -Wsign-compare and const propagation

--- Additional Comments From br1 at internet dot com dot uy 2005-08-29 23:23 --- I don't know much about const in C, just C++. I just wanted to have this request entered in your database, as a possible enhancement, of course. Regards, Bruno -- http://gcc.gnu.org/bugzilla/show_bug.

[Bug target/23548] [4.1 Regression] libstdc++ tests fail: could not split insn

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 23:19 --- I think this is really the same as PR 23601 also, just exposed in a different place. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23548

[Bug c++/23608] -Wsign-compare and const propagation

--- Additional Comments From bangerth at dealii dot org 2005-08-29 23:10 --- What Andrew is trying to say is that in C, even variables that are marked 'const' can be modified. Thus, the compiler can't (naively, i.e. without using flow analysis) determine that 'i' or 'ic' have the val

[Bug c++/23608] -Wsign-compare and const propagation

--- Additional Comments From pinskia at physics dot uc dot edu 2005-08-29 23:01 --- Subject: Re: -Wsign-compare and const propagation On Aug 29, 2005, at 6:24 PM, br1 at internet dot com dot uy wrote: > > --- Additional Comments From br1 at internet dot com dot uy > 2005-08-29

Re: [Bug c++/23608] -Wsign-compare and const propagation

On Aug 29, 2005, at 6:24 PM, br1 at internet dot com dot uy wrote: --- Additional Comments From br1 at internet dot com dot uy 2005-08-29 22:24 --- Could you point me to the section in the standard? I thought warning were a quality of implementation matter. No you misunderstood

[Bug rtl-optimization/23478] [3.4 regression] Miscompilation due to reloading of a var that is also used in EH pad

--- Additional Comments From sje at cup dot hp dot com 2005-08-29 22:51 --- The patch for this bug appears to be triggering PR 23548. -- What|Removed |Added

[Bug target/23548] [4.1 Regression] libstdc++ tests fail: could not split insn

--- Additional Comments From sje at cup dot hp dot com 2005-08-29 22:50 --- I have reproduced this bug on IA64 Linux and also verified that it does not happen if the patch for PR 23478 is removed. -- What|Removed |Added ---

[Bug c++/23608] -Wsign-compare and const propagation

--- Additional Comments From br1 at internet dot com dot uy 2005-08-29 22:24 --- Could you point me to the section in the standard? I thought warning were a quality of implementation matter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23608

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

--- Additional Comments From geoffk at gcc dot gnu dot org 2005-08-29 22:21 --- There was a comment in here about making visibility control happen at the namespace level. How would this work with, say, 'vector'? I would expect that if -fvisibility=hidden is set, then this instantiat

[Bug libstdc++/23528] [3.4 Regression] Wrong default allocator in ext/hash_map

--- Additional Comments From pcarlini at suse dot de 2005-08-29 22:14 --- Fixed with: 2005-08-29 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/23528 Port from HEAD/4_0-branch: 2004-07-28 Matt Austern <[EMAIL PROTECTED]> * include/ext/hashtable.h: Us

[Bug c++/23628] Typeinfo comparison code easily breaks shared libs

--- Additional Comments From mmarcus at emarcus dot org 2005-08-29 21:57 --- Maybe I should rephrase my concern as the following question. Suppose a gcc user is building an application and some shared libraries that depend on third party libraries. Under what circumstances can he safel

[Bug c++/23628] Typeinfo comparison code easily breaks shared libs

--- Additional Comments From pinskia at physics dot uc dot edu 2005-08-29 21:32 --- Subject: Re: Typeinfo comparison code easily breaks shared libs On Aug 29, 2005, at 5:27 PM, mmarcus at emarcus dot org wrote: > > --- Additional Comments From mmarcus at emarcus dot org > 2005-

Re: [Bug c++/23628] Typeinfo comparison code easily breaks shared libs

On Aug 29, 2005, at 5:27 PM, mmarcus at emarcus dot org wrote: --- Additional Comments From mmarcus at emarcus dot org 2005-08-29 21:27 --- The point is that you are saying all symbols are hidden by default so you are marking the RTTI as hidden too which is a good idea for your ow

[Bug c++/23628] Typeinfo comparison code easily breaks shared libs

--- Additional Comments From mmarcus at emarcus dot org 2005-08-29 21:27 --- Suppose for a moment that the boost authors can be convinced to add a bunch of GCC-specific pragmas to their code. Would the problem then be solved? What if a client is using a third party library (maybe a lar

[Bug middle-end/23623] volatile keyword changes bitfield access size from 32bit to 8bit

--- Additional Comments From falk at debian dot org 2005-08-29 21:10 --- (In reply to comment #0) > Access to bf1.b is correctly done as 32-bits (lwz/stw opcodes), bf2.b is > accessed as 8-bits (lbz/stb opcodes). GCC3.4.3 shows the same behaviour, can't > go back any further. The same h

[Bug c++/23628] Typeinfo comparison code easily breaks shared libs

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 21:08 --- >From the sounds of it, it sounds like boost headers are incorrectly not having >the push/pop mechanism either when they should. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23628

[Bug target/23602] [4.1 regression] 1081 test failures in libjava, when configured for i486-linux

--- Additional Comments From debian-gcc at lists dot debian dot org 2005-08-29 21:05 --- the test results from CVS 20050607 look ok, those from CVS 20050719 show the failures. Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23602

[Bug c++/23628] Typeinfo comparison code easily breaks shared libs

--- Additional Comments From mmarcus at emarcus dot org 2005-08-29 21:00 --- Looks like our changes collided. I am requesting the bug be reopened pending answer to the above question. -- What|Removed |Added

[Bug c++/23628] Typeinfo comparison code easily breaks shared libs

--- Additional Comments From mmarcus at emarcus dot org 2005-08-29 20:59 --- Ok, marking the standard library headers for default visibility sounds like it would address one aspect of this report. I'm not sure that it addresses the other aspect. Are you saying that this will somehow also

[Bug libfortran/23598] iostat handling after library error return

-- What|Removed |Added Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23598

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 20:57 --- *** Bug 23628 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug c++/23628] Typeinfo comparison code easily breaks shared libs

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 20:57 --- Yes this is a dup of bug 19664 for the pop/push in libstdc++ as coding the includes as: #pragma GCC visibility push(default) #include #include #include #pragma GCC visibility pop makes this works just f

[Bug libfortran/23598] iostat handling after library error return

--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-08-29 20:56 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug c++/23628] Typeinfo comparison code easily breaks shared libs

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 20:52 --- (In reply to comment #9) > Sorry, I was a bit sloppy--I didn't remove all intermediate layers from my > test > environment. I will explore this further. In any case, if I explicitly invoke > g++ -fvisibilit

[Bug libmudflap/18244] libmudflap installs include/mf-runtime.h in version-independent path

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fche at redhat dot com |dot org | Status|NEW

[Bug libfortran/23598] iostat handling after library error return

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-29 20:48 --- Subject: Bug 23598 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-29 20:48:38 Modified files: libgfortran: Change

[Bug c++/23628] Typeinfo comparison code easily breaks shared libs

--- Additional Comments From mmarcus at emarcus dot org 2005-08-29 20:44 --- Sorry, I was a bit sloppy--I didn't remove all intermediate layers from my test environment. I will explore this further. In any case, if I explicitly invoke g++ -fvisibility=hidden t.cc && ./a.out the "Oops" c

[Bug libfortran/23598] iostat handling after library error return

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-29 20:40 --- Subject: Bug 23598 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-29 20:40:02 Modified files: libgfortran: ChangeLog libgfortran/io : l

[Bug c++/23628] Typeinfo comparison code easily breaks shared libs

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 20:34 --- I still reproduce this problem, I am starting to think something is wrong some where else and not with gcc as -fvisibility=default is default and I am using dynamic libraries as shown below and I know no

[Bug c++/23628] Typeinfo comparison code easily breaks shared libs

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 20:31 --- One more thing -fvisibility=default is default anyways. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23628

[Bug c++/23628] Typeinfo comparison code easily breaks shared libs

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 20:30 --- Also GCC's testsuite would have caught this by now if the testcase fails as there are testcases in the testsuite for this kind of thing. Please give the output of "gcc -v". -- http://gcc.gnu.org/bugzi

[Bug c++/23628] Typeinfo comparison code easily breaks shared libs

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 20:27 --- This just works just fine with: GNU C++ version 4.1.0 20050822 (experimental) (powerpc-apple-darwin7.9.0) compiled by GNU C version 4.1.0 20050822 (experimental). GGC heuristics: --param ggc-min-expa

[Bug c++/23628] Typeinfo comparison code easily breaks shared libs

--- Additional Comments From mmarcus at emarcus dot org 2005-08-29 20:23 --- Actually, I'll just paste the darwin test case here. On this platform, libstdc++ is a sharedlib. The following code: ### #include #include #include int main (int argc, char * const argv[]) { std::

[Bug c++/23628] Typeinfo comparison code easily breaks shared libs

--- Additional Comments From mmarcus at emarcus dot org 2005-08-29 20:18 --- This is for the case when the shared libraries are loaded statically. One test case can be found by following the link found in this post: . I will als

[Bug libmudflap/18244] libmudflap installs include/mf-runtime.h in version-independent path

--- Additional Comments From gerald at pfeifer dot com 2005-08-29 20:05 --- Frank, would you mind having a look at this? -- What|Removed |Added CC|

[Bug c++/23273] gcc doesn't compile the stl headers

--- Additional Comments From pinskia at physics dot uc dot edu 2005-08-29 20:01 --- Subject: Re: gcc doesn't compile the stl headers On Aug 29, 2005, at 3:59 PM, jacob dot navia at ants dot com wrote: > > OK? > > Should we file a new bug report? Yes but this is most likely PR 23167.

Re: [Bug c++/23273] gcc doesn't compile the stl headers

On Aug 29, 2005, at 3:59 PM, jacob dot navia at ants dot com wrote: OK? Should we file a new bug report? Yes but this is most likely PR 23167. -- Pinski

[Bug c++/23273] gcc doesn't compile the stl headers

--- Additional Comments From jacob dot navia at ants dot com 2005-08-29 19:58 --- Subject: RE: gcc doesn't compile the stl headers Hi OK, Since you tell me that is not standard C++, a developer (Mr Prasad Kommoju) went through all the min/max usage in our code and changed them. Afte

[Bug c++/23628] Typeinfo comparison code easily breaks shared libs

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 19:58 --- Oh, one more thing, we need a testcase because this is hard to reproduce. -- What|Removed |Added -

[Bug c++/23628] Typeinfo comparison code easily breaks shared libs

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 19:55 --- Usually when this is brought up, we ask how shared libraries are loaded, they need to be loaded with global when calling dlopen (if you loading dynamicly). If the shared libraries are loaded staticly, t

[Bug c++/23628] New: Typeinfo comparison code easily breaks shared libs

There is a problem in GCC's typeinfo comparison code where it just compares the address of the symbol, not what the symbol points at. Hence if the linker chooses one typeinfo instance in one binary and another in another binary, even though they are the same typeinfo it returns different results.

[Bug tree-optimization/23619] Missed pre opportunity

--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-29 19:31 --- mine -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dberlin at gcc d

[Bug tree-optimization/23619] Missed pre opportunity

--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-29 19:31 --- Subject: Bug 23619 Zdenek, the following patch (bootstrapping now) should fix your bug 23619.diff --- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-29 19:31 --- Created an att

[Bug tree-optimization/23619] Missed pre opportunity

--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-29 19:29 --- not a dupe -- What|Removed |Added Status|RESOLVED|UNCONFIRME

[Bug tree-optimization/23509] [4.1 regression] ICE with ivopts

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 18:09 --- *** Bug 23627 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug tree-optimization/23627] [4.1 Regression] ICE: tree check: expected ssa_name, have unlt_expr in verify_ssa, at tree-ssa.c:746

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 18:09 --- A dup of bug 23509. *** This bug has been marked as a duplicate of 23509 *** -- What|Removed |Added -

[Bug tree-optimization/23627] [4.1 Regression] ICE: tree check: expected ssa_name, have unlt_expr in verify_ssa, at tree-ssa.c:746

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 18:03 --- Reduced testcase: typedef unsigned U16; U16*t1orig[15]; void CalculateLut (long dx, U16 *lowBuffer, U16*t0) { int i; U16*darkBuffer = __null; for (i=0; ihttp://gcc.gnu.org/bugzill

[Bug tree-optimization/23627] New: ICE: tree check: expected ssa_name, have unlt_expr in verify_ssa, at tree-ssa.c:746

I get an ICE if I compile the small program below with the actual snapshot. Michael Cieslinski gcc41m -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.1-20050826/configure --prefix=/usr/local/gcc41m -- program-suffix=41m --with-arch=opteron --enable-languages=c

[Bug middle-end/23408] [4.1 Regression] ICE in cgraph_decide_inlining_incrementally (using freed GC memory)

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 17:49 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug middle-end/23408] [4.1 Regression] ICE in cgraph_decide_inlining_incrementally (using freed GC memory)

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-29 17:49 --- Subject: Bug 23408 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-29 17:48:59 Modified files: gcc: ChangeLog ipa-inline.c gcc/t

[Bug tree-optimization/23626] [4.1 Regression] ICE after cunrolling

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

[Bug tree-optimization/23626] [4.1 Regression] ICE after cunrolling

-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23626

[Bug tree-optimization/23626] New: [4.1 Regression] ICE after cunrolling

The following C++ code currently fails at -O2 -fnon-call-exceptions: extern "C" void abort (); int a[3]; int f () { int sum = 0; try { for (int i = 0; i < 3; ++i) sum += a[i]; } catch (...) { abort (); } return sum; } I think someone forgets to cleanup the eh regions

[Bug rtl-optimization/23567] [3.4/4.0/4.1 regression] if-conversion causes wrong code

-- What|Removed |Added CC||rth at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org

[Bug tree-optimization/23622] Dom jump threading at -O1 confuses branch prediction

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 16:20 --- If we run CCP right after DOM and do a DCE, we get a cleaned up loops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23622

[Bug middle-end/23623] volatile keyword changes bitfield access size from 32bit to 8bit

-- What|Removed |Added Known to fail||3.1 3.3 4.1.0 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23623

[Bug libstdc++/23578] Implement resolution of DR 464 [Ready]

--- Additional Comments From pcarlini at suse dot de 2005-08-29 16:12 --- Fixed for 4.1. -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug libstdc++/23578] Implement resolution of DR 464 [Ready]

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-29 16:11 --- Subject: Bug 23578 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-29 16:11:20 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/inclu

[Bug tree-optimization/23625] [4.1 Regression] ICE: in bsi_after_labels, at tree-flow-inline.h:758

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 16:10 --- Confirmed, reduced testcase: typedef long INT32; void find_best_colors () { int ic0, ic1, ic2; INT32 * bptr; INT32 dist1; INT32 dist2; INT32 xx1; for (ic0 = (1<<(5 -3))-1;ic0 >= 0;ic0--) { for (ic1 = (1<<(

[Bug ada/21053] Warnings from init.c

--- Additional Comments From charlet at gcc dot gnu dot org 2005-08-29 15:48 --- Should be fixed now. -- What|Removed |Added Status|NEW |

[Bug ada/21053] Warnings from init.c

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-29 15:41 --- Subject: Bug 21053 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-29 15:41:45 Modified files: gcc/ada: s-stalib.adb decl.c fe.h init.c Log

[Bug tree-optimization/23625] [4.1 Regression] ICE: in bsi_after_labels, at tree-flow-inline.h:758

-- What|Removed |Added Keywords||ice-on-valid-code Known to fail||4.1.0 Known to work|

[Bug middle-end/23623] volatile keyword changes bitfield access size from 32bit to 8bit

-- What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23623

[Bug c++/23624] [3.4/4.0/4.1 Regression] ICE: internal compiler error: in invert_truthvalue, at fold-const.c:2697

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 15:35 --- Reduced testcase: template void f() { int *t, i; t[i ? 0 : i]; } -- What|Removed |Added --

[Bug tree-optimization/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191

--- Additional Comments From dank at kegel dot com 2005-08-29 15:34 --- I think Jim's fold fix/workaround is at http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00371.html I'm using it locally now, and it seems at first glance to get us past this problem. -- http://gcc.gnu.org/bugzilla/

[Bug c++/23624] [3.4/4.0/4.1 Regression] ICE: internal compiler error: in invert_truthvalue, at fold-const.c:2697

-- What|Removed |Added Keywords||ice-on-valid-code Known to fail||3.4.0 4.0.0 4.1.0 Known to work|

[Bug tree-optimization/23625] ICE: in bsi_after_labels, at tree-flow-inline.h:758

--- Additional Comments From micis at gmx dot de 2005-08-29 15:26 --- Created an attachment (id=9613) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9613&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23625

[Bug tree-optimization/22348] [4.0 Regression] Execution continues past end of for loop end condition with optimisation enabled

--- Additional Comments From rakdver at gcc dot gnu dot org 2005-08-29 15:25 --- The same workaround should work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22348

[Bug tree-optimization/23625] New: ICE: in bsi_after_labels, at tree-flow-inline.h:758

When I compile qt334 with the actual snapshot (20050826) of gcc41 I get an ICE when I use -O2 -ftree-loop-linear -ftree-vectorize. last working snapshot is: gcc-4.1-20050723 first failing snapshot is: gcc-4.1-20050730 Michael Cieslinski gcc41m -c -O2 -ftree-loop-linear -ftree-vectorize -o jqu

[Bug tree-optimization/23619] Missed pre opportunity

--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-29 15:23 --- Subject: Re: Missed pre opportunity > Disabling reassoc, it knows that p + q is antic over the backedge. > Which means it knows it *could* insert it. Okay, it determines it's not fully available in block

[Bug tree-optimization/23619] Missed pre opportunity

--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-29 15:15 --- Subject: Re: Missed pre opportunity On Mon, 2005-08-29 at 12:46 +, rakdver at gcc dot gnu dot org wrote: > --- Additional Comments From rakdver at gcc dot gnu dot org 2005-08-29 > 12:46 --- >

[Bug c++/23624] New: ICE: internal compiler error: in invert_truthvalue, at fold-const.c:2697

Attempting to compile the following example (with no explicit command-line arguments) results in an ICE: --- typedef unsigned char RESET_OCCUR_DT; typedef struct { RESET_OCCUR_DT*pResetOccur; } DintgRec; template void f() { int i, resetScalar;

[Bug c/23506] [4.0 Regression] Bad array access in DEF_GCC_BUILTIN

--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-29 15:02 --- Maybe the patch could be backported to 4.0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23506

[Bug target/22077] [4.0 Regression] vec_all_eq does not produce good result

--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-29 15:02 --- Maybe the patch could be backported to 4.0? -- What|Removed |Added CC|

[Bug rtl-optimization/15248] [4.0 Regression] Reload may generate stores to read-only memory

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-29 14:58 --- Subject: Bug 15248 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-29 14:41:20 Modified files: gcc: reload

[Bug target/21169] [4.0 regression] ICE in reload_cse_simplify_operands with -fnon-call-exceptions -fPIC -O2

--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-29 14:55 --- Can anybody do a regression hunt on mainline? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21169

[Bug rtl-optimization/15248] [4.0 Regression] Reload may generate stores to read-only memory

--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-29 14:41 --- All branches now have the "quick fix". -- What|Removed |Added Status|NEW

[Bug tree-optimization/22348] [4.0 Regression] Execution continues past end of for loop end condition with optimisation enabled

--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-29 14:37 --- Could this apply to 4.0 as well? -- What|Removed |Added CC|

[Bug bootstrap/21268] [4.0/4.1 Regression] Bootstrap, configuration problem and insn-conditions.c

--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-29 14:36 --- Patch applied. -- What|Removed |Added Status|ASSIGNED|RESOLV

[Bug c++/23099] [4.0/4.1 regression] ICE in build_simple_base_path, at cp/class.c:460

--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-08-29 14:18 --- Fixed in 4.0.2. -- What|Removed |Added Status|ASSIGNED|RESO

[Bug c++/23099] [4.0/4.1 regression] ICE in build_simple_base_path, at cp/class.c:460

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-29 14:15 --- Subject: Bug 23099 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-29 14:09:08 Modified files: gcc/cp : cp-tree.h decl.c init.c name-lookup.c

[Bug bootstrap/21268] [4.0/4.1 Regression] Bootstrap, configuration problem and insn-conditions.c

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-29 14:05 --- Subject: Bug 21268 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-29 14:04:18 Modified files: gcc: Change

[Bug c/23623] New: volatile keyword changes bitfield access size from 32bit to 8bit

struct { unsigned int b : 1; } bf1; volatile struct { unsigned int b : 1; } bf2; void test(void) { bf1.b = 1; bf2.b = 1; } Access to bf1.b is correctly done as 32-bits (lwz/stw opcodes), bf2.b is accessed as 8-bits (lbz/stb opcodes). GCC3.4.3 shows the same behaviour, can't go back a

[Bug c++/22488] [4.1 Regression] C++ generates incorrect overlapping fields

--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-29 13:57 --- I've changed the summary to match what the actual bug appears to be, at least until a C++ person tells us whether it's supposed to be generating these overlaps or not. -- What|Removed

[Bug c++/23099] [4.0/4.1 regression] ICE in build_simple_base_path, at cp/class.c:460

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-29 13:56 --- Subject: Bug 23099 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-29 13:56:48 Modified files: gcc/cp : cp-tre

[Bug c++/22488] [4.1 Regression] ICE: in first_vi_for_offset, at tree-ssa-structalias.c:2585 with -O3

--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-29 13:54 --- Subject: Re: [4.1 Regression] ICE: in first_vi_for_offset, at tree-ssa-structalias.c:2585 with -O3 On Mon, 2005-08-29 at 12:13 +, rguenth at gcc dot gnu dot org wrote: > --- Additional Comm

  1   2   >