[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2
--- Additional Comments From jvdelisle at verizon dot net 2005-02-01 07:52 --- Using -O3 with flag_complex_divide_method = 1 in toplev.c on i686-pc-linux-gnu CGV drivers: 64 out of 1092 tests failed to pass the threshold CST drivers: 1 out of 11664 tests failed to pass the threshold DXV drivers:200 out of 5000 tests failed to pass the threshold SXV drivers: 37 out of 5000 tests failed to pass the threshold SST drivers: 1 out of 14256 tests failed to pass the threshold ZGV drivers: 66 out of 1092 tests failed to pass the threshold ZXV drivers: 24 out of 5000 tests failed to pass the threshold I think this is getting there. I will also start looking at results within for the outliers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug c++/19499] [3.4/4.0 regression] Bad diagnostic for namespace as template parameter
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-01 07:04 --- Subject: Bug 19499 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-02-01 07:04:01 Modified files: gcc/testsuite : ChangeLog gcc/cp : ChangeLog parser.c pt.c gcc/testsuite/g++.dg/parse: typename7.C Log message: gcc/cp/ChangeLog: PR c++/18757 PR c++/19366 PR c++/19499 * parser.c (cp_parser_template_id): Revert 2004-12-09's patch. Issue an error when creating the template id. * pt.c (fn_type_unification): Return early if the explicit template arg list is an error_mark_node. gcc/testsuite/ChangeLog: * g++.dg/parse/typename7.C: Adjust error messages. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.354&r2=1.3389.2.355 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.193&r2=1.3892.2.194 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.157.2.50&r2=1.157.2.51 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.816.2.49&r2=1.816.2.50 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/typename7.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.1.10.1&r2=1.1.10.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19499
[Bug c++/19366] [4.0 Regression] Excessive duplicate error messages trying to treat '>>' as '> >'
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-01 07:04 --- Subject: Bug 19366 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-02-01 07:04:01 Modified files: gcc/testsuite : ChangeLog gcc/cp : ChangeLog parser.c pt.c gcc/testsuite/g++.dg/parse: typename7.C Log message: gcc/cp/ChangeLog: PR c++/18757 PR c++/19366 PR c++/19499 * parser.c (cp_parser_template_id): Revert 2004-12-09's patch. Issue an error when creating the template id. * pt.c (fn_type_unification): Return early if the explicit template arg list is an error_mark_node. gcc/testsuite/ChangeLog: * g++.dg/parse/typename7.C: Adjust error messages. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.354&r2=1.3389.2.355 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.193&r2=1.3892.2.194 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.157.2.50&r2=1.157.2.51 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.816.2.49&r2=1.816.2.50 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/typename7.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.1.10.1&r2=1.1.10.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19366
[Bug c++/18757] [3.4 Regression] ICE (on invalid) in get_innermost_template_args
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-01 07:04 --- Subject: Bug 18757 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-02-01 07:04:01 Modified files: gcc/testsuite : ChangeLog gcc/cp : ChangeLog parser.c pt.c gcc/testsuite/g++.dg/parse: typename7.C Log message: gcc/cp/ChangeLog: PR c++/18757 PR c++/19366 PR c++/19499 * parser.c (cp_parser_template_id): Revert 2004-12-09's patch. Issue an error when creating the template id. * pt.c (fn_type_unification): Return early if the explicit template arg list is an error_mark_node. gcc/testsuite/ChangeLog: * g++.dg/parse/typename7.C: Adjust error messages. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.354&r2=1.3389.2.355 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.193&r2=1.3892.2.194 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.157.2.50&r2=1.157.2.51 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.816.2.49&r2=1.816.2.50 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/typename7.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.1.10.1&r2=1.1.10.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18757
[Bug java/19738] New: gcjh generates invalid class member floating-point initialisers
For floating-point (float/double) class members that are initialised, gcjh generates invalid C++ code. See: http://gcc.gnu.org/ml/gcc/2005-01/msg01738.html for the issue in general and: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00032.html for how it affects GCJ. -- Summary: gcjh generates invalid class member floating-point initialisers Product: gcc Version: unknown Status: UNCONFIRMED Severity: critical Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rmathew 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=19738
[Bug tree-optimization/19723] [4.0 Regression] A side effect is missed in 0 % a++.
--- Additional Comments From rth at gcc dot gnu dot org 2005-02-01 06:36 --- Subject: Re: [4.0 Regression] A side effect is missed in 0 % a++. On Mon, Jan 31, 2005 at 08:45:34PM -0700, Jeffrey A Law wrote: > + /* X % 0, return X % 0 unchanged so that we can get the > + proper warnings and errors. */ > if (integer_zerop (arg1)) > return t; > > + /* 0 % X is always zero, but be sure to preserve any side > + effects in X. Place this after checking for X == 0. */ > + if (integer_zerop (arg0)) > + return omit_one_operand (type, integer_zero_node, arg1); Not ok yet. You have to *know* that arg1 is not zero. Otherwise you're still potentially removing a division-by-zero. The only check you have at this level for this is integer_nonzerop. r~ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19723
[Bug middle-end/19331] [4.0 Regression] Inefficient code generated for bitfield assignment
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01
05:57 ---
Hmm, maybe gcc should be able to optimize the following RTL better when
combining them (if gcc
does combine them):
(insn 19 18 20 0 (set (reg:CCZ 17 flags)
(compare:CCZ (zero_extract:SI (subreg:DI (reg:QI 61 [+5 ]) 0)
(const_int 1 [0x1])
(const_int 0 [0x0]))
(const_int 0 [0x0]))) 283 {*testqi_ext_3} (insn_list:REG_DEP_TRUE
16 (nil))
(nil))
...
(insn 23 22 24 0 (set (reg:QI 68)
(ne:QI (reg:CCZ 17 flags)
(const_int 0 [0x0]))) 480 {*setcc_1} (insn_list:REG_DEP_TRUE 19
(nil))
(expr_list:REG_DEAD (reg:CC 17 flags)
(nil)))
And we should get:
(set (reg:QI 68) (zero_extract:SI (subreg:DI (reg:QI 61 [+5 ]) 0)
(const_int 1 [0x1])
(const_int 0 [0x0])))
because we know that what the compare compares against can only be 1 or 0 as it
is a zero_extract of
size 1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19331
[Bug c++/19499] [3.4/4.0 regression] Bad diagnostic for namespace as template parameter
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-01 05:56 --- Subject: Bug 19499 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-01 05:56:08 Modified files: gcc/testsuite : ChangeLog gcc/cp : ChangeLog parser.c pt.c gcc/testsuite/g++.dg/parse: typename7.C Log message: gcc/cp/ChangeLog: PR c++/18757 PR c++/19366 PR c++/19499 * parser.c (cp_parser_template_id): Revert 2004-12-09's patch. Issue an error when creating the template id. * pt.c (fn_type_unification): Return early if the explicit template arg list is an error_mark_node. gcc/testsuite/ChangeLog: * g++.dg/parse/typename7.C: Adjust error messages. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4967&r2=1.4968 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4607&r2=1.4608 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&r1=1.306&r2=1.307 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.970&r2=1.971 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/typename7.C.diff?cvsroot=gcc&r1=1.1&r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19499
[Bug c++/18757] [3.4 Regression] ICE (on invalid) in get_innermost_template_args
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-01 05:56 --- Subject: Bug 18757 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-01 05:56:08 Modified files: gcc/testsuite : ChangeLog gcc/cp : ChangeLog parser.c pt.c gcc/testsuite/g++.dg/parse: typename7.C Log message: gcc/cp/ChangeLog: PR c++/18757 PR c++/19366 PR c++/19499 * parser.c (cp_parser_template_id): Revert 2004-12-09's patch. Issue an error when creating the template id. * pt.c (fn_type_unification): Return early if the explicit template arg list is an error_mark_node. gcc/testsuite/ChangeLog: * g++.dg/parse/typename7.C: Adjust error messages. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4967&r2=1.4968 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4607&r2=1.4608 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&r1=1.306&r2=1.307 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.970&r2=1.971 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/typename7.C.diff?cvsroot=gcc&r1=1.1&r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18757
[Bug c++/19366] [4.0 Regression] Excessive duplicate error messages trying to treat '>>' as '> >'
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-01 05:56 --- Subject: Bug 19366 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-01 05:56:08 Modified files: gcc/testsuite : ChangeLog gcc/cp : ChangeLog parser.c pt.c gcc/testsuite/g++.dg/parse: typename7.C Log message: gcc/cp/ChangeLog: PR c++/18757 PR c++/19366 PR c++/19499 * parser.c (cp_parser_template_id): Revert 2004-12-09's patch. Issue an error when creating the template id. * pt.c (fn_type_unification): Return early if the explicit template arg list is an error_mark_node. gcc/testsuite/ChangeLog: * g++.dg/parse/typename7.C: Adjust error messages. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4967&r2=1.4968 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4607&r2=1.4608 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&r1=1.306&r2=1.307 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.970&r2=1.971 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/typename7.C.diff?cvsroot=gcc&r1=1.1&r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19366
[Bug c++/9634] [DR224] Injected class name as qualifier should not make the name dependent
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01 04:43 --- *** Bug 19737 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||gianni at mariani dot ws http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9634
[Bug c++/19737] typename requirement error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01 04:43 --- This is a kinda of a regression but GDR says there are problems with core issue 224 still, this is a dup of bug 9634. Note DR numbers are in summary for most bugs as a quick search of that DR number would have found the bug. *** This bug has been marked as a duplicate of 9634 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19737
[Bug c++/19737] typename requirement error
--- Additional Comments From gianni at mariani dot ws 2005-02-01 04:41 --- BTW - gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) accepts the code, would this be a regression ? -- What|Removed |Added Keywords||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19737
[Bug c++/19737] New: typename requirement error
In a recent posting by Daveed Vandervoorde on comp.std.c++, apparently the code
below is valid, yet the latest GCC snapshot (20050130) indicates that this is
still an issue.
struct N {
typedef char C;
};
template struct B {
typedef long L;
};
template struct S: N, B {
typedef int I;
S::I i; // Okay
S::C c; // Okay
//S::L l; // Error: typename required
};
Daveed writes:
> It's a consequence of the resolution of core issue 224
> (which improves the definition of "dependent type").
--
Summary: typename requirement error
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gianni at mariani dot ws
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19737
[Bug preprocessor/19077] [3.4/4.0 Regression] Internal compiler error compiling MPlayer
--- Additional Comments From echristo at redhat dot com 2005-02-01 04:25 --- [EMAIL PROTECTED] ~/tmp]$ /dzur/sourceware/builds-gcc/build-dzur/gcc/xgcc -B/dzur/sourceware/builds-gcc/build-dzur/gcc/ bug.c -c -save-temps -g3 *** glibc detected *** malloc(): memory corruption: 0x08ca4ba8 *** bug.c:5: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. will probably help a bit more. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |echristo at redhat dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2004-12-19 18:51:51 |2005-02-01 04:25:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19077
[Bug java/9157] SEGV on bad java source
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01 04:06 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9157
[Bug tree-optimization/19723] [4.0 Regression] A side effect is missed in 0 % a++.
--- Additional Comments From law at redhat dot com 2005-02-01 03:46 --- Fixed with tonight's change to fold-const.c -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19723
[Bug target/18404] unnecessary sll when -mint64 (MIPS)
--- Additional Comments From echristo at redhat dot com 2005-02-01 03:06 --- Deprecating -mint64. http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00019.html -- What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18404
[Bug java/9157] SEGV on bad java source
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-01 02:37 --- Subject: Bug 9157 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-01 02:36:36 Modified files: gcc/java : ChangeLog parse.y Log message: PR java/9157 * parse.y (build_string_concatenation): Remove redundant if. (patch_conditional_expr): Attempt to patch_string() the condition of a ?: as well, in addition to its other operands. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1537&r2=1.1538 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/parse.y.diff?cvsroot=gcc&r1=1.527&r2=1.528 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9157
[Bug preprocessor/13726] [3.3/3.4/4.0 regression]cpp -C -dI loses comments on same line as #include directives
--- Additional Comments From echristo at redhat dot com 2005-02-01 02:21 --- The best I can get without major surgery to cpp is this: #include "test.h" /* comment from include line */ Which is likely insufficient for any good needs. I think what we need to be able to do with cpplib is to put actions on a stack and have them popped at the end of the directive. Another option is to have _cpp_push_include (or push_file) finish out the current buffer before actually pushing out the file. I don't know how well this will work out in practice though. Thoughts? -- What|Removed |Added CC||zack at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13726
[Bug middle-end/17961] ICE for operation on small vector with altivec enabled
--- Additional Comments From janis at gcc dot gnu dot org 2005-02-01 01:51 --- I just tried with today's mainline for powerpc64-unknown-linux-gnu and get the same two ICEs as were reported originally. The 3.4 branch gives the error that Serge noted for -DVECSIZE=2 and accepts -DVECSIZE=8. This is a regression, but no one seems to expect generic vectors to actually work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17961
[Bug other/19696] gcc.c-torture/execute/ieee/copysign1.c: Unsatisfied symbols: copysignl
--- Additional Comments From danglin at gcc dot gnu dot org 2005-02-01 01:32 --- Fixed om PA. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19696
[Bug tree-optimization/19723] [4.0 Regression] A side effect is missed in 0 % a++.
--- Additional Comments From law at redhat dot com 2005-02-01 01:04 ---
This testcase (from Ranjit) should give an error on the bogus case label:
int foo(int x)
{
switch(x)
{
case 0 % 0:
return 1;
default:
return 2;
}
}
I'm testing a fix for both problems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19723
[Bug tree-optimization/19736] [4.0 Regression] ICE with type mismatch between SSA_NAME and its symbol
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code Summary|ICE with type mismatch |[4.0 Regression] ICE with |between SSA_NAME and its|type mismatch between |symbol |SSA_NAME and its symbol Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19736
[Bug tree-optimization/19736] New: ICE with type mismatch between SSA_NAME and its symbol
Today's GCC mainline ICEs building 176.gcc from SPEC CPU2000 on powerpc64-unknown-linux-gnu with "-O1 -g" and either -m32 or -m64: sdbout.c:1026: error: Type mismatch between an SSA_NAME and its symbol. sdbout.c:1026: error: Missing definition for SSA_NAME: p_915in statement: # current_function_decl_1093 = V_MAY_DEF ; # asm_out_file_1094 = V_MAY_DEF ; # target_flags_1095 = V_MAY_DEF ; # buffer_1096 = V_MAY_DEF ; # buffer_1097 = V_MAY_DEF ; # buffer_1098 = V_MAY_DEF ; # buffer_1099 = V_MAY_DEF ; __builtin_memcpy (p_915, &"union"[0], 6); sdbout.c:1026: internal compiler error: verify_ssa failed. Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. specmake: *** [sdbout.o] Error 1 The "sdbout.c:1026" here is in the benchmark program being compiled. I'll try to provide a minimized testcase tomorrow. -- Summary: ICE with type mismatch between SSA_NAME and its symbol Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19736
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From joel at oarcorp dot com 2005-02-01 00:46 --- Subject: Re: gnat tools not buildable cross charlet at adacore dot com wrote: > --- Additional Comments From charlet at adacore dot com 2005-01-31 16:38 > --- > Subject: Re: gnat tools not buildable cross > > >>I don't think so. When you get into the libada directory, >>CC="$(CC_FOR_TARGET)" >>and all hope is lost of having the tools work in a cross configuration. > > > That is wrong, ada/Makefile.in is designed to support this configuration, > and use the native gnat bootstrap compiler instead of $(CC) to build the > tools in the case of cross compilation. FWIW I get the same error on the gcc-libada-gnattools-branch. Nathaniel are there any special instructions for cross Ada or is it just supported to work? --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug c++/19735] Grammar "error" in error message.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01 00:45 --- No the grammar in this example is correct even though it looks werid for a non native speaker of English. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19735
[Bug c++/19735] Grammar "error" in error message.
-- What|Removed |Added Keywords||diagnostic Summary|Spelling "error" in error |Grammar "error" in error |message.|message. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19735
[Bug c++/19735] New: Spelling "error" in error message.
When fed with the following code: unsigned char val = -1; gcc-4.0.0 20050130 (experimental) reports: warning: converting of negative value '-0x1' to 'unsigned char' As for my feeling, it should correctly say "conversion of..." or "converting" but not "converting of...". -- Summary: Spelling "error" in error message. Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: minor Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wwieser at gmx dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-linux-gnu GCC host triplet: i686-linux-gnu GCC target triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19735
[Bug c++/19550] strong attribute is not strong enough
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01 00:37 --- This is no longer a regression as we don't ICE on it but it is still a rejects valid. -- What|Removed |Added Keywords|ice-on-valid-code |rejects-valid Summary|[4.0 Regression] strong |strong attribute is not |attribute is not strong |strong enough |enough | Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19550
[Bug tree-optimization/19701] [4.0 regression] Way too many IVs
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-01 00:33 --- Patch posted for review for inclusion in GCC 4.0 is here: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg02207.html. -- What|Removed |Added Severity|minor |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19701
[Bug middle-end/19331] [4.0 Regression] Inefficient code generated for bitfield assignment
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01 00:32 --- This changed between 20040708 and 20040709. Which means that it was most likely caused by: 2004-07-08 Joseph S. Myers <[EMAIL PROTECTED]> Neil Booth <[EMAIL PROTECTED]> PR c/2511 PR c/3325 Which is what I thought as we get optimial code from the C++ front-end for x86 though on ppc we get the same optimial code for both the C and C++ front-ends. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19331
[Bug target/11380] [ia64] stack frame > 2 GB and no optimization results in SEGV
--- Additional Comments From sje at cup dot hp dot com 2005-02-01 00:27 --- Resolving as fixed since 3.4 and ToT both look OK. It is still broken on the 3.3 branch. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11380
[Bug tree-optimization/18880] DSE is not doing its job for global variables
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-01 00:23 --- Let's just leave it as-is and revisit for 4.1. -- What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18880
[Bug middle-end/17278] [4.0 Regression] 8% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-01 00:22 --- I have no further ideas for speedups for this bug... -- What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17278
[Bug middle-end/17278] [4.0 Regression] 8% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level
-- What|Removed |Added Status|WAITING |NEW Last reconfirmed|2004-09-02 11:05:08 |2005-02-01 00:21:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17278
[Bug middle-end/19708] [4.0 Regression] does not fold "&int_cst->a" to just INT_CST
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01 00:20 --- : Search converges between 2004-08-30-trunk (#529) and 2004-08-31-trunk (#530). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19708
[Bug c/19333] [4.0 Regression] C front end accepts arrays of incomplete types
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-01 00:19 --- I'm on there twice :) -- What|Removed |Added CC|stevenb at suse dot de | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19333
[Bug c/19333] [4.0 Regression] C front end accepts arrays of incomplete types
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-01 00:15 --- http://gcc.gnu.org/ml/gcc-patches/2005-01/msg02245.html -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19333
[Bug middle-end/17961] ICE for operation on small vector with altivec enabled
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01 00:10 --- I think this has been fixed on the mainline but I don't know for sure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17961
[Bug c/19333] [4.0 Regression] C front end accepts arrays of incomplete types
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-01 00:09 --- Subject: Bug 19333 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-01 00:09:40 Modified files: gcc: ChangeLog c-decl.c c-typeck.c gcc/testsuite : ChangeLog gcc/testsuite/gcc.c-torture/compile: 20011130-1.c gcc/testsuite/gcc.dg: 20030815-1.c array-7.c pr18596-3.c gcc/testsuite/gcc.dg/noncompile: 2901-1.c init-2.c init-4.c Log message: gcc/ PR c/19333 * c-decl.c (start_decl): Do not warn about arrays of elements with an incomplete type here. (grokdeclarator): Do it here by making a pedwarn an error. * c-typeck.c (push_init_level): If there were previous errors with the constructor type, do not warn about braces for initializers. (process_init_element): Likewise for excess initializer elements. testsuite/ PR c/19333 * testsuite/gcc.c-torture/compile/20011130-1.c: Reorder to make the test case valid. * testsuite/gcc.dg/20030815-1.c: Remove invalid tests. * testsuite/gcc.dg/array-7.c: Adjust expected result. * testsuite/gcc.dg/pr18596-3.c: Likewise. * testsuite/gcc.dg/noncompile/2901-1.c: Likewise. * testsuite/gcc.dg/noncompile/init-2.c: Likewise. * testsuite/gcc.dg/noncompile/init-4.c: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7349&r2=2.7350 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&r1=1.628&r2=1.629 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&r1=1.415&r2=1.416 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4964&r2=1.4965 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/20011130-1.c.diff?cvsroot=gcc&r1=1.1&r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20030815-1.c.diff?cvsroot=gcc&r1=1.1&r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/array-7.c.diff?cvsroot=gcc&r1=1.1&r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr18596-3.c.diff?cvsroot=gcc&r1=1.1&r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/noncompile/2901-1.c.diff?cvsroot=gcc&r1=1.1&r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/noncompile/init-2.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/noncompile/init-4.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19333
[Bug c++/19734] [3.4/4.0 regression] Another ICE on invalid destructor call
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01 00:03 --- : Search converges between 2003-07-16-trunk (#296) and 2003-07-17-trunk (#297). Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-01 00:03:45 date|| Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19734
[Bug c++/19733] [3.4/4.0 regression] ICE on invalid destructor call
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01 00:03 --- : Search converges between 2002-12-14-trunk (#159) and 2002-12-29-trunk (#160). Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-01 00:03:12 date|| Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19733
[Bug c++/19732] [4.0 regression] Invalid destructor declarations accepted
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01 00:01 --- : Search converges between 2004-06-22-trunk (#470) and 2004-06-24-trunk (#471). Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-01 00:01:01 date|| Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19732
[Bug rtl-optimization/19680] sub-optimial register allocation with sse
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 23:42 --- d-19680-1 + d-19680-3 isn't as good, 14.9fps, as some silly stack movements are induced; ie: 40265f: 0f 29 04 24 movaps %xmm0,(%esp) 402663: 0f 57 c0xorps %xmm0,%xmm0 402666: 0f c2 d0 01 cmpltps %xmm0,%xmm2 40266a: 0f 56 14 24 orps (%esp),%xmm2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19680
[Bug target/14625] tail call optimization missed
--- Additional Comments From drepper at redhat dot com 2005-01-31 23:34 --- > /* If this function requires more stack slots than the current > function, we cannot change it into a sibling call. */ > || args_size.constant > current_function_args_size > > args_size.constant == 8 (2 ints) and current_function_args_size == 0 > because nothing gets passed on the stack. Correct. But this does not take the stdcall attribute into account. It should. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14625
[Bug rtl-optimization/19680] sub-optimial register allocation with sse
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 23:28 --- Wow! We got a winner. 15.8 fps with -fno-gcse, inlining and only d-19680-3. 402680: 66 0f 6f d1 movdqa %xmm1,%xmm2 .. 402688: 66 0f db 50 30 pand 0x30(%eax),%xmm2 40268d: 66 0f 6e 41 28 movd 0x28(%ecx),%xmm0 402692: 66 0f 70 c0 00 pshufd $0x0,%xmm0,%xmm0 402697: 66 0f df c8 pandn %xmm0,%xmm1 40269b: 66 0f eb ca por%xmm2,%xmm1 40269f: 0f 29 48 30 movaps %xmm1,0x30(%eax) That's the final integer update. Perfect. Want me to try that champ in conjunction with d-19680-1? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19680
[Bug c++/19734] New: [3.4/4.0 regression] Another ICE on invalid destructor call
The following invalid code snippet causes an ICE since gcc 3.4.0:
==
struct A;
void foo() { A::~A(); }
==
Mainline's error message reads:
bug.cc: In function 'void foo()':
bug.cc:2: internal compiler error: vector VEC(tree) index domain error, in
cp_parser_lookup_name at cp/parser.c:14160
Please submit a full bug report, [etc.]
--
Summary: [3.4/4.0 regression] Another ICE on invalid destructor
call
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19734
[Bug target/14625] tail call optimization missed
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-31 23:17 --- FWIW we don't emit the tail call because of this: /* If this function requires more stack slots than the current function, we cannot change it into a sibling call. */ || args_size.constant > current_function_args_size args_size.constant == 8 (2 ints) and current_function_args_size == 0 because nothing gets passed on the stack. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14625
[Bug c++/19733] New: [3.4/4.0 regression] ICE on invalid destructor call
The following invalid code snippet causes an ICE since gcc 3.4.0:
==
struct A {};
void foo() { A().A::~~A(); }
==
Mainline's error message reads:
bug.cc: In function 'void foo()':
bug.cc:2: error: expected class-name before '~' token
bug.cc:2: error: expected `;' before '~' token
bug.cc:2: internal compiler error: in gimplify_expr, at gimplify.c:4065
Please submit a full bug report, [etc.]
--
Summary: [3.4/4.0 regression] ICE on invalid destructor call
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19733
[Bug c++/19732] New: [4.0 regression] Invalid destructor declarations accepted
The following invalid code snippet is accepted by mainline:
==
struct A;
struct B { ~A(); };
==
Mark, this was caused by your patch
http://gcc.gnu.org/ml/gcc-cvs/2004-06/msg00888.html
This patch not only removed the error message
error ("destructor `%T' must match class name `%T'", name, rename);
for destructors from grokdeclarator, but also
error ("destructors must be member functions");
A testcase that used to trigger the second error message but is now accepted
is the following:
==
struct A;
void ~A();
==
--
Summary: [4.0 regression] Invalid destructor declarations
accepted
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: accepts-invalid, monitored
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,mark at codesourcery dot
com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19732
[Bug rtl-optimization/19680] sub-optimial register allocation with sse
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 22:58 --- In previous test i've used a crufted string of compilation options; i've removed all that crap for -O3 -march=k8 -mfpmath=sse -fno-gcse -fno-exceptions. The second patch, hack sse simode inputs, is a small win or at least a draw, inlined or not, -fno-gcse or not. The first one, mark builtins constant, is a lose in every conditions; it's the one that triggers those stack references/movements noted earlier (and my guess is what's causing the perf regression, other than that the code seems prettier). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19680
[Bug c++/18962] [3.4 Regression] specialization of template class with inner template members and parameter
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 22:46 --- *** Bug 19731 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||nick at ilm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18962
[Bug c++/19731] arguments incorrectly named in static member specialization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 22:46 --- This is a dup of bug 18962 which is already fixed in 3.4.4 and 4.0.0. *** This bug has been marked as a duplicate of 18962 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19731
[Bug c++/19731] arguments incorrectly named in static member specialization
-- What|Removed |Added Keywords||accepts-invalid, rejects- ||valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19731
[Bug c++/19731] New: arguments incorrectly named in static member specialization
It looks like in the specialization of a static template member of a template
class, the argument names are used from the original declaration, rather than
from the specialization declaration.
template
struct W {
template static S getAsS(const T &v_orig);
};
template <>
template
inline S W::getAsS(const float &v_spec)
{
return S(v_spec);
}
the above code compiles on 3.3, but does not compile under 3.4.2 and 3.4.3:
foo.C: In static member function `static S W::getAsS(const T&) [with S = S, T
= float]':
foo.C:10: error: `v_spec' undeclared (first use this function)
foo.C:10: error: (Each undeclared identifier is reported only once for each
function it appears in.)
if you change the second to last line to:
return S(v_orig);
(using the variable name from the original declaration) the code erroneously
compiles under 3.4.1, 3.4.2, even if the function gets instantiated.
-nick
--
Summary: arguments incorrectly named in static member
specialization
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nick at ilm 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=19731
[Bug target/14625] tail call optimization missed
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-31 22:34 --- The code produced by CVS HEAD from today for the test case of comment #0 doesn't exactly get one thrilled and excited either: .file "t.c" .text .p2align 4,,15 .type foo, @function foo: addl%edx, %eax addl%ecx, %eax addl4(%esp), %eax addl8(%esp), %eax ret $8 .size foo, .-foo .p2align 4,,15 .globl bar .type bar, @function bar: subl$8, %esp movl$1, %ecx movl$3, 4(%esp) movl$2, (%esp) callfoo subl$8, %esp addl$8, %esp ret .size bar, .-bar .ident "GCC: (GNU) 4.0.0 20050131 (experimental)" .section.note.GNU-stack,"",@progbits -- What|Removed |Added Last reconfirmed|2005-01-29 13:35:11 |2005-01-31 22:34:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14625
[Bug rtl-optimization/19680] sub-optimial register allocation with sse
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 22:21 --- Oops, my bad. Thought pshufd mixed both operands à la shufps; i'm obviously not familiar with the integer side of SSE. And yes the combination is a lose, albeit a small one around 3%. But i'm timing the whole thing not just that intersection code. To give you an idea here's the peak perf for a given tree. intersection inlined: ICC: 16.4 fps gcc: 14.7 unpatched, 14.4 patched gcc & -fno-gcse: 14.8 unpatched, 14.5 patched intersection not inlined: gcc: 14.9 unpatched, 13.7 patched gcc & -fno-gcse: 14.8 unpatched, 14.0 patched The problem is that the surrounding code (kdtree search) also change a lot and gcc doesn't find an optimal way for that either. What's reassuring is that ICC isn't much smarter than gcc on the tree search. Each compiler comes up with nice trick here and there but none got the whole picture right. Still ICC doesn't suck as much on average. I'm going to replace all that tree search with asm to settle the issue someday. BTW the difference between ICC and GCC is around ~5% on the scalar path. I'm going to try each patch in turn as requested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19680
[Bug libgcj/19728] libgcj Gnu.java missing SHA-160
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-31 22:17:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19728
[Bug c++/16240] [3.4/3.5 ABI Regression] g++ generates incorrect mangled name
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 22:12 --- *** Bug 19730 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||unicorn at freeshell dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16240
[Bug other/19730] segfault in cp-demangle
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 22:12 --- (In reply to comment #1) > Ian, can you have a look? Mainline __cxa_demangle returns -2. This is a dup of bug 16240 which both the mangling and demangling problems have been fixed on the mainline (4.0.0). *** This bug has been marked as a duplicate of 16240 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19730
[Bug target/19726] suboptimal constructor generated
--- Additional Comments From yuri at tsoft dot com 2005-01-31 22:02 --- actually I want to generalize it: any situation in C++/C/Ada when many enough close (in memory) variables are assigned the same value should use bulk "stos(b/w/l)". This should be applied as part of optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19726
[Bug target/19658] fail to build gcc 3.4.3 on IRIX6.5
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-01-31 21:53 --- FWIW, I've not had any problems like this, although I tend to use the MIPSpro cc as the bootstrap compiler, not gcc 3.3. There have been other successful build reports too. If you don't have access to MIPSpro, could you try bootstrapping with the 3.4.0 binaries available here: http://people.redhat.com/rsandifo/ Thanks, Richard -- What|Removed |Added CC||rsandifo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19658
[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
--- Additional Comments From law at redhat dot com 2005-01-31 21:35 --- Subject: Re: [meta-bug] optimizations that CSE still catches On Mon, 2005-01-31 at 20:14 +, stevenb at suse dot de wrote: > --- Additional Comments From stevenb at suse dot de 2005-01-31 20:14 > --- > Subject: Re: [meta-bug] optimizations that CSE still catches > > My numbers for not disabling CSE completely but disabling path following > are a lot less pessimistic. This was on an AMD Opteron at 1600MHz: Right. That's what I'd focus on first -- that's what I was looking at when I realized eons ago when I realized that if we don't do a good job at jump threading, then we have little hope of ever drastically simplifying CSE. I've been stuck in jump threading hell ever since :-) Note I would _STRONGLY_ recommend people look at more than just the compiler when evaluating the old CSE code. In particular it is important that we look at things like 64bit arithmetic on 32bit hosts (which happens often in kernels, but not nearly as often in user level benchmarks). jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
[Bug other/19730] segfault in cp-demangle
--- Additional Comments From pcarlini at suse dot de 2005-01-31 21:20 --- Ian, can you have a look? Mainline __cxa_demangle returns -2. -- What|Removed |Added CC||ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19730
[Bug rtl-optimization/19680] sub-optimial register allocation with sse
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-31 21:12 --- (In reply to comment #21) > 4010ce: 0f 29 6c 24 10 movaps %xmm5,0x10(%esp) > 4010de: 0f 59 5c 24 10 mulps 0x10(%esp),%xmm3 > 4011a1: 0f 29 04 24 movaps %xmm0,(%esp) > 4011af: 0f 56 0c 24 orps (%esp),%xmm1 These instruction patterns didn't change. I only fibbed wrt "int" inputs. It's not impossible that some of this is due to adding the const to the builtin signatures, but... > Just to be sure i've tried that patched version on my app, and it's slower > than the unpatched version (both with -fno-gcse). So, overall the combination of the two patches is a lose? How about each patch individually? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19680
[Bug other/19730] New: segfault in cp-demangle
gcc version 3.4.2 [FreeBSD] 20040728
# c++filt _Z4test1AILZ2buEE
Segmentation fault (core dumped)
gcc version 3.2
# c++filt _Z4test1AILZ2buEE
test(A)
Quick workaround patch based on 3.2 libiberty sources.
(similar to be done over libiberty demangler)
Index: cp-demangle.c
===
RCS file: /home/ncvs/src/contrib/gcc/cp-demangle.c,v
retrieving revision 1.1.1.5
diff -u -r1.1.1.5 cp-demangle.c
--- cp-demangle.c 28 Jul 2004 03:11:34 - 1.1.1.5
+++ cp-demangle.c 31 Jan 2005 21:03:22 -
@@ -2242,6 +2242,47 @@
return al;
}
+static struct demangle_component *
+d_literal (di)
+ struct d_info *di;
+{
+ struct demangle_component *type;
+ enum demangle_component_type t;
+ const char *s;
+
+ type = cplus_demangle_type (di);
+
+ /* If we have a type we know how to print, we aren't going to
+ print the type name itself. */
+ if (type->type == DEMANGLE_COMPONENT_BUILTIN_TYPE
+ && type->u.s_builtin.type->print != D_PRINT_DEFAULT)
+di->expansion -= type->u.s_builtin.type->len;
+
+ /* Rather than try to interpret the literal value, we just
+ collect it as a string. Note that it's possible to have a
+ floating point literal here. The ABI specifies that the
+ format of such literals is machine independent. That's fine,
+ but what's not fine is that versions of g++ up to 3.2 with
+ -fabi-version=1 used upper case letters in the hex constant,
+ and dumped out gcc's internal representation. That makes it
+ hard to tell where the constant ends, and hard to dump the
+ constant in any readable form anyhow. We don't attempt to
+ handle these cases. */
+
+ t = DEMANGLE_COMPONENT_LITERAL;
+ if (d_peek_char (di) == 'n')
+{
+ t = DEMANGLE_COMPONENT_LITERAL_NEG;
+ d_advance (di, 1);
+}
+ s = d_str (di);
+ while (d_peek_char (di) != 'E')
+d_advance (di, 1);
+
+ return d_make_comp (di, t, type, d_make_name (di, s, d_str (di) - s));
+}
+
+
/* ::=
::= X E
::=
@@ -2263,7 +2304,19 @@
return ret;
case 'L':
- return d_expr_primary (di);
+ d_advance (di, 1);
+
+ if(d_peek_char(di) == 'Z') {
+d_advance (di, 1);
+
+ ret = d_encoding(di, 0);
+ } else
+ ret = d_literal(di);
+
+ if (d_next_char (di) != 'E')
+ return NULL;
+
+ return ret;
default:
return cplus_demangle_type (di);
@@ -2392,41 +2445,8 @@
if (d_peek_char (di) == '_')
ret = cplus_demangle_mangled_name (di, 0);
else
-{
- struct demangle_component *type;
- enum demangle_component_type t;
- const char *s;
-
- type = cplus_demangle_type (di);
-
- /* If we have a type we know how to print, we aren't going to
-print the type name itself. */
- if (type->type == DEMANGLE_COMPONENT_BUILTIN_TYPE
- && type->u.s_builtin.type->print != D_PRINT_DEFAULT)
- di->expansion -= type->u.s_builtin.type->len;
-
- /* Rather than try to interpret the literal value, we just
-collect it as a string. Note that it's possible to have a
-floating point literal here. The ABI specifies that the
-format of such literals is machine independent. That's fine,
-but what's not fine is that versions of g++ up to 3.2 with
--fabi-version=1 used upper case letters in the hex constant,
-and dumped out gcc's internal representation. That makes it
-hard to tell where the constant ends, and hard to dump the
-constant in any readable form anyhow. We don't attempt to
-handle these cases. */
-
- t = DEMANGLE_COMPONENT_LITERAL;
- if (d_peek_char (di) == 'n')
- {
- t = DEMANGLE_COMPONENT_LITERAL_NEG;
- d_advance (di, 1);
- }
- s = d_str (di);
- while (d_peek_char (di) != 'E')
- d_advance (di, 1);
- ret = d_make_comp (di, t, type, d_make_name (di, s, d_str (di) - s));
-}
+ret = d_literal(di);
+
if (d_next_char (di) != 'E')
return NULL;
return ret;
--
Summary: segfault in cp-demangle
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: unicorn at freeshell dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-unknown-freebsd5.3
GCC host triplet: i386-unknown-freebsd5.3
GCC target triplet: i386-unknown-freebsd5.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19730
[Bug rtl-optimization/19680] sub-optimial register allocation with sse
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-31 21:02 --- (In reply to comment #22) No, it isn't. Look at your functions again. The assembly that you pasted is 100% perfect. You cannot improve on that in any way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19680
[Bug libgcj/19729] libgcj DSASignature.java null pointer exception
--- Additional Comments From ovidr at users dot sourceforge dot net 2005-01-31 21:02 --- Created an attachment (id=8118) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8118&action=view) The file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19729
[Bug libgcj/19729] New: libgcj DSASignature.java null pointer exception
appRandom might be null in DSASignature (it is not initialized), yet in the method "public byte[] engineSign()" appRandom is used which causes an NPE. Casey Marshall sent me the attached replacement DSASignature.java file and it works. -- Summary: libgcj DSASignature.java null pointer exception Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ovidr at users dot sourceforge dot net 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=19729
[Bug libgcj/19728] New: libgcj Gnu.java missing SHA-160
Index: Gnu.java
===
RCS file: /cvsroot/gcc/gcc/libjava/gnu/java/security/provider/Gnu.java,v
retrieving revision 1.7
diff -u -r1.7 Gnu.java
--- Gnu.java 15 Nov 2004 20:02:04 - 1.7
+++ Gnu.java 31 Jan 2005 20:47:01 -
@@ -129,6 +129,7 @@
// Format "Alias", "Actual Name"
put("Alg.Alias.MessageDigest.SHA1", "SHA");
put("Alg.Alias.MessageDigest.SHA-1", "SHA");
+put("Alg.Alias.MessageDigest.SHA-160", "SHA");
// Algorithm Parameters
put("AlgorithmParameters.DSA",
--
Summary: libgcj Gnu.java missing SHA-160
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ovidr at users dot sourceforge dot net
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=19728
[Bug rtl-optimization/19680] sub-optimial register allocation with sse
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 20:35 --- Hmm, there's something fishy with _mm_set1_epi32. With your patches there's no stack copy anymore but, with http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19714 testcase, i get: 00401080 : 401080: 66 0f 6e 4c 24 04 movd 0x4(%esp),%xmm1 401086: 66 0f 70 c1 00 pshufd $0x0,%xmm1,%xmm0 40108b: c3 ret 00401090 : 401090: 8b 44 24 04 mov0x4(%esp),%eax 401094: 66 0f 6e 08 movd (%eax),%xmm1 401098: 66 0f 70 c1 00 pshufd $0x0,%xmm1,%xmm0 40109d: c3 ret 00401050 : 401050: 8b 44 24 04 mov0x4(%esp),%eax 401054: 66 0f 6e 08 movd (%eax),%xmm1 401058: 66 0f 70 c1 00 pshufd $0x0,%xmm1,%xmm0 40105d: c3 ret ... and that's quite bogus :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19680
[Bug target/19724] ICE when building a m68hc11 cross-compiler on ia64
--- Additional Comments From aurelien at aurel32 dot net 2005-01-31 20:28 --- (In reply to comment #5) > Isn't this the same as PR 16925? No, this is different. The patch attached to PR 16925 fixes the problem on all three hosts (amd64, ia64 and alpha). And the problem is on a different file, with a different testcase. BTW, I have checked all the differences between amd64, alpha and ia64, and I have found one: alpha and amd64 are using 40-bit address space whereas ia64 is using a 64-bit address space. There is some signedness error (comparison between signed and unsigned during the build). If the full 64-bit range is used, I think it may cause such kind of error. And addresses return by gcc on ia64 (such as 0x202dc720) are using all the bits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19724
[Bug target/19724] ICE when building a m68hc11 cross-compiler on ia64
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 20:22 --- Isn't this the same as PR 16925? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19724
[Bug rtl-optimization/19680] sub-optimial register allocation with sse
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 20:18 --- -fno-gcse is a godsend, instant speedup and most of the sillyness when inlining is gone. Now i've applied both your patches, and while there's promising they also triggers their own nastyness; gcc is so fond of memory inputs that it dumps stuff on the stack only to address them some instructions latter (well, that's my interpretation :). For example, 4010c3: 0f 28 6c 13 30 movaps 0x30(%ebx,%edx,1),%xmm5 4010c8: 0f 28 f9movaps %xmm1,%xmm7 4010cb: 0f 28 cbmovaps %xmm3,%xmm1 4010ce: 0f 29 6c 24 10 movaps %xmm5,0x10(%esp) 4010d3: 0f 59 cemulps %xmm6,%xmm1 4010d6: 0f 59 c4mulps %xmm4,%xmm0 4010d9: 0f 28 6c 16 30 movaps 0x30(%esi,%edx,1),%xmm5 4010de: 0f 59 5c 24 10 mulps 0x10(%esp),%xmm3 or 40119d: 0f c2 c1 01 cmpltps %xmm1,%xmm0 4011a1: 0f 29 04 24 movaps %xmm0,(%esp) 4011a5: 0f 28 c5movaps %xmm5,%xmm0 4011a8: 0f c2 c1 01 cmpltps %xmm1,%xmm0 4011ac: 0f 28 c8movaps %xmm0,%xmm1 4011af: 0f 56 0c 24 orps (%esp),%xmm1 Other than those quirks, it looks better to me. Just to be sure i've tried that patched version on my app, and it's slower than the unpatched version (both with -fno-gcse). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19680
[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
--- Additional Comments From stevenb at suse dot de 2005-01-31 20:14 --- Subject: Re: [meta-bug] optimizations that CSE still catches My numbers for not disabling CSE completely but disabling path following are a lot less pessimistic. This was on an AMD Opteron at 1600MHz: GCC was configured as: configure --enable-threads=posix --enable-languages="c,c++,f95" GCC bootstrap times for 'make -j1 bootstrap && make install': Bootstrap time base compiler: 2208 s Bootstrap time peak compiler: 2150 s (-2.6%) SPECint 64 bits Total time for base compilation: 192 s Total time for peak compilation: 180 s (-6.7%) base peakpeak/base 164.gzip 794799+0.63% 175.vpr 729715-1.92% 176.gcc 958963+0.52% 181.mcf 410411+0.24% 186.crafty1362 1380 +1.32% 197.parser558558= 252.eon X X 253.perlbmk 962964+0.21% 254.gap 774776+0.26% 255.vortex1159 1162 +0.26% 256.bzip2 779772-0.90% 300.twolf 836876+4.78% SPECfp 64 bits Total time for base compilation: 212 s Total time for peak compilation: 208 s (-1.9%) base peakpeak/base 168.wupwise 781793+1.53% 171.swim 690687-0.43% 172.mgrid 513514+0.02% 173.applu 624624= 177.mesa 1000998-0.20% 178.galgel X X 179.art 941953+1.28% 183.equake817820+0.37% 187.facerec 674677+0.44% 188.ammp 859859= 189.lucas 858858= 191.fma3d 699698-0.14% 200.sixtrack 382382= 301.apsi 770771+0.12% SPECint 32 bits Total time for base compilation: 257 s Total time for peak compilation: 246 s (-4.5%) base peakpeak/base 164.gzip 696700+0.57% 175.vpr 691710+2.74% 176.gcc 884875-1.02% 181.mcf 528530+0.38% 186.crafty920922+0.22% 197.parser629634+0.79% 252.eon 970963-0.72% 253.perlbmk 935938+0.32% 254.gap X X 255.vortex X X 256.bzip2 678681+0.04% 300.twolf 974966-0.82% SPECfp 32 bits Total time for base compilation: 210 s Total time for peak compilation: 204 s (-2.9%) base peakpeak/base 168.wupwise 672658-2.08% 171.swim 692696+0.58% 172.mgrid 370370= 173.applu 580580= 177.mesa 678655-3.39% 178.galgel X X 179.art 484483-0.21% 183.equake822821-0.12% 187.facerec 616617+0.16% 188.ammp 712713+0.14% 189.lucas 693695+0.20% 191.fma3d 716716= 200.sixtrack 422422= 301.apsi 685685= The SPEC numbers are the mean of three runs, so that's pretty solid. Index: params.def === RCS file: /cvs/gcc/gcc/gcc/params.def,v retrieving revision 1.53 diff -u -3 -p -r1.53 params.def --- params.def 20 Jan 2005 12:45:12 - 1.53 +++ params.def 31 Jan 2005 17:09:21 - @@ -321,7 +321,7 @@ DEFPARAM(PARAM_MIN_CROSSJUMP_INSNS, DEFPARAM(PARAM_MAX_CSE_PATH_LENGTH, "max-cse-path-length", "The maximum length of path considered in cse", -10, 0, 0) +1, 0, 0) /* The cost of expression in loop invariant motion that is considered expensive. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
[Bug target/19724] ICE when building a m68hc11 cross-compiler on ia64
--- Additional Comments From aurelien at aurel32 dot net 2005-01-31 19:59 --- I have just built a new gcc targeted for m68hc11 with gcc-3.4, and the problem is still there, both with default optimizations and with -O2. I have also run 'gcc -da' on the testcase on both amd64 and ia64 hosts, and then I have done a diff between the two (see attachement, --- is amd64, +++ is ia64). It seems they started to differ at prl19724_testcase.c.24.greg. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19724
[Bug target/19724] ICE when building a m68hc11 cross-compiler on ia64
--- Additional Comments From aurelien at aurel32 dot net 2005-01-31 19:56 --- Created an attachment (id=8117) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8117&action=view) diff of debugging dumps between amd64 and ia64 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19724
[Bug other/19722] gcc 3.2.3 installation problem on x86
--- Additional Comments From bangerth at dealii dot org 2005-01-31 19:30 --- In general, you have to make sure that you have the required versions of other packages. As for helping you to sort out hardware problems -- please look elsewhere on the web, this forum here is concerned with gcc development, not with helping users with their hardward, sorry. W. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19722
[Bug rtl-optimization/19680] sub-optimial register allocation with sse
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-31 19:04 --- I think you'll also want to try using -fno-gcse. The gcse pass is hoisting values out of your loop (as it is supposed to), except that we don't have enough registers to hold it all, so the values get spilled back to the stack. This is a known problem. If we had anything approaching a decent register allocator, we'd be able to move these values (known to be loop invariant) back inside the loop instead of spilling them. Of course, we've got multiple passes that hoist values out of loops, and using -fno-gcse only prevents half of the spilled values from being moved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19680
[Bug other/19722] gcc 3.2.3 installation problem on x86
--- Additional Comments From sitaram dot banda at gmail dot com 2005-01-31 19:01 --- (In reply to comment #5) > I think it is time to check your memory and/or hardware, this works for so many other people. Yeah, can you help me insorting out the issue. I am providing some of the info here. As i noticed from the gcc installation guide a list of prerequesites are provided. I am missing some of the tools in Tools/Packages necessary for modifing gcc. they are 1. requisite is gettext 0.12 but iam having 0.11.4 version 2. requisite is autogen 5.5.4 but iam not having 3. requisite is guile 1.4.1 but iam not having 4. requisite is tex 4.2 but iam not having Does these differences effect the istallation? As u mentions i should check my memory n hardware, in what should i chek Can u please elobarate. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19722
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pcarlini at suse dot de 2005-01-31 18:57 --- Adding pragma visibility push(default)/pop to the basic_string.h header (or to the std_string.h header, for that matter) does *not* fix the issue for me. Is anyone able to confirm this or viceversa? (binutils 2.15.91.0.2 on x86_64) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug target/19726] suboptimal constructor generated
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 18:49 --- Confirmed, note this is either a front-end bug because the front-end produces multiple stores or a target bug for not combining those stores to one store string instruction. Also if one initializer is missing it turns out it is undefined if you access that data. -- What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Component|c++ |target Ever Confirmed||1 GCC target triplet||i686-pc-linux-gnu Last reconfirmed|-00-00 00:00:00 |2005-01-31 18:49:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19726
[Bug libstdc++/19656] libstdc++ testsuite results differ if bootstrap gcc 4.0 using some gcc 4.0 version or early (gcc 3.4.3) gcc version at FreeBSD
--- Additional Comments From wanderer at rsu dot ru 2005-01-31 18:44 --- And PR18360 indeed related to this bug report. If gcc 3.4.3 bootstraped using installed gcc 4.0: gcc/intl/configure test using gcc 4.0 and found /usr/local/include/libintl.h and remember this But stage1 gcc 3.4.3 not search in /usr/local/include and fail compile stage2 with error: In file included from c-parse.y:42: /home/wanderer/pkg/build/gcc/src/gcc_34/gcc/gcc/intl.h:31:21: libintl.h: No such file or directory I think rebuilding gcc/intl before each stage using previous build C compiler can fix PR19656 and PR18360 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19656
[Bug target/19727] i386 regparm attribute mismatch does not generate warning
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 18:43 --- Fixed in 3.4.0: : Search converges between 2004-02-02-3.4 (#1) and 2004-03-01-3.4 (#2). : Search converges between 2004-02-01-trunk (#445) and 2004-03-01-trunk (#446). -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |target Keywords||diagnostic Resolution||FIXED Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19727
[Bug c/19727] New: i386 regparm attribute mismatch does not generate warning
A "gcc -Wall -c test.c" of the following compiles cleanly while it should generate an error as incorrect code will be produced for function calls to foo() via bar(). int foo(void) __attribute__((regparm(3))); int (*bar)(void) __attribute__((regparm(0))) = foo; -- Summary: i386 regparm attribute mismatch does not generate warning Product: gcc Version: 3.2.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bcrl at kvack dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19727
[Bug middle-end/19650] [4.0 Regression] miscompiling of array acess of (int)(a==2)
--- Additional Comments From dalej at apple dot com 2005-01-31 18:27 --- Fixed by patch above. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19650
[Bug other/19722] gcc 3.2.3 installation problem on x86
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 18:20 --- I think it is time to check your memory and/or hardware, this works for so many other people. -- What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19722
[Bug c++/19726] suboptimal constructor generated
-- What|Removed |Added Component|tree-optimization |c++ Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19726
[Bug target/19720] missing braces around initializer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 18:16 --- Not a gcc bug so closing. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19720
[Bug middle-end/19650] [4.0 Regression] miscompiling of array acess of (int)(a==2)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-31 18:01 --- Subject: Bug 19650 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-31 18:00:52 Modified files: gcc: ChangeLog fold-const.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/opt: pr19650.C Log message: 2005-01-31 Roger Sayle <[EMAIL PROTECTED]> Dale Johannesen <[EMAIL PROTECTED]> PR middle-end/19650 * fold-const.c (fold_binary_op_with_conditional_arg): Make types match original operands, before STRIP_NOPS. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7341&r2=2.7342 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.499&r2=1.500 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4963&r2=1.4964 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/pr19650.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19650
[Bug tree-optimization/19723] [4.0 Regression] A side effect is missed in 0 % a++.
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |law at redhat dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19723
[Bug tree-optimization/19723] [4.0 Regression] A side effect is missed in 0 % a++.
--- Additional Comments From law at redhat dot com 2005-01-31 17:30 --- Subject: Re: [4.0 Regression] A side effect is missed in 0 % a++. On Mon, 2005-01-31 at 14:44 +, pinskia at gcc dot gnu dot org wrote: > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 > 14:44 --- > Confirmed via Roger on the mailing list. Go ahead and assign it to me. I'll try to nail it down a little later today. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19723
[Bug other/19722] gcc 3.2.3 installation problem on x86
--- Additional Comments From sitaram dot banda at gmail dot com 2005-01-31 17:23 --- (In reply to comment #3) > gcc 3.2.x was definitely not stable on opteron. As far as I remember, > opteron support was developed by SuSE on the hammer branch and by > redhat on top of their 3.2.x based compiler. I believe that both folded > their changes back into the 3.3.x series, but 3.2.3 is certainly not > a good idea to use on that system. > > Besides that, we stopped support for 3.2.3. Please test with a newer > release, and if there are still problems, open a new PR. > > Thanks > Wolfgang Thanks for the early replies. I downloaded 3.4.3 from sources.redhat.com. When i am tring to install the problem is still there. And there is no change in the status with 3.3.5 also. Is the patch for 3.2.3 is available? Which version shall i use? -- Thanks & Regards, Sitaram. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19722
[Bug libfortran/19568] incorrect formatted read
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-31
17:02 ---
This looks promising.
I'll do a full check later.
Thomas
--- transfer.c.orig 2005-01-31 18:03:12.0 +0100
+++ transfer.c 2005-01-31 18:04:00.0 +0100
@@ -150,6 +150,14 @@
else
p = base = data;
+ /* If we have seen the end of the record already, we just
+ * return blanks.
+ */
+ if (sf_seen_eor) {
+memset(base,' ',*length);
+return base;
+ }
+
memset(base,'\0',*length);
current_unit->bytes_left = options.default_recl;
@@ -1222,8 +1230,11 @@
case FORMATTED_SEQUENTIAL:
length = 1;
/* sf_read has already terminated input because of an '\n' */
- if (sf_seen_eor)
- break;
+ if (sf_seen_eor)
+ {
+ sf_seen_eor = 0;
+ break;
+ }
do
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19568
[Bug libstdc++/19656] libstdc++ testsuite results differ if bootstrap gcc 4.0 using some gcc 4.0 version or early (gcc 3.4.3) gcc version at FreeBSD
--- Additional Comments From wanderer at rsu dot ru 2005-01-31 16:59 --- I found problem: At FreeBSD intl.h placed in /usr/local/include and gcc 3.4.* not search by default /usr/local/include for system headers (I check this for system compiler gcc version 3.4.2 [FreeBSD] 20040728 and gcc 3.4.3) gcc/intl/configure check intl.h by run test with command line: gcc -o conftest -g -O2 conftest.c 1>&5 and fail. As result if gcc 4.0 bootstrap using gcc 3.4.* we have gcc 4.0 with disabled intl support :((( -- What|Removed |Added CC||ljrittle at gcc dot gnu dot ||org, pinskia at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19656
[Bug libstdc++/17005] wide character strings don't work on HP-UX 11i using gcc 3.4.1
--- Additional Comments From pcarlini at suse dot de 2005-01-31 16:39 --- *** Bug 19725 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||hundertmarck at boehme-weihs ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17005
[Bug libstdc++/19725] missing std::wstring support
--- Additional Comments From pcarlini at suse dot de 2005-01-31 16:39 --- *** This bug has been marked as a duplicate of 17005 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |libstdc++ Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19725
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From charlet at adacore dot com 2005-01-31 16:38 --- Subject: Re: gnat tools not buildable cross > I don't think so. When you get into the libada directory, > CC="$(CC_FOR_TARGET)" > and all hope is lost of having the tools work in a cross configuration. That is wrong, ada/Makefile.in is designed to support this configuration, and use the native gnat bootstrap compiler instead of $(CC) to build the tools in the case of cross compilation. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug tree-optimization/19726] New: suboptimal constructor generated
1. code below compiles into many instructions like "movl $0, 16(%eax)", should
have been "stosw" since all initializations are zeros. Even if one or two are
skipped in the middle still bulk stosw should be used.
2. Even when class E with external constructor uncommented this shouldn't change
since constructor can't change any data in C.
Yuri
code
class E {
// int j;
public: E();
};
class C {
int h, i, j, k, l;
// E e;
int m, n, o, p, q, r, s, t, u, v;
public:
C();
};
C::C() : h(0), i(0), j(), k(0), l(0), m(0), n(0), o(0), p(0), q(0), r(0), s(0),
t(0), u(0), v(0) { }
--
Summary: suboptimal constructor generated
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19726
