[Bug c++/43586] Missing strstream.h file in Include directory
--- Comment #2 from skalyan_g at yahoo dot co dot in 2010-03-30 06:01 --- (In reply to comment #1) First off your find will only find files named exactly strstream. And second strstream.h never existed and is not part of the C++ standard (strstream is not either). You should use stringstream instead. I belive the backward compactibilty should be exits.Also i think the old style library's is with .h extension(strstream.h,iostream.h) and new style is without .h extension(strstream,iostream) I amtrying build with old source code which was written years back. My code is inculde strstream.h library,but i didnt not see that library in inculde directory. lxdenvdss02.dev.qintra.com#[/usr] find . -name strstream.h lxdenvdss02.dev.qintra.com#[/usr] find . -name strstream ./include/c++/3.4.6/backward/strstream ./include/c++/4.1.1/backward/strstream -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43586
[Bug c++/43586] Missing strstream.h file in Include directory
--- Comment #3 from skalyan_g at yahoo dot co dot in 2010-03-30 06:07 --- I belive the backward compactibilty should be exits.Also i think the old style library's is with .h extension(strstream.h,iostream.h) and new style is without .h extension(strstream,iostream) I am trying build the source code which was written years back. My code is using all the libraries with .h extensions.( strstream.h library),but i didnt not see strstream.h file library in inculde directory. lxdenvdss02.dev.qintra.com#[/usr] find . -name strstream.h lxdenvdss02.dev.qintra.com#[/usr] find . -name strstream ./include/c++/3.4.6/backward/strstream ./include/c++/4.1.1/backward/strstream -- skalyan_g at yahoo dot co dot in changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43586
[Bug libstdc++/43586] Missing strstream.h file in Include directory
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-30 07:48 --- Well fix the code. This code is no where near standards complaint and we are not going to keep around this extension just for one or two people. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |libstdc++ Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43586
[Bug c++/25811] No failure creating a POD containing a const member, using new without a new-initializer.
--- Comment #2 from fabien dot chene at gmail dot com 2010-03-30 08:22
---
is it still invalid in c++0X ?
5.3.4.15 has been revamped, and I no longer find a motif to reject such code.
I think the following code is also invalid, according to 8.5.6 (c++03) / 8.5.8
(c++0x):
struct A { int i; };
void f () { new A; }
I have a patch to fix both issues.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25811
[Bug c++/25811] No failure creating a POD containing a const member, using new without a new-initializer.
--- Comment #3 from redi at gcc dot gnu dot org 2010-03-30 09:16 ---
(In reply to comment #2)
is it still invalid in c++0X ?
Yes.
5.3.4.15 has been revamped, and I no longer find a motif to reject such code.
In C++0x the object is default-initialized, which for a class type means the
default constructor is called. In this code, the default constructor is
deleted, so the code will not compile. See 12.1/5
I think the following code is also invalid, according to 8.5.6 (c++03) / 8.5.8
(c++0x):
struct A { int i; };
void f () { new A; }
Not quite: in C++0x the program doesn't call for default-initialization of
A::i, it calls for default-initialization of A, which is invalid because the
default constructor is deleted.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25811
[Bug middle-end/43574] [4.5 Regression] Revision 157795 failed gcc.dg/lto/20090914-1 c_lto_20090914-1_0.o
--- Comment #3 from jiez at gcc dot gnu dot org 2010-03-30 09:20 --- The patch: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01395.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43574
[Bug target/43580] [4.5 Regression] ICE segfault compiling libgcc2.c
--- Comment #3 from mikpe at it dot uu dot se 2010-03-30 09:38 --- Building gcc-4.5-20100325 as a cross to arm-unknown-eabi works and compiles __mulsc3 for all three of thumb, arm, and arm + float-abi=hard. But a cross to arm-unknown-elf fails to build because of an ICE when compiling __mulsc3 for arm + float-abi=hard: /tmp/objdir/./gcc/xgcc -B/tmp/objdir/./gcc/ -B/tmp/junk/arm-unknown-elf/bin/ -B/tmp/junk/arm-unknown-elf/lib/ -isystem /tmp/junk/arm-unknown-elf/include -isystem /tmp/junk/arm-unknown-elf/sys-include-g -O2 -mfloat-abi=hard -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fno-inline -Wno-missing-prototypes -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I/tmp/gcc-4.5-20100325/libgcc -I/tmp/gcc-4.5-20100325/libgcc/. -I/tmp/gcc-4.5-20100325/libgcc/../gcc -I/tmp/gcc-4.5-20100325/libgcc/../include -DHAVE_CC_TLS -o _mulsc3.o -MT _mulsc3.o -MD -MP -MF _mulsc3.dep -DL_mulsc3 -c /tmp/gcc-4.5-20100325/libgcc/../gcc/libgcc2.c \ /tmp/gcc-4.5-20100325/libgcc/../gcc/libgcc2.c: In function '__mulsc3': /tmp/gcc-4.5-20100325/libgcc/../gcc/libgcc2.c:1889:1: internal compiler error: Segmentation fault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43580
[Bug middle-end/43589] segmentation fault after using __attribute__((optimize()))
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-30 09:39 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.4.3 4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-03-30 09:39:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43589
[Bug other/43581] [4.5 Regression] exception handling broken across shared libaries
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-30 09:46 --- Works for me as well. Building GCC with --as-needed is known to at least break libjava big times (you can see that when testing). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43581
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6
--- Comment #24 from LpSolit at netscape dot net 2010-03-30 09:54 --- We are very close from releasing Bugzilla 3.6: https://bugzilla.mozilla.org/show_bug.cgi?id=554523 The plan is to release it next week. So you may as well upgrade to 3.6 directly. Note that I'm on vacation this week and next week. If you need help for the upgrade, now is a good time! :) -- LpSolit at netscape dot net changed: What|Removed |Added Summary|Upgrade gcc.gnu.org/bugzilla|Upgrade gcc.gnu.org/bugzilla |to Bugzilla 3.4.5 |to Bugzilla 3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug c++/25811] No failure creating a POD containing a const member, using new without a new-initializer.
--- Comment #4 from fabien dot chene at gmail dot com 2010-03-30 10:07
---
(In reply to comment #3)
(In reply to comment #2)
is it still invalid in c++0X ?
Yes.
5.3.4.15 has been revamped, and I no longer find a motif to reject such
code.
In C++0x the object is default-initialized, which for a class type means the
default constructor is called. In this code, the default constructor is
deleted, so the code will not compile. See 12.1/5
OK thanks.
I think the following code is also invalid, according to 8.5.6 (c++03) /
8.5.8
(c++0x):
struct A { int i; };
void f () { new A; }
Not quite: in C++0x the program doesn't call for default-initialization of
A::i, it calls for default-initialization of A, which is invalid because the
default constructor is deleted.
OK, but it appears that the C++0X part is not yet implemented in GCC -- the
constructor is not deleted in this case.
Nevertheless, can you confirm that it is valid C++03 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25811
[Bug c++/25811] No failure creating a POD containing a const member, using new without a new-initializer.
--- Comment #5 from fabien dot chene at gmail dot com 2010-03-30 10:10 --- Nevertheless, can you confirm that it is valid C++03 ? I mean invalid, sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25811
[Bug c++/25811] No failure creating a POD containing a const member, using new without a new-initializer.
--- Comment #6 from redi at gcc dot gnu dot org 2010-03-30 11:19 --- (In reply to comment #5) Nevertheless, can you confirm that it is valid C++03 ? I mean invalid, sorry. Yup :-) It is invalid. A is a non-POD class type, so 5.3.4/15 says the new-expression without a new-initializer causes the object to be default-initialized, which causes a default constructor to be implicitly-defined with an empty mem-initializer list (12.1/7) which is ill-formed by 8.5/5 because the reference member is not initialized. In C++03 the cases of Foo and A are slightly different, new Foo is ill-formed according to 5.3.4/15 and new A is ill-formed as described above. In C++0x both new Foo and new A result in a call to a deleted constructor. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25811
[Bug c++/42844] const variable requires initializer / no explicitly declared default constructor
--- Comment #5 from fabien dot chene at gmail dot com 2010-03-30 11:40 --- I'm working on this bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42844
[Bug c++/42844] const variable requires initializer / no explicitly declared default constructor
--- Comment #6 from dodji at gcc dot gnu dot org 2010-03-30 11:44 --- Subject: Re: const variable requires initializer / no explicitly declared default constructor I'm working on this bug Could you please assign it to yourself then? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42844
[Bug c++/42844] const variable requires initializer / no explicitly declared default constructor
--- Comment #7 from fabien dot chene at gmail dot com 2010-03-30 11:51 --- (In reply to comment #6) Subject: Re: const variable requires initializer / no explicitly declared default constructor I'm working on this bug Could you please assign it to yourself then? Thanks. I would be glad to know how to do that :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42844
[Bug c++/42844] const variable requires initializer / no explicitly declared default constructor
--- Comment #8 from redi at gcc dot gnu dot org 2010-03-30 11:56 --- you should have the option Accept bug below the comment box. I've done it for you -- redi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fabien dot chene at gmail |dot org |dot com Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42844
[Bug other/25232] libgcc-std.ver should include __unordxf2 and __unordtf2
--- Comment #2 from jsm28 at gcc dot gnu dot org 2010-03-30 12:35 --- Subject: Bug 25232 Author: jsm28 Date: Tue Mar 30 12:35:08 2010 New Revision: 157819 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157819 Log: PR other/25232 * libgcc-std.ver (GCC_4.5.0): Define version. Include __unordxf2 and __unordtf2. * config/bfin/libgcc-bfin.ver (GCC_4.5.0): Define version. Include ___unordxf2 and ___unordtf2. * config/i386/libgcc-glibc.ver: Do not define inheritance from GCC_4.4.0 here. Modified: trunk/gcc/ChangeLog trunk/gcc/config/bfin/libgcc-bfin.ver trunk/gcc/config/i386/libgcc-glibc.ver trunk/gcc/libgcc-std.ver -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25232
[Bug other/25232] libgcc-std.ver should include __unordxf2 and __unordtf2
--- Comment #3 from jsm28 at gcc dot gnu dot org 2010-03-30 12:36 --- Fixed for 4.5.0. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.5.0 Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25232
[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-03-30 13:09 --- Subject: Bug 43553 Author: rguenth Date: Tue Mar 30 13:08:52 2010 New Revision: 157821 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157821 Log: 2010-03-30 Jack Howarth howa...@bromo.med.uc.edu PR c/43553 * Makefile.in (INTERNAL_CFLAGS): Add @set_use_emu...@. * configure.ac: Use GCC_CHECK_EMUTLS to see if emulated TLS is used and substitute set_use_emutls. * configure: Regenerated. Modified: trunk/libgcc/ChangeLog trunk/libgcc/Makefile.in trunk/libgcc/configure trunk/libgcc/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
[Bug libgcj/40860] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux
--- Comment #28 from mikpe at it dot uu dot se 2010-03-30 13:21 ---
I've looked at the amount of .ARM.exidx entry merging being done and its
consequences for the various unwinders in gcc. Currently only table entries
with immediate (inlined) data are merged, and for that all of gcc except for
libjava seems to be Ok. However, gcc can still leak bogus unwind data via
_Unwind_GetRegionStart, so I'm proposing a patch like the following:
--- gcc-4.4.3/gcc/config/arm/unwind-arm.c.~1~
+++ gcc-4.4.3/gcc/config/arm/unwind-arm.c
@@ -621,7 +621,6 @@ get_eit_entry (_Unwind_Control_Block *uc
UCB_PR_ADDR (ucbp) = 0;
return _URC_FAILURE;
}
- ucbp-pr_cache.fnstart = selfrel_offset31 (eitp-fnoffset);
/* Can this frame be unwound at all? */
if (eitp-content == EXIDX_CANTUNWIND)
@@ -637,6 +636,15 @@ get_eit_entry (_Unwind_Control_Block *uc
/* It is immediate data. */
ucbp-pr_cache.ehtp = (_Unwind_EHT_Header *)eitp-content;
ucbp-pr_cache.additional = 1;
+ /* Adjacent EIT entries with identical immediate data may be merged,
+making fnoffset/fnstart inaccurate. The ARM unwinder doesn't need
+fnstart for immediate EIT data. Other PRs than ARM's often use
+fnstart to derive the locations of landing pads, but such PRs cannot
+use immediate data in EIT entries, so are not affected by this issue.
+However, code constructing stack traces may see stack frames for
+functions with immediate data EIT entries. Clear fnstart to ensure
+_Unwind_GetRegionStart doesn't return wrong data in this case. */
+ ucbp-pr_cache.fnstart = 0;
}
else
{
@@ -645,6 +653,7 @@ get_eit_entry (_Unwind_Control_Block *uc
ucbp-pr_cache.ehtp =
(_Unwind_EHT_Header *) selfrel_offset31 (eitp-content);
ucbp-pr_cache.additional = 0;
+ ucbp-pr_cache.fnstart = selfrel_offset31 (eitp-fnoffset);
}
/* Discover the personality routine address. */
This caused no regressions for c/c++/objc/obj-c++, but libjava got two more
(ExtraClassLoader and InvokeInterface).
The problem with libjava appears to be its stacktrace.cc module. It uses
_Unwind_GetRegionStart to realign any interior PC to its function start PC,
then it uses that to look up method and class in a hash table keyed by method
start PC. With the .ARM.exidx merging, _Unwind_GetRegionStart can return the
PC for a different method, possibly also in a different class, which totally
breaks this. With my patch above libjava's stacktrace.cc can detect this case
and switch to a linear search instead. I'll try to implement that soonish.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-30 13:46 --- Not primary or secondary target. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug c++/43559] [4.5 Regression] Overloaded template functions became ambiguous
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-30 13:47 --- Still unconfirmed, leaving at P3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43559
[Bug middle-end/43574] [4.5 Regression] Revision 157795 failed gcc.dg/lto/20090914-1 c_lto_20090914-1_0.o
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2010-03-30 13:53:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43574
[Bug target/43580] [4.5 Regression] ICE segfault compiling libgcc2.c
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-30 13:55 --- CCing ARM maintainer. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||richard dot earnshaw at arm ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43580
[Bug other/43581] [4.5 Regression] exception handling broken across shared libaries
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43581
[Bug libgcj/40860] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux
--- Comment #29 from pbrook at gcc dot gnu dot org 2010-03-30 14:04 --- Wouldn't it be better to just remove _Unwind_GetRegionStart? This function is not part of the ARM EABI, and removing it would expose any (already broken) users at compile time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
--- Comment #22 from dodji at gcc dot gnu dot org 2010-03-30 14:06 --- I'll be looking into this. -- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-12-28 06:30:47 |2010-03-30 14:06:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation
--- Comment #6 from corsepiu at gcc dot gnu dot org 2010-03-30 14:11 --- (In reply to comment #5) Not primary or secondary target. Well, then redefine your priorities - AFAICT, this bug affects cross building gcc for all targets - This isn't a regression, this is a show stopper! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug c++/42844] const variable requires initializer / no explicitly declared default constructor
--- Comment #9 from fabien dot chene at gmail dot com 2010-03-30 14:11
---
(In reply to comment #8)
you should have the option Accept bug below the comment box.
I've done it for you
I've just seen it since you did it for me (thanks), but I still can't do it by
myself for other bugs :-(
reduced testcase for this one:
struct A {};
void f()
{
A const a;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42844
[Bug bootstrap/43583] [4.5 Regression] value computed not used in parallel.c:121:4
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-03-30 14:21 --- It doesn't warn for me. Please provide -v output of the command that warns for team.i or parallel.i. tmp /abuild/rguenther/trunk-g/gcc/cc1 -quiet -o /dev/null -Wall -O2 parallel.i -m32 -g -march=i486 -ftls-model=initial-exec -mtune=i686 -Werror tmp -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43583
[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-03-30 14:35 --- I only see -I../libdecnumber, not libcpp. And that's a host include dir which looks ok as we are building h8300.o, an object for the host. In fact what looks broken is -isystem /opt/rtems-4.11/h8300-rtems4.11/include -isystem /opt/rtems-4.11/h8300-rtems4.11/sys-include which is target includes when building a host object. Or maybe I'm missing something. At least please say how you configured gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug target/43129] Simplify global variable's address loading with option -fpic
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-03-30 14:36 --- Doesn't this belong in the linker as a relaxation? This would solve the reloc problem in the process. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129
[Bug target/43580] [4.5 Regression] ICE segfault compiling libgcc2.c
--- Comment #5 from mikpe at it dot uu dot se 2010-03-30 14:42 --- It's caused or exposed by r157476: 2010-03-16 Jakub Jelinek ja...@redhat.com PR debug/43051 PR debug/43092 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43580
[Bug target/43580] [4.5 Regression] ICE segfault compiling libgcc2.c
--- Comment #6 from mikpe at it dot uu dot se 2010-03-30 14:48 --- (In reply to comment #5) It's caused or exposed by r157476: 2010-03-16 Jakub Jelinek ja...@redhat.com PR debug/43051 PR debug/43092 Actually this caused a different ICE earlier in libgcc2.c (__muldi3), but before this revision it didn't ICE at all. I'll continue looking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43580
[Bug libgcj/40860] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux
--- Comment #30 from mikpe at it dot uu dot se 2010-03-30 15:09 --- (In reply to comment #29) Wouldn't it be better to just remove _Unwind_GetRegionStart? This function is not part of the ARM EABI, and removing it would expose any (already broken) users at compile time. No. First it'd break most of gcc since the c, c++, and objc unwinders use it. And they generally use it to provide a base address when interpreting LSDA and computing landing pad addresses. Second, all _Unwind_GetRegionStart does is give r/o access to the fnstart value in ARM's UCB. But ARM's own unwinder uses fnstart in __gnu_unwind_pr_common, so if fnstart is broken then so it ARM's unwinder. ARM's unwinder is in the same boat as the c/c++/objc ones. It works because .ARM.exidx merging is limited to immediate table data, but the code using fnstart (by luck or design) only runs when the table contains non-immediate data, and in those cases fnstart is accurate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
[Bug bootstrap/43583] [4.5 Regression] value computed not used in parallel.c:121:4
--- Comment #9 from tkoenig at gcc dot gnu dot org 2010-03-30 15:10 --- Created an attachment (id=20257) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20257action=view) Output obtained from adding '-v to the 32/libgomp Makefile Here's the output of make, just after having added -v to the options of the relevant Makefile. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43583
[Bug bootstrap/43583] [4.5 Regression] value computed not used in parallel.c:121:4
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-03-30 15:16 --- Err, cc1: error: unrecognized command line option -fsave-temps but - still works for me. How did you configure? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43583
[Bug target/43580] [4.5 Regression] ICE segfault compiling libgcc2.c
--- Comment #7 from jakub at gcc dot gnu dot org 2010-03-30 15:32 ---
Looks like an arm backend bug:
(insn/f 624 6 625 2 /users/joel/test-gcc/gcc-svn/libgcc/../gcc/libgcc2.c:1827
(set (mem:XF (pre_dec:XF (reg/f:SI 13 sp)) [0 S12 A32])
(reg:XF 23 f7)) 390 {*movxf_fpa} (expr_list:REG_DEAD (reg:XF 23 f7)
(nil)))
is certainly not valid RTL. PRE_DEC must have machine mode for pointers on
the machine in use, XFmode is not such a mode.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||ramana at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43580
[Bug target/43580] [4.5 Regression] ICE segfault compiling libgcc2.c
--- Comment #8 from jakub at gcc dot gnu dot org 2010-03-30 15:34 --- Created an attachment (id=20258) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20258action=view) gcc45-pr43580.patch Untested fix. Can somebody please test it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43580
[Bug debug/43557] ICE with -combine and -g
--- Comment #3 from jakub at gcc dot gnu dot org 2010-03-30 15:47 --- Created an attachment (id=20259) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20259action=view) gcc45-pr43557.patch This is a --combine mode bug, the type definitely shouldn't be incomplete just because it has been incomplete in another TU, but it doesn't hurt if expand_debug_expr is more robust. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43557
[Bug bootstrap/43583] [4.5 Regression] value computed not used in parallel.c:121:4
--- Comment #11 from tkoenig at gcc dot gnu dot org 2010-03-30 15:49 --- (In reply to comment #10) Err, cc1: error: unrecognized command line option -fsave-temps but - still works for me. How did you configure? Sorry, that should have been -save-temps. I added this to the Makefile in x86_64-unknown-linux-gnu/32/libgomp by hand and messed up that particular option. This is better: make[9]: Entering directory `/home/ig25/Gcc/trunk-bin/x86_64-unknown-linux-gnu/32/libgomp' /bin/sh ./libtool --tag=CC --mode=compile /home/ig25/Gcc/trunk-bin/./gcc/xgcc -B/home/ig25/Gcc/trunk-bin/./gcc/ -B/home/ig25/x86_64-unknown-linux-gnu/bin/ -B/home/ig25/x86_64-unknown-linux-gnu/lib/ -isystem /home/ig25/x86_64-unknown-linux-gnu/include -isystem /home/ig25/x86_64-unknown-linux-gnu/sys-include-DHAVE_CONFIG_H -I. -I../../../../trunk/libgomp -I../../../../trunk/libgomp/config/linux/x86 -I../../../../trunk/libgomp/config/linux -I../../../../trunk/libgomp/config/posix -I../../../../trunk/libgomp -Wall -Werror -v -save-temps -ftls-model=initial-exec -march=i486 -mtune=i686 -Wc,-pthread -g -O2 -m32 -MT parallel.lo -MD -MP -MF .deps/parallel.Tpo -c -o parallel.lo ../../../../trunk/libgomp/parallel.c libtool: compile: /home/ig25/Gcc/trunk-bin/./gcc/xgcc -B/home/ig25/Gcc/trunk-bin/./gcc/ -B/home/ig25/x86_64-unknown-linux-gnu/bin/ -B/home/ig25/x86_64-unknown-linux-gnu/lib/ -isystem /home/ig25/x86_64-unknown-linux-gnu/include -isystem /home/ig25/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../../trunk/libgomp -I../../../../trunk/libgomp/config/linux/x86 -I../../../../trunk/libgomp/config/linux -I../../../../trunk/libgomp/config/posix -I../../../../trunk/libgomp -Wall -Werror -v -save-temps -ftls-model=initial-exec -march=i486 -pthread -mtune=i686 -g -O2 -m32 -MT parallel.lo -MD -MP -MF .deps/parallel.Tpo -c ../../../../trunk/libgomp/parallel.c -fPIC -DPIC -o .libs/parallel.o Reading specs from /home/ig25/Gcc/trunk-bin/./gcc/specs COLLECT_GCC=/home/ig25/Gcc/trunk-bin/./gcc/xgcc COLLECT_LTO_WRAPPER=/home/ig25/Gcc/trunk-bin/./gcc/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../trunk/configure --prefix=/home/ig25 --enable-languages=all,ada --with-mpc=/usr/local : (reconfigured) ../trunk/configure --prefix=/home/ig25 --enable-languages=all,ada --with-mpc=/usr/local Thread model: posix gcc version 4.5.0 20100330 (experimental) (GCC) COLLECT_GCC_OPTIONS='-B/home/ig25/Gcc/trunk-bin/./gcc/' '-B/home/ig25/x86_64-unknown-linux-gnu/bin/' '-B/home/ig25/x86_64-unknown-linux-gnu/lib/' '-isystem' '/home/ig25/x86_64-unknown-linux-gnu/include' '-isystem' '/home/ig25/x86_64-unknown-linux-gnu/sys-include' '-DHAVE_CONFIG_H' '-I.' '-I../../../../trunk/libgomp' '-I../../../../trunk/libgomp/config/linux/x86' '-I../../../../trunk/libgomp/config/linux' '-I../../../../trunk/libgomp/config/posix' '-I../../../../trunk/libgomp' '-Wall' '-Werror' '-v' '-save-temps' '-ftls-model=initial-exec' '-march=i486' '-pthread' '-mtune=i686' '-g' '-O2' '-m32' '-MT' 'parallel.lo' '-MD' '-MP' '-MF' '.deps/parallel.Tpo' '-c' '-fPIC' '-DPIC' '-o' '.libs/parallel.o' /home/ig25/Gcc/trunk-bin/./gcc/cc1 -E -quiet -v -I. -I../../../../trunk/libgomp -I../../../../trunk/libgomp/config/linux/x86 -I../../../../trunk/libgomp/config/linux -I../../../../trunk/libgomp/config/posix -I../../../../trunk/libgomp -imultilib 32 -iprefix /home/ig25/Gcc/trunk-bin/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.5.0/ -isystem /home/ig25/Gcc/trunk-bin/./gcc/include -isystem /home/ig25/Gcc/trunk-bin/./gcc/include-fixed -MD .libs/parallel.d -MF .deps/parallel.Tpo -MP -MT parallel.lo -D_REENTRANT -DHAVE_CONFIG_H -DPIC -isystem /home/ig25/x86_64-unknown-linux-gnu/include -isystem /home/ig25/x86_64-unknown-linux-gnu/sys-include ../../../../trunk/libgomp/parallel.c -march=i486 -mtune=i686 -m32 -Wall -Werror -ftls-model=initial-exec -fPIC -g -fworking-directory -O2 -fpch-preprocess -o parallel.i ignoring nonexistent directory /home/ig25/x86_64-unknown-linux-gnu/include ignoring nonexistent directory /home/ig25/x86_64-unknown-linux-gnu/sys-include ignoring nonexistent directory /home/ig25/Gcc/trunk-bin/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include ignoring nonexistent directory /home/ig25/Gcc/trunk-bin/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include-fixed ignoring nonexistent directory /home/ig25/Gcc/trunk-bin/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../x86_64-unknown-linux-gnu/include ignoring nonexistent directory /home/ig25/Gcc/trunk-bin/gcc/../lib/gcc/../../include ignoring
[Bug bootstrap/43583] [4.5 Regression] value computed not used in parallel.c:121:4
--- Comment #12 from tkoenig at gcc dot gnu dot org 2010-03-30 15:54 --- Please forget the second half of my previous comment (I copied / pasted the wrong part). Here's the actual output, probably not very useful: i...@linux-fd1f:~/Gcc/trunk-bin gcc/cc1 -quiet -o /dev/null -O2 -Wall -m32 -g -march=i486 -ftls-model=initial-exec -mtune=i686 -Werror -v x86_64-unknown-linux-gnu/32/libgomp/parallel.i ignoring nonexistent directory /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/include /home/ig25/include /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include-fixed /usr/include End of search list. cc1: warnings being treated as errors ../../../../trunk/libgomp/parallel.c: In function 'GOMP_parallel_end': ../../../../trunk/libgomp/parallel.c:121:4: error: value computed is not used -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43583
[Bug bootstrap/43583] [4.5 Regression] value computed not used in parallel.c:121:4
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-03-30 16:00 --- (In reply to comment #12) Please forget the second half of my previous comment (I copied / pasted the wrong part). Here's the actual output, probably not very useful: i...@linux-fd1f:~/Gcc/trunk-bin gcc/cc1 -quiet -o /dev/null -O2 -Wall -m32 -g -march=i486 -ftls-model=initial-exec -mtune=i686 -Werror -v x86_64-unknown-linux-gnu/32/libgomp/parallel.i ignoring nonexistent directory /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/include /home/ig25/include /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include-fixed /usr/include End of search list. cc1: warnings being treated as errors ../../../../trunk/libgomp/parallel.c: In function 'GOMP_parallel_end': ../../../../trunk/libgomp/parallel.c:121:4: error: value computed is not used /tmp /abuild/rguenther/trunk-g/gcc/xgcc -B /abuild/rguenther/trunk-g/gcc -S -o /dev/null -O2 -Wall -m32 -g -march=i486 -ftls-model=initial-exec -mtune=i686 -Werror team.i -v Reading specs from /abuild/rguenther/trunk-g/gcc/specs COLLECT_GCC=/abuild/rguenther/trunk-g/gcc/xgcc COLLECT_LTO_WRAPPER=/abuild/rguenther/trunk-g/gcc/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /space/rguenther/src/svn/trunk/configure --disable-bootstrap --disable-nls --disable-libstdcxx-pch --enable-lto --enable-languages=c,ada,c++,fortran,java,lto,objc,obj-c++ --enable-gold --with-plugin-ld=/usr/bin/gold : (reconfigured) : (reconfigured) : (reconfigured) : (reconfigured) : (reconfigured) : (reconfigured) : (reconfigured) /space/rguenther/src/svn/trunk/configure --disable-bootstrap --disable-nls --disable-libstdcxx-pch --enable-lto --enable-gold --with-plugin-ld=/usr/bin/gold CFLAGS=-g --enable-languages=c,ada,c++,fortran,java,lto,objc,obj-c++ --no-create --no-recursion : (reconfigured) : (reconfigured) : (reconfigured) : (reconfigured) : (reconfigured) : (reconfigured) : (reconfigured) : (reconfigured) : (reconfigured) : (reconfigured) Thread model: posix gcc version 4.5.0 20100316 (experimental) (GCC) COLLECT_GCC_OPTIONS='-B' '/abuild/rguenther/trunk-g/gcc' '-S' '-o' '/dev/null' '-O2' '-Wall' '-m32' '-g' '-march=i486' '-ftls-model=initial-exec' '-mtune=i686' '-Werror' '-v' /abuild/rguenther/trunk-g/gcc/cc1 -fpreprocessed team.i -quiet -dumpbase team.i -m32 -march=i486 -mtune=i686 -auxbase-strip /dev/null -g -O2 -Wall -Werror -version -ftls-model=initial-exec -o /dev/null GNU C (GCC) version 4.5.0 20100330 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.3.4 [gcc-4_3-branch revision 152973], GMP version 4.3.1, MPFR version 2.3.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.5.0 20100330 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.3.4 [gcc-4_3-branch revision 152973], GMP version 4.3.1, MPFR version 2.3.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: d120cdac577033febb1405d25e77a328 COMPILER_PATH=/abuild/rguenther/trunk-g/gcc/ LIBRARY_PATH=/abuild/rguenther/trunk-g/gcc/32/:/lib/../lib/:/usr/lib/../lib/:/abuild/rguenther/trunk-g/gcc/:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-B' '/abuild/rguenther/trunk-g/gcc' '-S' '-o' '/dev/null' '-O2' '-Wall' '-m32' '-g' '-march=i486' '-ftls-model=initial-exec' '-mtune=i686' '-Werror' '-v' /tmp that's with revision 157820. Thus, I can't reproduce it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43583
[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-03-30 16:01 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
[Bug target/43580] [4.5 Regression] ICE segfault compiling libgcc2.c
--- Comment #9 from mikpe at it dot uu dot se 2010-03-30 16:04 --- (In reply to comment #8) Created an attachment (id=20258) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20258action=view) [edit] gcc45-pr43580.patch Untested fix. Can somebody please test it? Worked for me. Tested on top of 4.5 r157825 with cross to arm-unknown-elf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43580
[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation
--- Comment #8 from corsepiu at gcc dot gnu dot org 2010-03-30 16:09 --- (In reply to comment #7) At least please say how you configured gcc. We build one-tree-style build with newlib symlinked into gcc's sourcetree. Configuration from a sparc-rtems4.11-gcc: # /opt/rtems-4.11/bin/sparc-rtems4.11-gcc -v Using built-in specs. COLLECT_GCC=/opt/rtems-4.11/bin/sparc-rtems4.11-gcc COLLECT_LTO_WRAPPER=/opt/rtems-4.11/libexec/gcc/sparc-rtems4.11/4.5.0/lto-wrapper Target: sparc-rtems4.11 Configured with: ../gcc-4.5-20100325/configure --prefix=/opt/rtems-4.11 --bindir=/opt/rtems-4.11/bin --exec_prefix=/opt/rtems-4.11 --includedir=/opt/rtems-4.11/include --libdir=/opt/rtems-4.11/lib --libexecdir=/opt/rtems-4.11/libexec --mandir=/opt/rtems-4.11/share/man --infodir=/opt/rtems-4.11/share/info --datadir=/opt/rtems-4.11/share --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=sparc-rtems4.11 --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose --with-newlib --with-system-zlib --disable-nls --without-included-gettext --disable-win32-registry --enable-version-specific-runtime-libs --enable-threads --disable-lto --disable-plugin --enable-newlib-io-c99-formats --enable-languages=c,c++ Thread model: rtems gcc version 4.5.0 20100325 (RTEMS gcc-4.5.0-5.fc12/newlib-1.18.0-5.fc12) (GCC) RPMS/SRPMS can be found below ftp://ftp.rtems.org/pub/rtems/linux/4.11/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug bootstrap/43583] [4.5 Regression] value computed not used in parallel.c:121:4
--- Comment #14 from jakub at gcc dot gnu dot org 2010-03-30 16:13 --- I can't reproduce this iether. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43583
[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation
--- Comment #9 from joel at gcc dot gnu dot org 2010-03-30 16:22 --- Maybe I am misreading the command invoked in Ralf's original report but it is using xgcc which is the cross gcc: make[5]: Entering directory `/users/rtems/src/rpms/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.5.0/build/gcc' /users/rtems/src/rpms/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.5.0/build/./gcc/xgcc -B/users/rtems/src/rpms/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.5.0/build/./gcc/ -B/opt/rtems-4.11/h8300-rtems4.11/bin/ -B/opt/rtems-4.11/h8300-rtems4.11/lib/ -isystem /opt/rtems-4.11/h8300-rtems4.11/include -isystem So any attempt to compile h8300.c with the cross xgcc is just wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation
--- Comment #10 from joel at gcc dot gnu dot org 2010-03-30 16:29 --- I encountered this issue while doing builds to run gcc tests. Newlib is symlinked into gcc. binutils was built and installed separately. My configure command is pretty simple. /users/joel/test-gcc/gcc-svn/configure --enable-threads=rtems --with-gnu-as --enable-multilib --enable-newlib-mb --enable-newlib-iconv --with-gnu-ld --with-newlib --verbose --with-system-zlib --disable-nls --enable-version-specific-runtime-libs --enable-languages=c,c++ --target=h8300-rtems4.10 --prefix=/users/joel/test-gcc/install-svn -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug lto/42757] lto1 does not emit common symbols with -fuse-linker-plugin
--- Comment #9 from rwild at gcc dot gnu dot org 2010-03-30 16:39 ---
(In reply to comment #2)
Works when linking in comm.o main.o order.
FWIW one can construct test cases where neither order works, e.g.,
cat main.c \EOF
extern int i;
int j;
int main(void)
{
i = 0;
return i;
}
EOF
cat comm.c \EOF
extern int j;
int i;
int f() { return j; }
EOF
(libtool likes to produce such code with preload symfiles)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42757
[Bug c++/43559] [4.5 Regression] Overloaded template functions became ambiguous
--- Comment #4 from jason at gcc dot gnu dot org 2010-03-30 16:46 --- Yes, this is a bug. The call to same_type_p in more_specialized_fn is wrong because the two template parms have different indices. -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-30 16:46:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43559
[Bug c++/42844] const variable requires initializer / no explicitly declared default constructor
--- Comment #10 from fabien dot chene at gmail dot com 2010-03-30 16:47
---
reduced testcase for this one:
struct A {};
void f()
{
A const a;
}
I misspoke, let's keep the original testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42844
[Bug fortran/38568] ICE with invalid bounds for I/O FMT= array
--- Comment #6 from dominiq at lps dot ens dot fr 2010-03-30 16:48 --- I do not get any ICE with the different 4.5 versions I have tried (oldest is r156618). Could someone check that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38568
[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation
--- Comment #11 from corsepiu at gcc dot gnu dot org 2010-03-30 16:50 --- (In reply to comment #9) Maybe I am misreading the command invoked in Ralf's original report but it is using xgcc which is the cross gcc: No, you haven't - It's likely a better analysis of the same issue I was observing xgcc being used with target-includes causing build failures for the m32r and h8300, because this pulls-in build-host config.h's into compiling target files. You are saying: h8300.c is a host file and should not be compiled with the cross-compiler. I think we are getting closer ... Could this be a CC vs. CC_FOR_BUILD issue? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug middle-end/43464] copy prop breaks loop closed SSA form
--- Comment #14 from spop at gcc dot gnu dot org 2010-03-30 16:57 --- Subject: Bug 43464 Author: spop Date: Tue Mar 30 16:56:49 2010 New Revision: 157828 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157828 Log: Fix PR43464: copyprop should maintain loop close phi nodes with multiple arguments. 2010-03-30 Richard Guenther rguent...@suse.de Zdenek Dvorak o...@ucw.cz Sebastian Pop sebastian@amd.com PR middle-end/43464 * tree-ssa-copy.c (init_copy_prop): Handle loop close phi nodes with multiple arguments. (execute_copy_prop): Remove call to rewrite_into_loop_closed_ssa. Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/tree-ssa-copy.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43464
[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation
--- Comment #12 from joel at gcc dot gnu dot org 2010-03-30 16:58 --- Created an attachment (id=20260) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20260action=view) generated gcc/Makefile This is the gcc/Makefile generated for my h8300-rtems4.10 build. h8300.o is supposed to go in libbackend.a if I am reading this right. If that's the case, it should NEVER be compiled with the xgcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug other/43581] [4.5 Regression] exception handling broken across shared libaries with -fuse-linker-plugin
--- Comment #3 from rwild at gcc dot gnu dot org 2010-03-30 16:58 --- Bug also happens with $ g++ -v Using built-in specs. COLLECT_GCC=/opt/bin/g++ COLLECT_LTO_WRAPPER=/opt/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure -C --enable-maintainer-mode --prefix=/opt --with-libelf=/opt --enable-lto --without-cloog --without-ppl --with-mpc=/opt --enable-gold LD=/opt/bin/ld LD_FOR_TARGET=/opt/bin/ld --enable-languages=c,c++,fortran,java,lto,objc,obj-c++ Thread model: posix gcc version 4.5.0 20100329 (experimental) (GCC) and $ /opt/bin/ld -v GNU gold (GNU Binutils 2.20.51.20100319) 1.9 $ /lib/libc.so.6 GNU C Library stable release version 2.7, by Roland McGrath et al. But my overriding of LD_LIBRARY_PATH was bogus, as it was wrongly removing /opt/lib64 which is where the just-installed libstdc++.so.6 lives. Sorry about the testcase reduction error (libtool --mode=execute prepends to LD_LIBRARY_PATH rather than overriding it). I still see the original testsuite error, though only with '-flto -fuse-linker-plugin' (adjusting bug title and keywords). So, from the original error description, grab the source files, then CXX='g++' CXXFLAGS='-O2 -flto' LDFLAGS=-fuse-linker-plugin $CXX $CXXFLAGS -c main.cpp $CXX $CXXFLAGS -c lib.cpp -fPIC $CXX -fPIC -shared $CXXFLAGS $LDFLAGS lib.o -Wl,-soname -Wl,liba.so.1 -o liba.so.1 ln -sf liba.so.1 liba.so $CXX $CXXFLAGS $LDFLAGS -o main main.o -L. -la LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH ./main leads to Aborted (core dumped) with a backtrace of #0 0x7fc2ae066095 in raise () from /lib/libc.so.6 (gdb) bt #0 0x7fc2ae066095 in raise () from /lib/libc.so.6 #1 0x7fc2ae067af0 in abort () from /lib/libc.so.6 #2 0x7fc2ae6f94bd in uw_update_context_1 (context=0x7fff7fe51010, fs=0x7fff7fe50e90) at ../../../gcc/libgcc/../gcc/unwind-pe.h:155 #3 0x7fc2ae6f97d9 in uw_update_context (context=0x7fff7fe51010, fs=0x7fff7fe50e90) at ../../../gcc/libgcc/../gcc/unwind-pe.h:155 #4 0x7fc2ae6fa40b in _Unwind_RaiseException (exc=0x4030b0) at ../../../gcc/libgcc/../gcc/unwind-pe.h:155 #5 0x7fc2ae7dba31 in __cxa_throw (obj=value optimized out, tinfo=value optimized out, dest=value optimized out) at ../../../../gcc/libstdc++-v3/libsupc++/eh_throw.cc:78 #6 0x7fc2 in ?? () #7 0x7fff7fe51408 in ?? () #8 0x7fff7fe513f8 in ?? () #9 0x00403028 in ?? () #10 0x in ?? () It even fails without -O2, the backtrace is then #0 0x7f44e1705095 in raise () from /lib/libc.so.6 #1 0x7f44e1706af0 in abort () from /lib/libc.so.6 #2 0x7f44e1e7b6ed in __gnu_cxx::__verbose_terminate_handler () at ../../../../gcc/libstdc++-v3/libsupc++/vterminate.cc:93 #3 0x7f44e1e79906 in __cxxabiv1::__terminate (handler=value optimized out) at ../../../../gcc/libstdc++-v3/libsupc++/eh_terminate.cc:39 #4 0x7f44e1e79933 in std::terminate () at ../../../../gcc/libstdc++-v3/libsupc++/eh_terminate.cc:49 #5 0x7f44e1e79a3e in __cxa_throw (obj=value optimized out, tinfo=value optimized out, dest=value optimized out) at ../../../../gcc/libstdc++-v3/libsupc++/eh_throw.cc:83 #6 0x7f44e1ecdac7 in libbar () from /tmp/a/liba.so.1 #7 0x7f44e1ecdb5c in libfoo () from /tmp/a/liba.so.1 #8 0x004010e2 in exceptions_in_lib () #9 0x0040116e in main () If I add -g to '-O2 -flto', the backtrace is #0 0x7fd0d5b75095 in raise () from /lib/libc.so.6 #1 0x7fd0d5b76af0 in abort () from /lib/libc.so.6 #2 0x7fd0d6207504 in execute_cfa_program (insn_ptr=0x7fd0d628aabd , insn_end=0x7fd0d628b717 E, context=0x7fffc0cf93a0, fs=0x7fffc0cf9220) at ../../../gcc/libgcc/../gcc/unwind-pe.h:155 #3 0x7fd0d6208a78 in uw_frame_state_for (context=0x7fffc0cf93a0, fs=0x7fffc0cf9220) at ../../../gcc/libgcc/../gcc/unwind-pe.h:155 #4 0x7fd0d6209416 in _Unwind_RaiseException (exc=0x4030b0) at ../../../gcc/libgcc/../gcc/unwind-pe.h:155 #5 0x7fd0d62eaa31 in __cxa_throw (obj=value optimized out, tinfo=value optimized out, dest=value optimized out) at ../../../../gcc/libstdc++-v3/libsupc++/eh_throw.cc:78 #6 0x7fd0d633e57e in libbar () from /tmp/a/liba.so.1 #7 0x7fffc0cf9788 in ?? () #8 0x00403028 in ?? () #9 0x in ?? () Without -fuse-linker-plugin, it passes for me. I get a similar failure for exceptions from dlopen'ed modules, if you like I can provide a testcase for that as well. -- rwild at gcc dot gnu dot org changed: What|Removed |Added Keywords||lto Summary|[4.5 Regression] exception |[4.5 Regression] exception |handling broken across |handling broken across |shared libaries |shared libaries with -fuse- |
[Bug testsuite/29404] make check fails to compile library testcases
--- Comment #10 from ghazi at gcc dot gnu dot org 2010-03-30 17:11 --- Still happens on 4.5 trunk. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2009-01-17 03:03:45 |2010-03-30 17:11:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29404
[Bug fortran/38568] ICE with invalid bounds for I/O FMT= array
--- Comment #7 from burnus at gcc dot gnu dot org 2010-03-30 17:12 --- Hmm, currently, I cannot reproduce it - not even with valgrind; I tried: gfortran 4.1, 4.2, 4.3, 4.4, 4.5 - and various older trunk versions (2008-12-18, 2008-12-05,2009-01-05, 2009-02-05, 2009-05-05, 2009-08-05) - but no segfault. Neither with valgrind nor without. (That's on x86-64-linux.) The ICE could be reproduced trice: in comment 0 and in comment 2 and in comment 5; it could not be reproduced in comment 1, comment 6 - and in this comment 7. Close as WORKSFORME? Or can someone reproduce it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38568
[Bug fortran/41059] -fwhole-file and error messages
--- Comment #2 from dominiq at lps dot ens dot fr 2010-03-30 17:13 --- ... . I guess that we could tag every line for errors but this would need a bigger change to error.c than I am prepared to embark on. I understand that! Although there is no emergency to clean up the error handling in gfortran, someday someone will have to do it, for instance to remove the ICE after legitimate errors (see pr36192, pr37744, pr38568, and pr43266). In addition, if someday -fwhole-file becomes the default, the testsuite will have to adjusted to handle the change in the type and/or place of the messages. My inclination is WONTFIX but I would be happy to discuss. I would prefer to leave this pr open (could you confirm it?) until these issues are resolved. This will probably not prevent duplicate reports, but at least it will keep some memory of the problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41059
[Bug rtl-optimization/30957] Misscompare with variable expansion optimization
--- Comment #19 from ghazi at gcc dot gnu dot org 2010-03-30 17:16 --- gcc.dg/pr30957-1.c still XFAILs on x86_64-unknown-linux-gnu -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2009-11-22 18:01:42 |2010-03-30 17:16:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
[Bug libmudflap/32276] [4.3/4.4/4.5 Regression]: libmudflap.c++/pass41-frag.cxx
--- Comment #14 from ghazi at gcc dot gnu dot org 2010-03-30 17:17 --- Reconfirm -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2009-12-20 16:12:51 |2010-03-30 17:17:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32276
[Bug fortran/43591] New: internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604
When compiling the attached sources, I get Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/archive/ohl/tools64/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/ohl/archive/gcc/svn/configure --prefix=/archive/ohl/tools64/ --enable-languages=c,c++,fortran Thread model: posix gcc version 4.5.0 20100330 (experimental) (GCC) ward.f90:79:0: internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ohl at physik dot uni-wuerzburg dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43591
[Bug fortran/43591] internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604
--- Comment #1 from ohl at physik dot uni-wuerzburg dot de 2010-03-30 17:21 --- Created an attachment (id=20261) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20261action=view) program that triggers the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43591
[Bug c/39959] [4.5 Regression] IMA is broken, gcc.dg/pr34668-1.c, gcc.dg/pr34668-2.c ICE
--- Comment #20 from ghazi at gcc dot gnu dot org 2010-03-30 17:22 --- Still have gcc.dg/pr34668-1.c failing on mainline (with checking enabled). -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2009-11-16 16:38:01 |2010-03-30 17:22:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39959
[Bug fortran/38568] ICE with invalid bounds for I/O FMT= array
--- Comment #8 from dominiq at lps dot ens dot fr 2010-03-30 17:24 --- I get the ICE with 4.4.2 (intel/ppc), 4.3.4, and 4.2.4 (ppc), but not on trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38568
[Bug middle-end/36143] [4.4 Regression]: FAIL: g++.dg/tree-ssa/pr19637.C
--- Comment #16 from ghazi at gcc dot gnu dot org 2010-03-30 17:25 --- PASSes on 4.5 trunk, but still XFAILs on 4.4 branch. Since it's a 4.4 regression, should the patch be backported to 4.4 ? -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.4.4 Last reconfirmed|2008-05-25 18:13:41 |2010-03-30 17:25:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36143
[Bug bootstrap/43583] [4.5 Regression] value computed not used in parallel.c:121:4
--- Comment #15 from tkoenig at gcc dot gnu dot org 2010-03-30 17:30 --- This was caused by a local modification on my tree. Sorry for the noise :-( Closing as invalid. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43583
[Bug fortran/43591] internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604
--- Comment #2 from jv244 at cam dot ac dot uk 2010-03-30 17:58 --- confirmed. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-30 17:58:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43591
[Bug fortran/43591] internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604
--- Comment #3 from dominiq at lps dot ens dot fr 2010-03-30 18:29 --- Reduced test: module ward_lib implicit none type omega_procedures procedure(number_particles_out), nopass, pointer :: number_particles_out = NULL() procedure(number_flavor_states), nopass, pointer :: number_flavor_states = NULL() end type omega_procedures contains subroutine quantum_numbers2 (physical, unphysical) type(omega_procedures), intent(in) :: physical, unphysical integer, dimension(physical%number_particles_out(), physical%number_flavor_states()) :: table_flavor_states end subroutine quantum_numbers2 end module ward_lib -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43591
[Bug fortran/43592] New: Unexpected INTERFACE statement in INTERFACE block at (1)
cat small.f90 interface assignment (=) interface pseudo_scalar pure function double_tensor2odd (x, t2) result (xt2) gfortran small.f90 small.f90:2.25: interface pseudo_scalar 1 Error: Unexpected INTERFACE statement in INTERFACE block at (1) f951: 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. -- Summary: Unexpected INTERFACE statement in INTERFACE block at (1) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43592
[Bug c++/43559] [4.5 Regression] Overloaded template functions became ambiguous
--- Comment #5 from jason at gcc dot gnu dot org 2010-03-30 19:40 --- Subject: Bug 43559 Author: jason Date: Tue Mar 30 19:39:48 2010 New Revision: 157831 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157831 Log: PR c++/43559 * pt.c (more_specialized_fn): Don't control cv-qualifier check with same_type_p. Added: trunk/gcc/testsuite/g++.dg/template/partial7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43559
[Bug c++/43559] [4.5 Regression] Overloaded template functions became ambiguous
--- Comment #6 from jason at gcc dot gnu dot org 2010-03-30 19:47 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43559
[Bug fortran/43591] PPC: internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604
--- Comment #4 from dominiq at lps dot ens dot fr 2010-03-30 19:55 --- Further reduced test that does not give an ICE, but several errors: [macbook] f90/bug% cat pr43591_red_1.f90 module ward_lib implicit none type omega_procedures procedure(number_particles_out), nopass, pointer :: number_particles_out = NULL() end type omega_procedures contains subroutine quantum_numbers2 () !type(omega_procedures), intent(in) :: physical integer, dimension(physical%number_particles_out()) :: table_flavor_states end subroutine quantum_numbers2 end module ward_lib [macbook] f90/bug% gfc pr43591_red_1.f90 pr43591_red_1.f90:14.31: integer, dimension(physical%number_particles_out()) 1 Error: Expected another dimension in array declaration at (1) pr43591_red_1.f90:7.35: procedure(number_particles_out), nopass, pointer :: number_particles_out = 1 Error: Symbol 'number_particles_out' at (1) has no IMPLICIT type pr43591_red_1.f90:7.77: procedure(number_particles_out), nopass, pointer :: number_particles_out = 1 Error: Interface 'number_particles_out' of procedure pointer component 'number_particles_out' at (1) must be explicit If uncomment the commented line I get an ICE: #0 fancy_abort (file=0x100974ce0 ../../p_work/gcc/fortran/expr.c, line=3604, function=0x1009f4d80 gfc_traverse_expr) at ../../p_work/gcc/diagnostic.c:762 #1 0x00010002b86f in gfc_traverse_expr (expr=0x141815840, sym=0x0, func=0x100026480 expr_check_typed_help, f=0) at ../../p_work/gcc/fortran/expr.c:3604 #2 0x00010002c5e7 in gfc_expr_check_typed (e=0x141815840, ns=0x142078600, strict=value temporarily unavailable, due to optimizations) at ../../p_work/gcc/fortran/expr.c:3767 #3 0x000169f5 in gfc_match_array_spec (asp=0x100c8f140) at ../../p_work/gcc/fortran/array.c:310 #4 0x000100018bcf in match_attr_spec () at ../../p_work/gcc/fortran/decl.c:3044 #5 0x00010001d137 in gfc_match_data_decl () at ../../p_work/gcc/fortran/decl.c:3730 #6 0x000100062f22 in match_word (str=value temporarily unavailable, due to optimizations, subr=0x10001d0d0 gfc_match_data_decl, old_locus=0x7fff5fbfd380) at ../../p_work/gcc/fortran/parse.c:65 #7 0x0001000637ad in decode_statement () at ../../p_work/gcc/fortran/parse.c:283 #8 0x000100064dd5 in next_statement () at ../../p_work/gcc/fortran/parse.c:715 #9 0x00010006613c in parse_spec (st=value temporarily unavailable, due to optimizations) at ../../p_work/gcc/fortran/parse.c:2549 #10 0x00010006838d in parse_progunit (st=ST_ARITHMETIC_IF) at ../../p_work/gcc/fortran/parse.c:3758 #11 0x000100068708 in parse_contained (module=1) at ../../p_work/gcc/fortran/parse.c:3698 #12 0x000100069c8a in gfc_parse_file () at ../../p_work/gcc/fortran/parse.c:3953 #13 0x0001000a291c in gfc_be_parse_file (set_yydebug=value temporarily unavailable, due to optimizations) at ../../p_work/gcc/fortran/f95-lang.c:239 #14 0x0001006d6b5a in toplev_main (argc=2, argv=0x7fff5fbfd9e8) at ../../p_work/gcc/toplev.c:1053 #15 0x000119e4 in start () Although gfortran should not give an ICE, I have doubts about the validity of the code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43591
[Bug tree-optimization/43430] Missed vectorization: stmt not supported: cond_expr
--- Comment #6 from spop at gcc dot gnu dot org 2010-03-30 19:58 --- Subject: Bug 43430 Author: spop Date: Tue Mar 30 19:58:35 2010 New Revision: 157833 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157833 Log: Replace type != type comparisons with types_compatible_p. 2010-03-30 Sebastian Pop sebastian@amd.com PR middle-end/43430 * tree-vect-slp.c (vect_get_and_check_slp_defs): Replace type pointer comparisons with types_compatible_p. * tree-vect-stmts.c (vectorizable_call): Same. (vectorizable_condition): Same. * gcc.dg/vect/pr43430-1.c: New. Added: trunk/gcc/testsuite/gcc.dg/vect/pr43430-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c trunk/gcc/tree-vect-stmts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43430
[Bug debug/43593] New: Var-tracking unnecessarily flushes all call used registers on calls instead of regs invalidated by call
Flushing e.g. sp on each call is completely unnecessary: for (r = 0; r FIRST_PSEUDO_REGISTER; r++) -if (TEST_HARD_REG_BIT (call_used_reg_set, r)) +if (TEST_HARD_REG_BIT (regs_invalidated_by_call, r)) var_regno_delete (set, r); -- Summary: Var-tracking unnecessarily flushes all call used registers on calls instead of regs invalidated by call Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: jakub at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43593
[Bug fortran/43592] Unexpected INTERFACE statement in INTERFACE block at (1)
--- Comment #1 from dominiq at lps dot ens dot fr 2010-03-30 20:00 --- Confirmed: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x 0x0001000674c8 in parse_spec (st=ST_INTERFACE) at ../../p_work/gcc/fortran/parse.c:2239 2239gfc_add_function (sym-attr, sym-name, NULL); (gdb) bt #0 0x0001000674c8 in parse_spec (st=ST_INTERFACE) at ../../p_work/gcc/fortran/parse.c:2239 #1 0x00010006838d in parse_progunit (st=ST_ARITHMETIC_IF) at ../../p_work/gcc/fortran/parse.c:3758 #2 0x00010006942c in gfc_parse_file () at ../../p_work/gcc/fortran/parse.c:4192 #3 0x0001000a291c in gfc_be_parse_file (set_yydebug=value temporarily unavailable, due to optimizations) at ../../p_work/gcc/fortran/f95-lang.c:239 #4 0x0001006d6b5a in toplev_main (argc=2, argv=0x7fff5fbfd9f0) at ../../p_work/gcc/toplev.c:1053 #5 0x000119e4 in start () Not a regression, I get the Bus error for 4.2.4, 4.3.4, 4.4.2, and trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43592
[Bug target/43580] [4.5 Regression] ICE segfault compiling libgcc2.c
--- Comment #10 from ramana at gcc dot gnu dot org 2010-03-30 20:09 --- This would be arm-elf only because arm-eabi configurations don't touch the FPA which is why this didn't show up earlier. My last trawl of this looked for PRE_DEC and BLKmode - didn't expect an XFmode for this. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|arm-rtems4.10 |arm-rtems4.10, arm-elf Last reconfirmed|-00-00 00:00:00 |2010-03-30 20:09:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43580
[Bug debug/43593] Var-tracking unnecessarily flushes all call used registers on calls instead of regs invalidated by call
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-30 20:17 --- Subject: Bug 43593 Author: jakub Date: Tue Mar 30 20:16:52 2010 New Revision: 157834 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157834 Log: PR debug/43593 * var-tracking.c (dataflow_set_clear_at_call): Invalidate just regs_invalidated_by_call instead all call_used_reg_set registers. * gcc.dg/guality/pr43593.c: New test. Added: trunk/gcc/testsuite/gcc.dg/guality/pr43593.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43593
[Bug debug/43593] Var-tracking unnecessarily flushes all call used registers on calls instead of regs invalidated by call
--- Comment #2 from jakub at gcc dot gnu dot org 2010-03-30 20:18 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43593
[Bug lto/43581] exception handling broken across shared libaries with -fuse-linker-plugin
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-30 20:29 --- So this cannot be a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |UNCONFIRMED Component|other |lto Summary|[4.5 Regression] exception |exception handling broken |handling broken across |across shared libaries with |shared libaries with -fuse- |-fuse-linker-plugin |linker-plugin | Target Milestone|4.5.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43581
[Bug debug/42977] [4.5 Regression] -fcompare-debug failure with -O2 -finline-functions -fomit-frame-pointer -ftracer -fsched2-use-superblocks -fPIC
--- Comment #10 from jakub at gcc dot gnu dot org 2010-03-30 21:01 --- Subject: Bug 42977 Author: jakub Date: Tue Mar 30 21:00:47 2010 New Revision: 157837 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157837 Log: PR debug/42977 * cselib.c (n_useless_values): Document handling of debug locs. (n_useless_debug_values, n_debug_values): New variables. (new_elt_loc_list): Don't add to debug values, keep count. (promote_debug_loc): New. (cselib_reset_table): Zero new variables. (entry_and_rtx_equal_p): Promote debug locs. (discard_useless_locs): Increment n_useless_debug_values for debug values. (remove_useless_values): Adjust n_useless_values and n_debug_values with n_useless_debug_values. (add_mem_for_addr): Promote debug locs. (cselib_lookup_mem): Likewise. (cselib_lookup_addr): Renamed to... (cselib_lookup_addr_1): ... this. Promote debug locs. Don't call... (cselib_log_lookup): ... this. Turn into... (cselib_lookup_addr): ... new wrapper. (cselib_lookup_from_insn): New. (cselib_invalidate_regno): Increment n_useless_debug_values for debug values. (cselib_invalidate_mem): Likewise. (cselib_process_insn): Take n_deleted and n_debug_values into account to guard remove_useless_value call. (cselib_finish): Zero n_useless_debug_values. * cselib.h (cselib_lookup_from_insn): Declare. * sched-deps.c (sched_analyze_1): Use cselib_lookup_from_insn. (sched_analyze_2): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/cselib.c trunk/gcc/cselib.h trunk/gcc/sched-deps.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42977
[Bug debug/42977] [4.5 Regression] -fcompare-debug failure with -O2 -finline-functions -fomit-frame-pointer -ftracer -fsched2-use-superblocks -fPIC
--- Comment #11 from jakub at gcc dot gnu dot org 2010-03-30 21:01 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42977
[Bug c++/41786] [4.4/4.5 regression] misparsing an object declaration - parameter may not have variably modified type
--- Comment #4 from jason at gcc dot gnu dot org 2010-03-30 21:19 --- Subject: Bug 41786 Author: jason Date: Tue Mar 30 21:19:23 2010 New Revision: 157838 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157838 Log: PR c++/41185 PR c++/41786 * parser.c (cp_parser_direct_declarator): Don't allow VLAs in function parameter context. Don't print an error if parsing tentatively. Added: trunk/gcc/testsuite/g++.dg/parse/ambig5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/varmod1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41786
[Bug c++/41185] [4.4/4.5 regression] size of array ... has non-integral type ...
--- Comment #9 from jason at gcc dot gnu dot org 2010-03-30 21:19 --- Subject: Bug 41185 Author: jason Date: Tue Mar 30 21:19:23 2010 New Revision: 157838 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157838 Log: PR c++/41185 PR c++/41786 * parser.c (cp_parser_direct_declarator): Don't allow VLAs in function parameter context. Don't print an error if parsing tentatively. Added: trunk/gcc/testsuite/g++.dg/parse/ambig5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/varmod1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41185
[Bug c++/41786] [4.4/4.5 regression] misparsing an object declaration - parameter may not have variably modified type
--- Comment #5 from jason at gcc dot gnu dot org 2010-03-30 21:21 --- Subject: Bug 41786 Author: jason Date: Tue Mar 30 21:20:58 2010 New Revision: 157839 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157839 Log: PR c++/41185 PR c++/41786 * parser.c (cp_parser_direct_declarator): Don't allow VLAs in function parameter context. Don't print an error if parsing tentatively. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/parse/ambig5.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/parser.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/g++.dg/parse/varmod1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41786
[Bug c++/41185] [4.4/4.5 regression] size of array ... has non-integral type ...
--- Comment #10 from jason at gcc dot gnu dot org 2010-03-30 21:21 --- Subject: Bug 41185 Author: jason Date: Tue Mar 30 21:20:58 2010 New Revision: 157839 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157839 Log: PR c++/41185 PR c++/41786 * parser.c (cp_parser_direct_declarator): Don't allow VLAs in function parameter context. Don't print an error if parsing tentatively. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/parse/ambig5.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/parser.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/g++.dg/parse/varmod1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41185
[Bug c++/41786] [4.4/4.5 regression] misparsing an object declaration - parameter may not have variably modified type
--- Comment #6 from jason at gcc dot gnu dot org 2010-03-30 21:22 --- Fixed for 4.4.4 and 4.5.0. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41786
[Bug c++/41185] [4.4/4.5 regression] size of array ... has non-integral type ...
--- Comment #11 from jason at gcc dot gnu dot org 2010-03-30 21:23 --- Fixed for 4.4.4 and 4.5.0. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41185
[Bug c++/43076] [4.3/4.4/4.5 Regression] ICE: SIGSEGV with invalid C++ code after giving diagnostics
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-02-16 23:13:21 |2010-03-30 21:47:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43076
[Bug c++/42938] ICE with 4.4.2 on MIPS
--- Comment #6 from manuel dot montezelo at gmail dot com 2010-03-30 22:30 --- For the record, the last build worked fine (same upstream package, same gcc version): https://buildd.debian.org/fetch.cgi?pkg=openscenegraph;ver=2.8.2-2;arch=mips;stamp=1265665688 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42938
[Bug c++/43076] [4.3/4.4/4.5 Regression] ICE: SIGSEGV with invalid C++ code after giving diagnostics
--- Comment #3 from jason at gcc dot gnu dot org 2010-03-30 22:34 --- Subject: Bug 43076 Author: jason Date: Tue Mar 30 22:34:02 2010 New Revision: 157842 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157842 Log: PR c++/43076 * pt.c (push_template_decl_real): Deal better with running out of scopes before running out of template parms. Added: trunk/gcc/testsuite/g++.dg/template/error-recovery1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43076
[Bug target/43580] [4.5 Regression] ICE segfault compiling libgcc2.c
--- Comment #11 from joel at gcc dot gnu dot org 2010-03-30 23:05 --- Patch worked for me targeting arm-rtems4.10 on the same gcc checkout. Please apply it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43580
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6
--- Comment #25 from dberlin at gcc dot gnu dot org 2010-03-30 23:18 --- Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6 Note: I have no urge or time to upgrade gcc's bugzilla anymore. If ya'll want to work on it, i'm happy to give you all the info i have and get you shell access to gcc.gnu.org + the current bugzilla code + it's mysql so you can do it. On Tue, Mar 30, 2010 at 5:54 AM, LpSolit at netscape dot net gcc-bugzi...@gcc.gnu.org wrote: --- Comment #24 from LpSolit at netscape dot net 2010-03-30 09:54 --- We are very close from releasing Bugzilla 3.6: https://bugzilla.mozilla.org/show_bug.cgi?id=554523 The plan is to release it next week. So you may as well upgrade to 3.6 directly. Note that I'm on vacation this week and next week. If you need help for the upgrade, now is a good time! :) -- LpSolit at netscape dot net changed: What |Removed |Added Summary|Upgrade gcc.gnu.org/bugzilla|Upgrade gcc.gnu.org/bugzilla |to Bugzilla 3.4.5 |to Bugzilla 3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug rtl-optimization/43520] gcc.dg/pr43058.c uses way too memory on ia64
--- Comment #4 from wilson at gcc dot gnu dot org 2010-03-30 23:58 --- I've confirmed that Vlad's -fsched-pressure patch is the problem, and done a bit more analysis to see why. The testcase has approximately 20,000 movdi_internal insns, 6000 movsi_internal insns, and 10,000 call_value_gp insns. The ia64 movdi_internal patterns has constraints 'd' for memory pipeline application registers and 'e' for integer pipeline application registers. The 'd' class has 2 regs, both fixed. The 'e' class has 3 regs, two fixed. Since the two classes have only 0 and 1 allocatable register each, the -fsched-pressure patch puts them in implicit_reg_pending_clobbers. The movsi_internal pattern also uses 'd', so it is handled similarly. So we end up with all 26,000 move insns on the reg_last-implicit_sets list. Meanwhile, because we have 4 fixed registers, every call insn is assumes to use these registers. Thus we end up with all 10,000 call insns on reg_last-uses. Since we create a dependency between implicit_sets and uses, that means we end up with approx 260M dependencies, each 40 bytes each, which is 10GB. Plus memory for insns lists and other stuff. The convention is that there is only supposed to be one mov* pattern, since reload does not re-recognize, so it doesn't appear to me that the ia64.md file is doing anything wrong. We could reduce the problem if the fixed registers were split out into separate move insns though. We still have the one not-fixed register (ar.lc), but it isn't call clobbered either, so I think that one might be OK. I haven't tested that theory yet. We would need to split the 'e' class to separate the fixed and non-fixed registers. Another option here would be to have a special letter like '*' and '#' except that it can be used to disable the register-pressure code. We still need to split the 'e' class for this, since we still want the register-pressure code for the non-fixed register (ar.lc). This would require fewer changes to the ia64 port than the above option. Another option here is to throttle the reg_last-use and/or reg_last-implicit_sets lists somehow. We could just keep a count of them and arbitrarily flush them when they get too big. There is already code to do this that uses uses_length and clobbers_length. Adding a implicit_sets_length might help. There is code to free a list when we see a set, but the testcase does not have sets for 4 of the 5 registers, so the lists do not get freed this way. The current code that tests uses_length and clobber_length only triggers if there is a clobber, and again there are no clobbers of any of the 5 registers here. The lists will only get freed if we flush them some how in the implicit_sets handling code. Or maybe we could try to keep trace of reads and writes better. If we have a series of implicit sets followed by a series of uses followed by some more implicit sets, then we can actually flush the implicit_set list when we see the second set of implicit sets. This is because every use will depend on every implicit set in the first group, and every implicit set in the second group will depend on every use, so there is no need to retain the insns in the first group in the implicit set list. Similarly, we can free insns from the use group when we see a second set of uses. Another option here is to make -fno-sched-pressure disable the code that sets implicit_reg_pending_clobbers, though this isn't a fix, just a workaround. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||vmakarov at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-30 23:58:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43520
[Bug c++/43594] New: long-standing g++ bug?
//#include cstdio
struct values
{
static const int one = 1;
};
struct counter
{
int n;
counter() : n(0) {}
counter
operator,(int const) { n++; return *this; }
};
int
main()
{
values vals;
counter cntr;
cntr, vals.one;
//std::printf(%d\n, cntr.n);
return 0;
}
g++ problem.cpp
/tmp/cc88FSiA.o: In function `main':
problem.cpp:(.text+0x19): undefined reference to `values::one'
collect2: ld returned 1 exit status
I'm getting the same failure with gcc 3.2, 4.1, 4.4, 4.5.0 20100109.
It works as expected with Visual C++ 9.0.
Is this a bug?
--
Summary: long-standing g++ bug?
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rwgk at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43594
[Bug c++/43594] long-standing g++ bug?
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-31 00:14 --- Not a bug, see PR 42101. *** This bug has been marked as a duplicate of 42101 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43594
[Bug c++/42101] Linking failure with static constants and ternary inline function
--- Comment #12 from pinskia at gcc dot gnu dot org 2010-03-31 00:14 --- *** Bug 43594 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rwgk at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42101
[Bug middle-end/43574] [4.5 Regression] Revision 157795 failed gcc.dg/lto/20090914-1 c_lto_20090914-1_0.o
--- Comment #4 from jiez at gcc dot gnu dot org 2010-03-31 01:46 --- A new patch: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01440.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43574
