[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:[EMAIL PROTECTED] Sent: 10 February 2005 15:29 To: Karine Maillard Subject: [Bug middle-end/19875] bug when installing R on OSF1 -- What|Removed |Added Severity|critical|normal Component|fortran |middle-end GCC target triplet||alpha-dec-osf Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19875 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. This message contains confidential and potentially legally privileged information solely for its intended recipients and others may not distribute, copy or use it. If you have received this communication in error, please tell us by return email and delete it, and any copies of it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19875
[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 `templateint anonymous struct A' dPR19762.cc:2: error: ISO C++ forbids declaration of `type name' with no type dPR19762.cc:2: error: abstract declarator `int' used as declaration dPR19762.cc:2: internal compiler error: tree check: expected class 'd', have 'x' (error_mark) in do_decl_instantiation, at cp/pt.c:10671 Please submit a full bug report, [etc.] -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19762
[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: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00494.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19666
[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: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00450.html -- What|Removed |Added Keywords|ssemmx |patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19858
[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 that the rotate and the EOR are being merged, which is what this PR was about. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18560
[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. Your code snippet shows that the rotate and the EOR are being merged, which is what this PR was about. The PR is about initial eor/mov opt., not eor/rotate ;-) At this moment the comercial IAR compiler generates good code. The GCC should be good too :) reverse: 0x0D04 E0201860 EOR R1, R0, R0, ROR #16 0x0D08 E3C118FF BIC R1, R1, #0xFF 0x0D0C E1A01421 MOV R1, R1, LSR #8 0x0D10 E0210460 EOR R0, R1, R0, ROR #8 0x0D14 E12FFF1E BX LR -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18560
[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 heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
render.c: In function 'render':
render.c:2: internal compiler error: tree check: expected real_cst, have
integer_cst in const_binop, at fold-const.c:1490
Configured with: ../gcc/configure --prefix=/tmp/gcc4 --enable-languages=c
--disable-nls
void render()
{
float i;
for (i=1; i=0; i--) {}
i=1;
}
--
Summary: ICE: tree check: expected real_cst, have integer_cst in
const_binop, at fold-const.c:1490 with -ftree-vectorize
-msse2
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: commie1 at gmx dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19899
[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 dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18427
[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|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18818
[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 Exception raised in Test_Block. CXA4006 FAILED . ,.,. CXA4017 ACATS 2.5 05-02-11 01:16:04 CXA4017 Check that the subprograms defined in package Ada.Strings.Wide_Bounded are available, and that they produce correct results. * CXA4017 Exception raised in Test_Block. CXA4017 FAILED . -- Summary: ACATS cxa4006 cxa4017 ada.string.(un)bounded fail at runtime Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19903
[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, or modified. We've informed the ACAA about this issue (incompatibility with Ada 2005). Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19902
[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=8174action=view) copy some code from pa-host.c This seems to fix some pch failures on sparc64-linux. I don't trust my testing so far though. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |phython at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19300
[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 show the warning. So it appears to be a RedHat-only problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19881
[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_CHAIN (list) == NULL); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19900
[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 http://gcc.gnu.org/ml/gcc/2005-01/msg01093.html and others, Kenner was trying to fix this for a while now. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|ada |tree-optimization Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-11 13:43:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19901
[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 Ever Confirmed||1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2005-02-11 13:50:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19904
[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 Last reconfirmed|2004-11-12 02:43:04 |2005-02-11 14:12:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18437
[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 related to the vectorizor at all. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Last reconfirmed|2004-11-12 02:43:29 |2005-02-11 14:19:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18439
[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;
d += 0.2f;
if (d 4)
d = 0.0;
for (i=0; iNUMPOINTS; i++)
{
opoints[i] = sqrt (d);
}
}
void NormalizeVectors1 (void)
{
int i, r;
float s, x, y, z;
static float d = 0.0;
d += 0.2f;
if (d 4)
d = 0.0;
s = d;
for (i=0; iNUMPOINTS; i++)
{
opoints[i] = sqrt (s);
}
}
--
Summary: 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)
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19905
[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 BugsThisDependsOn||19905 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18439
[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 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: greg dot weeks at timesys dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-linux GCC host triplet: i686-timesys-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19906
[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=8175action=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 |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19906
[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 CC||greg dot weeks at timesys ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12984
[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 AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17805
[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 Component: java AssignedTo: aph at gcc dot gnu dot org ReportedBy: aph at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19907
[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=8177action=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 from Malaysia whereas Sun 1.5 outputs Ng Keng Yap, 27 of IQ=110 from Malaysia -- Summary: Inlining of final fields incompatible with Sun's implementation Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: minor Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dog at bluezoo dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org GCC host triplet: powerpc-apple-darwin7.7.0 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=8179action=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 Status|ASSIGNED|RESOLVED Resolution||DUPLICATE Target Milestone|--- |3.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11762
[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 CC||bkoz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16529
[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 support Technical Report ISO/IEC 15580: 1998(E), which will then permit the use of the ieee_arithmetic, ieee_features, and ieee_exceptions intrinsic modules. If you want to set a NaN in gfortran you can do, program test real nan integer duh equivalence (nan,duh) duh = z'FFC0' print*, nan end program test The question then becomes what are going to do with NaN? I suspect the gfortran's behavior of the numeric rational operation and numeric binary operation may give undefined behavior, which is again permitted by the Fortran 95 standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19904
[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 Summary|[3.4 regression] bad error |[3.4/4.0 regression] bad |message / ICE for invalid |error message / ICE for |template parameter |invalid template parameter http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19253
[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/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/warn: Wbraces1.C Log message: PR c++/19755 * decl.c (reshape_init): Issue warnings about missing braces. PR c++/19755 * g++.dg/warn/Wbraces1.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4622r2=1.4623 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gccr1=1.1361r2=1.1362 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5016r2=1.5017 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/warn/Wbraces1.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19755
[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 zero, so that it generates code that performs the division at run time, and does not try to evaluate it at compile time. Also, while your argument is correct that the Fortran 95 standard does not require nans to be handled correctly, your code is also undefined according to the Fortran 95 standard, because you use the variable nan without defining it: if you assign to an equivalenced storage an integer value, then you are only allowed to read out the integer value, and vice versa for the real value. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19904
[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 : ChangeLog gcc/cp : ChangeLog decl.c Added files: gcc/testsuite/g++.dg/warn: Wbraces1.C Log message: PR c++/19755 * decl.c (reshape_init): Issue warnings about missing braces. PR c++/19755 * g++.dg/warn/Wbraces1.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.359r2=1.3389.2.360 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/warn/Wbraces1.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3892.2.197r2=1.3892.2.198 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.1174.2.29r2=1.1174.2.30 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19755
[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|RESOLVED Resolution||FIXED Summary|[3.3/3.4/4.0 Regression] - |[3.3 Regression] -Wmissing- |Wmissing-braces doesn't warn|braces doesn't warn anymore |anymore | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19755
[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 compiler should do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918
[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 |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19878
[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||reichelt at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
[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. Anyway, if you want to make gfortran accept your code, constant folding is done in arith.c. I suggest that you add a -fallow_inf_nan option to gfortran and make the appropriate modifications to arith.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19904
[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 this is prohibited? W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19894
[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 technically regressions, I don't consider such artificial codes really important to fix. There are more important things, and we get this right for gcc 4.6.2, that'll be ok with me as well :-) W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19253
[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.4.3/configure --prefix=/usr --enable-shared --enable- threads=posix --enable-checking --enable-__cxa_atexit --enable-languages=c,c++ - -disable-nls Thread model: posix gcc version 3.4.3 gcc's error report: ../term /usr/X11R6/include /usr/src/gnuplot-4.0.0/gd1.3/include /usr/include/libpng12 /usr/local/include /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/include /usr/include End of search list. /usr/libexec/gcc/i686-pc-linux-gnu/3.4.3/cc1 -fpreprocessed plot3d.i -quiet - dumpbase plot3d.c -march=i686 -auxbase-strip plot3d.o -O3 -Wall -version -fno- strict-aliasing -o plot3d.s GNU C version 3.4.3 (i686-pc-linux-gnu) compiled by GNU C version 3.4.3. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 plot3d.c: In function `eval_3dplots': plot3d.c:1771: error: verify_flow_info: Wrong frequency of block 174 -1 plot3d.c:1771: internal compiler error: verify_flow_info failed I don't see any button on this bugzilla form to attach the preprocessed source file. I have it, ask me for it at mailto:[EMAIL PROTECTED] -- Summary: verify-flow-info: wrong frequency ... Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cgweav at email dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19909
[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/bugzilla/show_bug.cgi?id=19885
[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 2005-02-10 23:36 --- As an aside, DWARF2 is about to become the default debugging information used in WinAVR, for both Atmel's AVR Studio and for use with avr-gdb/avr-insight. So this one is crucial for having a successful 4.0.0 release for the avr target. Hi Eric, brief question: As far as I know you have monitored Thorleif Sandes attempts of getting the dwarf support working for avr-studio. Do you remember that it was necessary at the time to implement bug-fixes for getting it functional for gcc 3.4. ? Yours, Björn -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19885
[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;
int index = 0;
for(d = 5; d =2; d--)
for (e = (d - 1); e =1; e--)
for (f = (e - 1); f =0; f--)
y[d][e][f] = index++;
}
void foo() {
initx();
inity();
}
--
Summary: ICE with -ftree-loop-linear
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dalej at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin8.0.0
GCC host triplet: powerpc-apple-darwin8.0.0
GCC target triplet: powerpc-apple-darwin8.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19910
[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/bugzilla/show_bug.cgi?id=17993
[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/bugzilla/show_bug.cgi?id=17994
[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 http://gcc.gnu.org/bugs.html. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19909
[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/bugzilla/show_bug.cgi?id=19087
[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: PR c++/19632 * pt.c (get_mostly_instantiated_function_type): Save and restore flag_access_control instead of push/pop_access_scope. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4623r2=1.4624 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gccr1=1.974r2=1.975 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19632
[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 iostream
#include string
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 = string::npos endl;
p = test.find(s, 5); // correct at 5
cerr p = p , npos = string::npos endl;
p = test.find(s, 5, 5); // incorrect, should be 5 is npos
cerr p = p , npos = string::npos endl;
}
--
Summary: Using std::string find the n field always causes nothing
to be found
Product: gcc
Version: 3.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: grogers at cray dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19911
[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.cgi?id=19403
[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 this will not be able to find the string. This documented by 21.3.6.1 of the C++ standard. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19911
[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: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00521.html. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||patch, wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19907
[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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19834
[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 CC||mckinlay at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19907
[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 search. pinskia at gcc dot gnu dot org wrote: --- 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 this will not be able to find the string. This documented by 21.3.6.1 of the C++ standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19911
[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 gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-02-11 21:06:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19910
[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/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: 20050210-1.c Log message: PR middle-end/19858 * fold-const.c (make_bit_field_ref): If bitpos == 0 and bitsize is number of inner's bits, avoid creating a BIT_FIELD_REF. * gcc.c-torture/compile/20050210-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7449r2=2.7450 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gccr1=1.504r2=1.505 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5017r2=1.5018 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/20050210-1.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19858
[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 linear offset generation. If i did, you'd notice that this loop really goes from 5 to MAX (2, j) or something like that) Loop w step size = -1 linear offset: Linear expression: -i + j constant: 5 invariants: denominator: 1 lower bound: Linear expression: i - j constant: 0 invariants: denominator: 1 upper bound: Linear expression: i - j constant: -3 invariants: denominator: 1 Linear expression: i constant: -5 invariants: denominator: 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19910
[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/testsuite/g++.dg/other: ptrmem6.C Log message: PR c++/19666 2004-06-08 Andrew Pinski [EMAIL PROTECTED] * fold-const.c (fold_convert): Treat OFFSET_TYPE like POINTER_TYPE and INTEGER_TYPE. * gcc/testsuite/g++.dg/other/ptrmem6.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5018r2=1.5019 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/other/ptrmem6.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19666
[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 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19634
[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/show_bug.cgi?id=19911
[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: ChangeLog fold-const.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/other: ptrmem6.C Log message: PR c++/19666 2004-06-08 Andrew Pinski [EMAIL PROTECTED] * fold-const.c (fold_convert): Treat OFFSET_TYPE like POINTER_TYPE and INTEGER_TYPE. * gcc/testsuite/g++.dg/other/ptrmem6.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.797r2=2.2326.2.798 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.322.2.15r2=1.322.2.16 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.360r2=1.3389.2.361 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/other/ptrmem6.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19666
[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.4/4.0. -- What|Removed |Added Keywords|ice-on-valid-code, patch| Known to work|3.2.3 4.0.0 |3.2.3 4.0.0 3.4.4 Summary|[3.3/3.4 Regression] Trouble|[3.3 Regression] Trouble |with prt-to-members:|with prt-to-members: |rejects-valid/ICE in|rejects-valid/ICE in |fold_convert|fold_convert Target Milestone|3.4.4 |3.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19666
[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 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19858
[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+k once and then doubles it.
This is not the case with two other compilers i tested -
intel's icc and the microsoft's compiler.
I think that this way GCC is missing very important
and basic opportunities for optimizations.
For example there are many macros out there in the
wilderness, that heavily rely on such kind of
optimizations that disclose parentheses.
--
Summary: GCC does not disclose parentheses
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: l_belev at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19912
[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 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+k once and then doubles it.
Note that the first expression can involve undefined behavior when the
second doesn't, so transformations between these forms would be invalid
with -ftrapv and until we have internal overflow flags on expressions we
could only transform in one direction without -fwrapv.
(Consider k == -46341 with 32-bit int. The first expression involves
signed integer overflow, undefined behavior in ISO C which needs a trap
with -ftrapv, while the second doesn't.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19912
[Bug c++/19913] New: The wrong number of arguments have been specified for destructor.
Sourc code for t.cpp:
int main()
{
typedef int I;
I x = 1;
I *p = x;
p-I::~I(0);
return 0;
}
Expected Behaviour:
t.cpp, line 6.17: 1540-0215 (S) The wrong number of arguments have been
specified for ~I
Actual Behaviour:
None.
t.ii generated with -save-temps option
# 1 t.cpp
# 1 built-in
# 1 command line
# 1 t.cpp
int main()
{
typedef int I;
I x = 1;
I *p = x;
p-I::~I(0);
return 0;
}
Release:
GCC Version: 3.2.0
Environment:
System Type:
Reading specs from
/usr/local/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/specs
Configured with: /scratch/gcc-3.2/configure --prefix=/usr/local/gcc.3.2.0
--enable-threads=aix --disable-nls
Thread model: aix
gcc version 3.2
/usr/local/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/cpp0 -lang-c++
-D__GNUG__=3 -D__DEPRECATED -D__EXCEPTIONS -v -iprefix
/usr/local/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/ -D__GNUC__=3
-D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=0 -D__GXX_ABI_VERSION=102 -D_IBMR2
-D_POWER -D_LONG_LONG -D_AIX -D_AIX32 -D_AIX41 -D_AIX43 -D_AIX51 -D_IBMR2
-D_POWER -D_LONG_LONG -D_AIX -D_AIX32 -D_AIX41 -D_AIX43 -D_AIX51 -Asystem=unix
-Asystem=aix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D_XOPEN_SOURCE=500
-D_XOPEN_SOURCE_EXTENDED=1 -D_LARGE_FILE_API -D_ALL_SOURCE
-D__WCHAR_TYPE__=short unsigned int -D_ARCH_COM t.cpp t.ii
GNU CPP version 3.2 (cpplib)
ignoring nonexistent directory
/usr/local/lib/gcc-lib/../../powerpc-ibm-aix5.1.0.0/include
ignoring nonexistent directory
/usr/local/gcc.3.2.0/powerpc-ibm-aix5.1.0.0/include
ignoring duplicate directory /usr/local/gcc.3.2.0/include/c++/3.2
ignoring duplicate directory
/usr/local/gcc.3.2.0/include/c++/3.2/powerpc-ibm-aix5.1.0.0
ignoring duplicate directory /usr/local/gcc.3.2.0/include/c++/3.2/backward
ignoring duplicate directory
/usr/local/gcc.3.2.0/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/include
#include ... search starts here:
#include ... search starts here:
/usr/local/lib/gcc-lib/../../include/c++/3.2
/usr/local/lib/gcc-lib/../../include/c++/3.2/powerpc-ibm-aix5.1.0.0
/usr/local/lib/gcc-lib/../../include/c++/3.2/backward
/usr/local/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/include
/usr/local/include
/usr/local/gcc.3.2.0/include
/usr/include
End of search list.
/usr/local/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/cc1plus -fpreprocessed
t.ii -quiet -dumpbase t.cpp -version -o t.s
GNU CPP version 3.2 (cpplib)
GNU C++ version 3.2 (powerpc-ibm-aix5.1.0.0)
compiled by GNU C version 3.2.
as -u -mcom -o t.o t.s
/usr/local/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/collect2
-bpT:0x1000 -bpD:0x2000 -btextro -bnodelcsect /lib/crt0.o
-L/usr/local/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2
-L/usr/local/bin/../lib/gcc-lib
-L/usr/local/gcc.3.2.0/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2
-L/usr/local/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/../../..
-L/usr/local/gcc.3.2.0/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/../../.. t.o
/usr/local/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/libgcc.a
/usr/local/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/libgcc_eh.a -lc
/usr/local/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/libgcc.a
/usr/local/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/libgcc_eh.a
How-To-Repeat:
gcc -v -save-temps t.cpp
--
Summary: The wrong number of arguments have been specified for
destructor.
Product: gcc
Version: 3.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: msadoghi at ca dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19913
[Bug c++/19913] The wrong number of arguments have been specified for destructor.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 21:44 --- Fixed in 3.4.0, this is not a regression from what I can tell so closing as fixed. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||accepts-invalid Known to fail||3.3.3 3.2.3 3.0.4 2.95.3 Known to work||3.4.0 4.0.0 Resolution||FIXED Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19913
[Bug ada/19900] ACATS c391002 c432002 ICE categorize_ctor_elements_1
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-11 21:48 --- Confirmed on x86. -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-11 21:48:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19900
[Bug ada/19903] ACATS cxa4006 cxa4017 ada.string.(un)bounded fail at runtime
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-11 21:50 --- Confirmed on x86. -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-11 21:50:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19903
[Bug rtl-optimization/19909] verify-flow-info: wrong frequency ...
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 21:50 --- Closing as invalid and -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID 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 21:50 --- Reopen it so we get it into an unconfirmed state. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19909
[Bug tree-optimization/19876] [4.0 Regression] g++ starts eating all the memory and the CPU
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-11 21:52 --- Subject: Bug 19876 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-11 21:52:39 Modified files: gcc: ChangeLog tree-ssa-pre.c Log message: PR tree-optimization/19876 Partially revert my change from 2005-01-14 * tree-ssa-pre.c (compute_antic_aux): Make recursive once again... (compute_antic): ...and remove the loop here. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7450r2=2.7451 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-pre.c.diff?cvsroot=gccr1=2.63r2=2.64 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19876
[Bug tree-optimization/19876] [4.0 Regression] g++ starts eating all the memory and the CPU
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-11 21:56 --- Should be fixed now. Bash me if it is not. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19876
[Bug middle-end/19697] [4.0 Regression] gcc.c-torture/execute/ieee/mzero6.c:24: error: unrecognizable insn
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-11 22:10 --- Subject: Bug 19697 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-02-11 22:10:35 Modified files: gcc: ChangeLog gcc/config/pa : pa.md Log message: PR middle-end/19697 2005-01-30 Roger Sayle [EMAIL PROTECTED] * config/pa/pa.md (anddi3, iordi3): On HPPA64, disallow an integer constant as the second operand and a register as the third. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.798r2=2.2326.2.799 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/pa.md.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.138.4.7r2=1.138.4.8 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19697
