[Bug fortran/51632] [OOP] Bogus argument checking for generated _def_init parameter and _copy procedure with CAF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51632
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Known to fail||4.6.3, 4.7.0
--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-12-20
08:03:11 UTC ---
Patch for the _def_init issue:
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -11492,6 +11492,7 @@ resolve_fl_derived0 (gfc_symbol *sym)
/* F2008, C444. */
if (c-ts.type == BT_DERIVED c-ts.u.derived-attr.coarray_comp
+ !sym-attr.vtype
(c-attr.codimension || c-attr.pointer || c-attr.dimension
|| c-attr.allocatable))
{
[Bug c++/51633] New: [c++0x] [4.6/4.7 Regression] ICE with invalid constexpr constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51633
Bug #: 51633
Summary: [c++0x] [4.6/4.7 Regression] ICE with invalid
constexpr constructor
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org
The following invalid code snippet triggers an ICE since GCC 4.6.0:
==
struct A
{
~A();
};
struct B
{
A a;
constexpr B() {}
};
==
bug.cc: In constructor 'constexpr B::B()':
bug.cc:9:18: internal compiler error: in
build_constexpr_constructor_member_initializers, at cp/semantics.c:5908
Please submit a full bug report, [etc.]
A slightly different code snippet triggers an ICE in a different place:
==
struct A
{
constexpr A() {}
~A();
};
struct B
{
A a;
constexpr B() { return; }
};
==
bug.cc: In constructor 'constexpr B::B()':
bug.cc:10:27: internal compiler error: in build_data_member_initialization, at
cp/semantics.c:5782
Please submit a full bug report, [etc.]
This looks related to PR51612 where the ICE happens in the same place.
[Bug c++/51633] [c++0x] [4.6/4.7 Regression] ICE with invalid constexpr constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51633 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Target Milestone|--- |4.6.3
[Bug fortran/51634] New: [OOP] ICE with polymorphic operators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51634 Bug #: 51634 Summary: [OOP] ICE with polymorphic operators Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Depends on: 46328, 51334 Related to PR 51334 and PR 46328, though the error message is slightly different. foo.f90:37:0: internal compiler error: tree check: expected function_type or method_type, have pointer_type in gimplify_call_expr, at gimplify.c:2430 module field_module implicit none private public :: field type :: field real, allocatable :: f(:) contains procedure :: multiply_real = multiply procedure :: copy = copy_field generic :: operator(*)= multiply_real generic :: assignment(=) = copy end type contains subroutine copy_field (lhs, rhs) class(field), intent(inout) :: lhs class(field), intent(in) :: rhs lhs%f = rhs%f end subroutine function multiply(lhs,rhs) class(field) ,intent(in) :: lhs real ,intent(in) :: rhs class(field) ,allocatable :: multiply allocate(multiply) multiply%f = lhs%f * rhs end function end module field_module program main use field_module implicit none type(field) :: f, g real :: dt, half dt = 7 half = 0.5 f = g * dt * half end program main
[Bug c++/51630] failure to detect missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51630 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-20 08:57:19 UTC --- the code fails for me using any of GCC 4.4, 4.5, 4.6 of 4.7 are you sure that's the actual code you're compiling?
[Bug c++/51630] failure to detect missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51630 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-20 08:59:11 UTC --- Ah, it's because you're using -fsyntax-only, so it doesn't instantiate templates. Don't do that.
[Bug libstdc++/51365] cannot use final empty class in std::tuple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365 --- Comment #14 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-20 09:09:56 UTC --- Author: redi Date: Tue Dec 20 09:09:50 2011 New Revision: 182523 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182523 Log: PR libstdc++/51365 * include/std/tuple (_Tuple_impl): Check __is_final as well as is_empty. * testsuite/20_util/tuple/51365.cc: New. Added: trunk/libstdc++-v3/testsuite/20_util/tuple/51365.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/tuple
[Bug target/43437] ICE in CSE, during libgcc build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437 --- Comment #17 from Mikael Pettersson mikpe at it dot uu.se 2011-12-20 09:14:03 UTC --- Created attachment 26150 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26150 reduced second test case Reduced test case, very sensitive to control flow and other details.
[Bug debug/46796] debug info missing builtin type names with lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46796 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-20 09:49:22 UTC --- Author: rguenth Date: Tue Dec 20 09:49:17 2011 New Revision: 182524 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182524 Log: 2011-12-20 Richard Guenther rguent...@suse.de PR lto/46796 * dwarf2out.c (modified_type_die): When the type variant chain is corrupt use the types name, if available, instead of __unknown__. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug debug/46796] debug info missing builtin type names with lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46796 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 Known to fail||4.6.2 --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-20 09:49:53 UTC --- Fixed on trunk.
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-20 CC||ebotcazou at gcc dot ||gnu.org, rguenth at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-20 10:20:19 UTC --- The point is that even if you use sth like typedef int myint __attribute__((aligned(1))); to capture the misaligned pointer to the packed structure element: myint *p = s-i; then accesses like '*p' will still assume an _aligned_ int at 'p' for STRICT_ALIGNMENT targets. That's a long-long-long-standing bug and a cause of major headache for more modern GCCs even ... The testcase with using a 'int *' pointer is indeed invalid though.
[Bug ada/51624] [4.6/4.7 regression] Assert_Failure atree.adb:808 on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51624 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.3
[Bug c++/51630] failure to detect missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51630 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-20 10:24:49 UTC --- Agreed.
[Bug c++/51633] [c++0x] [4.6/4.7 Regression] ICE with invalid constexpr constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51633 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-20 10:30:39 UTC --- By the way, calling these issues Regression doesn't seem appropriate: granted, 4.5 may have parsed some constrexpr usages, but didn't have any semantics implemented, could very hardly fail.
[Bug c++/51612] [c++0x] [4.6/4.7 Regression] ICE with constexpr constructor and virtual base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51612 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-12-20 10:38:48 UTC --- Author: paolo Date: Tue Dec 20 10:38:44 2011 New Revision: 182526 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182526 Log: /cp 2011-12-20 Paolo Carlini paolo.carl...@oracle.com PR c++/51612 * semantics.c (is_valid_constexpr_fn): In case of constexpr constructors also check for virtual base classes. /testsuite 2011-12-20 Paolo Carlini paolo.carl...@oracle.com PR c++/51612 * g++.dg/cpp0x/constexpr-ice4.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ice4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/51612] [c++0x] [4.6/4.7 Regression] ICE with constexpr constructor and virtual base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51612 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-20 10:40:43 UTC --- Fixed for 4.7.0.
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-12-20 10:52:19 UTC --- The point is that even if you use sth like typedef int myint __attribute__((aligned(1))); to capture the misaligned pointer to the packed structure element: myint *p = s-i; then accesses like '*p' will still assume an _aligned_ int at 'p' for STRICT_ALIGNMENT targets. That's a long-long-long-standing bug and a cause of major headache for more modern GCCs even ... That's a limitation rather than a bug. Clearly, on strict-alignment targets, you must know what you're doing when you start to misalign things. As for typedef int myint __attribute__((aligned(1))); that's an abomination I don't even want to know of ;-)
[Bug c++/50518] [C++0x] repeated c++11 opaque enum declarations are invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50518 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-20 10:54:06 UTC --- Any news on this?
[Bug c++/50592] g++ fails to see function side effect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50592 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-12-20 Ever Confirmed|0 |1
[Bug lto/41159] [LTO] ICE in insert_value_copy_on_edge, at tree-outof-ssa.c:225
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41159 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #19 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-20 10:58:47 UTC --- Mine. The issue is that we are on a PROMOTE_MODE target and with !optimize expand SSA names to stack slots: var = SSA_NAME_VAR (partition_to_var (SA.map, dest)); src_mode = TYPE_MODE (TREE_TYPE (src)); dest_mode = promote_decl_mode (var, unsignedp); gcc_assert (src_mode == TYPE_MODE (TREE_TYPE (var))); gcc_assert (dest_mode == GET_MODE (SA.partition_to_pseudo[dest])); (gdb) call debug_tree (var) var_decl 0x75a2b320 i type integer_type 0x75a2e5e8 int public SI ... (gdb) p SA.partition_to_pseudo[dest] $2 = (rtx) 0x75ad4c78 (gdb) call debug_rtx ($2) (mem/c/i:SI (plus:DI (reg/f:DI 65 virtual-stack-vars) (const_int 4 [0x4])) [0 i+0 S4 A32]) (gdb) p dest_mode $1 = DImode but we cannot deal with stack temporaries. I have a patch.
[Bug lto/41159] [LTO] ICE in insert_value_copy_on_edge, at tree-outof-ssa.c:225
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41159 --- Comment #20 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-20 11:01:37 UTC --- Created attachment 26151 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26151 patch I'm testing this patch on x86_64-linux, but it won't make any difference there. So can you guys test on arm/alpha please and report back? Thx.
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 --- Comment #6 from rguenther at suse dot de rguenther at suse dot de 2011-12-20 11:04:37 UTC --- On Tue, 20 Dec 2011, ebotcazou at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-12-20 10:52:19 UTC --- The point is that even if you use sth like typedef int myint __attribute__((aligned(1))); to capture the misaligned pointer to the packed structure element: myint *p = s-i; then accesses like '*p' will still assume an _aligned_ int at 'p' for STRICT_ALIGNMENT targets. That's a long-long-long-standing bug and a cause of major headache for more modern GCCs even ... That's a limitation rather than a bug. Clearly, on strict-alignment targets, you must know what you're doing when you start to misalign things. As for typedef int myint __attribute__((aligned(1))); that's an abomination I don't even want to know of ;-) Huh, it's not. It's the same as a packed struct or enum type. Why can't you strict-align people simply fix this case? Richard.
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-12-20 11:18:24 UTC --- Huh, it's not. It's the same as a packed struct or enum type. No, it isn't, the mode is integral instead of BLKmode. In Ada we do support misaligned integers, but we simply wrap them in a BLKmode record. Why can't you strict-align people simply fix this case? Because integral modes are naturally aligned. The only reasonable way to support the aforementioned abomination is to use the Ada approach.
[Bug c++/51621] [c++0x] [4.6/4.7 Regression] ICE with invalid constexpr and array class member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51621 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-12-20 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-20 11:19:27 UTC --- On it.
[Bug tree-optimization/51583] One more missing force_gimple_operand in SRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51583 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org 2011-12-20 11:20:52 UTC --- Fixed.
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 --- Comment #8 from rguenther at suse dot de rguenther at suse dot de 2011-12-20 11:23:48 UTC --- On Tue, 20 Dec 2011, ebotcazou at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-12-20 11:18:24 UTC --- Huh, it's not. It's the same as a packed struct or enum type. No, it isn't, the mode is integral instead of BLKmode. In Ada we do support misaligned integers, but we simply wrap them in a BLKmode record. Why can't you strict-align people simply fix this case? Because integral modes are naturally aligned. The only reasonable way to support the aforementioned abomination is to use the Ada approach. You mean that handling the TYPE_ALIGN != MODE_ALIGN case when expanding a MEM_REF (thus, INDIRECT_REF on old branches) won't work? Why not? You'd simply have to emit the same RTL as when expanding that wrapped struct case. Richard.
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-12-20 11:34:00 UTC --- You mean that handling the TYPE_ALIGN != MODE_ALIGN case when expanding a MEM_REF (thus, INDIRECT_REF on old branches) won't work? But you cannot have TYPE_ALIGN MODE_ALIGN (TYPE_MODE).
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 --- Comment #10 from rguenther at suse dot de rguenther at suse dot de 2011-12-20 11:56:22 UTC --- On Tue, 20 Dec 2011, ebotcazou at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-12-20 11:34:00 UTC --- You mean that handling the TYPE_ALIGN != MODE_ALIGN case when expanding a MEM_REF (thus, INDIRECT_REF on old branches) won't work? But you cannot have TYPE_ALIGN MODE_ALIGN (TYPE_MODE). You can. Just check what you get with that aligned(1) int typedef. For vector types you can anyways (by design) to allow unaligned vector moves. Is it documented anywhere that you can't take the address of an unaligned structure member (given the struct is packed) on STRICT_ALIGNMENT targets (or, when it's a vector component even on non-STRICT_ALIGNMENT targets)? Why does the C frontend not warn for these cases (unconditionally?)? I don't see at all that we can't support expanding such moves properly. After all we can extract an INT mode value from unaligned memory (we are never generating a mem:BLK with INT mode size in that case anyway, or a MEM:SI with MEM_ALIGN less than SImode align anyway)
[Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635 Bug #: 51635 Summary: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@trippelsdorf.de Created attachment 26152 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26152 testcase patch Firefox's libxul fails to build with -flto and -g: lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22494 I've delta reduced the failure to two files and then reduced the files individually. Here's what I have thus far: % patch -p0 patch patching file Makefile patching file test2.ii patching file test.ii % make gcc -r -nostdlib test2.ii test.ii -w -std=gnu++0x -pipe -g -Os -flto lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22494 Please submit a full bug report Will keep trying to reduce the files further.
[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-20 CC||rguenth at gcc dot gnu.org Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-20 12:06:10 UTC --- Confirmed.
[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-20 12:13:27 UTC --- (gdb) call debug_tree (context) record_type 0x758bd7e0 nsSVGEffects asm_written QI ... (gdb) call debug_tree (context-type_common.name) type_decl 0x758ad958 nsSVGEffects type record_type 0x758bd7e0 nsSVGEffects asm_written QI ... public VOID file /tmp/test2.ii line 3256 col 17 align 8 context translation_unit_decl 0x75a42f18 D.2349 (gdb) call lookup_type_die (context) $1 = (struct die_struct *) 0x758fdd70 (gdb) call debug_tree (node-created_for) type_decl 0x758dc2e0 FramePropertyDescriptor type record_type 0x758bd9d8 FramePropertyDescriptor BLK ... asm_written used nonlocal VOID file /tmp/test.ii line 2611 col 51 align 1 context record_type 0x758bd7e0 nsSVGEffects so it's DECL_CONTEXT is a type from a different TU. And indeed in the types TYPE_FIELDS we have type_decl 0x758ada10 nsSVGEffects type record_type 0x758bd7e0 nsSVGEffects asm_written QI which is another instance of the TYPE_DECL. That asks for proper merging of those TYPE_DECLs :(
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 --- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-12-20 12:25:13 UTC --- You can. Just check what you get with that aligned(1) int typedef. Well, we're going in circles as this example precisely doesn't work. Is it documented anywhere that you can't take the address of an unaligned structure member (given the struct is packed) on STRICT_ALIGNMENT targets (or, when it's a vector component even on non-STRICT_ALIGNMENT targets)? Why does the C frontend not warn for these cases (unconditionally?)? Good question, but for a C maintainer. The C front-end would have implemented something for a long time if it had cared about the issue, but apparently not. In Ada we do care since Ada 2005, so we have implemented the necessary support.
[Bug lto/41159] [LTO] ICE in insert_value_copy_on_edge, at tree-outof-ssa.c:225
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41159 --- Comment #21 from Ryan Mansfield rmansfield at qnx dot com 2011-12-20 12:27:29 UTC --- (In reply to comment #20) I'm testing this patch on x86_64-linux, but it won't make any difference there. So can you guys test on arm/alpha please and report back? Thx. For arm eabi, using rev182526 the ICE still happens on my original testcase but after applying your patch the ICE no longer happens. Thanks!
[Bug libstdc++/51636] New: Thread-safeness of new and delete operators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51636 Bug #: 51636 Summary: Thread-safeness of new and delete operators Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: i...@pyrillion.org Dear colleagues, I had a nasty thread-safeness bug that I finally did not track down completely (but solved). My system: Linux ubuntu 3.0.0-14-generic #23-Ubuntu SMP Mon Nov 21 20:28:43 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux My gcc: gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 libstdc++: libstdc++.so.6.0.16 Problem: application crashes if too many concurrent POSIX threads get started Description: application is platform-independent; was developed for Win32/Win64 and Linux 32bit/64bit If executed with valgrind/hellgrind (Linux) or Microsoft Application Verifier (Windows 7/64bit), then no errors occur. If executed on above mentioned host AND more than 100 concurrent threads performing a lot of new/delete operations, then memory clobbered. Application was tested using valgrind or GNU mprobe, respectively. GNU mprobe aborts application with memory clobbered before memory block. All sources compiled with -pthread, -fpic. Error occurs with Debug and Release build. POSIX threads are performing a mix of new/delete/malloc/free and use thread-specific data. My fix: Wrote another shared object implementing malloc/calloc/free/realloc, new/delete/new[]/delete[] with and without throw(std::bad_alloc). Linking this shared object to my application fixes the problem. Guess: the new/new[] operators throwing std::bad_alloc have a MT-safeness problem. Sorry for this obfuscating bug report but I am not allowed to disclose more information. Maybe someone ran into this bug?, too?
[Bug libstdc++/51636] Thread-safeness of new and delete operators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51636 Ingo K. ingo at pyrillion dot org changed: What|Removed |Added Severity|normal |minor
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-20 12:35:18 UTC --- What Ada does looks just like a workaround for what should be done properly in the expander. So no, IMHO we shouldn't be changing all other FEs and the middle-end (when it wants to generate them e.g. for memcpy) to do what Ada does, but we should change the expander. It has all the information to perform the unaligned reads/writes, it just doesn't use them.
[Bug tree-optimization/48189] [4.4/4.5/4.6/4.7 Regression] ICE: SIGFPE (division by zero) in in predict_loops () at predict.c:991 with --param max-predicted-iterations=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48189 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-20 13:10:15 UTC --- Already the: if (host_integerp (niter, 1) compare_tree_int (niter, max-1) == -1) nitercst = tree_low_cst (niter, 1) + 1; looks wrong, if max is 0, then we are calling compare_tree_int with UHWI maximum and even huge nitercst values will make through. IMHO we should just guard the above with max != 0 as well. I think max_stmt_executions_int will never return 0, so both patches probably work fine. Honza?
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 --- Comment #13 from rguenther at suse dot de rguenther at suse dot de 2011-12-20 13:21:02 UTC --- On Tue, 20 Dec 2011, ebotcazou at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 --- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-12-20 12:25:13 UTC --- You can. Just check what you get with that aligned(1) int typedef. Well, we're going in circles as this example precisely doesn't work. Is it documented anywhere that you can't take the address of an unaligned structure member (given the struct is packed) on STRICT_ALIGNMENT targets (or, when it's a vector component even on non-STRICT_ALIGNMENT targets)? Why does the C frontend not warn for these cases (unconditionally?)? Good question, but for a C maintainer. The C front-end would have implemented something for a long time if it had cared about the issue, but apparently not. In Ada we do care since Ada 2005, so we have implemented the necessary support. Fact is, the middle-end needs a way to support this (well, or wants). Otherwise stripping off component-refs does not work even for the long time working cases. Fixes to avoid stripping them away are not really fixes but workarounds around fixing this long-time issue. But I see you are not going to work on fixing the expansion side (which I hoped, since you have plenty of experience in this area and strict-alignment targets)
[Bug c++/50518] [C++0x] repeated c++11 opaque enum declarations are invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50518 --- Comment #2 from fabien at gcc dot gnu.org 2011-12-20 13:29:26 UTC --- (In reply to comment #1) Any news on this? No, sorry, I'll try to work on it before the end of stage 3.
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 --- Comment #11 from Dodji Seketeli dodji at gcc dot gnu.org 2011-12-20 13:36:08 UTC --- Author: dodji Date: Tue Dec 20 13:36:04 2011 New Revision: 182532 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182532 Log: PR debug/49951 - jumpy stepping at end of scope in C++ gcc/cp/ PR debug/49951 * decl.c (cxx_maybe_build_cleanup): Don't set location of the call to the destructor. gcc/testsuite/ PR debug/49951 * g++.dg/gcov/gcov-2.C: Adjust. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/gcov/gcov-2.C
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from Dodji Seketeli dodji at gcc dot gnu.org 2011-12-20 13:40:30 UTC --- This should be fixed in trunk (4.7).
[Bug fortran/51637] New: Add compile-time error if array is too large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51637 Bug #: 51637 Summary: Add compile-time error if array is too large Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org The following program compiles and produces the dump on x86-64-linux: struct t a[-1]; a[-9223372036854775808] = t.0; and with -m32 struct t a[-1]; a[0] = t.0; Expected: An error is printed such as ftn-951 crayftn: ERROR MAIN, File = rc1.f90, Line = 4, Column = 79 The extent for dimension 1 is too large for array A. TYPE T END TYPE T TYPE(T), DIMENSION(-9223372036854775807_8: 9223372036854775807_8) :: A a(1) = t() end Motivated by the discussion starting at http://j3-fortran.org/pipermail/interop-tr/2011-December/000942.html / Example taken from http://j3-fortran.org/pipermail/interop-tr/2011-December/000964.html
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-20 13:49:28 UTC --- Thanks! It would be very helpful to get this into 4.6.3 too if it's safe
[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-20 14:16:35 UTC --- It's actually easy to do. We just have to make sure that the TYPE_DECLs we refer to are those of their type. Thus, Index: gcc/lto/lto.c === --- gcc/lto/lto.c (revision 182525) +++ gcc/lto/lto.c (working copy) @@ -867,7 +867,11 @@ uniquify_nodes (struct data_in *data_in, if (t == NULL_TREE) continue; - if (TREE_CODE (t) == VAR_DECL) + if (TYPE_P (t) + TYPE_NAME (t) + TREE_CODE (TYPE_NAME (t)) == TYPE_DECL) + TYPE_NAME (t) = TYPE_NAME (TREE_TYPE (TYPE_NAME (t))); + else if (TREE_CODE (t) == VAR_DECL) lto_register_var_decl_in_symtab (data_in, t); else if (TREE_CODE (t) == FUNCTION_DECL !DECL_BUILT_IN (t)) lto_register_function_decl_in_symtab (data_in, t);
[Bug bootstrap/51388] Configure failure to detect unsupported warning options for non-bootstrap builds (including cross builds)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388 Andreas Tobler andreast at gcc dot gnu.org changed: What|Removed |Added CC||andreast at gcc dot gnu.org --- Comment #10 from Andreas Tobler andreast at gcc dot gnu.org 2011-12-20 14:42:03 UTC --- -Wno-*) option=-W`expr $real_option : '-Wno-\(.*\)'` ;; The expr on FreeBSD treats leading minus (-) in an expression as an option. Therefor this does not work there. I'm trying to find a solution. One would be to remove the leading minus.
[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-20
14:47:25 UTC ---
Doesn't work. Instead testing a similar
Index: gcc/lto/lto.c
===
--- gcc/lto/lto.c (revision 182525)
+++ gcc/lto/lto.c (working copy)
@@ -845,6 +845,14 @@ uniquify_nodes (struct data_in *data_in,
if (ix i)
lto_fixup_types (f2);
streamer_tree_cache_insert_at (cache, f1, ix);
+ /* Make sure that the type of a TYPE_DECL refers
+ to the type decl that prevails in the prevailing
+ record or union type. */
+ if (TREE_CODE (f1) == TYPE_DECL)
+ {
+ tree f1t = gimple_register_type (TREE_TYPE (f1));
+ TYPE_NAME (f1t) = f1;
+ }
}
}
[Bug target/43437] ICE in CSE, during libgcc build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437 --- Comment #18 from Mikael Pettersson mikpe at it dot uu.se 2011-12-20 15:14:41 UTC --- The second test case started failing with r170199: http://gcc.gnu.org/ml/gcc-cvs/2011-02/msg00744.html This is the reversal of the same change that was later reapplied as r17, i.e. when the second test case stopped failing on trunk. I have to re-bisect further back in time.
[Bug fortran/51638] New: gfortran optimization breaks a single variable used as both input and output for subroutine call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51638 Bug #: 51638 Summary: gfortran optimization breaks a single variable used as both input and output for subroutine call Classification: Unclassified Product: gcc Version: fortran-dev Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bard...@iram.fr Created attachment 26153 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26153 Program fails with -O flag under 32 bits systems Hello, the attached program provides 2 subroutines which do not run correctly if the program is compiled with the optimization option (-O). Since the program behaves correctly without this option, this sounds like a bug (at least it severely annoys us). The subroutines are inherited from our Fortran 77 legacy code, which behaved well with the other compilers (ifc/ifort, g95, ...) for at least one decade. * About the test program: it should be self-explanatory. The idea it to swap the bytes in 4 and 8 bytes integers, but I am not sure this is a major point. The key point is that the same variable is used as 2 different dummy variables (input and output) in the calling sequence. Here is the output when the program fails: ubuntu-32:~$ gfortran -O test.f90 -o test (some type mismatch warnings) ubuntu-32:~$ ./test Call to subroutine IEI4EI with single I/O variable failed: Input:2147483647 (int4) =-1 -1 -1 127 (4 int1) Output: 2147483519 (int4) = 127 -1 -1 127 (4 int1) Call to subroutine IEI8EI with single I/O variable failed: In: 9223372036854775807 (int8) =-1 -1 -1 -1 -1 -1 -1 127 (8 int1) Out: 9223372036854775679 (int8) = 127 -1 -1 -1 -1 -1 -1 127 (8 int1) You can see that the bytes of the output variable are not correctly swapped. * About the context: - Many (if not all) 32 bits linux (and MinGW) are affected, including the latest 32 bits Ubuntu (11.10). - No 64 bits linux I tested is affected. - All the gfortran versions seem affected, including latest 4.7.0 20111215 - The optimization seems mandatory to reproduce the bug, although I suspect I observed the bug without this option in the past. Thanks for your help. Unfortunately I won't be available for feedback during Xmas holidays.
[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #5 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-12-20 15:31:47 UTC ---
(In reply to comment #4)
Doesn't work. Instead testing a similar
Index: gcc/lto/lto.c
===
--- gcc/lto/lto.c (revision 182525)
+++ gcc/lto/lto.c (working copy)
@@ -845,6 +845,14 @@ uniquify_nodes (struct data_in *data_in,
if (ix i)
lto_fixup_types (f2);
streamer_tree_cache_insert_at (cache, f1, ix);
+ /* Make sure that the type of a TYPE_DECL refers
+ to the type decl that prevails in the prevailing
+ record or union type. */
+ if (TREE_CODE (f1) == TYPE_DECL)
+ {
+ tree f1t = gimple_register_type (TREE_TYPE (f1));
+ TYPE_NAME (f1t) = f1;
+ }
}
}
This one is extremely slow. lto1 has already used 12min of CPU time when
linking libxul and is still running... (3min is normal)
perf top shows:
27.92% lto1 [.] lto_read_decls
14.79% lto1 [.] htab_find_slot_with_hash
9.37% lto1 [.] gimple_type_eq
6.39% libc-2.14.90.so[.] _int_malloc
5.60% [kernel] [k] 0x81037d72
4.80% lto1 [.] gtc_visit
3.68% libc-2.14.90.so[.] memset
[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #6 from rguenther at suse dot de rguenther at suse dot de
2011-12-20 15:38:16 UTC ---
On Tue, 20 Dec 2011, markus at trippelsdorf dot de wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #5 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-12-20 15:31:47 UTC ---
(In reply to comment #4)
Doesn't work. Instead testing a similar
Index: gcc/lto/lto.c
===
--- gcc/lto/lto.c (revision 182525)
+++ gcc/lto/lto.c (working copy)
@@ -845,6 +845,14 @@ uniquify_nodes (struct data_in *data_in,
if (ix i)
lto_fixup_types (f2);
streamer_tree_cache_insert_at (cache, f1, ix);
+ /* Make sure that the type of a TYPE_DECL refers
+ to the type decl that prevails in the prevailing
+ record or union type. */
+ if (TREE_CODE (f1) == TYPE_DECL)
+ {
+ tree f1t = gimple_register_type (TREE_TYPE (f1));
+ TYPE_NAME (f1t) = f1;
+ }
}
}
This one is extremely slow. lto1 has already used 12min of CPU time when
linking libxul and is still running... (3min is normal)
perf top shows:
27.92% lto1 [.] lto_read_decls
14.79% lto1 [.] htab_find_slot_with_hash
9.37% lto1 [.] gimple_type_eq
6.39% libc-2.14.90.so[.] _int_malloc
5.60% [kernel] [k] 0x81037d72
4.80% lto1 [.] gtc_visit
3.68% libc-2.14.90.so[.] memset
That's odd - TREE_TYPE (f1) should already be registered - but I suppose
that adjusting TYPE_NAME might break all the caching we do with the
type-pair cache as TREE_TYPE (TYPE_NAME (f1)) is in the SCC of the
type we change that SCC by that adjustment - probably causing
the hit rate of the type-pair compare cache to become absymal?
Maybe you can check that theory (I have no other idea why the above
should be slow).
Richard.
[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #7 from rguenther at suse dot de rguenther at suse dot de
2011-12-20 15:40:01 UTC ---
On Tue, 20 Dec 2011, Richard Guenther wrote:
On Tue, 20 Dec 2011, markus at trippelsdorf dot de wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #5 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-12-20 15:31:47 UTC ---
(In reply to comment #4)
Doesn't work. Instead testing a similar
Index: gcc/lto/lto.c
===
--- gcc/lto/lto.c (revision 182525)
+++ gcc/lto/lto.c (working copy)
@@ -845,6 +845,14 @@ uniquify_nodes (struct data_in *data_in,
if (ix i)
lto_fixup_types (f2);
streamer_tree_cache_insert_at (cache, f1, ix);
+ /* Make sure that the type of a TYPE_DECL refers
+ to the type decl that prevails in the prevailing
+ record or union type. */
+ if (TREE_CODE (f1) == TYPE_DECL)
+ {
+ tree f1t = gimple_register_type (TREE_TYPE (f1));
+ TYPE_NAME (f1t) = f1;
+ }
}
}
This one is extremely slow. lto1 has already used 12min of CPU time when
linking libxul and is still running... (3min is normal)
perf top shows:
27.92% lto1 [.] lto_read_decls
14.79% lto1 [.] htab_find_slot_with_hash
9.37% lto1 [.] gimple_type_eq
6.39% libc-2.14.90.so[.] _int_malloc
5.60% [kernel] [k] 0x81037d72
4.80% lto1 [.] gtc_visit
3.68% libc-2.14.90.so[.] memset
That's odd - TREE_TYPE (f1) should already be registered - but I suppose
that adjusting TYPE_NAME might break all the caching we do with the
type-pair cache as TREE_TYPE (TYPE_NAME (f1)) is in the SCC of the
type we change that SCC by that adjustment - probably causing
the hit rate of the type-pair compare cache to become absymal?
Maybe you can check that theory (I have no other idea why the above
should be slow).
Though we should be hitting the gimple_type_leader cache only ...
maybe it's too small though?
[Bug bootstrap/51388] Configure failure to detect unsupported warning options for non-bootstrap builds (including cross builds)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388 --- Comment #11 from Andreas Schwab sch...@linux-m68k.org 2011-12-20 15:48:28 UTC --- Does this work? diff --git a/config/warnings.m4 b/config/warnings.m4 index 292e5a4..b64b594 100644 --- a/config/warnings.m4 +++ b/config/warnings.m4 @@ -32,7 +32,7 @@ for real_option in $1; do # Do the check with the no- prefix removed since gcc silently # accepts any -Wno-* option on purpose case $real_option in --Wno-*) option=-W`expr $real_option : '-Wno-\(.*\)'` ;; +-Wno-*) option=-W`expr x$real_option : 'x-Wno-\(.*\)'` ;; *) option=$real_option ;; esac AS_VAR_PUSHDEF([acx_Woption], [acx_cv_prog_cc_warning_$option])
[Bug bootstrap/51388] Configure failure to detect unsupported warning options for non-bootstrap builds (including cross builds)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388 --- Comment #12 from Andreas Tobler andreast at gcc dot gnu.org 2011-12-20 15:57:36 UTC --- Seems to work. At least in stage one, compiling gcc. Thank you!
[Bug fortran/51639] New: Nested type pointer null initialisation fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51639 Bug #: 51639 Summary: Nested type pointer null initialisation fails Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: jonathan.h...@stfc.ac.uk The following code appears to produce a regression in 4.6: program main implicit none type type1 integer, dimension(:), allocatable :: member end type type1 type type2 type(type1), pointer :: t1ptr=null() end type type2 call test contains subroutine test type(type2) :: t2 print *, associated(t2%t1ptr) = , associated(t2%t1ptr) end subroutine test end program Produces the output associated(t2%t1ptr) = T but should produce the output associated(t2%t1ptr) = F Further valgrind shows that access is to an uninitialised pointer. The code works as expected under 4.4.6 and 4.5.4. To provoke the error it seems that the associated() check must occur within a subroutine, and that type1 must have an allocatable component. Thanks, Jonathan.
[Bug fortran/51639] Nested type pointer null initialisation fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51639 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-12-20 16:27:46 UTC --- This seems to have been fixed on trunk between revisions 181881 (valgrind error) and 182076 (OK).
[Bug c++/51640] New: Misleading error if the type in the catch() is ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51640
Bug #: 51640
Summary: Misleading error if the type in the catch() is
ambiguous
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pets...@gmail.com
Created attachment 26154
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26154
test case that triggers the bug
There is a regression from g++ 4.4 in later versions. If the name of the class
is ambiguous in a catch(), this fact is not reported.
At line 25 when compiling the attached test case with 4.5.x, 4.6.x or 4.7.0,
the ambiguity of the type name 'ex2' is not mentioned.
4.4.6 reports the ambiguity at the catch(), though for other ambiguities (at
variable definition, class declaration w/ ambiguous parent) it prints the
message twice. 4.5 and above versions print the error once in these latter
cases. I suspect that this regression might be connected to fixing the
duplicated error printing.
Tested on an amd64 machine with Debian Wheezy, stock 4.4, 4.5, 4.6 versions
(4.4.6-14, 4.5.3-9, 4.6.2-7) and 4.7.0 built from svn trunk r182460.
The original cpp file is attached, since it doesn't have any preprocessor
directives except for comments.
Command line and output:
g++-r182460 -v -save-temps -Wall -Wextra -c test_gccexbug2.cpp
Using built-in specs.
COLLECT_GCC=g++-r182460
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --program-suffix -r182460
Thread model: posix
gcc version 4.7.0 20111219 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-c' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/cc1plus -E -quiet -v
-D_GNU_SOURCE test_gccexbug2.cpp -mtune=generic -march=x86-64 -Wall -Wextra
-fpch-preprocess -o test_gccexbug2.ii
ignoring nonexistent directory
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/x86_64-unknown-linux-gnu
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/backward
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include
/usr/local/include
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-c' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/cc1plus -fpreprocessed
test_gccexbug2.ii -quiet -dumpbase test_gccexbug2.cpp -mtune=generic
-march=x86-64 -auxbase test_gccexbug2 -Wall -Wextra -version -o
test_gccexbug2.s
GNU C++ (GCC) version 4.7.0 20111219 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.0 20111218 (experimental), GMP version 5.0.2,
MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.7.0 20111219 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.0 20111218 (experimental), GMP version 5.0.2,
MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: fafea236350b995726228b0b21cd1771
test_gccexbug2.cpp: In function ‘void bar()’:
test_gccexbug2.cpp:25:11: error: expected type-specifier before ‘ex2’
test_gccexbug2.cpp:25:14: error: expected ‘)’ before ‘’ token
test_gccexbug2.cpp:25:14: error: expected ‘{’ before ‘’ token
test_gccexbug2.cpp:25:15: error: expected primary-expression before ‘)’ token
test_gccexbug2.cpp:25:15: error: expected ‘;’ before ‘)’ token
[Bug c++/51640] Misleading error if the type in the catch() is ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51640 --- Comment #1 from petschy at gmail dot com 2011-12-20 16:49:02 UTC --- Created attachment 26155 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26155 a slightly more verbose test case Extended test case with ambiguous type name in variable definition and class declaration.
[Bug fortran/51639] [4.6 Regression] Nested type pointer null initialisation fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51639 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org Target Milestone|--- |4.6.3 Summary|Nested type pointer null|[4.6 Regression] Nested |initialisation fails|type pointer null ||initialisation fails
[Bug c++/51640] Misleading error if the type in the catch() is ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51640 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-20 Known to work||4.4.3 Ever Confirmed|0 |1 Known to fail||4.5.2, 4.6.2, 4.7.0
[Bug middle-end/51472] ICE: verify_gimple failed: invalid rhs for gimple memory store with -fgnu-tm --param tm-max-aggregate-size=32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51472 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org |gnu.org | --- Comment #3 from Aldy Hernandez aldyh at gcc dot gnu.org 2011-12-20 17:00:56 UTC --- Proposed fix http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01467.html
[Bug c++/51641] New: Lookup finds enclosing class member instead of template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51641
Bug #: 51641
Summary: Lookup finds enclosing class member instead of
template parameter
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: do...@gcc.gnu.org
Depends on: 36019, 45625
Another case of the lookup problem you fixed previously has come up on the core
mailing list:
struct A {
struct B { typedef int X; };
};
templateclass B struct C : A {
B::X q; // Ok: A::B.
struct U { typedef int X; };
templateclass U
struct D;
};
templateclass B
templateclass U
struct CB::D {
typename U::X r; // { dg-error }
Cint::Ddouble y;
The use of U in D should find the template parameter, leading to an error on
instantiation.
[Bug c++/51037] SIGSEGV -O3 C++ only
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51037 Marc Glisse marc.glisse at normalesup dot org changed: What|Removed |Added CC||marc.glisse at normalesup ||dot org --- Comment #4 from Marc Glisse marc.glisse at normalesup dot org 2011-12-20 17:07:54 UTC --- It still happens on Debian, which has a version based on r182430 (Dec 17), but not when I build today's (Dec 20) branch myself.
[Bug fortran/51639] [4.6 Regression] Nested type pointer null initialisation fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51639 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-12-20 17:13:31 UTC --- Tobias, Do you have a 4.6.3 build after r182062 (p51435)? If yes, could you check its behavior for this pr? TIA.
[Bug fortran/51638] gfortran optimization breaks a single variable used as both input and output for subroutine call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51638 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-12-20 17:20:46 UTC --- (In reply to comment #0) the attached program provides 2 subroutines which do not run correctly if the program is compiled with the optimization option (-O). I can reproduce it with -O -m32 on x86-64-linux. It works with -O0 or with -O2 or higher. And it is independent of the usual suspects, i.e. -fno-frontend-optimize and -mfpmath=sse do not change the result. I have not yet understood why it causes problems. * * * The key point is that the same variable is used as 2 different dummy variables (input and output) in the calling sequence. I think that's actually not the key point. While it is invalid (in the general case) to pass twice the same argument, it does not seem to cause the problem. (Passing the same argument multiple times is valid if one does not modify it; also pointer and target attribute enable some valid use. However, your usage is clearly invalid.) The problem of passing the argument multiple times can be removed by changing the code to: call iei4ei( (in4), in4) call iei8ei( (in8), in8) (Note the (...).) However, the issue is unaffected by this change. In terms of code validity, there are two other issues: a) Wrong objects in EQUIVALENCE: C591 (R566) If an equivalence-object is default integer, default real, double precision real, default complex, default logical, or of numeric sequence type, all of the objects in the equivalence set shall be of these types and kinds. C594 (R566) If an equivalence-object is of an intrinsic type but is not default integer, default real, double precision real, default complex, default logical, or default character, all of the objects in the equivalence set shall be of the same type with the same kind type parameter value. b) Passing an INTEGER(kind=4) to an INTEGER(kind=1) is invalid. Nevertheless, one should try to find out what goes wrong.
[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622 --- Comment #9 from Domingo Alvarez mingodad at gmail dot com 2011-12-20 17:30:55 UTC --- Some mistakes corrected and it was compiled with mingw 4.6.1 and wotk as expected. The results: lua 5.1.4 with _Decimal64 from 2.4MB to 681KB sqlite3 with _Decimal64 from 3MB to 1.239KB http://code.google.com/p/luafltk/downloads/detail?name=bid_decimal-splited-2.zipcan=2q= dfp-filenames = ifneq ($(D32PBIT)$(D64PBIT)$(D128PBIT),) ifeq ($(enable_decimal_float),bid) dfp-filenames += bid_decimal_globals bid_decimal_data \ bid_bd_to_bid32 bid_bd_to_bid64 bid_bd_to_bid128 \ bid_bd_to_binary32 bid_bd_to_binary64 \ bid_bd_to_binary80 bid_bd_to_binary128 \ bid_bd_power_five bid_bd_roundbound_128 \ bid_convert_data \ _isinfd32 _isinfd64 _isinfd128 bid64_noncomp \ bid128_noncomp bid128_fma bid_round bid_from_int \ bid64_add bid128_add bid64_div bid128_div \ bid64_mul bid128_mul bid64_compare bid128_compare \ bid128 bid32_to_bid64 bid32_to_bid128 bid64_to_bid128 \ bid64_to_int32 bid64_to_int64 \ bid64_to_uint32 bid64_to_uint64 \ bid128_to_int32 bid128_to_int64 \ bid128_to_uint32 bid128_to_uint64 else dfp-filenames += decContext decNumber decExcept decRound decLibrary decDouble decPacked decQuad decSingle endif endif
[Bug lto/51642] New: Weak variable reference triggers ICE with -flto option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51642
Bug #: 51642
Summary: Weak variable reference triggers ICE with -flto option
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sip...@gmail.com
The following program triggers ICE when compiled with -flto switch.
Tested on:
- GCC 4.6.2 and 4.6.1 on ARM target;
- GCC 4.6.2 x86 target (Fedora-16, x86_64)
NOTE: trying to add/remove -fnodefaultlibs option,
trying to add __attribute__(used) to config_np -
just the same ICE.
extern const int config_board;
const int config_np = 1;
#pragma weak config_board = config_np
int main(void)
{
return config_board;
}
Logs:
## Case 1: cross-gcc for ARM
$ /opt/arm/gnuarm-4.6.2/bin/arm-eabi-gcc -o test.ax t00x0.c -O3 -nodefaultlibs
-flto
lto1: 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.
lto-wrapper: /opt/arm/gnuarm-4.6.2/bin/arm-eabi-gcc returned 1 exit status
/opt/arm/gnuarm-4.6.2/lib/gcc/arm-eabi/4.6.2/../../../../arm-eabi/bin/ld:
lto-wrapper failed
collect2: ld returned 1 exit status
$ /opt/arm/gnuarm-4.6.2/bin/arm-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=/opt/arm/gnuarm-4.6.2/bin/arm-eabi-gcc
COLLECT_LTO_WRAPPER=/opt/arm/gnuarm-4.6.2/libexec/gcc/arm-eabi/4.6.2/lto-wrapper
Target: arm-eabi
Configured with: ../../src/gcc-4.6.2/configure --target=arm-eabi
--prefix=/opt/arm/gnuarm-4.6.2 --enable-multilib --enable-interwork
--enable-biendian --enable-fpu --with-newlib --with-gnu-ld --with-gnu-as
--disable-nls --disable-shared --with-arch=armv5te --with-fpu=vfp
--with-float=softfp --with-abi=aapcs-linux --enable-lto
--enable-languages=c,c++ --disable-threads --enable-ppl --enable-cloog
--enable-gmp --enable-mpfr --enable-lto
-with-headers=/opt/arm/gnuarm-4.6.2/arm-eabi/include
Thread model: single
gcc version 4.6.2 (GCC)
## Case 2: Native gcc, Fedora-16
$ gcc -o test.ax t00x0.c -O3 -nodefaultlibs -flto
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bugzilla for instructions.
lto-wrapper: /usr/bin/gcc returned 1 exit status
/usr/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.6.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.6.2 20111027 (Red Hat 4.6.2-1) (GCC)
[Bug fortran/51639] [4.6 Regression] Nested type pointer null initialisation fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51639 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-12-20 17:43:43 UTC --- (In reply to comment #2) Do you have a 4.6.3 build after r182062 (p51435)? If yes, could you check its behavior for this pr? TIA. I have a 4.6 build from Dec 11, which should be after Rev. 182062. There, I do not see any valgrind error (contrary to the 4.6.2 release version). Seems to be indeed a duplicate of PR 51435. Jonathan: Could you try with a newer GCC - either GCC 4.6.3 (newer than 2011-12-06), or GCC 4.7 (experimental) [newer than 2011-12-06]. You could also try an older version, GCC 4.5 is not affected. Links to unofficial binaries and to instructions for building from source: http://gcc.gnu.org/wiki/GFortranBinaries *** This bug has been marked as a duplicate of bug 51435 ***
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 --- Comment #14 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-12-20 17:43:07 UTC --- What Ada does looks just like a workaround for what should be done properly in the expander. So no, IMHO we shouldn't be changing all other FEs and the middle-end (when it wants to generate them e.g. for memcpy) to do what Ada does, but we should change the expander. Of course I have the exactly opposite viewpoint, since I think that we should keep the invariants we have: integral modes are naturally aligned and TYPE_ALIGN = MODE_ALIGN (TYPE_MODE). Breaking them for a few pathological cases that the C compiler has shun for years doesn't seem the best course of action.
[Bug fortran/51638] gfortran optimization breaks a single variable used as both input and output for subroutine call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51638 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org 2011-12-20 17:44:56 UTC --- (In reply to comment #1) (In reply to comment #0) the attached program provides 2 subroutines which do not run correctly if the program is compiled with the optimization option (-O). I can reproduce it with -O -m32 on x86-64-linux. It works with -O0 or with -O2 or higher. And it is independent of the usual suspects, i.e. -fno-frontend-optimize and -mfpmath=sse do not change the result. I have not yet understood why it causes problems. * * * The key point is that the same variable is used as 2 different dummy variables (input and output) in the calling sequence. Actually, the same variable is used as the actual argument in the call to the subroutine, and the actual argument becomes associated with two different dummy argument. I think that's actually not the key point. While it is invalid (in the general case) to pass twice the same argument, it does not seem to cause the problem. Huh? It is not invalid to have an entity appear as multiple actual arguments in an argument list. (Passing the same argument multiple times is valid if one does not modify it; also pointer and target attribute enable some valid use. However, your usage is clearly invalid.) You even state that it is valid! The problem is that the OP modifies on of the dummy arguments. This is clearly discussed in 12.4.1.7 Restrictions on entities associated with dummy arguments While an entity is associated with a dummy argument, the following restrictions hold: (1) ... Action that affects the value of the entity or any subobject of it shall be taken only through the dummy argument unless ... (unless stuff involves things with POINTER or TARGET attributes, which OP doesn't have) Further down in Note 12.29 If there is a partial or complete overlap between the actual arguments associated with two different dummy arguments of the same procedure and the dummy arguments have neither the POINTER nor TARGET attribute, the overlapped portions shall not be defined, redefined, or become unde- fined during the execution of the procedure. For example, in CALL SUB (A(1:5), A(3:9)) A(3:5) shall not be defined, redefined, or become undefined through the first dummy argument because it is part of the argument associated with the second dummy argument and shall not be defined, redefined, or become undefined through the second dummy argument because it is part of the argument associated with the first dummy argument. A(1:2)remains definable through the first dummy argument and A(6:9) remains definable through the second dummy argument.
[Bug fortran/51435] [4.6/4.7 Regression] Bad association status after null() of derived type component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51435 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||jonathan.hogg at stfc dot ||ac.uk --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2011-12-20 17:43:43 UTC --- *** Bug 51639 has been marked as a duplicate of this bug. ***
[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #8 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-12-20 18:06:34 UTC ---
(In reply to comment #7)
On Tue, 20 Dec 2011, Richard Guenther wrote:
This one is extremely slow. lto1 has already used 12min of CPU time when
linking libxul and is still running... (3min is normal)
That's odd - TREE_TYPE (f1) should already be registered - but I suppose
that adjusting TYPE_NAME might break all the caching we do with the
type-pair cache as TREE_TYPE (TYPE_NAME (f1)) is in the SCC of the
type we change that SCC by that adjustment - probably causing
the hit rate of the type-pair compare cache to become absymal?
Maybe you can check that theory (I have no other idea why the above
should be slow).
Though we should be hitting the gimple_type_leader cache only ...
maybe it's too small though?
Increasing the cache 4-fold doesn't help.
I will look deeper tomorrow. In the meantime here is a disassembly of the
hot-spot.
uniquify_nodes:
: /* Second fixup all trees in the new cache entries. */
: for (i = len; i-- from;)
0.00 : 49969f: mov%ebp,%eax
0.00 : 4996a1: jmpq 4994b0 lto_read_decls+0x110
0.00 : 4996a6: nopw %cs:0x0(%rax,%rax,1)
: tree t = VEC_index (tree, cache-nodes, i);
: if (t == NULL_TREE)
:continue;
:
: if (TREE_CODE (t) == VAR_DECL)
:lto_register_var_decl_in_symtab (data_in, t);
0.00 : 4996b0: mov0x38(%rsp),%rdi
0.00 : 4996b5: callq 499250
lto_register_var_decl_in_symtab
0.00 : 4996ba: jmpq 499520 lto_read_decls+0x180
: variant list state before fixup is broken. */
: tree tem, mv;
:
: /* Remove us from our main variant list if we are
not the
: variant leader. */
: if (TYPE_MAIN_VARIANT (t) != t)
0.00 : 4996bf: mov0x68(%r15),%rdi
0.00 : 4996c3: cmp%rdi,%r15
0.00 : 4996c6: je 499701 lto_read_decls+0x361
:{
: tem = TYPE_MAIN_VARIANT (t);
: while (tem TYPE_NEXT_VARIANT (tem) != t)
0.00 : 4996c8: test %rdi,%rdi
0.00 : 4996cb: je 4996f9 lto_read_decls+0x359
0.00 : 4996cd: mov0x60(%rdi),%rax
0.00 : 4996d1: cmp%rax,%r15
0.00 : 4996d4: jne4996e3 lto_read_decls+0x343
0.00 : 4996d6: jmpq 4997d9 lto_read_decls+0x439
0.00 : 4996db: nopl 0x0(%rax,%rax,1)
0.50 : 4996e0: mov%rcx,%rax
0.70 : 4996e3: test %rax,%rax
0.00 : 4996e6: je 4996f9 lto_read_decls+0x359
0.00 : 4996e8: mov0x60(%rax),%rcx
98.41 : 4996ec: cmp%rcx,%r15
0.00 : 4996ef: jne4996e0 lto_read_decls+0x340
:tem = TYPE_NEXT_VARIANT (tem);
: if (tem)
:TYPE_NEXT_VARIANT (tem) = TYPE_NEXT_VARIANT
(t);
0.00 : 4996f1: mov0x60(%r15),%rcx
0.00 : 4996f5: mov%rcx,0x60(%rax)
: TYPE_NEXT_VARIANT (t) = NULL_TREE;
0.00 : 4996f9: movq $0x0,0x60(%r15)
:}
:
: /* Query our new main variant. */
: mv = gimple_register_type (TYPE_MAIN_VARIANT (t));
0.01 : 499701: callq 5be860 gimple_register_type
:
: /* If we were the variant leader and we get
replaced ourselves drop
: all variants from our list. */
: if (TYPE_MAIN_VARIANT (t) == t
0.00 : 499706: mov0x30(%rsp),%rdx
0.00 : 49970b: cmp0x68(%rdx),%rdx
0.00 : 49970f: je 4997b7 lto_read_decls+0x417
:}
:}
:
: /* If we are not our own variant leader link us
into our new leaders
: variant list. */
: if (mv != t)
0.00 : 499715: cmp%rax,0x30(%rsp)
0.00 : 49971a: je 49992d lto_read_decls+0x58d
:{
[Bug c++/19185] [4.4/4.5/4.6/4.7 Regression] ICE in cp_expr_size with PCC_STATIC_STRUCT_RETURN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19185 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||jason at gcc dot gnu.org --- Comment #15 from Jason Merrill jason at gcc dot gnu.org 2011-12-20 18:11:32 UTC --- The expr size langhook was removed in GCC 4.5; I expect that this ICE went away then, too.
[Bug c++/19185] [4.4/4.5/4.6/4.7 Regression] ICE in cp_expr_size with PCC_STATIC_STRUCT_RETURN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19185 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #16 from John David Anglin danglin at gcc dot gnu.org 2011-12-20 18:53:24 UTC --- The target machine is no longer available. So, based on Jason's comment, I am closing this PR.
[Bug libstdc++/51636] Thread-safeness of new and delete operators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51636 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-12-20 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-20 19:48:56 UTC --- Without a self contained testcase nothing will happen, per the bug reporting instructions. Please attach one or the bug will be soon closed. Thanks.
[Bug c++/51630] failure to detect missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51630 Robert Ramey ramey at rrsd dot com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #5 from Robert Ramey ramey at rrsd dot com 2011-12-20 21:04:38 UTC --- thank you for a prompt and spot on answer. I looked for some more information on the -fsyntax-only option but didn't find it. These days with lots of template libraries, skipping the instantiation misses a lot of syntax errors. Perhaps another option is in order? Thank you again. Robert Ramey
[Bug rtl-optimization/51643] New: Incorrect code produced for tail-call of weak function with -O2/-O3 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643
Bug #: 51643
Summary: Incorrect code produced for tail-call of weak function
with -O2/-O3 option
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sip...@gmail.com
A tail-call of weak function produces incorrect code, compiled with -O2 or -O3.
Target: arm-eabi
Version: GCC 4.6.2 and 4.6.1
* Test case: t00x1.c
extern void __attribute__((weak)) wfunc(void);
void main(void)
{
wfunc(); // tail weak call fails!!!
// __asm__ volatile (nop:::memory); // workaround
}
$ /opt/arm/gnuarm-4.6.2/bin/arm-eabi-gcc -c -S -o t00x1.S -O2 t00x1.c
* Contents of t00x1.S:
.filet00x1.c
.section.text.startup,ax,%progbits
.align2
.globalmain
.typemain, %function
main:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
bwfunc Will be replaced by NOP in linker!!
so, no return sequence!
.sizemain, .-main
.weakwfunc
.identGCC: (GNU) 4.6.2
* Disassembled (objdump) code: t00x1.lst:
0240 main:
240:e1a0 nop; (mov r0, r0) really, NOP
0244 __do_global_dtors_aux:
244:e92d4010 push{r4, lr}
248:e59f4028 ldrr4, [pc, #40]; 278
...
**
Call to function wfunc was converted to NOP by linker, as expected.
As a result, no return sequence from main(), falling througt to next code line.
For reference: the same program compiled with -O1
***
.filet00x1.c
.text
.align2
.globalmain
.typemain, %function
main:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
stmfdsp!, {r3, lr}
blwfunc
ldmfdsp!, {r3, pc}
.sizemain, .-main
.weakwfunc
.identGCC: (GNU) 4.6.2
Code with workaround, compiled with -O2 correct:
$ /opt/arm/gnuarm-4.6.2/bin/arm-eabi-gcc -c -S -o t00x1.S -O2 t00x1.c
***
.filet00x1.c
.section.text.startup,ax,%progbits
.align2
.globalmain
.typemain, %function
main:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
stmfdsp!, {r3, lr}
blwfunc
@ 5 t00x1.c 1
nop
@ 0 2
ldmfdsp!, {r3, pc}
.sizemain, .-main
.weakwfunc
.identGCC: (GNU) 4.6.2
***
Compiler options:
$ /opt/arm/gnuarm-4.6.2/bin/arm-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=/opt/arm/gnuarm-4.6.2/bin/arm-eabi-gcc
COLLECT_LTO_WRAPPER=/opt/arm/gnuarm-4.6.2/libexec/gcc/arm-eabi/4.6.2/lto-wrapper
Target: arm-eabi
Configured with: ../../src/gcc-4.6.2/configure --target=arm-eabi
--prefix=/opt/arm/gnuarm-4.6.2 --enable-multilib --enable-interwork
--enable-biendian --enable-fpu --with-newlib --with-gnu-ld --with-gnu-as
--disable-nls --disable-shared --with-arch=armv5te --with-fpu=vfp
--with-float=softfp --with-abi=aapcs-linux --enable-lto
--enable-languages=c,c++ --disable-threads --enable-ppl --enable-cloog
--enable-gmp --enable-mpfr --enable-lto
-with-headers=/opt/arm/gnuarm-4.6.2/arm-eabi/include
Thread model: single
gcc version 4.6.2 (GCC)
[Bug target/51643] Incorrect code produced for tail-call of weak function with -O2/-O3 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target|arm-eabi| Component|rtl-optimization|target Known to fail|4.6.1, 4.6.2| Build|x86_64-redhat-linux | Severity|major |normal --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-12-20 21:26:44 UTC --- I think this code is undefined. You are calling a weak function without checking if it is null.
[Bug target/51643] Incorrect code produced for tail-call of weak function with -O2/-O3 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-12-20 21:27:15 UTC --- Also the linker seems funny to replace a branch to null with a nop.
[Bug target/49865] [4.7 Regression] Unnecessary reload causes small bloat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49865 --- Comment #7 from Vladimir Makarov vmakarov at gcc dot gnu.org 2011-12-20 21:29:40 UTC --- Author: vmakarov Date: Tue Dec 20 21:29:36 2011 New Revision: 182553 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182553 Log: 2011-12-20 Vladimir Makarov vmaka...@redhat.com PR target/49865 * ira-costs.c (find_costs_and_classes): Prefer registers even if the memory cost is the same. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-costs.c
[Bug c/51644] New: [4.7 Regression] va_list vs. warning: ‘noreturn’ function does return is not fixable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51644
Bug #: 51644
Summary: [4.7 Regression] va_list vs. warning: ‘noreturn’
function does return is not fixable
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jan.kratoch...@redhat.com
PASS: gcc (GCC) 4.6.3 20111220 (prerelease)
FAIL: gcc (GCC) 4.7.0 20111220 (experimental)
#include stdarg.h
extern __attribute__ ((__noreturn__)) void b (int s, va_list ap);
__attribute__ ((__noreturn__)) void a (int s, ...)
{
va_list args;
va_start (args, s);
b (s, args);
va_end (args);
}
-Wall -fexceptions
35.c:9:1: warning: ‘noreturn’ function does return [enabled by default]
It gets fixed by removing that va_end but I must not (suggested by Tom
Tromey):
ISO C99 7.15.1
Each invocation of the va_start and va_copy macros shall be matched by a
corresponding invocation of the va_end macro in the same function.
[Bug rtl-optimization/42839] [4.5/4.6 Regression] gcc.target/mips/octeon-bbit-2.c failing for -mabi=64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42839 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||rsandifo at gcc dot gnu.org Resolution||FIXED Known to fail||4.6.0 --- Comment #20 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-12-20 21:35:47 UTC --- Not really suitable for a backport, so closing.
[Bug target/51643] Incorrect code produced for tail-call of weak function with -O2/-O3 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643 --- Comment #3 from Alexander Osipenko sipych at gmail dot com 2011-12-20 21:39:11 UTC --- This behavior is explicitly defined in ARM RealView compiler, and GCC seems try to follow this convention.
[Bug middle-end/39586] make linux kernel error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39586 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-12-20 21:48:59 UTC --- No feedback in over 2 years now.
[Bug target/51643] Incorrect code produced for tail-call of weak function with -O2/-O3 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643 --- Comment #4 from Alexander Osipenko sipych at gmail dot com 2011-12-20 21:58:39 UTC --- From ARM EABI specification (doc: ARM IHI 0044A) On platforms that do not support dynamic pre-emption of symbols an unresolved weak reference to a symbol relocated by R_ARM_CALL shall be treated as a jump to the next instruction (the call becomes a no-op). The behaviour of R_ARM_JUMP24 in these conditions is unspecified. At least, tail call + epilogue shall not be replaced by (undefined) JUMP.
[Bug testsuite/51645] New: FAIL: g++.dg/cpp0x/alias-decl-debug-0.C (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51645
Bug #: 51645
Summary: FAIL: g++.dg/cpp0x/alias-decl-debug-0.C (test for
excess errors)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
CC: r...@gcc.gnu.org
Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
Build: hppa64-hp-hpux11.11
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++
-B/test/gnu/
gcc/objdir/gcc/testsuite/g++/../../
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x
/alias-decl-debug-0.C -nostdinc++
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/l
ibstdc++-v3/include/hppa64-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.
11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/g
cc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/
util -fmessage-length=0 -std=c++0x -gstabs+ -S -o alias-decl-debug-0.s
(ti
meout = 300)
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/alias-decl-debug-0.C:1:0: error:
ta
rget system does not support the stabs debug format
compiler exited with status 1
output is:
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/alias-decl-debug-0.C:1:0: error:
ta
rget system does not support the stabs debug format
FAIL: g++.dg/cpp0x/alias-decl-debug-0.C (test for excess errors)
Needs:
/* { dg-skip-if No stabs { mmix-*-* *-*-aix* alpha*-*-* hppa*64*-*-* ia64-*-*
*-*-vxworks* } { * } { } } */
as in gcc.dg/20040813-1.c.
[Bug target/51643] Incorrect code produced for tail-call of weak function with -O2/-O3 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643 --- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-12-20 22:34:43 UTC --- On Tue, 20 Dec 2011, sipych at gmail dot com wrote: On platforms that do not support dynamic pre-emption of symbols an unresolved weak reference to a symbol relocated by R_ARM_CALL shall be treated as a jump to the next instruction (the call becomes a no-op). The behaviour of R_ARM_JUMP24 in these conditions is unspecified. At least, tail call + epilogue shall not be replaced by (undefined) JUMP. That's an ABI specifying relocation handling, not an API specifying semantics of C source code. The C semantics are as specified in the C standard, i.e. undefined behavior if the call is executed; C is a high-level language not a portable assembler and the semantics are those of the C standard not those of particular instructions you might guess have some relation to particular C operations. The EABI semantics say what happens with a relocation that might have been generated from code where the call is properly conditional in the C source, or might have been generated from code with undefined behavior. It would be valid for the compiler to rely on the EABI semantics to optimize code generation for if (wfunc) wfunc ();, for example, but those semantics do not change the undefined nature of code that doesn't condition the call.
[Bug target/43437] ICE in CSE, during libgcc build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #19 from Mikael Pettersson mikpe at it dot uu.se 2011-12-20 23:27:23 UTC --- The real cause of the ICE in the second test case is Alexandre Oliva's PR debug/43092 + PR rtl-optimization/43494 fix in r169782: http://gcc.gnu.org/ml/gcc-cvs/2011-02/msg00325.html The ICE is masked when the PR37273 missed-optimization fix is present, i.e. from r169231 to r170199 (exclusive), and from r17 on current trunk. But 4.6 branch doesn't have the PR37273 fix, so the ICE does occur there.
[Bug target/51643] Incorrect code produced for tail-call of weak function with -O2/-O3 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643 --- Comment #6 from Alexander Osipenko sipych at gmail dot com 2011-12-20 23:33:06 UTC --- It seems reasonable to expect minimal consistency, either generating invalid (zero for example) reference for any direct weak function call, better marking it with warning or even error message, or not depending on the optimization options. In any case, the semantics of weak referencies is beyond of the C standard scope, so even if( wfunc ) wfunc(); may be treated only in terms of reasonable consistency. EABI specification follows a simple rule: call to undefined weak function do nothing. Just the same do if( wfunc ) wfunc();, a little bit longer, if we believe that undefined wfunc == 0 always, but not 0xDEADBEEF eventually when optimized.
[Bug c++/51621] [c++0x] [4.6/4.7 Regression] ICE with invalid constexpr and array class member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51621 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-12-20 23:51:13 UTC --- Author: paolo Date: Tue Dec 20 23:51:09 2011 New Revision: 182556 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182556 Log: /cp 2011-12-20 Paolo Carlini paolo.carl...@oracle.com PR c++/51621 * tree.c (diagnose_non_constexpr_vec_init): For value initialization pass void_type_node, not void_zero_node, to build_vec_init_elt. /testsuite 2011-12-20 Paolo Carlini paolo.carl...@oracle.com PR c++/51621 * g++.dg/cpp0x/constexpr-ice5.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ice5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog
[Bug c++/51621] [c++0x] [4.6/4.7 Regression] ICE with invalid constexpr and array class member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51621 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.6.3 |4.7.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-20 23:52:46 UTC --- Fixed for 4.7.0.
[Bug c++/51305] [C++11][constexpr] noexcept-specifier overconstraints constexpr functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51305 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.7.0 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-21 01:14:51 UTC --- On it.
[Bug middle-end/51200] Wrong code sequence to store restrict volatile bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51200 Bernd Schmidt bernds at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||bernds at gcc dot gnu.org Resolution||FIXED --- Comment #3 from Bernd Schmidt bernds at gcc dot gnu.org 2011-12-21 01:22:08 UTC --- Fixed, I think?
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 --- Comment #14 from asmwarrior asmwarrior at gmail dot com 2011-12-21 03:21:07 UTC --- Thanks for fix this bug, I hope some devs will backport this patch to 4.5/4.6 branches.
[Bug rtl-optimization/43491] Unnecessary temporary for global register variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43491 --- Comment #4 from amker.cheng amker.cheng at gmail dot com 2011-12-21 03:44:03 UTC --- This bug is even worse on mips. The cause is ssa-pre eliminates global register variable when it is the RHS of single assign statment, while following passes do not handle the const/register attributes of the variable. It can be handled in tree-ssa-pre.c without hurting true redundancy elimination on global register variables. So could somebody change the tag from rtl-optimization to tree-optimization?
[Bug middle-end/51200] Wrong code sequence to store restrict volatile bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51200 Joey Ye joey.ye at arm dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #4 from Joey Ye joey.ye at arm dot com 2011-12-21 04:34:57 UTC --- Fixed in trunk 182545
[Bug target/51552] bfin generates bad assembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51552 --- Comment #2 from Jie Zhang jiez at gcc dot gnu.org 2011-12-21 04:35:19 UTC --- (gdb) p insn $23 = (rtx) 0x7701b180 (gdb) pr (parallel [ (unspec [ (const_int -4 [0xfffc]) ] 5) (set/f (mem:SI (plus:SI (reg/f:SI 14 SP) (const_int -4 [0xfffc])) [0 S4 A32]) (reg:SI 7 R7)) (set/f (reg/f:SI 14 SP) (plus:SI (reg/f:SI 14 SP) (const_int -4 [0xfffc]))) Before that commit, dwarf2out_frame_debug_expr (insn) will set any_cfis_emitted in dwarf2out_frame_debug, which will cause dwarf2out_flush_queued_reg_saves to emit the CFI. But after that commit, dwarf2out_frame_debug_expr (insn) will not set any_cfis_emitted.
[Bug c++/51630] failure to detect missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51630 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-21 05:08:32 UTC --- The syntax of your example was OK, so -fsyntax-only doesn't give errors. If -fsyntax-errors only isn't what you're looking for, don't use it. It's not clear what you're asking for, maybe you want -Wfatal-errors
[Bug c++/51630] failure to detect missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51630
Robert Ramey ramey at rrsd dot com changed:
What|Removed |Added
Resolution|INVALID |WONTFIX
--- Comment #7 from Robert Ramey ramey at rrsd dot com 2011-12-21 05:39:49
UTC ---
what I expected was that -fsyntax-only would run the normal process but skip
the code generation. I don't think that's an unreasonable expectation from the
name of the option and the simple description of it.
Also I wouldn't characterize the program as not having any syntax errors. The
first example
name test2(){
name x, y;
return (x y) ? y : x;
}
generates an compile time error as one would expect. If the same code were
placed inside a macro, it would also provoke an error. Then you move it into
at template - and voila - no syntax error. This is not regular or intuitive
behavior. When you tested it you also expected to see an error - to the extent
you tried on several versions of gcc.
If your asking me what I want, I would respond that the current behavior of the
-fsyntax-only is inconsistent and confusing and has room for improvement. It's
not much of an answer to say don't do that. Taken to it's logical
conclusion, you might just skip emission of compile time errors all together
and replace them with the admonition - don't write incorrect code !
Anyway, thanks again for detecting this.
Robert Ramey
[Bug lto/41159] [LTO] ICE in insert_value_copy_on_edge, at tree-outof-ssa.c:225
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41159
--- Comment #22 from Uros Bizjak ubizjak at gmail dot com 2011-12-21 07:21:38
UTC ---
Hardly to believe, but alpha finished --with-build-config=bootstrap-lto build,
with lto crippled by the following patch:
Index: lto-wrapper.c
===
--- lto-wrapper.c (revision 182526)
+++ lto-wrapper.c (working copy)
@@ -581,7 +581,7 @@ run_gcc (unsigned argc, char *argv[])
switch (option-opt_index)
{
case OPT_o:
- linker_output = option-arg;
+ /* linker_output = option-arg; */
/* We generate new intermediate output, drop this arg. */
continue;
The results of this experiment are at [1].
The failing testcase works as well, so the patch certainly fixes the bug and
doesn't introduce any problems.
(I can take care for backport of the patch to 4.6 and 4.5 branches).
[1] http://gcc.gnu.org/ml/gcc-testresults/2011-12/msg02168.html
[Bug tree-optimization/43491] Unnecessary temporary for global register variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43491 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Component|rtl-optimization|tree-optimization Known to fail|| --- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2011-12-21 07:54:15 UTC --- (In reply to comment #4) So could somebody change the tag from rtl-optimization to tree-optimization? Done.
