[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

--- Additional Comments From jvdelisle at verizon dot net 2005-02-11 08:18 --- For what its worth, with the files all in the one directory. g77 passes on -O0 and -O1, and hangs on -O2 and -O3. Test set up is as in Comment #33. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900

[Bug middle-end/19875] bug when installing R on OSF1

--- Additional Comments From k dot maillard at oxagen dot co dot uk 2005-02-11 08:36 --- Subject: RE: bug when installing R on OSF1 Thank you for your answer. I have installed R on a LINUX machine instead. -Original Message- From: pinskia at gcc dot gnu dot org [mailto:[EMAI

[Bug c++/19762] [3.4 regression] ICE in invalid explicit instantiation of a destructor

--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-11 08:44 --- Mark, I still get the failure on the 3.4 branch: dPR19762.cc:2: error: wrong number of template arguments (0, should be 1) dPR19762.cc:1: error: provided for `template > struct A' dPR19762.cc:2: error: ISO

[Bug c++/19666] [3.3/3.4 Regression] Trouble with prt-to-members: rejects-valid/ICE in fold_convert

--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-11 09:55 --- Patch here: -- What|Removed |Added

[Bug middle-end/19858] [4.0 Regression] ICE on simple SSE code

--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-11 09:59 --- Patch here: -- What|Removed |Added

[Bug rtl-optimization/18560] better optimalization of EOR/MOV block.

--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-02-11 10:15 --- The new register allocator (new-ra) has been removed because it was buggy and there were no plans to fix it. I was using it to show that the initial MOV was an unrelated issue. Your code snippet shows tha

[Bug rtl-optimization/18560] better optimalization of EOR/MOV block.

--- Additional Comments From pluto at pld-linux dot org 2005-02-11 10:47 --- (In reply to comment #4) > The new register allocator (new-ra) has been removed because it was buggy and > there were no plans to fix it. > I was using it to show that the initial MOV was an unrelated issue. > Y

[Bug tree-optimization/19899] New: ICE: tree check: expected real_cst, have integer_cst in const_binop, at fold-const.c:1490 with -ftree-vectorize -msse2

/tmp/gcc4/libexec/gcc/i686-pc-linux-gnu/4.0.0/cc1 -quiet -v render.c -quiet -dumpbase render.c -msse2 -auxbase render -O -ftree-vectorize -o render.s -version GNU C version 4.0.0 20050211 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.0.0 20050211 (experimental). GGC

[Bug rtl-optimization/18560] better optimalization of EOR/MOV block.

--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-02-11 11:13 --- I've linked this to the register-allocator meta-bug -- What|Removed |Added BugsThisDepends

[Bug rtl-optimization/18427] [meta-bug] We need a better register allocator

--- Additional Comments From pluto at pld-linux dot org 2005-02-11 11:27 --- CC /me -- What|Removed |Added CC||pluto at pld-linux

[Bug ada/19900] New: ACATS c391002 c432002 ICE categorize_ctor_elements_1

This was introduced very recently, happens on x86 and x86_64. /home/guerby/work/gcc/build/build-20050210T230923/gcc/xgcc -c -B/home/guerby/work/gcc/build/build-20050210T230923/gcc/ -gnatws -O2 -I/home/guerby/work/gcc/build/build-20050210T230923/gcc/testsuite/ada/acats/support c391002.adb +

[Bug ada/19901] New: ACATS c85006e ICE block does not dominate

This happened very recently, at least on x86 and x86_64 /home/guerby/work/gcc/build/build-20050210T230912/gcc/xgcc -c -B/home/guerby/work/gcc/build/build-20050210T230912/gcc/ -gnatws -O2 -I/home/guerby/work/gcc/build/build-20050210T230912/gcc/testsuite/ada/acats/support c85006e.adb c85006e.adb: In

[Bug ada/18818] ACATS cd10002 fails at runtime

--- Additional Comments From laurent at guerby dot net 2005-02-11 11:44 --- Now fixed on x86 and x86_64 (recent commit). -- What|Removed |Added Status|UNCONFIRME

[Bug fortran/18714] Runtime hang in LAPACK routine SLAMC1 - in Quetzal benchmark suite

--- Additional Comments From giovannibajo at libero dot it 2005-02-11 11:47 --- Not a GCC bug. -- What|Removed |Added Status|UNCONFIRMED |RESOLVE

[Bug ada/19902] New: ACATS cxa3004 cxb3006 fail at compile time "ambiguous expression"

Probably related to recent changes, might be an ACATS problem. /home/guerby/work/gcc/build/build-20050210T230912/gcc/xgcc -c -B/home/guerby/work/gcc/build/build-20050210T230912/gcc/ -gnatws -O2 -I/home/guerby/work/gcc/build/build-20050210T230912/gcc/testsuite/ada/acats/support cxa3004.adb cxa3004.

[Bug ada/19903] New: ACATS cxa4006 cxa4017 ada.string.(un)bounded fail at runtime

May be linked to recent commits, happens on x86 and x86_64, unanalyzed yet. ,.,. CXA4006 ACATS 2.5 05-02-11 01:15:38 CXA4006 Check that the subprograms defined in package Ada.Strings.Bounded are available, and that they produce correct results. * CXA4006 Exc

Re: [Bug ada/19902] New: ACATS cxa3004 cxb3006 fail at compile time "ambiguous expression"

> Probably related to recent changes, might be an ACATS problem. Right, these tests should be removed from the repository, or modified. We've informed the ACAA about this issue (incompatibility with Ada 2005). Arno

[Bug ada/19902] ACATS cxa3004 cxb3006 fail at compile time "ambiguous expression"

--- Additional Comments From charlet at adacore dot com 2005-02-11 12:03 --- Subject: Re: New: ACATS cxa3004 cxb3006 fail at compile time "ambiguous expression" > Probably related to recent changes, might be an ACATS problem. Right, these tests should be removed from the repository,

[Bug debug/19769] [4.0 Regression] GCC produces wrong dwarf2 output that breaks gdb

--- Additional Comments From aph at gcc dot gnu dot org 2005-02-11 12:07 --- This is a workaround for everyone that needs to use debugging on HEAD. If we can't get this bug fixed soon something like this will need to be committed. Index: include/posix-threads.h ==

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-11 12:09 --- (In reply to comment #39) > One suspect is this code snippet from gcc/config/ia64.c : > > static bool > ia64_rtx_costs (rtx x, int code, int outer_code, int *total) > case DIV: > case UDIV: >

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-11 12:10 --- (In reply to comment #40) > ** On entry to DGEEV parameter number 1 had an illegal value I had that one, as well. There are some routines which occur more than once. Copying the files from the rig

[Bug target/19300] [4.0 Regression] PCH failures on sparc-linux

--- Additional Comments From phython at gcc dot gnu dot org 2005-02-11 12:48 --- Created an attachment (id=8174) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8174&action=view) copy some code from pa-host.c This seems to fix some pch failures on sparc64-linux. I don't trust my

[Bug fortran/19904] New: Division by zero leads to error

I want to define a parameter that contains a nan. When I use a division by zero in a parameter statement, gfortran aborts with an error instead of setting the parameter to nan. (The Intel Fortran compiler accepts this parameter statement without warning.) subroutine x implicit none do

[Bug c/19881] strange warning about alloca

--- Additional Comments From bruno at clisp dot org 2005-02-11 13:13 --- > the warning is not the FSF's gcc, you two should have filed it with Redhat > instead. You're right: Current gcc CVS ("gcc version 4.0.0 20050211 (experimental)") doesn't sho

[Bug c/19881] strange warning about alloca

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 13:29 --- (In reply to comment #4) > > the warning is not the FSF's gcc, you two should have filed it with Redhat > > instead. > > You're right: Current gcc CVS ("gcc ver

[Bug c++/19891] [4.0 Regression] Covariant returns are broken

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

[Bug tree-optimization/19899] ICE: tree check: expected real_cst, have integer_cst in const_binop, at fold-const.c:1490 with -ftree-vectorize -msse2

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 13:39 --- Confirmed. -- What|Removed |Added CC||dorit at i

[Bug ada/19902] ACATS cxa3004 cxb3006 fail at compile time "ambiguous expression"

-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-

[Bug ada/19900] ACATS c391002 c432002 ICE categorize_ctor_elements_1

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 13:41 --- This looks like a front-end problem: /* We don't expect more than one element of the union to be initialized. Not sure what we should do otherwise... */ gcc_assert (TREE_CHA

[Bug tree-optimization/19901] ACATS c85006e ICE block does not dominate

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 13:43 --- Most likely different IV selection make this show up so this is a latent bug in ivopts. See and others, Kenner was trying to fix this for a while now. --

[Bug tree-optimization/19901] ACATS c85006e ICE block does not dominate

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 13:47 --- http://gcc.gnu.org/ml/gcc/2004-11/msg01200.html http://gcc.gnu.org/ml/gcc/2004-12/msg00144.html And more -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19901

[Bug fortran/19904] Division by zero leads to error

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 13:50 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW E

[Bug tree-optimization/18437] vectorizer failed for matrix multiplication

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 14:12 --- We now get: t3.c:9: note: not vectorized: can't determine dependence between: (*D.1338_16)[0] and (*D.1336_10)[i_53] -- What|Removed |Added ---

[Bug tree-optimization/18439] vectorizer failed for vector normalization

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 14:19 --- Really there are two problems which cause the missed vectorizor. One is that we don't scalarize the static variables that well. So that is the bug which really needs to be fixed first and really is not

[Bug tree-optimization/19905] New: Extra V_MAY_DEF on a static variable whose address is not taken (we should be able to move the load out of the loop)

The following two functions should be the same (note don't compile with -ffast-math or even -fno- math-errno as sqrt is marked as pure) #define NUMPOINTS 20 float opoints[NUMPOINTS]; double sqrt (double); void NormalizeVectors (void) { int i, r; float s, x, y, z; static float d = 0.0;

[Bug tree-optimization/18439] vectorizer failed for vector normalization

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 14:47 --- I filed PR 19905 for the missed optimization not really related (but blocking) the tree vectorizor. -- What|Removed |Added --

[Bug tree-optimization/19905] Extra V_MAY_DEF on a static variable whose address is not taken (we should be able to move the load out of the loop)

-- What|Removed |Added OtherBugsDependingO||18439 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19905

[Bug c/19906] New: multilib setup fails when building canadian

The mklibgcc fails to setup the multilib directories correctly when building canadian. I have a patch that works for me and is covered under the TimeSys copyright assignment. -- Summary: multilib setup fails when building canadian Product: gcc Version: 3.4.1

[Bug c/19906] multilib setup fails when building canadian

--- Additional Comments From greg dot weeks at timesys dot com 2005-02-11 14:57 --- Created an attachment (id=8175) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8175&action=view) proposed patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19906

[Bug c/19906] multilib setup fails when building canadian

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 15:01 --- This is a dup of bug 12984. Could you attach the patch there and send it to gcc-patches? *** This bug has been marked as a duplicate of 12984 *** -- What|Removed |Adde

[Bug bootstrap/12984] libgcc*.so files are mis-installed when doing a candian cross

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 15:01 --- *** Bug 19906 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug c/19906] multilib setup fails when building canadian

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 15:01 --- Also could you make a patch for the mainline first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19906

[Bug c++/17805] too liberal operator lookup

--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-11 15:20 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00453.html -- What|Removed |Added

[Bug bootstrap/12984] libgcc*.so files are mis-installed when doing a candian cross

--- Additional Comments From greg dot weeks at timesys dot com 2005-02-11 15:24 --- The patch does apply with some fuzz to the mainline CVS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12984

[Bug java/19907] New: Incorrect code generated for ManifestElement.java

The bytecode compiler generates incorrect code for the attached .class file. -- Summary: Incorrect code generated for ManifestElement.java Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Compon

[Bug java/19907] Incorrect code generated for ManifestElement.java

--- Additional Comments From aph at gcc dot gnu dot org 2005-02-11 16:37 --- Created an attachment (id=8177) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8177&action=view) ManifestElement.class -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19907

[Bug java/19908] New: Inlining of final fields incompatible with Sun's implementation

The issue reported on the mailing list http://gcc.gnu.org/ml/java/2005-02/msg00031.html shows that gcj will not inline a primitive final field that is i initialised where it is declared, whereas Sun's implementation will (1.5). The output of FinalFieldChange is Ng Keng Yap, 27 of IQ=150 fr

[Bug java/19907] Incorrect code generated for ManifestElement.java

--- Additional Comments From aph at gcc dot gnu dot org 2005-02-11 16:41 --- The method ArrayList.add() return a boolean, so the bytecode compiler generates a temp of type promoted_boolean. Unfortunately, the same temp is used later as an int. This problem arises because promoted boole

[Bug java/19908] Inlining of final fields incompatible with Sun's implementation

--- Additional Comments From dog at bluezoo dot org 2005-02-11 16:41 --- Created an attachment (id=8178) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8178&action=view) The Person class -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19908

[Bug java/19908] Inlining of final fields incompatible with Sun's implementation

--- Additional Comments From dog at bluezoo dot org 2005-02-11 16:42 --- Created an attachment (id=8179) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8179&action=view) The main class to reproduce the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19908

[Bug java/19908] Inlining of final fields incompatible with Sun's implementation

-- What|Removed |Added Attachment #8178|text/x-java-source |text/plain mime type|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19908

[Bug java/19908] Inlining of final fields incompatible with Sun's implementation

-- What|Removed |Added Attachment #8179|text/x-java-source |text/plain mime type|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19908

[Bug java/19908] Inlining of final fields incompatible with Sun's implementation

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 16:54 --- As dicussed there are still questions if this is wrong code or not. Yes this is not the same as Sun's implementation but that means nothing really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19908

[Bug c++/16529] [3.4/4.0 regression] ICE for: namespace-alias shall no be declared as the name of any other entity

--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-11 16:58 --- Btw, fix and testcase are here (wrongly attributed to PR16489): http://gcc.gnu.org/ml/gcc-cvs/2004-08/msg00026.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16529

[Bug c++/11762] namespace aliasing ICE in warn_extern_redeclared_static

--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-11 17:04 --- *** This bug has been marked as a duplicate of 16529 *** -- What|Removed |Added

[Bug c++/16529] [3.4/4.0 regression] ICE for: namespace-alias shall no be declared as the name of any other entity

--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-11 17:04 --- *** Bug 11762 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug fortran/19904] Division by zero leads to error

--- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2005-02-11 17:10 --- Gfortran is a Fortran 95 compiler, and AFAIK gfortran's behavior conforms to the Fortran 95 standard, because it has no allowance for floating point exception. Someday, gfortran may/will su

[Bug c++/19253] [3.4/4.0 regression] bad error message / ICE for invalid template parameter

--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-11 17:12 --- Mark, the first code snippet in comment #3 still crashes on mainline. So this is not yet fixed on mainline. -- What|Removed |Added -

[Bug c++/19253] [3.4/4.0 regression] bad error message / ICE for invalid template parameter

--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-11 17:13 --- Sorry, I meant comment #2, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19253

[Bug c++/19755] [3.3/3.4/4.0 Regression] -Wmissing-braces doesn't warn anymore

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-11 17:15 --- Subject: Bug 19755 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-11 17:15:51 Modified files: gcc/cp : ChangeLog decl.c gcc/testsui

[Bug fortran/19904] Division by zero leads to error

--- Additional Comments From schnetter at aei dot mpg dot de 2005-02-11 17:17 --- Actually, gfortran handles nans correctly (according to the IEEE standard) in all other cases. I can e.g. generate a nan through the expression a/b, if I only hide from the compiler the fact that b is ze

[Bug c++/19755] [3.3/3.4/4.0 Regression] -Wmissing-braces doesn't warn anymore

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-11 17:20 --- Subject: Bug 19755 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-02-11 17:20:03 Modified files: gcc/testsuite : Change

[Bug c++/19755] [3.3 Regression] -Wmissing-braces doesn't warn anymore

--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-02-11 17:22 --- Fixed in GCC 3.4.4. -- What|Removed |Added Status|ASSIGNED|

[Bug c++/18604] [3.4/4.0 Regression] Strong using lookup conflicts

--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-02-11 17:23 --- Jason, will you be able to look into this PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18604

[Bug fortran/18918] Eventually support the co-array f95 extension in gfortran

--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-02-11 17:24 --- You might want to check out the "global arrays" toolkit at http://www.emsl.pnl.gov/docs/global/ga.html GA implements the same programming model as Co-Array Fortran, but it's a library, so any standard F95 co

[Bug c++/19878] [4.0 Regression] ICE in import_export_decl

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW

[Bug c++/19403] [4.0 Regression] name lookup is broken with friends

--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-11 17:37 --- This looks like a duplicate of PR 1016 to me. -- What|Removed |Added CC|

[Bug fortran/19904] Division by zero leads to error

--- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2005-02-11 17:44 --- You are probably right that my example does not conform to the standard, because I don't use equilance() and I whipped up the example in a minute without inspection of its conformance. Anyw

[Bug c++/19894] pointer-to-void member not rejected in template

--- Additional Comments From bangerth at dealii dot org 2005-02-11 17:44 --- Quite naively, I would say that this could even be ok, just that there will never be a member variable the address of which one could initialize this pointer-to-member with. Do you have chapter and verse where

[Bug c++/19253] [3.4/4.0 regression] bad error message / ICE for invalid template parameter

--- Additional Comments From bangerth at dealii dot org 2005-02-11 17:50 --- Volker, you seem to be on a quest to make gcc accept without crashing even the most obnoxious wrong code snippets without ICEing. How do you generate all these snippets? (As a sidenote, even if they are te

[Bug c/19909] New: verify-flow-info: wrong frequency ...

gcc-3.4.3 internal compiler error at -O3 -fno-strict-aliasing, disappears with -O2. (linux-2.4.29, glibc-2.3.3-200410112214, binutils-2.15.92.0.2). gcc -v (CFLAGS="-march=i686 -O2" ../gcc-3.4.3/configure ...): Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/specs Configured with: ../gcc-3

[Bug debug/19885] [4.0 Regression] avr dwarf-2 support is broken for head 4.0

--- Additional Comments From bjoern dot m dot haase at web dot de 2005-02-11 19:00 --- I have tried to trace back the date when dwarf2 support startet to fail. So far I have found out that it was broken already at december 5th 2004. Yours, Björn -- http://gcc.gnu.org/bugzil

[Bug debug/19885] [4.0 Regression] avr dwarf-2 support is broken for head 4.0

--- Additional Comments From bjoern dot m dot haase at web dot de 2005-02-11 19:04 --- Subject: Re: [4.0 Regression] avr dwarf-2 support is broken for head 4.0 Am Freitag, 11. Februar 2005 00:36 schrieb ericw at evcohs dot com: > --- Additional Comments From ericw at evcohs dot com

[Bug tree-optimization/19910] New: ICE with -ftree-loop-linear

The following gets an ICE with -O3 -ftree-loop-linear: int x[6][5][4]; int y[6][5][4]; void initx(void) { int a,b,c; int index = 0; for(a = 5; a >=2; a--) for (b = (a - 1); b >=1; b--) for (c = (b - 1); c >=0; c--) x[a][b][c] = index++; } void inity(void) { int d,e,f; i

[Bug target/17993] Error in dwarf2 debug output of bitfield members

-- What|Removed |Added CC||bjoern dot m dot haase at ||web dot de http://gcc.gnu.org/bugzi

[Bug target/17994] avr-gcc does not output a dwarf2 .debug_frame section

-- What|Removed |Added CC||bjoern dot m dot haase at ||web dot de http://gcc.gnu.org/bugzi

[Bug rtl-optimization/19909] verify-flow-info: wrong frequency ...

-- What|Removed |Added Component|c |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19909

[Bug rtl-optimization/19909] verify-flow-info: wrong frequency ...

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 19:29 --- We need the preprocessed source. Read . -- What|Removed |Added

[Bug target/19087] Overflowed address in dwarf debug line information

-- What|Removed |Added CC||bjoern dot m dot haase at ||web dot de http://gcc.gnu.org/bugzi

[Bug target/10768] ICEs on compilation of ada support library for avr

--- Additional Comments From ericw at evcohs dot com 2005-02-11 19:38 --- Bernd, does this still fail on the most recent HEAD? Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10768

[Bug ada/19632] x86_64 RHE3 internal error: segmentation fault

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-11 20:22 --- Subject: Bug 19632 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-11 20:22:25 Modified files: gcc/cp : ChangeLog pt.c Log message:

[Bug libstdc++/19911] New: Using std::string find the n field always causes nothing to be found

This is for all flavors of find. According to the documentation I can find. #include #include using namespace std; int main(int argc, char **argv) { string test("this should be a bunch of words"); size_t p = test.find("s"); // correct at 3 cerr << "p = " << p << ", npos = " << st

[Bug fortran/19904] Division by zero leads to error

-- What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19904

[Bug c++/19403] [4.0 Regression] name lookup is broken with friends

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 20:34 --- (In reply to comment #13) > This looks like a duplicate of PR 1016 to me. It might be a dup bug the example in this bug was able to compile in 3.4.0 and before. -- http://gcc.gnu.org/bugzilla/show_bug.

[Bug libstdc++/19911] Using std::string find the n field always causes nothing to be found

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 20:46 --- No string.find (const char *s, size_type pos, size_t n) returns the same as: string.find(string(s, n), pos) which means you are allocating a string with length 5 but the string is really only of lenght 1 so

[Bug java/19907] Incorrect code generated for ManifestElement.java

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 20:50 --- Patch here: . -- What|Removed |Added

[Bug java/19834] Eclipse bytecode miscompiled with -O --indirect-dispatch

--- Additional Comments From mckinlay at redhat dot com 2005-02-11 20:56 --- 19907 is a dupe of this. *** This bug has been marked as a duplicate of 19907 *** -- What|Removed |Added

[Bug java/19907] Incorrect code generated for ManifestElement.java

--- Additional Comments From mckinlay at redhat dot com 2005-02-11 20:56 --- *** Bug 19834 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug libstdc++/19911] Using std::string find the n field always causes nothing to be found

--- Additional Comments From grogers at cray dot com 2005-02-11 20:59 --- Subject: Re: Using std::string find the n field always causes nothing to be found Okay, doesn't make much sense. The docs I found on the web all had it described as n being the number of characters past pos to

[Bug tree-optimization/19910] ICE with -ftree-loop-linear

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

[Bug middle-end/19858] [4.0 Regression] ICE on simple SSE code

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-11 21:08 --- Subject: Bug 19858 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-11 21:08:44 Modified files: gcc: ChangeLog fold-const.c gcc/t

[Bug tree-optimization/19910] ICE with -ftree-loop-linear

--- Additional Comments From dberlin at gcc dot gnu dot org 2005-02-11 21:09 --- This is caused by generating a complex linear offset in the transformed loop, which the "back to gcc" converter doesn't handle ATM, since they were never generated before. (I didn't completly minimize linea

[Bug c++/19666] [3.3/3.4 Regression] Trouble with prt-to-members: rejects-valid/ICE in fold_convert

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-11 21:10 --- Subject: Bug 19666 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-11 21:10:16 Modified files: gcc/testsuite : ChangeLog Added files: gcc/t

[Bug c++/19634] [4.0 regression] Infinite memory usage on Alpha

--- Additional Comments From rth at gcc dot gnu dot org 2005-02-11 21:10 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug libstdc++/19911] Using std::string find the n field always causes nothing to be found

--- Additional Comments From pcarlini at suse dot de 2005-02-11 21:11 --- I'm maintaining the string class, and Andrew is 100% right: please browse the standard (or any good book, such as Josuttis, if you like) instead of trusting "docs on the web" ;) -- http://gcc.gnu.org/bugzilla/s

[Bug c++/19666] [3.3/3.4 Regression] Trouble with prt-to-members: rejects-valid/ICE in fold_convert

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-11 21:13 --- Subject: Bug 19666 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-02-11 21:12:56 Modified files: gcc: Change

[Bug c++/19666] [3.3 Regression] Trouble with prt-to-members: rejects-valid/ICE in fold_convert

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 21:15 --- Fixed in the 3.4 branch, it is a rejects valid for the 3.3 branch but most likely will not get fixed there as many different places call convert instead of fold_convert on the 3.3 branch compared to the 3

[Bug middle-end/19858] [4.0 Regression] ICE on simple SSE code

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 21:16 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED

[Bug middle-end/19912] New: GCC does not disclose parentheses

GCC generates different codes for the both functions: int f1(int k) { return k*k+k; } int f2(int k) { return k*(k+1); } also the generated code for, say '(k*k+k) + (k*(k+1))' calculates the two parts independently and then sums them, whereas the code for '(k*k+k) + (k*k+k)' just calculates k*k

[Bug middle-end/19912] GCC does not disclose parentheses

--- Additional Comments From joseph at codesourcery dot com 2005-02-11 21:34 --- Subject: Re: New: GCC does not disclose parentheses On Fri, 11 Feb 2005, l_belev at yahoo dot com wrote: > GCC generates different codes for the both functions: > int f1(int k) { return k*k+k; } > int

  1   2   >