[Bug tree-optimization/50412] [4.6/4.7 Regression] gfortran -Ofast ICE in vect_do_peeling_for_loop_bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50412 --- Comment #4 from irar at gcc dot gnu.org 2011-09-25 09:04:24 UTC --- Author: irar Date: Sun Sep 25 09:04:19 2011 New Revision: 179160 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179160 Log: PR tree-optimization/50412 * tree-vect-data-refs.c (vect_analyze_group_access): Fail for accesses that require epilogue loop if vectorizing outer loop. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/vect/pr50412.f90 Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-vect-data-refs.c
[Bug tree-optimization/50413] [4.6/4.7 Regression] Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 --- Comment #15 from irar at gcc dot gnu.org 2011-09-25 09:26:03 UTC --- Author: irar Date: Sun Sep 25 09:25:59 2011 New Revision: 179162 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179162 Log: PR tree-optimization/50413 * tree-vect-data-refs.c (vect_analyze_data_refs): Fail to vectorize a basic block if one of its data-refs can't be analyzed. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/vect/slp-pr50413.cc Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/g++.dg/vect/vect.exp branches/gcc-4_6-branch/gcc/tree-vect-data-refs.c
[Bug tree-optimization/50412] [4.6/4.7 Regression] gfortran -Ofast ICE in vect_do_peeling_for_loop_bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50412 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Ira Rosen irar at il dot ibm.com 2011-09-25 09:26:59 UTC --- Fixed.
[Bug tree-optimization/50413] [4.6/4.7 Regression] Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #16 from Ira Rosen irar at il dot ibm.com 2011-09-25 09:27:41 UTC --- Fixed.
[Bug c++/50363] internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50363 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-09-25 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-25 09:44:17 UTC --- I will have a look.
[Bug target/48108] lto should be containerized in a single mach-o section on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48108 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Attachment #24958|0 |1 is obsolete|| --- Comment #19 from Iain Sandoe iains at gcc dot gnu.org 2011-09-25 09:49:04 UTC --- Created attachment 25359 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25359 wip 3 The new attachment implements the 'wrapper' in simple-object read and write and darwin.c Modulo checking comments/white space it's a candidate for fixing the bug. I am not sure why this has been labelled 'enhancement' - we are generating badly-formed mach-o (according to the vendor) - the fact that we don't see a reported error with earlier vendor tool-chains doesn't seem to make it an 'enhancement' to get it right ;) --- I've done --with-build-config='bootstrap-lto bootstrap-debug' (no Ada on trunk because of unrelated issues) on: trunk *-darwin9 (less Ada) 4.6 i686-darwin9 (incl. Ada) 4.6 powerpc-darwin9 is running. trunk x86_64-darwin10 (less Ada) 4.6 x86_64-darwin10 (incl. Ada) So - darwin 11 needs checking. The patch applies cleanly to both 4.6 and trunk as of this time.
[Bug lto/50383] ICE in lto_symtab_register_decl, at lto-symtab.c:148
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50383 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC|rguenther at suse dot de|rguenth at gcc dot gnu.org --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-25 09:52:12 UTC --- So why doesn't it have DECL_ASSEMBLER_NAME set?
[Bug tree-optimization/50415] [4.7 Regression] gfortran -Ofast SIGSEGV in find_uses_to_rename_use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50415 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug tree-optimization/50414] [4.7 Regression] gfortran -Ofast SIGSEGV in store_constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50414 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug fortran/50416] gfortran -O1 ICE MPFR assertion failed: 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50416 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-25 09:57:21 UTC --- old(?) mpfr bug.
[Bug tree-optimization/50417] regression: memcpy with known alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-25 09:58:43 UTC --- The middle-end does not know anything about the parameters alignment.
[Bug middle-end/50426] [4.7 Regression] gfortran -O1 ICE in estimate_function_body_sizes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50426 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug lto/50383] ICE in lto_symtab_register_decl, at lto-symtab.c:148
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50383 --- Comment #10 from Jan Hubicka hubicka at ucw dot cz 2011-09-25 10:12:47 UTC --- So why doesn't it have DECL_ASSEMBLER_NAME set? No idea. I suppose it is not seen by free_lang_data for whatever reason. Honza
[Bug target/50440] 128 bit unsigned int subtraction generates too many register moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50440 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-* Status|UNCONFIRMED |NEW Keywords||missed-optimization Last reconfirmed||2011-09-25 Component|rtl-optimization|target Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-25 10:20:19 UTC --- Seems to be an artifact of the *subti3_doubleword splitter.
[Bug c++/50280] Incorrect type deduced for T when passed a const bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50280 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-09-25 10:43:03 UTC --- Author: paolo Date: Sun Sep 25 10:43:00 2011 New Revision: 179163 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179163 Log: 2011-09-25 Paolo Carlini paolo.carl...@oracle.com PR c++/50280 * g++.dg/template/bitfield1.C: New. Added: trunk/gcc/testsuite/g++.dg/template/bitfield1.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/50280] Incorrect type deduced for T when passed a const bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50280 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 10:45:01 UTC --- Fixed for 4.7.0.
[Bug c++/48562] [C++0x] warn about uses of initializer_list that will lead to dangling pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48562 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 10:54:07 UTC --- Johannes, sorry about the dumb question: now I understand the issue decently well - and after all boils down to adding a warning - but I'm not sure to understand your code snippet: is it meant to crash at runtime? Trigger valgrind errors?
[Bug c/50466] Compiled code behaves differently with -O2 -fPIC flag combination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50466 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-09-25 Ever Confirmed|0 |1
[Bug fortran/50463] [4.6/4.7 Regression] -ftree-dse leeds to wrong code with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50463 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-25 11:07:48 UTC --- Smells like a Frontend decl merging issue.
[Bug preprocessor/48839] #error should terminate compilation - similar to missing #include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48839 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||paolo.carlini at oracle dot ||com Component|c++ |preprocessor --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 11:07:49 UTC --- Personally, I agree. Actually, I had to work around this behavior in the library headers by changing the macros to something like: #ifndef HAVE_CXX0X_AUTO #error This file requires the auto feature of C++0x #else // lots of code that uses auto. #endif Note, this doesn't seem C++ specific, is a preprocessor issue. I'd like to hear Jason about this.
[Bug middle-end/50460] [4.7 Regression] __builtin___strcpy_chk/__builtin_object_size don't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50460
--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-25
11:11:21 UTC ---
(In reply to comment #4)
Looking at:
const char *str1 = JIHGFEDCBA;
#define strcpy(x,y) __builtin___strcpy_chk (x, y, __builtin_object_size (x,
1))
int
f1 (void)
{
struct A { char buf1[9]; char buf2[1]; } a;
strcpy (a.buf1 + (0 + 4), str1 + 5);
return 0;
}
int
f2 (void)
{
struct A { char buf1[9]; char buf2[1]; } a;
strcpy ((char *) a + (0 + 4), str1 + 5);
return 0;
}
int
f3 (void)
{
struct A { char buf1[9]; char buf2[1]; } a;
char *p = (char *) a;
strcpy (p + (0 + 4), str1 + 5);
return 0;
}
int
f4 (void)
{
struct A { char buf0; char buf1[9]; char buf2[1]; } a;
char *p = (char *) a;
strcpy (p + (0 + 5), str1 + 5);
return 0;
}
int
f5 (void)
{
struct A { char buf0; char buf1[9]; char buf2[1]; } a;
strcpy ((char *) a + (0 + 5), str1 + 5);
return 0;
}
with GCC 4.4, seems we have always reconstructed it into a.buf1[4].
So likely we want to reconstruct it from the MEM_REF in the *.objsz pass then.
If there is union involved, we probably want to reconstruct it to the
alternative with the largest possible __builtin_object_size (X, 1) resp.
smallest possible __builtin_object_size (X, 3).
I'm not sure. What's the C / fortify difference of a.buf1 + 9 vs. a.buf2?
Both would be MEM[a, 9]. I suppose we didn't re-construct array-refs in
4.4 from
void *p = a.buf1;
char *q = p + 4;
so, did we fail with 4.4 here, too?
[Bug tree-optimization/50452] [4.7 Regression] Internal compiler error: verify_flow_info failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50452 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c++/45581] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45581 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.5.3, 4.6.1, 4.7.0 Resolution||FIXED --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 11:24:36 UTC --- Fixed long time ago.
[Bug c++/44499] [4.7 Regression?] No default constructor available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||paolo.carlini at oracle dot ||com Summary|No default constructor |[4.7 Regression?] No |available |default constructor ||available --- Comment #19 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 11:41:02 UTC --- In mainline this is accepted again! Is it a regression?
[Bug c++/43393] integral promotion of long bit-fields broken in gcc 4.4.0?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43393 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org |jsm28 at gcc dot gnu.org --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 11:43:50 UTC --- I'm tempted to close this, then. Comment #4 raises a C issue, however, maybe Joseph wants to have a look?
[Bug c++/40574] -O3 cause segfault in loop in hunspell
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40574 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 11:46:20 UTC --- Feedback not forthcoming.
[Bug regression/50472] Volatile qualification in data is not enough to avoid optimization over pointer to data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50472
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011-09-25
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-25
11:52:49 UTC ---
CCP optimizes the load from the static const foo via fold_stmt. I will have a
look.
Folding statement: D.2758_2 ={v} *bar_1;
Folded into: D.2758_2 = 1;
[Bug c++/38502] static_assert vs. enums
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38502 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Known to work||4.6.0 Resolution||FIXED --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 11:53:19 UTC --- The ICE has been fixed long ago, apparently.
[Bug c++/50474] GCC (cc1plus) hangs forever compiling with -O2 (-fcse-follow-jumps)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50474 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-25 11:55:12 UTC --- Please report this bug to CodeSourcery then.
[Bug driver/50475] [4.7 regression] internal compiler error at passes.c:1730
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50475 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug tree-optimization/50480] 10% performance regression on Spec2006 410.bwaves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50480 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target||i?86-*-* --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-25 11:57:42 UTC --- For 32bit only it seems. Supposedly a cost model issue, the register pressure will be higher and we have only half the number of SSE regs.
[Bug lto/50483] lto turns visibility from HIDDEN to DEFAULT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50483 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||lto CC||hubicka at gcc dot gnu.org --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-25 11:58:40 UTC --- Honza?
[Bug regression/50484] [4.6 regression] ia64-portbld-freebsd9.0, conftest.c:16:1: internal compiler error: Segmentation fault: 11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50484 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target||ia64-*-freebsd9.0 Target Milestone|--- |4.6.2
[Bug testsuite/50485] gcc.target/i386/sse4_1-blendps.c fails spuriously on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50485 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-25 Ever Confirmed|0 |1
[Bug rtl-optimization/50489] [UPC/IA64] mis-schedule of MEM ref with -ftree-vectorize and -fschedule-insns2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50489 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-25 12:13:44 UTC --- D.3059_11 = VIEW_CONVERT_EXPRshared [8] struct foo[1] *(D.3058); looks like bogus IL to me. You view D.3058, a struct of size 16, as a pointer (of size 8). I suppose you want to load D.3058.vaddr here? D.3060_12 = (shared [8] struct foo *) D.3059_11; D.3061_13 = VIEW_CONVERT_EXPRstruct upc_shared_ptr_t(D.3060_12).phase; looks bogus IL to me. It views the pointer(!?) D.3060_12 as being a struct upc_shared_ptr_t and extracts a value that is not within that pointer. But maybe I'm missing something because I don't recognize that 'shared [8]' qualification. Do you want to dereference D.3060_12 (D.3058.vaddr) here? That said, I wonder why you don't trip over tree-cfg.c verification of VIEW_CONVERT_EXPR as TYPE_SIZE (TREE_TYPE (D.3060_12)) != TYPE_SIZE (struct upc_shared_ptr_t). Please try to avoid using VIEW_CONVERT_EXPRs completely unless you know exactly what you are doing.
[Bug c/50506] gcc fails at assembly with -O1 while inlining is forced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50506 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-25 12:25:17 UTC --- And we can't inline varargs functions either. Don't use the always_inline attribute.
[Bug c++/49126] timevar_stack faild because define_label
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49126 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 12:26:18 UTC --- On x86_64-linux, I don't see any internal compiler error compiling this. Please double check.
[Bug c/50507] Huge amount of memory used while building GCC4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50507 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-09-25 Ever Confirmed|0 |1 Severity|critical|normal --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-25 12:27:10 UTC --- If it happens during the link stage then it's an issue with the linker, not GCC. Please provide information on how you configured GCC, and which host compiler and linker you use and what host platform you are working on.
[Bug c++/50504] g++ 4.5.2 -O2 with complexdouble produces incorrect code on AMD64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50504 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-09-25 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-25 12:31:01 UTC --- Please try 4.5.3.
[Bug c++/48667] [ skipping N instantiation contexts ] Skips exactly those which are of interest to me
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48667 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 12:32:12 UTC --- Jason, should we make this more flexible? (I see hardwired constants in print_instantiation_partial_context)
[Bug target/49468] SH Target: inefficient integer abs code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49468 Oleg Endo oleg.e...@t-online.de changed: What|Removed |Added Attachment #24625|0 |1 is obsolete|| --- Comment #7 from Oleg Endo oleg.e...@t-online.de 2011-09-25 12:48:24 UTC --- Created attachment 25360 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25360 Proposed patch The last version of the patch fails the test gcc.c-torture/execute/arith-rand-ll.c for -m2a-single -mb and multiple optimization levels with the following error: internal compiler error: in change_address_1, at emit-rtl.c:1994 The attached version fixes some of the failures but still fails the test above with -m2a-single -mb -O2. Other optimization levels work fine. The problem is caused by the define_insn_and_split *abssi2. It even fails if the *abssi2 splits into nothing but a simple register copy (movdi) or comparison insn. I'm now testing the patch without the DI abs parts and will submit it if passes without new failures. Cheers, Oleg
[Bug c++/46105] Ordering failure among partial specializations with non-deduced context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46105 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 12:49:59 UTC --- Jason, is this the same as PR45012?
[Bug c/50506] gcc fails at assembly with -O1 while inlining is forced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50506 Rafał Mużyło galtgendo at o2 dot pl changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #8 from Rafał Mużyło galtgendo at o2 dot pl 2011-09-25 12:52:53 UTC --- (In reply to comment #7) And we can't inline varargs functions either. Don't use the always_inline attribute. One moment, please... Last time I've checked, I was *not* one of glibc devs. ...No, I'm still not one. There are already plenty unpleasant things Linus said about gcc optimizations, you want to add glibc users too ? Just check the previous two attachments, how the final testcase was produced. Also, if the code is incorrect, why does adding '-fipa-cp' make it suddenly correct ?
[Bug c++/50504] g++ 4.5.2 -O2 with complexdouble produces incorrect code on AMD64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50504 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 12:56:53 UTC --- Indeed 4.5.3 works for me.
[Bug c++/50504] g++ 4.5.2 -O2 with complexdouble produces incorrect code on AMD64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50504 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2011-09-25 13:21:43 UTC --- The bug reproduces for me with the 4.5.3 release, but not with the latest 4.5 weekly snapshot, 4.5-20110922.
[Bug c++/50504] g++ 4.5.2 -O2 with complexdouble produces incorrect code on AMD64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50504 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 13:30:28 UTC --- Actually I tried 179164, not 4.5.3 proper, sorry. The fix must be very recent, then.
[Bug c/50506] gcc fails at assembly with -O1 while inlining is forced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50506 --- Comment #9 from Rafał Mużyło galtgendo at o2 dot pl 2011-09-25 13:33:42 UTC --- What I'm trying to say is that gcc should either: - accept the code even with -fno-ipa-cp - reject the code even with -fipa-cp - print better diagnostics, if -fipa-cp should be the magic switch to make the code work
[Bug c/50506] gcc fails at assembly with -O1 while inlining is forced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50506 --- Comment #10 from Rafał Mużyło galtgendo at o2 dot pl 2011-09-25 13:51:14 UTC --- So, I ran one more test: gcc-4.6.1 -O2 -Wall -c -o fprintf-mini-bug-4.6.o fprintf-mini-bug-4.6.i -fno-align-functions -fno-align-jumps -fno-align-labels -fno-align-loops -fno-caller-saves -fno-crossjumping -fno-cse-follow-jumps -fno-devirtualize -fno-expensive-optimizations -fno-gcse -fno-inline-small-functions -fno-ipa-cp -fno-ipa-sra -fno-optimize-register-move -fno-optimize-sibling-calls -fno-peephole2 -fno-regmove -fno-reorder-blocks -fno-reorder-functions -fno-rerun-cse-after-loop -fno-schedule-insns2 -fno-strict-aliasing -fno-thread-jumps -fno-tree-builtin-call-dce -fno-tree-pre -fno-tree-switch-conversion -fno-tree-vrp This makes '-Q --help=optimizers' output equal to '-O1' case, but the testcase from comment 2 succeeds with this command. So either '-Q --help=optimizers' output is incomplete or it's actually not any specific option that triggers the change... Well, unless there's a bug in the command line parser or a problem with the specs.
[Bug c++/44499] [4.7 Regression?] No default constructor available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499 --- Comment #20 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-25 13:57:13 UTC --- Probably this change: 2011-09-23 Jason Merrill ja...@redhat.com Core 253 - allow const objects with no initializer or user-provided default constructor if the defaulted constructor initializes all the subobjects. PR c++/20039 PR c++/42844 * class.c (default_init_uninitialized_part): New. * cp-tree.h: Declare it. * decl.c (check_for_uninitialized_const_var): Use it. * init.c (perform_member_init): Likewise. (build_new_1): Likewise. * method.c (walk_field_subobs): Likewise.
[Bug c++/44499] No default constructor available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WORKSFORME Target Milestone|--- |4.7.0 Summary|[4.7 Regression?] No|No default constructor |default constructor |available |available | --- Comment #21 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 14:11:52 UTC --- Oh, indeed. Then I guess this can be simply closed for 4.7.0, the diagnostic issue is now moot.
[Bug c++/48562] [C++0x] warn about uses of initializer_list that will lead to dangling pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48562
--- Comment #6 from Johannes Schaub schaub.johannes at googlemail dot com
2011-09-25 14:22:33 UTC ---
(In reply to comment #5)
Johannes, sorry about the dumb question: now I understand the issue decently
well - and after all boils down to adding a warning - but I'm not sure to
understand your code snippet: is it meant to crash at runtime? Trigger
valgrind
errors?
In the C++11 spec, it is said that the lifetime of the backing-up array is the
same as the lifetime of the initializer_list object which was initialized by
the array (not considering the DRs and their resolution that Jason has pointed
to). My code was just meant to test whether GCC obeys those rules.
struct X {
X(int) { cout +; }
X(X const) { cout +; }
~X() { cout -; }
};
auto *p = new initalizer_listX{1, 2, 3}; // ... not at this
delete p; // C++11 requires now at this point ...
(again not considering those DRs that revise these rules).
I think that a warning against ({...}) would be useful too
// fine
initializer_listint a{1, 2, 3};
// this is bad
initializer_listint b({1, 2, 3});
Second one is bad because it will destroy the array after initializing 'b', and
won't lengthen the lifetime (because it will use the copy/move constructor).
[Bug c++/48562] [C++0x] warn about uses of initializer_list that will lead to dangling pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48562 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|paolo.carlini at oracle dot |unassigned at gcc dot |com |gnu.org --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 14:39:07 UTC --- Ok, thanks. At the moment, I'm not really working on this.
[Bug c++/47791] finish function is using absolute value instead of the #defined one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47791 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 14:52:50 UTC --- It seems to me that the SF_* that you are mentioning actually are meant for start_preparsed_function, not for finish_function. The latter should probably have its own FF_* in cp-tree.h and the comment adjusted. At least, this is what I see in the tree now.
[Bug c++/45509] program abort after compiled with gcc-4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45509 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||INVALID --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 14:57:29 UTC --- Feedback not forthcoming.
[Bug c++/42222] GCC ooms when building KDE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||INVALID
[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||john.salmon at deshaw dot ||com --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 15:04:17 UTC --- *** Bug 40855 has been marked as a duplicate of this bug. ***
[Bug c++/40855] undefined reference to `typeinfo for __int128'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40855 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 15:04:17 UTC --- *** This bug has been marked as a duplicate of bug 43622 ***
[Bug c++/39778] Using DJGPP to compile CPP file and get failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39778 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||INVALID --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 15:05:24 UTC --- Feedback not forthcoming.
[Bug c++/41158] segfault while using PCH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41158 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||INVALID --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 15:07:18 UTC --- Feedback not forthcoming.
[Bug c++/18835] memory consumption is high for C++ testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18835 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||INVALID --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 15:08:14 UTC --- Feedback not forthcoming.
[Bug c++/48667] [ skipping N instantiation contexts ] Skips exactly those which are of interest to me
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48667 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-09-25 15:13:39 UTC --- It seems to me this is what PR44783 proposes, isn't it? It would be nice to get a maintainer to confirm the report and agree with the option name before anyone starts implementing it.
[Bug c++/44783] implement -ftemplate-backtrace-limit=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44783 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||brian.amberg at unibas dot ||ch --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 15:16:30 UTC --- *** Bug 48667 has been marked as a duplicate of this bug. ***
[Bug c++/48667] [ skipping N instantiation contexts ] Skips exactly those which are of interest to me
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48667 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 15:16:30 UTC --- Ah, ok, let's resolve as duplicate then. *** This bug has been marked as a duplicate of bug 44783 ***
[Bug c/50444] unaligned movdqa instruction after inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50444
--- Comment #1 from John Salmon john.salmon at deshaw dot com 2011-09-25
15:22:07 UTC ---
Here's a slightly smaller test case. The problem is the 'movdqa'. According
the x86-64 ABI, rsp+8 is 16-bit aligned at the entry to main, and therefore so
is %rdi when we try to execute
movdqa %xmm0, (%rdi)
resulting in segv.
thsalm...@drdlogin0039.en.desres$ cat e2.c
#include stdint.h
#include emmintrin.h
#include string.h
struct a4x32{
uint32_t v[4];
};
struct a1xm128i{
__m128i m;
};
static struct a4x32 zero () {
struct a1xm128i c1x128;
struct a4x32 c4x32;
c1x128.m = _mm_setzero_si128();
memcpy (c4x32.v[0], c1x128.m, sizeof (c4x32));
return c4x32;
}
struct S {
struct a4x32 v;
};
void method (struct S * e) {
e-v = zero ();
}
int main (int argc, char **argv) {
struct S e;
method(e);
return e.v.v[0];
}
salm...@drdlogin0039.en.desres$ desres-cleanenv -m gcc/4.6.1-23A/bin gcc -Wall
-O -std=c99 -pedantic -S e2.c
salm...@drdlogin0039.en.desres$ desres-cleanenv -m gcc/4.6.1-23A/bin gcc e2.s
salm...@drdlogin0039.en.desres$ ./a.out
Segmentation fault (core dumped)
salm...@drdlogin0039.en.desres$ cat e2.s
.filee2.c
.text
.globlmethod
.typemethod, @function
method:
.LFB522:
.cfi_startproc
pxor%xmm0, %xmm0
movdqa%xmm0, (%rdi)
ret
.cfi_endproc
.LFE522:
.sizemethod, .-method
.globlmain
.typemain, @function
main:
.LFB523:
.cfi_startproc
subq$16, %rsp
.cfi_def_cfa_offset 24
movq%rsp, %rdi
callmethod
movl(%rsp), %eax
addq$16, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE523:
.sizemain, .-main
.identGCC: (GNU) 4.6.1
.section.note.GNU-stack,,@progbits
salm...@drdlogin0039.en.desres$
[Bug c++/50504] g++ 4.5.2 -O2 with complexdouble produces incorrect code on AMD64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50504 --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2011-09-25 15:25:01 UTC --- According to my bisection, the bug started on trunk for 4.5.0 with r147851, stopped on trunk for 4.6.0 with r164136, and stopped on 4.5 branch with r175813. I can't say if those fixes are proper or just masking a latent issue.
[Bug c++/45880] Template-Methode in Shared Object not resolved when compiled with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45880 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 15:45:24 UTC --- Feedback not forthcoming.
[Bug c++/45169] C++ Hello World mudflap violations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45169 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Known to work||4.6.1, 4.7.0 Resolution||WORKSFORME --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 15:50:18 UTC --- Works for me in 4_6-branch and mainline.
[Bug c++/41966] g++ produces spurious alignment errors for prototypes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41966 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||WORKSFORME --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 15:59:13 UTC --- No errors in 4_6-branch and mainline.
[Bug c++/42032] Aliasing errors in stl_tree.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42032 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 16:01:01 UTC --- Richard, I don't think we want to keep this open, do we?
[Bug c++/42032] Aliasing errors in stl_tree.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42032 --- Comment #11 from Evan Martin evan at chromium dot org 2011-09-25 16:02:25 UTC --- I am on personal leave until 2012. If you're within Google, you can read http://www/~evanm/leave.html for more. Otherwise, for Chrome questions you can try asking t...@chromium.org, and for questions for me personally you can try mart...@danga.com.
[Bug c++/39699] No error reporting when function and variable have the same name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39699 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||WORKSFORME --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 16:04:24 UTC --- Works everywhere.
[Bug c++/39751] ICE in cp_lexer_new_from_tokens, at cp/parser.c:342
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39751 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 16:08:15 UTC --- *** Bug 46858 has been marked as a duplicate of this bug. ***
[Bug c++/46858] ICE: in cp_lexer_new_from_tokens, at cp/parser.c:464
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46858 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 16:08:15 UTC --- Duplicate. *** This bug has been marked as a duplicate of bug 39751 ***
[Bug c++/44725] -pedantic should report gcc extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44725 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||paolo.carlini at oracle dot ||com Resolution||INVALID --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 16:16:18 UTC --- That isn't an extension but an ISO Core DR, whose resolution is implemented (apparently). In such cases (hundreds) we definitely don't warn. By the way, Intel and Comeau behave exactly like GCC.
[Bug c++/41966] g++ produces spurious alignment errors for prototypes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41966 --- Comment #2 from Jens Gustedt jens.gustedt at loria dot fr 2011-09-25 16:33:05 UTC --- Just to add to the list, since this finally found some attention. The problem is also manifest for 4.5.2, only the difference is that this time the three line version at the end of the original report also have the error.
[Bug c++/41995] Incorrect point of instantiation for function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41995 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|SUSPENDED |NEW CC|gcc-bugs at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 16:49:22 UTC --- Both 225 and 993 have been resolved, as NAD and FDIS, respectively. We should analyze which are the implication for this..
[Bug c++/50512] New: surprising change in overloading resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50512 Bug #: 50512 Summary: surprising change in overloading resolution Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@mezzarobba.net The attached programm returns: 1 when compiled with g++ from the Debian package g++-4.6.1-9 (which says it is based on SVN r178501); 2 with g++-4.6.1-10 (r178746) or g++-4.6.1-11; 1 again with g++-4.6.12 (r179140) 2 with gcc-snapshot-20110924-1 (trunk r179143). I'm not 100% sure what the correct behaviour is, but the change does not look deliberate. (Could it be related to PR c++/50442?) ~$ g++ -v test.cpp Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.1-12' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.1 (Debian 4.6.1-12) COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/4.6.1/cc1plus -quiet -v -imultilib . -imultiarch x86_64-linux-gnu -D_GNU_SOURCE test.cpp -quiet -dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test -version -o /tmp/ccHeTpTX.s GNU C++ (Debian 4.6.1-12) version 4.6.1 (x86_64-linux-gnu) compiled by GNU C version 4.6.1, GMP version 5.0.2, MPFR version 3.0.1-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu ignoring nonexistent directory /usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../x86_64-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/include/c++/4.6 /usr/include/c++/4.6/x86_64-linux-gnu/. /usr/include/c++/4.6/backward /usr/lib/gcc/x86_64-linux-gnu/4.6.1/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/4.6.1/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. GNU C++ (Debian 4.6.1-12) version 4.6.1 (x86_64-linux-gnu) compiled by GNU C version 4.6.1, GMP version 5.0.2, MPFR version 3.0.1-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: a48902e2296a3dd0e51e6adfff572b1c COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' as --64 -o /tmp/ccnazg5w.o /tmp/ccHeTpTX.s COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/4.6.1/collect2 --build-id --no-add-needed --eh-frame-hdr -m elf_x86_64 --hash-style=both -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.6.1/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1 -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../.. /tmp/ccnazg5w.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/4.6.1/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu/crtn.o ~$ ./a.out || echo $? 1 ~$ g++ -v test.cpp Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.7.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 20110924-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,java,fortran,objc,obj-c++,go --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id
[Bug c++/43393] integral promotion of long bit-fields broken in gcc 4.4.0?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43393 --- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-09-25 16:51:02 UTC --- On Sun, 25 Sep 2011, paolo.carlini at oracle dot com wrote: I'm tempted to close this, then. Comment #4 raises a C issue, however, maybe Joseph wants to have a look? For C we treat long:33 as its own type, following some C90 DRs and the changes made in C99 following those DRs, and as it's wider than int it doesn't get promoted.
[Bug c++/50512] surprising change in overloading resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50512 --- Comment #1 from mm at mezzarobba dot net 2011-09-25 16:51:17 UTC --- Created attachment 25361 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25361 testcase
[Bug c++/50512] surprising change in overloading resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50512 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-25 17:05:54 UTC --- Jason, could you take a look? 4.6.0 returns 1, current 4.6 and 4.7 branches return 2
[Bug c++/34014] conversion operators misprinted in gimple dump
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34014 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||FIXED Known to fail|| --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 17:13:39 UTC --- No operator 1 anymore in .gimple.
[Bug c/50506] gcc fails at assembly with -O1 while inlining is forced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50506 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-25 17:16:16 UTC --- (In reply to comment #9) What I'm trying to say is that gcc should either: - accept the code even with -fno-ipa-cp - reject the code even with -fipa-cp - print better diagnostics, if -fipa-cp should be the magic switch to make the code work only -fipa-cp makes us see that the indirect call resolves to an always-inline function. We could issue an error whenever the out-of-line body of an always-inline function cannot be removed after optimization, but that would upset even more people.
[Bug c++/32118] ICE in c++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32118 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||paolo.carlini at oracle dot ||com Resolution||FIXED Known to fail|| --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 17:17:10 UTC --- Fixed in 4.5.x.
[Bug c++/43393] integral promotion of long bit-fields broken in gcc 4.4.0?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43393 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-25 17:19:55 UTC --- Thanks Joseph. Let's close this, then.
[Bug c/50444] unaligned movdqa instruction after inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50444 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-25 CC||hjl at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever Confirmed|0 |1
[Bug c/50506] gcc fails at assembly with -O1 while inlining is forced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50506 --- Comment #12 from Rafał Mużyło galtgendo at o2 dot pl 2011-09-25 18:02:58 UTC --- (In reply to comment #11) Does the WONTFIX resolution here mean that glibc will need a fix then ?
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #32 from Mikael Pettersson mikpe at it dot uu.se 2011-09-25 18:05:21 UTC --- (In reply to comment #31) * expmed.c (store_bit_field_1): Use the new interfaces. I'll continue trying to minimize the changeset. Of the three translation paths in store_bit_field_1 that were updated in that revision, vec_set, movstrict, and insv, only the insv path update matters for GNAT/m68k.
[Bug bootstrap/50513] New: cross configurations fail to build ipa-inline-analysis.o with -Werror
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50513 Bug #: 50513 Summary: cross configurations fail to build ipa-inline-analysis.o with -Werror Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: build Severity: major Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org Blocks: 44756 Host: x86_64-unknown-linux-gnu Target: any cross 183 of 198 configurations in contrib/config-list.mk fail to build build with this error: ../../../gcc/gcc/ipa-inline-analysis.c: In function ‘predicate_probability’: ../../../gcc/gcc/ipa-inline-analysis.c:485:8: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] ../../../gcc/gcc/ipa-inline-analysis.c: In function ‘remap_edge_change_prob’: ../../../gcc/gcc/ipa-inline-analysis.c:2356:5: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] cc1: all warnings being treated as errors (the other configurations fail for other reasons) I have used a native compiler previously bootstrapped from the same sources. I see that for the boostrap, ipa-inline-analysis.o was built once with the bootstrap compiler, and twice with the previous stage g++. For the cross-compilation, on the other hand, gcc is used (even though g++ is also available), with the additional options: -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat
[Bug c/50507] Huge amount of memory used while building GCC4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50507 --- Comment #2 from Roger Meyer fzvqedi at v dot mintemail.com 2011-09-25 19:03:05 UTC --- (In reply to comment #1) i'm using the stock gcc 4.4 that comes with debian 6 i386 compiling gcc 4.5.3 with the following options ./configure --with-newlib --with-headers=no --prefix=/ \ --disable-multilib --disable-nls --disable-shared --disable-mudflap \ --disable-libmudflap --disable-libssp --disable-libgomp \ --libdir=/lib --libexecdir=/lib --mandir=/share/man --infodir=/share/info i basically just set up a VM (without swap) using debian 6 netboot iso and installed make, gcc via apt-get, then tried to build from source.
[Bug bootstrap/50513] cross configurations fail to build ipa-inline-analysis.o with -Werror
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50513
Mikael Pettersson mikpe at it dot uu.se changed:
What|Removed |Added
CC||mikpe at it dot uu.se
--- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2011-09-25
19:22:14 UTC ---
Native builds of current trunk (mine is gcc-4.7-20110924 == r179148) also fail
in the same way, when configured with --disable-build-poststage1-with-cxx. The
reason is that PR50012 (a C++ FE diagnostics bug) causes some warnings in new
code to go undetected, until someone does a build in proper C mode.
Anyway, for this PR the fix should be:
--- gcc-4.7-20110924/gcc/ipa-inline-analysis.c.~1~ 2011-09-23
19:30:34.0 +0200
+++ gcc-4.7-20110924/gcc/ipa-inline-analysis.c 2011-09-25 20:39:45.0
+0200
@@ -482,8 +482,8 @@ predicate_probability (conditions conds,
i2 - predicate_first_dynamic_condition);
if (c-code == CHANGED
(c-operand_num
-VEC_length (inline_param_summary_t,
- inline_param_summary)))
+(int) VEC_length (inline_param_summary_t,
+ inline_param_summary)))
{
int iprob = VEC_index (inline_param_summary_t,
inline_param_summary,
@@ -2353,8 +2353,8 @@ remap_edge_change_prob (struct cgraph_ed
struct ipa_jump_func *jfunc = ipa_get_ith_jump_func (args, i);
if (jfunc-type == IPA_JF_PASS_THROUGH
(jfunc-value.pass_through.formal_id
- VEC_length (inline_param_summary_t,
- inlined_es-param)))
+ (int) VEC_length (inline_param_summary_t,
+ inlined_es-param)))
{
int prob1 = VEC_index (inline_param_summary_t,
es-param, i)-change_prob;
[Bug rtl-optimization/50489] [UPC/IA64] mis-schedule of MEM ref with -ftree-vectorize and -fschedule-insns2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50489 --- Comment #6 from Gary Funck gary at intrepid dot com 2011-09-25 19:58:58 UTC --- (In reply to comment #5) D.3059_11 = VIEW_CONVERT_EXPRshared [8] struct foo[1] *(D.3058); looks like bogus IL to me. You view D.3058, a struct of size 16, as a pointer (of size 8). I suppose you want to load D.3058.vaddr here? D.3060_12 = (shared [8] struct foo *) D.3059_11; D.3061_13 = VIEW_CONVERT_EXPRstruct upc_shared_ptr_t(D.3060_12).phase; looks bogus IL to me. It views the pointer(!?) D.3060_12 as being a struct upc_shared_ptr_t and extracts a value that is not within that pointer. But maybe I'm missing something because I don't recognize that 'shared [8]' qualification. [...] The syntax (shared [8] struct foo *) above is unique to UPC. This is a pointer to a shared' qualified object with a blocking factor (layout qualifier) of 8. This type of pointer is called a pointer-to-shared (PTS) in the UPC language definition; it is a pointer that can span nodes. On a 64-bit machine, using the sturct PTS (as opposed to packed PTS) representation it is a 16 byte quantity. Thus the casts back/forth between (shared *) and struct upc_shared_ptr_t do not violate the size assumptions of VIEW_CONVERT_EXPR(). The blocking factor (the [8] in shared [8] * above) is unique to UPC. In UPC, arrays are block distributed. This means that block 0 is on thread 0, block 1 is on thread 1 and so on. Thus, for a UPC program that is run with 2 threads, foo[0], foo[1] ... foo[7] are allocated on (have affinity to) thread 0 and foo[8], foo[9] ... foo[13] are allocated on thread 1. This blocking factor provides for the ability to cast a pointer to a block of shared storage into a regular C pointer (a local pointer) as long as the thread performing the cast has affinity to the block. What is potentially troublesome for the middle end tree optimizations and back end RTL optimizations is that these pointers-to-shared (PTS's) are fat pointers. Note that after the lowering pass (performed in upc/upc-genericize.c) that there will be no *indirections* through a PTS. Instead, indirections of a PTS in a value context will be converted into get calls, which are implemented by the UPC runtime (libupc/smp). Indirections that are the targets of assignments are translated into put calls, implemented by the UPC runtime. The lowering pass also translates UPC pointer-to-shared arithmetic operations into their equivalent operations which do not involve PTS's, but rather cast the PTS's to their representation type (struct upc_shared_ptr_t) and then operate on the component parts of the PTS. As you can see from the description of blocking factors above, the mapping of foo[i] to its (global) address requires a fairly complex arrangement of division and modulo operations. The libupc runtime is unique in that parts of it may be inlined. Inlining of the runtime is enabled at optimization levels greater than 0, or it can be explicitly inlined/not-inlined via the -fupc-inline-lib switch. The inlining is accomplished via a pre-include of a runtime header file, implemented by the upc driver. Inlining is enabled in the test case documented in this bug report. Thus, a simple assignment statement involving array indexing of a UPC shared blocked array expands into a rather complex assortment of tree code, and generated RTL. (This complexity makes it difficult to create an equivalent C test case.) After lowering, any references to shared * (pointers-to-shared) should only occur in casts to/from the representation type and in moves/copies of the PTS container. We have run into a few places where the middle end makes some assumptions about regular pointers and tries to apply those assumptions to a UPC pointer-to-shared; we have been able to exclude PTS's by adding additional checks for them -- there are not many places that we have had to do this. Perhaps that sort of pointer-specific logic is kicking in here. Arguably, the UPC lowering pass should fully lower PTS typed expressions, so that they don't end up in the tree. Potentially, a PTS hanging around in the tree doesn't meet the strict (or even not-so-strict) definition of GENERIC. Fully lowering those expressions is on our to do list. When we do that, rather than using casts, we will likely rewrite the PTS type references into references to the PTS representation type. We have shied away from this because it makes the resulting tree code even more difficult to follow, because it loses logical correspondence to the original C source statements. That said, this technique of casting a PTS to its representation type and then extracting its sub-parts has been working for quite a while on several different target architectures. However, maybe this recast of a pointer-to-shared is confusing the post-reload instruction scheduler and/or the logic that creates the MEM_REF?. We would like to see if we can find a way to make the
[Bug fortran/50514] New: gfortran should check ISHFT ISHFTC aruments (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50514 Bug #: 50514 Summary: gfortran should check ISHFT ISHFTC aruments (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! gfortran should check ISHFT ISHFTC aruments (r178939) ! gfortran should not accept SHIFTBIT_SIZE(I) print *,ishft(I=m,SHIFT=640) print *,ishftc(I=m,SHIFT=640) ! abs(SHIFT) must be = SIZE print *,ishftc(I=m,SHIFT=1,SIZE=0) end
[Bug fortran/50515] New: gfortran should not accept an external that is a common (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50515 Bug #: 50515 Summary: gfortran should not accept an external that is a common (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! gfortran should not accept an external that is a common (r178939) common/sub/ a external sub end
[Bug fortran/50516] New: gfortran must detect illegal statements in a block data (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50516 Bug #: 50516 Summary: gfortran must detect illegal statements in a block data (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! gfortran must detect illegal statements in a block data (r178939) block data common x ! illegal f(x)=x ! illegal interface end interface ! illegal 1 format() en
[Bug fortran/50517] New: gfortran must detect that actual argument type is different from dummy argument type (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50517 Bug #: 50517 Summary: gfortran must detect that actual argument type is different from dummy argument type (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! gfortran must detect that actual argument type is different from dummy argument type (r178939) module m type t integer g end type type u integer g end type end module program main use m interface subroutine sub(tfunction) use m ! this is a type(t) function type(t), external :: tfunction end subroutine end interface ! this is a type(u) function type(u), external :: ufunction call sub(ufunction) ! gfortran should emit an error message here end program
[Bug regression/50484] [4.6 regression] ia64-portbld-freebsd9.0, conftest.c:16:1: internal compiler error: Segmentation fault: 11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50484 --- Comment #2 from Anton Shterenlikht mexas at bristol dot ac.uk 2011-09-25 20:24:24 UTC --- Gerald has provided a fix for the _Unwind_FindTableEntry FreeBSD ia64 issue (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45650). With this fix, 4.7 on ia64 FreeBSD now gives the same error: checking for ia64-portbld-freebsd9.0-gcc... /usr/ports/lang/gcc47/work/build/./gcc/xgcc -B/usr/ports /lang/gcc47/work/build/./gcc/ -B/usr/local/ia64-portbld-freebsd9.0/bin/ -B/usr/local/ia64-portbld-fr eebsd9.0/lib/ -isystem /usr/local/ia64-portbld-freebsd9.0/include -isystem /usr/local/ia64-portbld-f reebsd9.0/sys-include checking for suffix of object files... configure: error: in `/usr/ports/lang/gcc47/work/build/ia64-p ortbld-freebsd9.0/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[2]: *** [configure-stage2-target-libgcc] Error 1 gmake[2]: Leaving directory `/usr/ports/lang/gcc47/work/build'
[Bug regression/50484] [4.6 regression] ia64-portbld-freebsd9.0, conftest.c:16:1: internal compiler error: Segmentation fault: 11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50484 --- Comment #3 from Anton Shterenlikht mexas at bristol dot ac.uk 2011-09-25 20:25:19 UTC --- Created attachment 25362 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25362 libgcc config.log from ia64 FreeBSD
[Bug c++/42844] const variable requires initializer / no explicitly declared default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42844 --- Comment #16 from Jason Merrill jason at gcc dot gnu.org 2011-09-25 20:29:09 UTC --- Author: jason Date: Sun Sep 25 20:29:04 2011 New Revision: 179170 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179170 Log: Core 234 - allow const objects with no initializer or user-provided default constructor if the defaulted constructor initializes all the subobjects. PR c++/20039 PR c++/42844 * class.c (default_init_uninitialized_part): New. * cp-tree.h: Declare it. * decl.c (check_for_uninitialized_const_var): Use it. * init.c (perform_member_init): Likewise. (build_new_1): Likewise. * method.c (walk_field_subobs): Likewise. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/init/const8.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/class.c branches/gcc-4_6-branch/gcc/cp/cp-tree.h branches/gcc-4_6-branch/gcc/cp/decl.c branches/gcc-4_6-branch/gcc/cp/init.c branches/gcc-4_6-branch/gcc/cp/method.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-object1.C branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/defaulted2.C branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/pr42844-2.C branches/gcc-4_6-branch/gcc/testsuite/g++.dg/init/pr42844.C branches/gcc-4_6-branch/gcc/testsuite/lib/prune.exp
[Bug c++/20039] uninitialized const in `new' of `const struct'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20039 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2011-09-25 20:29:09 UTC --- Author: jason Date: Sun Sep 25 20:29:04 2011 New Revision: 179170 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179170 Log: Core 234 - allow const objects with no initializer or user-provided default constructor if the defaulted constructor initializes all the subobjects. PR c++/20039 PR c++/42844 * class.c (default_init_uninitialized_part): New. * cp-tree.h: Declare it. * decl.c (check_for_uninitialized_const_var): Use it. * init.c (perform_member_init): Likewise. (build_new_1): Likewise. * method.c (walk_field_subobs): Likewise. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/init/const8.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/class.c branches/gcc-4_6-branch/gcc/cp/cp-tree.h branches/gcc-4_6-branch/gcc/cp/decl.c branches/gcc-4_6-branch/gcc/cp/init.c branches/gcc-4_6-branch/gcc/cp/method.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-object1.C branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/defaulted2.C branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/pr42844-2.C branches/gcc-4_6-branch/gcc/testsuite/g++.dg/init/pr42844.C branches/gcc-4_6-branch/gcc/testsuite/lib/prune.exp
[Bug c++/50518] New: repeated c++11 opaque enum declarations are invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50518
Bug #: 50518
Summary: repeated c++11 opaque enum declarations are invalid
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fab...@gcc.gnu.org
The below example should not compile:
struct B
{
enum E: int;
enum E: int;
};
Repeating opaque-enum-declarations at class scope is invalid under 9.2/1:
--
A member shall not be declared twice in the member-specification, except that a
nested class or member class template can be declared and then later defined,
and except that an enumeration can be introduced with an
opaque-enum-declaration and later redeclared with an enum-specifier.
--
However,
struct A
{
enum E: int;
enum E: int { e1 };
};
is OK.
