[Bug c++/28148] [4.0/4.1/4.2 Regression] ICE with pointer to member function initializer and cast to a different type
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-08-03 07:36 --- I don't know what I was thinking when I proclaimed this invalid code. It's clearly valid; the cast is a reinterpret_cast. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED Keywords|ice-on-invalid-code |ice-on-valid-code Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28148
[Bug target/28508] Assembler Error: operand out of range (145 not between -128 and 127) form m32r-target
--- Comment #6 from inaoka dot kazuhiro at renesas dot com 2006-08-03 07:59 --- (In reply to comment #4) > Modified: > trunk/gcc/ChangeLog > trunk/gcc/config/m32r/m32r.md Could you please apply the same path to 4.1 and 4.0 branch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28508
[Bug debug/19523] [4.0/4.1/4.2 Regression] DBX_USE_BINCL support broken in the C++ compiler
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-08-03 08:37 --- > Is this really such a big deal? Solaris uses DWARF, and so does Apple now. Sure, as far as Solaris is concerned, end of the story. But other platforms are stuck with STABS (Tru64, HP-UX). And it seems that we even have a patch. In the end, I guess it's entirely Mark's call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19523
[Bug c++/28582] New: error "'operator new' takes type 'size_t' " reported inside gcc header file
OS is OpenBSD 3.9-release.
I installed gcc 4.1.1 in the standard GCC way (configure, gmake, gmake
install),
*not* using the OpenBSD package system, under /usr/local/ . This gcc compiles
"hello, world" fine, and also a toy test program using 'new int[10]'.
However, attempting to compile a certain large application (a mixture of
C, C++, Fortran 77, and Fortran 90) dies in a C++ file, reporting the following
fatal errors inside an internal GCC header file:
/usr/local/lib/gcc/i386-unknown-openbsd3.9/4.1.1/../../../../include/c++/4.1.1/new:84:
error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter
/usr/local/lib/gcc/i386-unknown-openbsd3.9/4.1.1/../../../../include/c++/4.1.1/new:85:
error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter
/usr/local/lib/gcc/i386-unknown-openbsd3.9/4.1.1/../../../../include/c++/4.1.1/new:88:
error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter
/usr/local/lib/gcc/i386-unknown-openbsd3.9/4.1.1/../../../../include/c++/4.1.1/new:89:
error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter
/usr/local/lib/gcc/i386-unknown-openbsd3.9/4.1.1/../../../../include/c++/4.1.1/new:94:
error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter
/usr/local/lib/gcc/i386-unknown-openbsd3.9/4.1.1/../../../../include/c++/4.1.1/new:95:
error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter
>From looking at timestamps, the file in question (the pathname resolves to
/usr/local/include/c++/4.1.1/new) was indeed installed as part of this gcc.
Compiling the same application works fine with the same gcc version (4.1.1)
built on an i686-pc-linux-gnu system, so this problem seems to be specific
to OpenBSD.
I will attach the full output of '/usr/local/bin/g++ -v' and of
'/usr/local/bin/g++ -v -save-temps ... my-file.cc', along with the
gzipped .ii file generated by the latter command
--
Summary: error "'operator new' takes type 'size_t' " reported
inside gcc header file
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jthorn at aei dot mpg dot de
GCC build triplet: i386-unknown-openbsd3.9
GCC host triplet: i386-unknown-openbsd3.9
GCC target triplet: i386-unknown-openbsd3.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28582
[Bug c++/28582] error "'operator new' takes type 'size_t' " reported inside gcc header file
--- Comment #1 from jthorn at aei dot mpg dot de 2006-08-03 11:22 --- Created an attachment (id=12002) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12002&action=view) output of '/usr/local/bin/g++ -v' and '/usr/local/bin/g++ -v -save-temps ... my-file.cc' This is a script(1) transcript showing the execution of, and output from, /usr/local/bin/g++ -v and /usr/local/bin/g++ -v -save-temps ... [[many other options]] my-file.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28582
[Bug c++/28582] error "'operator new' takes type 'size_t' " reported inside gcc header file
--- Comment #2 from jthorn at aei dot mpg dot de 2006-08-03 11:25 --- Created an attachment (id=12003) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12003&action=view) preprocessed source file, gzipped This is the .ii file produced by /urs/local/bin/g++ -v -save-temps ... my-file.cc The raw file is a bit big, so I have gzipped it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28582
[Bug c++/28250] [4.2 regression] ICE with invalid catch
--- Comment #12 from reichelt at gcc dot gnu dot org 2006-08-03 11:34 --- Subject: Bug 28250 Author: reichelt Date: Thu Aug 3 11:33:49 2006 New Revision: 115900 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115900 Log: PR c++/28257 PR c++/28259 PR c++/28267 * toplev.c (compile_file): Return early on errorcount or sorrycount. * cgraphunit.c (cgraph_finalize_compilation_unit): Likewise. (cgraph_optimize): Likewise. PR c++/28250 * g++.dg/eh/catch4.C: New test. PR c++/28257 * g++.dg/other/qual1.C: New test. PR c++/28259 * g++.dg/inherit/error2.C: New test. PR c++/28267 * g++.dg/other/new1.C: New test. * g++.dg/warn/pr23075.C: Remove obsolete test. * g++.old-deja/g++.brendan/crash52.C: Remove dg-warning marker. * g++.old-deja/g++.jason/report.C: Remove dg-warning marker. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/eh/catch4.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/inherit/error2.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/new1.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/qual1.C Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/cgraphunit.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/warn/pr23075.C branches/gcc-4_1-branch/gcc/testsuite/g++.old-deja/g++.brendan/crash52.C branches/gcc-4_1-branch/gcc/testsuite/g++.old-deja/g++.jason/report.C branches/gcc-4_1-branch/gcc/toplev.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28250
[Bug c++/28267] [4.0/4.1 regression] ICE on invalid default variable in operator new
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-08-03 11:34 --- Subject: Bug 28267 Author: reichelt Date: Thu Aug 3 11:33:49 2006 New Revision: 115900 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115900 Log: PR c++/28257 PR c++/28259 PR c++/28267 * toplev.c (compile_file): Return early on errorcount or sorrycount. * cgraphunit.c (cgraph_finalize_compilation_unit): Likewise. (cgraph_optimize): Likewise. PR c++/28250 * g++.dg/eh/catch4.C: New test. PR c++/28257 * g++.dg/other/qual1.C: New test. PR c++/28259 * g++.dg/inherit/error2.C: New test. PR c++/28267 * g++.dg/other/new1.C: New test. * g++.dg/warn/pr23075.C: Remove obsolete test. * g++.old-deja/g++.brendan/crash52.C: Remove dg-warning marker. * g++.old-deja/g++.jason/report.C: Remove dg-warning marker. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/eh/catch4.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/inherit/error2.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/new1.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/qual1.C Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/cgraphunit.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/warn/pr23075.C branches/gcc-4_1-branch/gcc/testsuite/g++.old-deja/g++.brendan/crash52.C branches/gcc-4_1-branch/gcc/testsuite/g++.old-deja/g++.jason/report.C branches/gcc-4_1-branch/gcc/toplev.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28267
[Bug c++/28257] [4.0/4.1 regression] ICE with invalid variable declaration
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-08-03 11:34 --- Subject: Bug 28257 Author: reichelt Date: Thu Aug 3 11:33:49 2006 New Revision: 115900 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115900 Log: PR c++/28257 PR c++/28259 PR c++/28267 * toplev.c (compile_file): Return early on errorcount or sorrycount. * cgraphunit.c (cgraph_finalize_compilation_unit): Likewise. (cgraph_optimize): Likewise. PR c++/28250 * g++.dg/eh/catch4.C: New test. PR c++/28257 * g++.dg/other/qual1.C: New test. PR c++/28259 * g++.dg/inherit/error2.C: New test. PR c++/28267 * g++.dg/other/new1.C: New test. * g++.dg/warn/pr23075.C: Remove obsolete test. * g++.old-deja/g++.brendan/crash52.C: Remove dg-warning marker. * g++.old-deja/g++.jason/report.C: Remove dg-warning marker. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/eh/catch4.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/inherit/error2.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/new1.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/qual1.C Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/cgraphunit.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/warn/pr23075.C branches/gcc-4_1-branch/gcc/testsuite/g++.old-deja/g++.brendan/crash52.C branches/gcc-4_1-branch/gcc/testsuite/g++.old-deja/g++.jason/report.C branches/gcc-4_1-branch/gcc/toplev.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28257
[Bug c++/28259] [4.0/4.1 regression] ICE with invalid virtual inheritance
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-08-03 11:34 --- Subject: Bug 28259 Author: reichelt Date: Thu Aug 3 11:33:49 2006 New Revision: 115900 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115900 Log: PR c++/28257 PR c++/28259 PR c++/28267 * toplev.c (compile_file): Return early on errorcount or sorrycount. * cgraphunit.c (cgraph_finalize_compilation_unit): Likewise. (cgraph_optimize): Likewise. PR c++/28250 * g++.dg/eh/catch4.C: New test. PR c++/28257 * g++.dg/other/qual1.C: New test. PR c++/28259 * g++.dg/inherit/error2.C: New test. PR c++/28267 * g++.dg/other/new1.C: New test. * g++.dg/warn/pr23075.C: Remove obsolete test. * g++.old-deja/g++.brendan/crash52.C: Remove dg-warning marker. * g++.old-deja/g++.jason/report.C: Remove dg-warning marker. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/eh/catch4.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/inherit/error2.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/new1.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/qual1.C Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/cgraphunit.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/warn/pr23075.C branches/gcc-4_1-branch/gcc/testsuite/g++.old-deja/g++.brendan/crash52.C branches/gcc-4_1-branch/gcc/testsuite/g++.old-deja/g++.jason/report.C branches/gcc-4_1-branch/gcc/toplev.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28259
[Bug c++/28259] [4.0/4.1 regression] ICE with invalid virtual inheritance
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-08-03 11:36 --- Subject: Bug 28259 Author: reichelt Date: Thu Aug 3 11:35:52 2006 New Revision: 115901 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115901 Log: PR c++/28257 PR c++/28259 PR c++/28267 * toplev.c (compile_file): Return early on errorcount or sorrycount. * cgraphunit.c (cgraph_finalize_compilation_unit): Likewise. (cgraph_optimize): Likewise. PR c++/28250 * g++.dg/eh/catch4.C: New test. PR c++/28257 * g++.dg/other/qual1.C: New test. PR c++/28259 * g++.dg/inherit/error2.C: New test. PR c++/28267 * g++.dg/other/new1.C: New test. * g++.dg/warn/pr23075.C: Remove obsolete test. * g++.old-deja/g++.brendan/crash52.C: Remove dg-warning marker. * g++.old-deja/g++.jason/report.C: Remove dg-warning marker. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/eh/catch4.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/error2.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/other/new1.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/other/qual1.C Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/cgraphunit.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/g++.dg/warn/pr23075.C branches/gcc-4_0-branch/gcc/testsuite/g++.old-deja/g++.brendan/crash52.C branches/gcc-4_0-branch/gcc/testsuite/g++.old-deja/g++.jason/report.C branches/gcc-4_0-branch/gcc/toplev.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28259
[Bug c++/28267] [4.0/4.1 regression] ICE on invalid default variable in operator new
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-08-03 11:36 --- Subject: Bug 28267 Author: reichelt Date: Thu Aug 3 11:35:52 2006 New Revision: 115901 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115901 Log: PR c++/28257 PR c++/28259 PR c++/28267 * toplev.c (compile_file): Return early on errorcount or sorrycount. * cgraphunit.c (cgraph_finalize_compilation_unit): Likewise. (cgraph_optimize): Likewise. PR c++/28250 * g++.dg/eh/catch4.C: New test. PR c++/28257 * g++.dg/other/qual1.C: New test. PR c++/28259 * g++.dg/inherit/error2.C: New test. PR c++/28267 * g++.dg/other/new1.C: New test. * g++.dg/warn/pr23075.C: Remove obsolete test. * g++.old-deja/g++.brendan/crash52.C: Remove dg-warning marker. * g++.old-deja/g++.jason/report.C: Remove dg-warning marker. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/eh/catch4.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/error2.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/other/new1.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/other/qual1.C Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/cgraphunit.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/g++.dg/warn/pr23075.C branches/gcc-4_0-branch/gcc/testsuite/g++.old-deja/g++.brendan/crash52.C branches/gcc-4_0-branch/gcc/testsuite/g++.old-deja/g++.jason/report.C branches/gcc-4_0-branch/gcc/toplev.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28267
[Bug c++/28257] [4.0/4.1 regression] ICE with invalid variable declaration
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-08-03 11:36 --- Subject: Bug 28257 Author: reichelt Date: Thu Aug 3 11:35:52 2006 New Revision: 115901 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115901 Log: PR c++/28257 PR c++/28259 PR c++/28267 * toplev.c (compile_file): Return early on errorcount or sorrycount. * cgraphunit.c (cgraph_finalize_compilation_unit): Likewise. (cgraph_optimize): Likewise. PR c++/28250 * g++.dg/eh/catch4.C: New test. PR c++/28257 * g++.dg/other/qual1.C: New test. PR c++/28259 * g++.dg/inherit/error2.C: New test. PR c++/28267 * g++.dg/other/new1.C: New test. * g++.dg/warn/pr23075.C: Remove obsolete test. * g++.old-deja/g++.brendan/crash52.C: Remove dg-warning marker. * g++.old-deja/g++.jason/report.C: Remove dg-warning marker. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/eh/catch4.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/error2.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/other/new1.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/other/qual1.C Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/cgraphunit.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/g++.dg/warn/pr23075.C branches/gcc-4_0-branch/gcc/testsuite/g++.old-deja/g++.brendan/crash52.C branches/gcc-4_0-branch/gcc/testsuite/g++.old-deja/g++.jason/report.C branches/gcc-4_0-branch/gcc/toplev.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28257
[Bug c++/28250] [4.2 regression] ICE with invalid catch
--- Comment #13 from reichelt at gcc dot gnu dot org 2006-08-03 11:36 --- Subject: Bug 28250 Author: reichelt Date: Thu Aug 3 11:35:52 2006 New Revision: 115901 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115901 Log: PR c++/28257 PR c++/28259 PR c++/28267 * toplev.c (compile_file): Return early on errorcount or sorrycount. * cgraphunit.c (cgraph_finalize_compilation_unit): Likewise. (cgraph_optimize): Likewise. PR c++/28250 * g++.dg/eh/catch4.C: New test. PR c++/28257 * g++.dg/other/qual1.C: New test. PR c++/28259 * g++.dg/inherit/error2.C: New test. PR c++/28267 * g++.dg/other/new1.C: New test. * g++.dg/warn/pr23075.C: Remove obsolete test. * g++.old-deja/g++.brendan/crash52.C: Remove dg-warning marker. * g++.old-deja/g++.jason/report.C: Remove dg-warning marker. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/eh/catch4.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/error2.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/other/new1.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/other/qual1.C Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/cgraphunit.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/g++.dg/warn/pr23075.C branches/gcc-4_0-branch/gcc/testsuite/g++.old-deja/g++.brendan/crash52.C branches/gcc-4_0-branch/gcc/testsuite/g++.old-deja/g++.jason/report.C branches/gcc-4_0-branch/gcc/toplev.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28250
[Bug middle-end/28581] Illegal loading the address of a label with -O2
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-03 11:44 --- This is actually invalid but I cannot find where in the docs which talk about this issue. What is happening is the scheduler is moving around the label as the basic block which contains the user label is gone. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581
[Bug libgcj/28340] gij ignores -Djava.security.manager
-- gbenson at redhat dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |gbenson at redhat dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-03 11:49:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28340
[Bug target/28582] error "'operator new' takes type 'size_t' " reported inside gcc header file
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-03 11:50 --- This is a matter of a mismatch of defines with openbsd's headers and what openbsd's defines in GCC's headers say. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28582
[Bug rtl-optimization/28489] [4.2 regression] ICE in move_insn, at haifa-sched.c:1968
--- Comment #11 from mkuvyrkov at gcc dot gnu dot org 2006-08-03 12:03
---
(In reply to comment #10)
> Created an attachment (id=11997)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11997&action=view) [edit]
> Patch
>
This patch bootstraps and has no new regression on {i386, ia64}-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28489
[Bug c++/28257] [4.0/4.1/4.2 regression] ICE with invalid variable declaration
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-08-03 12:04 --- Now also fixed on 4.1 branch, and 4.0 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Summary|[4.0/4.1 regression] ICE|[4.0/4.1/4.2 regression] ICE |with invalid variable |with invalid variable |declaration |declaration http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28257
[Bug c++/28259] [4.0/4.1/4.2 regression] ICE with invalid virtual inheritance
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-08-03 12:04 --- Now also fixed on 4.1 branch and 4.0 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Summary|[4.0/4.1 regression] ICE|[4.0/4.1/4.2 regression] ICE |with invalid virtual|with invalid virtual |inheritance |inheritance http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28259
[Bug c++/28267] [4.0/4.1 regression] ICE on invalid default variable in operator new
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-08-03 12:05 --- Now also fixed on 4.1 branch and 4.0 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28267
[Bug c++/28148] [4.0/4.1/4.2 Regression] ICE with pointer to member function initializer and cast to a different type
--- Comment #7 from donour at cs dot unm dot edu 2006-08-03 13:21 --- Subject: Re: [4.0/4.1/4.2 Regression] ICE with pointer to member function initializer and cast to a different type mmitchel at gcc dot gnu dot org wrote: > --- Comment #6 from mmitchel at gcc dot gnu dot org 2006-08-03 07:36 > --- > I don't know what I was thinking when I proclaimed this invalid code. It's > clearly valid; the cast is a reinterpret_cast. > > Ok great. The issue is not really pressing with me anymore, as I've rewritten the offending code to alleviate the problem. Although I'm sure you want to get rid of all known ICE bugs. donour -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28148
[Bug c/28583] New: ICE in default_secondary_reload, at targhooks.c:532 when building libgcc2.c as _divsc3.o
I've come across the following whilst trying to build a gcc cross-compiler: /warthog/frv/gcc/build/./gcc/xgcc -B/warthog/frv/gcc/build/./gcc/ -B/opt/frv-4.1/frv-linux-gnu/bin/ -B/opt/frv-4.1/frv-linux-gnu/lib/ -isystem /opt/frv-4.1/frv-linux-gnu/include -isystem /opt/frv-4.1/frv-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber -DL_divsc3 -fvisibility=hidden -DHIDE_EXPORTS -c ../../gcc/gcc/libgcc2.c -o libgcc/./_divsc3.o ../../gcc/gcc/libgcc2.c: In function ‘__divsc3’: ../../gcc/gcc/libgcc2.c:1910: internal compiler error: in default_secondary_reload, at targhooks.c:532 The compiler sources were pulled by Subversion from the gcc repository: Path: . URL: svn://gcc.gnu.org/svn/gcc/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 115899 Node Kind: directory Schedule: normal Last Changed Author: schwab Last Changed Rev: 115899 Last Changed Date: 2006-08-03 10:28:37 +0100 (Thu, 03 Aug 2006) Properties Last Updated: 2006-08-01 21:01:27 +0100 (Tue, 01 Aug 2006) The binutils tools being used were: warthog>./as --version GNU assembler 2.14-frv-060512-1 20031112 And the tools necessary for the compiler can be obtained from: http://people.redhat.com/~dhowells/frv/as http://people.redhat.com/~dhowells/frv/ld http://people.redhat.com/~dhowells/frv/ar http://people.redhat.com/~dhowells/frv/ranlib http://people.redhat.com/~dhowells/frv/nm http://people.redhat.com/~dhowells/frv/objdump http://people.redhat.com/~dhowells/frv/strip Or in a huge tarball with lots of other stuff from: ftp://ftp.ges.redhat.com/private/releng/frv-060512-Fc6734/tools.tar.bz2 I've reproduced this problem compiling gcc on on an SMP i686 box and a UP x86_64 box. On both boxes the native compiler was installed from the gcc-4.1.1-1.fc5 Fedora Core 5 RPMs: warthog>gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.1 20060525 (Red Hat 4.1.1-1) warthog255>ssh hades gcc -v Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux Thread model: posix gcc version 4.1.1 20060525 (Red Hat 4.1.1-1) The partially built gcc claims its version to be: warthog>./gcc/xgcc -v Using built-in specs. Target: frv-linux-gnu Configured with: ../gcc/configure --target=frv-linux-gnu --prefix=/opt/frv-4.1 --enable-languages=c --with-build-time-tools=/opt/frv-4.1/frv-linux-gnu/bin/ --with-as=/opt/frv-4.1/frv-linux-gnu/bin/frv-linux-gnu-as Thread model: posix gcc version 4.2.0 20060803 (experimental) I configured the package with the configuration line you can see above and then just ran "make". The intermediate compiler can be used to trigger the bug with following command line: ./gcc/xgcc -B./gcc -O2 -c wibble.c -o wibble.o from within the build directory. wibble.c is the attached preprocessed and stripped down version of libgcc2.c. Note that adding: #define __builtin_expect(X, Y) (X) to the top of the file seems to make the problem go away. David -- Summary: ICE in default_secondary_reload, at targhooks.c:532 when building libgcc2.c as _divsc3.o Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dhowells at redhat dot com GCC build triplet: x86_64-unknown-linux-gnu, i686-pc-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu, i686-pc-linux-gnu GCC target triplet: frv-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28583
[Bug c/28583] ICE in default_secondary_reload, at targhooks.c:532 when building libgcc2.c as _divsc3.o
--- Comment #1 from dhowells at redhat dot com 2006-08-03 13:38 --- Created an attachment (id=12004) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12004&action=view) Stripped down testcase for the bug I get the error on line 92 of this source file: warthog>./gcc/xgcc -B./gcc -O2 -c wibble.c -o wibble.o wibble.c: In function ‘__divsc3’: wibble.c:92: internal compiler error: in default_secondary_reload, at targhooks.c:532 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28583
[Bug fortran/22244] dimension information is lost for multi-dimension array
--- Comment #6 from tom dot horsley at ccur dot com 2006-08-03 13:45 --- I'd add that this isn't a problem just for multi-dimension arrays. If you declare different arrays like "integer a1(5)" "integer a2(1:5)" "integer a3(2:6)" they all show up with incorrect lower bound of 0 and upper bound of 4, making it impossible to actually reference the correct array element in a subscript expression in a debugger. -- tom dot horsley at ccur dot com changed: What|Removed |Added CC||tom dot horsley at ccur dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22244
[Bug target/27566] [4.1/4.2 Regression] ICEs in final_scan_insn and reload_cse_simplify_operands for vectors with SPE
--- Comment #6 from dje at gcc dot gnu dot org 2006-08-03 13:48 --- Subject: Bug 27566 Author: dje Date: Thu Aug 3 13:48:01 2006 New Revision: 115902 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115902 Log: PR target/27566 * config/rs6000/rs6000.c (rs6000_legitimize_reload_address): Do not reload a SPE symbol_ref into a lo_sum address. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27566
[Bug c++/28584] New: Cast to pointer from integer of different size [gcc 4.0.x and 4.1.x on x86_64]
The following code does not generate any warning when
compiled with g++ 4.0.x and 4.1.x on a x86_64 platform:
/*
#include
int f(void);
int f(void)
{
return (long) &std::printf;
}
*/
typedef unsigned long mysize_t;
void *mymmap(void *start, mysize_t length, int prot , int flags, int fd, int
offset);
//typedef unsigned long DWORD;
typedef unsigned int DWORD;
struct UDA {
DWORD UserDirectAddr;
DWORD TransAddr;
DWORD Bytes;
};
void f(UDA *puda);
void f(UDA *puda)
{
puda->UserDirectAddr =
(unsigned long) mymmap((void *) puda->TransAddr,
puda->Bytes,
0, 0, 0, 0);
}
When compiled with g++ 3.4.6 on the same platform,
the following warning is issued:
g++ -c test.cpp
test.cpp: In function `void f(UDA*)':
test.cpp:30: warning: cast to pointer from integer of different size
--
Summary: Cast to pointer from integer of different size [gcc
4.0.x and 4.1.x on x86_64]
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: denis dot charland at imi dot cnrc-nrc dot gc dot ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28584
[Bug bootstrap/17601] gcc/Makefile.in: Setting up XX_FOR_TARGET does not work
--- Comment #6 from Alexandra dot Kossovsky at oktetlabs dot ru 2006-08-03 14:12 --- I've got this bug when building cross compiler gcc-3.4.6 on i686-linux for x86_64-linux on Debian Sarge system. Thanks to Ralf Corsepius for his patch. -- Alexandra dot Kossovsky at oktetlabs dot ru changed: What|Removed |Added CC||Alexandra dot Kossovsky at ||oktetlabs dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17601
[Bug fortran/28585] New: Fortran 2003: Support NEW_LINE intrinsic
Currently, gfortran does not support the NEW_LINE intrinsic.
Expected: It is supported.
Testcase:
-
program newline
implicit none
WRITE(*,'(A)') 'This is record 1.'//NEW_LINE('A')//'This is record 2.'
end program newline
-
>From Fortran 2003 standard:
13.7.85 NEW LINE (A)
Description. Returns a newline character.
Class. Inquiry function.
Argument. A shall be of type character. It may be a scalar or an array.
Result Characteristics. Character scalar of length one with the same kind type
parameter as A.
Result Value.
Case (i): If A is of the default character type and the character in
position of the ASCII collating sequence is representable in the default
character set, then the result is ACHAR(10).
Case (ii): If A is of the ASCII character type or the ISO 10646 character
type, then the result is CHAR(10,KIND(A)).
Case (iii): Otherwise, the result is a processor-dependent character that
represents a new line in output to files connected for formatted stream output
if there is such a character.
Case (iv): Otherwise, the result is the blank character.
--
Summary: Fortran 2003: Support NEW_LINE intrinsic
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28585
[Bug c++/28586] New: thowing exception before main() leads to crash on AIX
test enviroment: AIX 5.2, 5.3; gcc 3.3.2, 4.1.0
code to reproduce:
int f()
{
try
{
throw 1;
}
catch(int){}
return 0;
}
int i = f();
int main( int argc, char* argv[] )
{
return 0;
}
--
Summary: thowing exception before main() leads to crash on AIX
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bigwad at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28586
[Bug fortran/28548] [4.2 Regression]: Optional argument failed
--- Comment #10 from sgk at troutmask dot apl dot washington dot edu 2006-08-03 16:17 --- Subject: Re: [4.2 Regression]: Optional argument failed On Thu, Aug 03, 2006 at 06:40:21AM -, martin at mpa-garching dot mpg dot de wrote: > Hmm, but my point was that even if gfortran thinks that the __convert_* > routines are elemental (as was mentioned in an earlier comment), it should > still compile the code without problems, because it is proven that the > optional argument actually exists when the __convert_* call is made. It's more complicated than just optional and elemental. The patch, AFAICT, is correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28548
[Bug target/28586] thowing exception before main() leads to crash on AIX
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28586
[Bug rtl-optimization/27291] [4.2 regression] verify_flow_info failed: too many outgoing branch edges from bb 4
--- Comment #8 from sje at gcc dot gnu dot org 2006-08-03 16:35 --- Subject: Bug 27291 Author: sje Date: Thu Aug 3 16:35:31 2006 New Revision: 115904 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115904 Log: PR rtl-optimization/28221 Backport from mainline. 2005-11-30 Nathan Sidwell <[EMAIL PROTECTED]> * loop-doloop.c (add_test): Only add jump note if we did emit a jump. 2006-05-01 Zdenek Dvorak <[EMAIL PROTECTED]> PR rtl-optimization/27291 * loop-doloop.c (add_test, doloop_modify): Handle the case condition is folded to a constant. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/loop-doloop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27291
[Bug rtl-optimization/28221] [4.1 regression] ICE in add_insn_before, at emit-rtl.c:3479
--- Comment #11 from sje at gcc dot gnu dot org 2006-08-03 16:35 --- Subject: Bug 28221 Author: sje Date: Thu Aug 3 16:35:31 2006 New Revision: 115904 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115904 Log: PR rtl-optimization/28221 Backport from mainline. 2005-11-30 Nathan Sidwell <[EMAIL PROTECTED]> * loop-doloop.c (add_test): Only add jump note if we did emit a jump. 2006-05-01 Zdenek Dvorak <[EMAIL PROTECTED]> PR rtl-optimization/27291 * loop-doloop.c (add_test, doloop_modify): Handle the case condition is folded to a constant. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/loop-doloop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28221
[Bug rtl-optimization/28221] [4.1 regression] ICE in add_insn_before, at emit-rtl.c:3479
--- Comment #12 from sje at cup dot hp dot com 2006-08-03 16:39 --- Fixed by backporting Nathan's patch and the fix for PR 27291. -- sje at cup dot hp dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28221
[Bug c++/28256] [4.1 regression] ICE with empty initializer
--- Comment #2 from sje at gcc dot gnu dot org 2006-08-03 16:58 --- Subject: Bug 28256 Author: sje Date: Thu Aug 3 16:57:54 2006 New Revision: 115905 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115905 Log: PR c++/28256 * decl.c (check_initializer): Check for 1 initializer on scalar types. * g++.dg/init/brace2.C: Change expected error message, add empty init. Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/init/brace2.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28256
[Bug target/27537] XMM alignment fault when compiling for i386 with -Os
--- Comment #7 from hjl at lucon dot org 2006-08-03 16:58 --- Apparently, it was done on purpose: http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01161.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27537
[Bug c++/28256] [4.1 regression] ICE with empty initializer
--- Comment #3 from sje at cup dot hp dot com 2006-08-03 17:02 --- Fix is now on mainline and the 4.1 branch. -- sje at cup dot hp dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28256
[Bug middle-end/28417] suboptimal 'division by constant' optimization
--- Comment #12 from vda dot linux at googlemail dot com 2006-08-03 17:06 --- Created an attachment (id=12005) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12005&action=view) Alternative algorithm v. 3 Formatting fixes mostly -- vda dot linux at googlemail dot com changed: What|Removed |Added Attachment #11971|0 |1 is obsolete|| Attachment #12000|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417
[Bug c++/28432] [4.0/4.1/4.2 regression] duplicate "no member function declared" message
--- Comment #3 from sje at gcc dot gnu dot org 2006-08-03 17:10 --- Subject: Bug 28432 Author: sje Date: Thu Aug 3 17:09:57 2006 New Revision: 115906 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115906 Log: PR c++/28432 * decl2.c (check_classfn): Remove early return. * search.c (lookup_member): Return NULL with bad type. * g++.dg/other/pr28304.C: Change expected error message. * g++.dg/other/pr28432.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/pr28432.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/decl2.c branches/gcc-4_1-branch/gcc/cp/search.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/pr28304.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28432
[Bug c++/28432] [4.0/4.1/4.2 regression] duplicate "no member function declared" message
--- Comment #4 from sje at gcc dot gnu dot org 2006-08-03 17:16 --- Subject: Bug 28432 Author: sje Date: Thu Aug 3 17:16:20 2006 New Revision: 115908 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115908 Log: PR c++/28432 * decl2.c (check_classfn): Remove early return. * search.c (lookup_member): Return NULL with bad type. * g++.dg/other/pr28304.C: Change expected error message. * g++.dg/other/pr28432.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/other/pr28432.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/decl2.c branches/gcc-4_0-branch/gcc/cp/search.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/g++.dg/other/pr28304.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28432
[Bug c++/28432] [4.0/4.1/4.2 regression] duplicate "no member function declared" message
--- Comment #5 from sje at cup dot hp dot com 2006-08-03 17:17 --- Fixed on mainline, 4.1 branch, and 4.0 branch. -- sje at cup dot hp dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28432
[Bug libstdc++/28587] New: vector is extremely slow (900x slower than it should be)
Compare this trivial program compiled with -DVBOOL and not:
#include
int main() {
unsigned N = 10;
for (unsigned i = 0; i < 10; ++i) {
#if VBOOL
std::vector V;
V.resize(N);
#else
char *X = new char[(N+7)/8];
memset(X, 0, (N+7)/8);
delete[] X;
#endif
}
}
Compiled at -O3 on a 2.5Ghz G5, the -DVBOOL version takes 47.951s, the memset
version takes 0.053s.
This spends all of it's time in std::fill, inserting one bit at a time into the
vector when it resizes. This is bad and stuff.
-Chris
--
Summary: vector is extremely slow (900x slower than it
should be)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28587
[Bug libstdc++/28587] vector is extremely slow (900x slower than it should be)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-03 18:23 --- This is most likely due to the fact the C++98 standard special cases bool. Yes there is a defect against the standard about that and I think it was already going to change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28587
[Bug libstdc++/28587] vector is extremely slow (900x slower than it should be)
--- Comment #2 from sabre at nondot dot org 2006-08-03 18:31 --- Andrew, I'm well aware that vector stores things in compact form. If you read my example, it's clear that I understand that. Even with the current algorithm used by vector, it should not use std::fill internally, it should use memset, which would be far more efficient. Again, actually read the example plz. -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28587
[Bug target/27566] [4.1/4.2 Regression] ICEs in final_scan_insn and reload_cse_simplify_operands for vectors with SPE
--- Comment #7 from dje at gcc dot gnu dot org 2006-08-03 18:36 --- Subject: Bug 27566 Author: dje Date: Thu Aug 3 18:36:28 2006 New Revision: 115909 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115909 Log: PR target/27566 * config/rs6000/rs6000.c (rs6000_legitimize_reload_address): Do not reload a SPE symbol_ref into a lo_sum address. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27566
[Bug target/27566] [4.1/4.2 Regression] ICEs in final_scan_insn and reload_cse_simplify_operands for vectors with SPE
--- Comment #8 from dje at gcc dot gnu dot org 2006-08-03 18:37 --- Patch applied to mainline and 4.1 branch. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27566
[Bug target/28586] thowing exception before main() leads to crash on AIX
--- Comment #1 from dje at gcc dot gnu dot org 2006-08-03 18:48 --- Fixing this requires implementing fallback framestate for AIX, for which there is little demand. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-03 18:48:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28586
[Bug libstdc++/28587] vector is extremely slow (900x slower than it should be)
--- Comment #3 from pcarlini at suse dot de 2006-08-03 19:16 --- Hi. I think this specific issue can be (almost) fixed rather easily, by making fill_insert smarter, that is slowly setting some bits of the previous and next underlying unsigned long and then proceeding one unsigned long at a time, instead of a bit at a time, like we do elesewhere in vector (i.e., storing either 0 or ~0 at once). By the way, I think Andrew has a point, maybe not clearly stated, in that all the people actively working in the C++ Standard Commitee strongly dislike vector for many reasons, and probably it will be deprecated in C++03 and a replacement added. That implies, in turn, that it's not so easy to find people willing to spend much time on (the various) implementations... -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-03 19:16:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28587
[Bug libstdc++/28587] vector is extremely slow (900x slower than it should be)
--- Comment #4 from sabre at nondot dot org 2006-08-03 19:21 --- >the people actively working in the C++ Standard Commitee strongly dislike >vector for many reasons, and probably it will be deprecated in C++03 and > replacement added. That implies, in turn, that it's not so easy to find > people willing to spend much time on (the various) implementations... Fair enough. My impression was that this was because std::vector is "not a container" and that the specialization doesn't act like the parent container. My (possibly flawed) understanding was that they were planning on eliminating vector but were planning to introduce the same capability under a new name, e.g. bit_vector or something like it. If that's the case, the effort isn't lost. -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28587
[Bug libstdc++/28587] vector is extremely slow (900x slower than it should be)
--- Comment #5 from pcarlini at suse dot de 2006-08-03 19:28 --- (In reply to comment #4) > Fair enough. My impression was that this was because std::vector is > "not a container" and that the specialization doesn't act like the parent > container. My (possibly flawed) understanding was that they were planning on > eliminating vector but were planning to introduce the same capability > under a new name, e.g. bit_vector or something like it. Largely correct, AFAIK. > If that's the case, the effort isn't lost. Well, it depends on the actual design of the replacement. Obviusly it will not be identical to vector, likewise the implementation... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28587
[Bug c++/28588] New: static private function
$ cat test.cpp
class Foo { static void f() {} };
int main()
{
Foo foo;
void (*f)();
f = foo.f;
return 0;
}
$ g++ -Wall test.cpp && echo "success"
success
If trying compile it with another compiler
http://cpp.sourceforge.net/?show=18471
I got something like this:
ComeauTest.c(7): error: function "Foo::f" is inaccessible
f = foo.f;
--
Summary: static private function
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dushistov at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28588
[Bug libstdc++/27530] Possible memory leak in std::vector::reserve() or std::vector::clear()
--- Comment #8 from chris at bubblescope dot net 2006-08-03 19:48 --- One quick piece of advice. Have you tried compiling your entire application against the libstdc++ debug mode? It might help narrow down where the problem is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27530
[Bug c++/27398] [4.0/4.1 regression] ICE on missing closing parenthesis
--- Comment #5 from patchapp at dberlin dot org 2006-08-03 20:15 --- Subject: Bug number PR c++/27398 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00075.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27398
[Bug c++/28588] [4.0/4.1/4.2 Regression] static private function
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-03 20:16 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||3.3.3 3.4.0 4.0.0 4.1.0 Last reconfirmed|-00-00 00:00:00 |2006-08-03 20:16:41 date|| Summary|static private function |[4.0/4.1/4.2 Regression] ||static private function Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28588
[Bug target/27537] XMM alignment fault when compiling for i386 with -Os
--- Comment #8 from agner at agner dot org 2006-08-03 20:20 --- hjl wrote: >Apparently, it was done on purpose Yes, the -Os non-alignment was obviously done on purpose. The problem is that other modules that may be called from the -Os module rely on the stack being aligned by 16. The wrong alignment makes the program crash whem xmm registers are used. The alignment must be strictly enforced in the ABI if any function relies on it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27537
[Bug testsuite/27611] FAIL: g++.dg/other/unused1.C scan-assembler string\t"class2" and string\t"printer"
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-08-03 20:27 --- Subject: Re: FAIL: g++.dg/other/unused1.C scan-assembler string\t"class2" and string\t"printer" Attached hppa1.1-hp-hpux10.20 assembler output. Probably, we should XFAIL. Dave --- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2006-08-03 20:27 --- Created an attachment (id=12006) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12006&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27611
[Bug middle-end/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #21 from dorit at gcc dot gnu dot org 2006-08-03 20:35 --- Subject: Bug 27770 Author: dorit Date: Thu Aug 3 20:35:05 2006 New Revision: 115910 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115910 Log: PR tree-optimization/27770 * tree-vectorizer.h (get_vectype_for_scalar_type): Function declaration removed (moved to tree-flow.h). (vect_can_force_dr_alignment_p): Likewise. * tree-flow.h (get_vectype_for_scalar_type): New function declaration (moved from tree-vectorizer.h). (vect_can_force_dr_alignment_p): Likewise. * tree-vectorizer.c (vect_print_dump_info): Allow calling this function from outside the vectorizer - in particular from cgraph stage. * tree-vect-analyze.c (vect_compute_data_ref_alignment): Don't increase the alignment of global arrays when -fsection-anchors is enabled. * cgraphunit.c (cgraph_increase_alignment): New function. (cgraph_optimize): Call cgraph_increase_alignment. Added: trunk/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-69.c trunk/gcc/testsuite/gcc.dg/vect/section-anchors-pr27770.c trunk/gcc/testsuite/gcc.dg/vect/section-anchors-vect-69.c Removed: trunk/gcc/testsuite/gcc.dg/vect/vect-69.c Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect.exp trunk/gcc/testsuite/lib/target-supports.exp trunk/gcc/tree-flow.h trunk/gcc/tree-vect-analyze.c trunk/gcc/tree-vectorizer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug c++/28275] Error compiling template class containing dynamic_cast<> with -fno-rtti
--- Comment #3 from bonzini at gnu dot org 2006-08-03 20:36 --- is this a rejects-valid? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28275
[Bug other/28230] ICE during bootstrap (-O2 -fwrapv issue)
--- Comment #3 from pluto at agmk dot net 2006-08-03 20:39 --- now i'm sure that `-O2 -fwrapv` causes wrong-code in stage2 binaries. to reproduce this failure try to build gcc with: STAGE1_CFLAGS="-O1" BOOT_CFLAGS="-O2 -fwrapv" $ xgcc -v Using built-in specs. Target: x86_64-pld-linux Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local --libdir=/usr/lib64 --libexecdir=/usr/lib64 --infodir=/usr/share/info --mandir=/usr/share/man --x-libraries=/usr/lib64 --enable-shared --enable-threads=posix --enable-languages=c --enable-c99 --enable-long-long --enable-multilib --enable-nls --disable-werror --with-gnu-as --with-gnu-ld --with-demangler-in-ld --with-system-zlib --with-slibdir=/lib64 --without-system-libunwind --without-x --with-long-double-128 --enable-bootstrap x86_64-pld-linux Thread model: posix gcc version 4.2.0 20060803 (experimental) (PLD-Linux) -- pluto at agmk dot net changed: What|Removed |Added Keywords||wrong-code Summary|ICE during bootstrap|ICE during bootstrap (-O2 - |(possible wrong code at - |fwrapv issue) |O2).| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230
[Bug c++/28275] Error compiling template class containing dynamic_cast<> with -fno-rtti
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-03 20:39 --- I think we should error out even if the template is not instantiated. Otherwise we get a QOI problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28275
[Bug other/28230] ICE during bootstrap (-O2 -fwrapv issue)
--- Comment #4 from pluto at agmk dot net 2006-08-03 20:41 --- (In reply to comment #2) > works fine with BOOT_CFLAGS="-01" && STAGE1_CFLAGS="-O0". > with BOOT_CFLAGS="-O2" ices as above. please ignore this comment. i missed note about my common cflags (-fwrpav -fno-strict-aliasing) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230
[Bug other/28272] ICE during bootstrap (possible wrong code at -O2).
--- Comment #4 from pluto at agmk dot net 2006-08-03 20:42 --- *** This bug has been marked as a duplicate of 28230 *** -- pluto at agmk dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28272
[Bug other/28230] ICE during bootstrap (-O2 -fwrapv issue)
--- Comment #5 from pluto at agmk dot net 2006-08-03 20:42 --- *** Bug 28272 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230
[Bug bootstrap/28511] can't bootstrap gcc / syntax error in gcc/opt-gather.awk
--- Comment #6 from pluto at agmk dot net 2006-08-03 20:44 --- (In reply to comment #5) > (In reply to comment #4) > > so it will be better if gcc searches gawk in $path rather than awk. > > Why there are OS's which have real POSIX awk that are not gawk. Like mawk, > etc. because they choose so and there is no point in choosing gawk as the only one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28511
[Bug target/28126] gcc moves an expensive instruction outside of a conditional
--- Comment #9 from rsandifo at gcc dot gnu dot org 2006-08-03 21:06
---
Created an attachment (id=12010)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12010&action=view)
A hackish fix
I agree with Kaz that a blockage would be a correct fix here.
I'm just worried about the performance impact.
A simple hack for 4.1 is to model tls_tp_ as a division
instruction. The middle-end will then treat it as potentially
trapping and won't execute it speculatively. The advantages
are that:
(1) it won't hinder speculation or scheduling of unrelated
instructions, and
(2) it still allows the optimisers to remove redundant rdhwrs,
just as they would for redundant divisions of the same values.
Although this is indeed hackish, we're kind-of relying on the same
infrasturcture to prevent speculative execution of FPU code on targets
where kernel emulation is required. A cleaner fix would be to get
may_trap_p (and perhaps other functions) to call a target hook
for UNSPECs.
As it happens, we're not really getting (2) anyway. The use of register
$3 is exposed right at the outset, which stops most optimisers from
touching it. E.g. something as simple as:
extern __thread int x;
void foo (void) { x++; }
will execute rdhwr twice. It's simple to fix this by using a pseudo
instead of (reg $3). This shouldn't cause problems, as we're already
relying on the "=v" constraint to force the use of the right register.
If we do use a pseudo, the question is what to do about uses in loops.
E.g. if we have:
extern __thread int x;
void foo (int n, int *ptr)
{
while (n-- > 0)
if (*ptr++ == 1)
x++;
}
should we allow the rdhwr to be hoisted? (It will be if we keep
a non-trapping representation of tls_get_tp_, but won't be
if we treat it as trapping.) I think the answer is that, in the
absence of profiling information, we simply don't know. There are
going to be some cases where hoisting is exactly the right thing to
do and others where it's exactly the wrong thing.
This makes me wonder if we should compromise, and get the base pointer
lazily. When we first find that a function needs the base pointer,
we can allocate a function-wide pseudo for it, and make sure that
the pseudo is zeroed at the beginning of the function. We can then
emit:
(set (pc) (if_then_else (ne (reg bp) 0) (label_ref foo) (pc))
(set (reg bp) ...UNSPEC_TLS_GET_TP...)
foo:
every time. This in itself is easy to do, but we'd need some way
of telling the optimisers that the result of ...UNSPEC_TLS_GET_TP...
is nonzero, and that subsequent (ne (reg bp) 0) branches will
always be taken.
Random musing, sorry.
Richard
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28126
[Bug libstdc++/28587] vector is extremely slow (900x slower than it should be)
--- Comment #6 from gdr at integrable-solutions dot net 2006-08-03 21:13 --- Subject: Re: vector is extremely slow (900x slower than it should be) "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | By the way, I think Andrew has a point, maybe not clearly stated, in that all | the people actively working in the C++ Standard Commitee strongly dislike | vector for many reasons, and probably it will be deprecated in C++03 and | a replacement added. That implies, in turn, that it's not so easy to find | people willing to spend much time on (the various) implementations... some committee members dislike vector for various reasons; but I don't see a chance it is going to change. But that is no reason for us to keep the implementation slower :-) -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28587
[Bug libstdc++/28587] vector is extremely slow (900x slower than it should be)
--- Comment #7 from pcarlini at suse dot de 2006-08-03 22:12 --- (In reply to comment #6) > some committee members dislike vector for various reasons; but > I don't see a chance it is going to change. Really? Or that comment of yours is just the effect of my typo C++03 for C++0x? I was under the impression that C++0x will do something about the issue! > But that is no reason for > us to keep the implementation slower :-) Volunteers welcome ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28587
[Bug fortran/28590] New: A SEQUENCEd defined type which refers to another defined type generates a spurious complaint about the lack of SEQUENCE attribute in the latter
We have a code which uses a rather complicated set of defined types. When compiling one set of these type definitions (in a module), I get the following error. In file temp.f90:34 end type GroupRigidMotion 1 Error: Component prescribedmotiondata of SEQUENCE type declared at (1) does not have the SEQUENCE attribute In file temp.f90:61 end type GroupLL 1 Error: Component groupdefll of SEQUENCE type declared at (1) does not have the SEQUENCE attribute I get this with both the latest version and the version that ships with Ubuntu 6.06 (gfortran 4.0.3). I will attempt to attach a stripped down version of the code which duplicates the problem, if I can figure out how to do so. (And would someone please provide some clarification -- Summary: A SEQUENCEd defined type which refers to another defined type generates a spurious complaint about the lack of SEQUENCE attribute in the latter Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ccnelson at itacllc dot com GCC host triplet: i686-pc-linux-gnu GCC target triplet: i386-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28590
[Bug c++/28275] Error compiling template class containing dynamic_cast<> with -fno-rtti
--- Comment #5 from apl at alum dot mit dot edu 2006-08-03 22:51 --- issuing an error here probably will cause you to violate SFINAE as well. And to my mind as a 'user', the QOI issue is that an optimization flag is interfering with a perfectly reasonable behavior when I don't materialize the templated function. It's also a QOI issue that template classes should not compile functions that are not used. If I attempt to instantiate the function, THEN is when it should report an error that the optimization settings are inconsistent with the code I'm compiling. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28275
[Bug fortran/28590] A SEQUENCEd defined type which refers to another defined type generates a spurious complaint about the lack of SEQUENCE attribute in the latter
--- Comment #1 from ccnelson at itacllc dot com 2006-08-03 22:52 --- Created an attachment (id=12011) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12011&action=view) Demo file to illustrate the problem "gfortran -c temp.f90" should illustrate the problem. As an aside: Lahey, Intel, and G95 compilers can all handle this without problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28590
[Bug libstdc++/28587] vector is extremely slow (900x slower than it should be)
--- Comment #8 from gdr at integrable-solutions dot net 2006-08-03 23:01 --- Subject: Re: vector is extremely slow (900x slower than it should be) "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | (In reply to comment #6) | > some committee members dislike vector for various reasons; but | > I don't see a chance it is going to change. | | Really? well, that is my opinion. To me, the deprecation is pointless and ineffective. It would need a huge lobbying. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28587
[Bug debug/28591] New: [4.2 regression] ICE in splice_child_die, at dwarf2out.c:5513
I get the following gnat regression. It looks a lot like PR26827 but that one is with gcc-4.1 while mine works with 4.1 and fails with 4.2. Below is a reduced testcase based on the code from the application "ghdl" that is failing. (sid)101:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -g types.ads +===GNAT BUG DETECTED==+ | 4.2.0 20060721 (experimental) (ia64-unknown-linux-gnu) GCC error:| | in splice_child_die, at dwarf2out.c:5513 | | Error detected at interfac.ads:47:49 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. types.ads compilation abandoned zsh: exit 1 /usr/lib/gcc-snapshot/bin/gcc -c -g types.ads (sid)102:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c types.ads (sid)103:[EMAIL PROTECTED]: ~] gcc-4.1 -c -g types.ads (sid)104:[EMAIL PROTECTED]: ~] cat types.ads with Interfaces; use Interfaces; package Types is type Mode_Type is (Mode_B2); type Value_Union (Mode : Mode_Type := Mode_B2) is record case Mode is when Mode_B2 => B2 : Integer_32; end case; end record; pragma Unchecked_Union (Value_Union); end Types; -- Summary: [4.2 regression] ICE in splice_child_die, at dwarf2out.c:5513 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28591
[Bug debug/26827] "GNAT BUG DETECTED" on compile GPS 1.3.1/gtkada
--- Comment #3 from tbm at cyrius dot com 2006-08-03 23:31 --- Sorry to be dense, but how do I split this attachment into separate files so they can be compiled? -- tbm at cyrius dot com changed: What|Removed |Added CC||tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26827
[Bug debug/28591] [4.2 regression] ICE in splice_child_die, at dwarf2out.c:5513
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28591
[Bug libstdc++/28406] What should be value of sqrt(complex(-1.0,-0.0))?
--- Comment #2 from pcarlini at suse dot de 2006-08-04 00:01 --- The difference between 3.4.x and 4.x is due to the builtins, therefore the underlying libc, being called by the latter. As such, this is not a libstdc++-v3 proper issue anymore, because in any case, we definitely want to use the builtins, when available... Gaby, can you have a look? -- pcarlini at suse dot de changed: What|Removed |Added CC||gdr at integrable-solutions ||dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28406
[Bug libstdc++/28406] What should be value of sqrt(complex(-1.0,-0.0))?
--- Comment #3 from gdr at integrable-solutions dot net 2006-08-04 00:09 --- Subject: Re: What should be value of sqrt(complex(-1.0,-0.0))? "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | The difference between 3.4.x and 4.x is due to the builtins, therefore the | underlying libc, being called by the latter. As such, this is not a | libstdc++-v3 proper issue anymore, because in any case, we definitely want to | use the builtins, when available... Gaby, can you have a look? yes; thanks! -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28406
[Bug libstdc++/28587] vector is extremely slow (900x slower than it should be)
--- Comment #9 from pcarlini at suse dot de 2006-08-04 00:19 --- (In reply to comment #8) > | (In reply to comment #6) > | > some committee members dislike vector for various reasons; but > | > I don't see a chance it is going to change. > | > | Really? > > well, that is my opinion. To me, the deprecation is pointless and > ineffective. It would need a huge lobbying. I see. As I said, maybe fixing this specific issue is not that difficult: the plan would be adding an optimized overload of std::fill for _Bit_iterator, similarly to what I did for _Deque_iterator. Ah, by the way, we have got libstdc++/16611 too, let's make progress on both, then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28587
[Bug c/28592] New: Segmentation Fault running -O2 on file with deep nesting
Running GCC with -O2 enabled on the attached file causes a segmentation fault. This file was reduced from a much bigger file using delta. [EMAIL PROTECTED]:~/cvs/Ivy/deputytests/minim$ gcc --version gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED]:~/cvs/Ivy/deputytests/minim$ gcc -O2 t.c t.c:29: warning: struct envelope declared inside parameter list t.c:29: warning: its scope is only this definition or declaration, which is probably not what you want t.c: In function sendall: t.c:30: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see -- Summary: Segmentation Fault running -O2 on file with deep nesting Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob at ennals dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28592
[Bug c/28592] Segmentation Fault running -O2 on file with deep nesting
--- Comment #1 from rob at ennals dot org 2006-08-04 00:27 --- Created an attachment (id=12012) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12012&action=view) Running gcc -O2 on this file gives a segfault. Tested using gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5), the standard GCC build that comes with Ubuntu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28592
[Bug libstdc++/28587] vector is extremely slow (900x slower than it should be)
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28587
[Bug c++/28593] New: [4.0/4.1/4.2 regression] ICE on invalid operator new
The following invalid code snippet triggers an ICE since GCC 4.0.0: = void *p = new (::X; = bug.cc:1: error: '::X' has not been declared bug.cc:1: error: expected type-specifier before ';' token bug.cc:1: internal compiler error: tree check: expected tree_list, have error_mark in resolve_args, at cp/call.c:2710 Please submit a full bug report, [etc.] Testing a patch. -- Summary: [4.0/4.1/4.2 regression] ICE on invalid operator new Product: gcc Version: 4.1.2 Status: UNCONFIRMED Keywords: ice-on-invalid-code, error-recovery, monitored Severity: normal Priority: P3 Component: c++ AssignedTo: reichelt at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28593
[Bug c++/28593] [4.0/4.1/4.2 regression] ICE on invalid operator new
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28593
[Bug c++/28594] New: [4.1/4.2 regression] ICE with invalid template parameter
The following invalid code snippet triggers an ICE on the 4.1 branch and mainline: === template struct A; === bug6.cc:1: error: 'void' is not a valid type for a template constant parameter bug6.cc:1: internal compiler error: tree check: expected tree_list, have error_mark in process_template_parm, at cp/pt.c:2359 Please submit a full bug report, [etc.] This is fallout from PR 27668. -- Summary: [4.1/4.2 regression] ICE with invalid template parameter Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, error-recovery, monitored Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org BugsThisDependsOn: 27668 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28594
[Bug c++/28594] [4.1/4.2 regression] ICE with invalid template parameter
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28594
[Bug c++/28595] New: [4.1/4.2 regression] ICE with invalid const static variable
The following invalid code snippet triggers an ICE since GCC 4.1.0:
===
template struct A
{
static const int i;
};
template struct B
{
char c[A::i], d;
};
B<0> b;
===
bug.cc: In instantiation of 'B<0>':
bug.cc:11: instantiated from here
bug.cc:7: internal compiler error: tree check: expected integer_cst, have
nop_expr in walk_subobject_offsets, at cp/class.c:3126
Please submit a full bug report, [etc.]
--
Summary: [4.1/4.2 regression] ICE with invalid const static
variable
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28595
[Bug c++/28595] [4.1/4.2 regression] ICE with invalid const static variable
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28595
[Bug other/28596] New: libssp does not build for cross-compile
Configure for libssp tries to build or run executables, even when configured for cross-compile. Workaround: specify --disable-libssp in configure. -- Summary: libssp does not build for cross-compile Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eager at eagercon dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: powerpc-unknown-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28596
[Bug bootstrap/28577] make of gcc-4.1.1 failed using icc v9.1.042 on ia64
--- Comment #2 from wilson at specifix dot com 2006-08-04 01:34 ---
Subject: Re: make of gcc-4.1.1 failed using icc v9.1.042
on ia64
pinskia at gcc dot gnu dot org wrote:
> --- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-02 20:13
> ---
> If not, then what is the line 49 of the file /usr/include/sys/ucontext.h?
Essentially, we are using offsetof to size an array. This would be a
GCC extension that icc apparently does not support.
Here is an out of context copy of the relevant lines
#if defined __cplusplus && __GNUC_PREREQ (3, 5)
# define _SC_GR0_OFFSET \
__builtin_offsetof (struct sigcontext, sc_gr[0])
#elif defined __GNUC__
# define _SC_GR0_OFFSET \
(((char *) &((struct sigcontext *) 0)->sc_gr[0]) - (char *) 0)
#else
# define _SC_GR0_OFFSET 0xc8/* pray that this is correct... */
#endif
typedef struct ucontext
{
union
{
mcontext_t _mc;
struct
{
unsigned long _pad[_SC_GR0_OFFSET/8];
struct ucontext *_link; /* this should overlay sc_gr[0] */
}
_uc;
}
_u;
}
ucontext_t;
Since current gcc uses __builtin_offsetof for both C and C++, this
header file could perhaps be changed to use that, assuming of course
that icc accepts this new extension, which maybe it does not.
This file is from glibc. If anything needs to be changed here, it is
glibc, not gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28577
[Bug c++/28597] New: friend function defined inside class declaration
When a friend function is defined in inside a class,
and then passed to a STL algorithm function,
gcc 4.1 reports it can't find the friend function.
gcc 4.0 and gcc 3.4.4 will compile the following code snippet.
gcc 4.1.0 (Fedora 5 x86-64) won't compile, it returns this error message.
friend_gcc4_bug.cc: In function int main(int, char**):
friend_gcc4_bug.cc:32: error: Compare was not declared in this scope
But gcc 4.1.0 will compile it if the friend is defined
outside the class, rather than inside.
friend_gcc4_bug.cc:
---
#include
#include
#include
#define FRIEND_IN_CLASS 1
class Class
{
private:
int mVal;
#if FRIEND_IN_CLASS
friend bool Compare( const Class& a, const Class& b )
{
return a.mVal < b.mVal;
}
#else
friend bool Compare( const Class& a, const Class& b );
#endif
};
#if ! FRIEND_IN_CLASS
bool Compare( const Class& a, const Class& b )
{
return a.mVal < b.mVal;
}
#endif
int main( int argc, char** argv )
{
std::vector vec;
std::sort( vec.begin(), vec.end(), Compare );
std::nth_element( vec.begin(), vec.begin(), vec.end(), Compare );
std::search( vec.begin(), vec.end(),
vec.begin(), vec.end(), Compare );
Class a, b;
Compare( a, b );
}
--
Summary: friend function defined inside class declaration
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nathanbates99 at yahoo dot com
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28597
[Bug target/28495] [4.2 regression] ICE in final_scan_insn, at final.c:2448
--- Comment #10 from wilson at gcc dot gnu dot org 2006-08-04 01:49 --- This is the same bug as PR 28490. I verified that my prototype patch for PR 28490 fixes it. *** This bug has been marked as a duplicate of 28490 *** -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
[Bug target/28490] [4.0/4.1/4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #13 from wilson at gcc dot gnu dot org 2006-08-04 01:49 --- *** Bug 28495 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug target/28490] [4.0/4.1/4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #14 from wilson at gcc dot gnu dot org 2006-08-04 01:55 --- Steve Ellcey posted a patch here: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00016.html I posted a better patch here: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00054.html This patch has not been tested yet. There are also some follow up questions raised in this thread that need to be answered. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug bootstrap/28577] make of gcc-4.1.1 failed using icc v9.1.042 on ia64
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-04 02:15 --- (In reply to comment #2) > Essentially, we are using offsetof to size an array. This would be a > GCC extension that icc apparently does not support. But that actually does not make sense since this is after ICC already compiled GCC. So I am thinking ICC miscompiled GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28577
[Bug c++/28597] friend function defined inside class declaration
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-04 02:17 --- friend bool Compare( const Class& a, const Class& b ); Does not inject a function (or class). Use the following option to get back the ARM (pre standard) behavior: -ffriend-injection Inject friend functions into enclosing namespace -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28597
[Bug libstdc++/28587] vector is extremely slow (900x slower than it should be)
--- Comment #10 from pcarlini at suse dot de 2006-08-04 02:23 --- Created an attachment (id=12013) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12013&action=view) Minimal fix Can you test a bit the attached together with your code, both from the correctness and the performance points of view? Should be sufficient for the immediate needs. Thanks in advance! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28587
[Bug libstdc++/28587] vector is extremely slow (900x slower than it should be)
--- Comment #11 from pcarlini at suse dot de 2006-08-04 02:25 --- Created an attachment (id=12014) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12014&action=view) Minimal fix Can you test a bit the attached together with your code, both from the correctness and the performance points of view? Should be sufficient for the immediate needs. Thanks in advance! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28587
[Bug target/28598] New: [4.2 Regression] GOT reloc using section anchor
`.LANCHOR0' referenced in section `.text' of libc_pic.a(strtoul_l.os): defined in discarded section `.gnu.linkonce.r.__strtol_ul_max_tab' of libc_pic.a(strtoul_l.os) `.LANCHOR1' referenced in section `.text' of libc_pic.a(strtoul_l.os): defined in discarded section `.gnu.linkonce.r.__strtol_ul_rem_tab' of libc_pic.a(strtoul_l.os) -fno-section-anchors strtoul_l.os 00fe 0f0e R_PPC_GOT16 __strtol_ul_max_tab + 0 0102 100e R_PPC_GOT16 __strtol_ul_rem_tab + 0 15: 140 OBJECT GLOBAL HIDDEN5 __strtol_ul_max_tab 16: 35 OBJECT GLOBAL HIDDEN6 __strtol_ul_rem_tab -fsection-anchors strtoul_l_os 00fe 060e R_PPC_GOT16 .LANCHOR0 + 0 0102 080e R_PPC_GOT16 .LANCHOR1 + 0 6: 0 NOTYPE LOCAL DEFAULT5 .LANCHOR0 8: 0 NOTYPE LOCAL DEFAULT6 .LANCHOR1 GOT relocs work by creating one entry in .got per symbol, so for example if there are a dozen GOT relocs referencing __strtol_ul_max_tab you get just one entry in .got. Global symbols merge. There can only be one strong definition of a global symbol, and all references resolve to that single definition. However, .LANCHOR0 is local, so is a different symbol to .LANCHOR0 in some other file. Thus the GOT reloc referencing .LANCHOR0 in this file creates a separate .got entry to a GOT reloc in another file referencing .LANCHOR0. I'd say this is a gcc bug. (The GOT reloc can't really use section anchors anyway because [EMAIL PROTECTED] has rather useless semantics, so why can't gcc use the original symbol?) ld can't treat the local symbols in linkonce sections as if they were global because .LANCHOR0 in .gnu.linkonce.r.__strtol_ul_max_tab must be different from .LANCHOR0 in .gnu.linkonce.r.some_other_name. -- Summary: [4.2 Regression] GOT reloc using section anchor Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dje at gcc dot gnu dot org GCC build triplet: powerpc-linux GCC host triplet: powerpc-linux GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28598
[Bug target/28598] [4.2 Regression] GOT reloc using section anchor
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28598
[Bug bootstrap/28577] make of gcc-4.1.1 failed using icc v9.1.042 on ia64
--- Comment #4 from t35t0r at gmail dot com 2006-08-04 04:35 --- I used: gcc-4.1.1-objdir% ../gcc-4.1.1/configure --prefix=/not/normal --enable-libada --enable-libssp --enable-threads --enable-tls but during configure it says: The following languages will be built: c,c++,java,objc Why is fortran not configured to be built? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28577
