[Bug debug/54971] SRA pessimizes debug info by not creating debug stmts for fields without replacements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54971
--- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-29
08:36:03 UTC ---
So, beyond the creation of new debug only accesses for whole struct writes into
hole if there aren't too many holes, I wonder if SRA doesn't have
infrastructure to do aggregate assignment propagation (which could help with
the rest of the -Os -m32 issues on the committed testcase, but even for code
generation on say):
struct A { int a, b, c, d, e, f, g, h; } z;
struct B { struct A a, b, c, d, e, f, g, h; } x, y;
void
foo (void)
{
struct A a = { 1, 2, 3, 4, 5, 6, 7, 8 };
struct A b = a;
struct A c = b;
struct A d = c;
struct A e = d;
z = e;
}
void
bar (void)
{
struct B a = x;
struct B b = a;
struct B c = b;
struct B d = c;
struct B e = d;
y = e;
}
Here, with -Os both routines result in terrible inefficient code, as total
scalarization is not performed and even for these simple cases where there is
one whole aggregate store and one whole aggregate read that is dominated by the
store SRA (nor any other optimization pass, but IMHO SRA has best
infrastructure for that) doesn't attempt to optimize by doing just y = x; (and
b = x; c = x; d = x; e = x; that would be DCEd away). With -O2 only the second
routine generates terrible code. While this testcase is artificial, the
checked in testcase shows at least one level of extra aggregate assignment
happens e.g. with compound literals.
[Bug ada/53517] gnat.dg/lto14.adb FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53517 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-10-29 09:37:34 UTC --- Author: ebotcazou Date: Mon Oct 29 09:37:30 2012 New Revision: 192911 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192911 Log: PR ada/53517 * gnat.dg/lto14.adb: Skip on Solaris. Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/lto14.adb
[Bug debug/54402] [4.8 Regression] var-tracking does not scale
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-29 09:48:59 UTC --- Haven't gathered var-tracking statistics yet, but from quick glance at i686 reflect_test..import routine it looks like with LRA more memory accesses are %ebp based, while with old reload they were %esp based: - movl%eax, 84(%esp) + movl%eax, -7592(%ebp) etc. As the var-tracking problem seems to be in the memory disambiguation code (added by Alex for 4.8+ for PR49888) perhaps that could have an effect. LRA code looks shorter (reflect all_tests.go)).
[Bug target/54963] [4.8 Regression] Wrong code generated for libgfortran/generated/eoshift3_8.c on SH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54963 --- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org 2012-10-29 11:13:19 UTC --- (In reply to comment #4) (In reply to comment #3) Created attachment 28551 [details] Proposed patch This patch fixes the problem, by using 'emit_move_insn' instead of manually doing the DImode reg copy. Does the pattern in negdi_cond emit_insn (gen_negc (low_dst, low_src)); emit_label_after (skip_neg_label, emit_insn (gen_negc (high_dst, high_src))); work in the problematic situation? Perhaps I've missed something. Ugh, you're right. The negdi will go wrong if input and output regs overlap. I guess making the output operand a =r for DImode should fix the issue (as it's done in the adddi3 or subdi3 patterns). Moreover, I think it should be OK to split up the absdi pattern before reload, except for negdi_cond. I'll try that out.
[Bug middle-end/55116] New: [4.8 Regression] LRA failed to decompose ASHIFT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55116 Bug #: 55116 Summary: [4.8 Regression] LRA failed to decompose ASHIFT Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: ubiz...@gmail.com, vmaka...@redhat.com [hjl@gnu-tools-1 tmp]$ /usr/gcc-4.8.0-x32/bin/gcc -S -O2 -w -S -mx32 /export/gnu/import/git/gcc/gcc/testsuite/gcc.c-torture/execute/builtin-prefetch-3.c -maddress-mode=long /export/gnu/import/git/gcc/gcc/testsuite/gcc.c-torture/execute/builtin-prefetch-3.c: In function ‘expr_vol_global’: /export/gnu/import/git/gcc/gcc/testsuite/gcc.c-torture/execute/builtin-prefetch-3.c:100:1: internal compiler error: in gen_add2_insn, at optabs.c:4694 } ^ 0x81fe4b gen_add2_insn(rtx_def*, rtx_def*) /export/gnu/import/git/gcc/gcc/optabs.c:4694 0x7e2dc7 lra_emit_add(rtx_def*, rtx_def*, rtx_def*) /export/gnu/import/git/gcc/gcc/lra.c:314 0x7eba63 process_addr_reg /export/gnu/import/git/gcc/gcc/lra-constraints.c:1092 0x7ebeed process_address /export/gnu/import/git/gcc/gcc/lra-constraints.c:2290 0x7ef52f curr_insn_transform /export/gnu/import/git/gcc/gcc/lra-constraints.c:2656 0x7f1984 lra_constraints(bool) /export/gnu/import/git/gcc/gcc/lra-constraints.c:3407 0x7e534e lra(_IO_FILE*) /export/gnu/import/git/gcc/gcc/lra.c:2281 0x7ad7f6 do_reload /export/gnu/import/git/gcc/gcc/ira.c:4614 0x7ad7f6 rest_of_handle_reload /export/gnu/import/git/gcc/gcc/ira.c:4720 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. [hjl@gnu-tools-1 tmp]$ Breakpoint 1, lra_emit_add (x=0x71adb440, y=0x71ae41b0, z=0x71ad7b00) at /export/gnu/import/git/gcc/gcc/lra.c:313 313 emit_move_insn (x, z); (gdb) call debug_rtx (x) (reg:SI 206) (gdb) call debug_rtx (y) (ashift:SI (reg:SI 96 [ glob_vol_int.22 ]) (const_int 2 [0x2])) (gdb)
[Bug preprocessor/55115] [=4.5.0 regression] missing headers as fatal breaks cproto logic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55115 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-10-29 CC||manu at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-10-29 12:54:28 UTC --- If the headers do nothing, just delete them? If the headers do something, how can you preprocess the file without the info from the headers? Please, explain why you think you need to preprocess a file ignoring missing headers, and you cannot do this simply by removing the headers before preprocessing. GCC has too many options, we should be cautious before adding more.
[Bug middle-end/55116] [4.8 Regression] LRA failed to decompose ASHIFT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55116 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-10-29 13:14:03 UTC --- ix86_decompose_address has case ASHIFT: if (index) return 0; index = XEXP (op, 0); tmp = XEXP (op, 1); if (!CONST_INT_P (tmp)) return 0; scale = INTVAL (tmp); if ((unsigned HOST_WIDE_INT) scale 3) return 0; scale = 1 scale; break;
[Bug c/51712] -Wtype-limits should not trigger for types of implementation-defined signedness
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51712 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||mikestump at comcast dot ||net --- Comment #15 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-10-29 13:25:22 UTC --- So the patch was approved and committed, basically hiding that the testcase is failing because there is a bug. Now, whoever fixes this bug has to also revert revision 191241.
[Bug tree-optimization/55111] ICE: tree check: expected ssa_name, have integer_cst in live_on_edge, at tree-vrp.c:89
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55111 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-29 CC||mpolacek at gcc dot ||gnu.org, rguenth at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2012-10-29 13:41:48 UTC --- Started with http://gcc.gnu.org/viewcvs?view=revisionrevision=191225
[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695 --- Comment #23 from Richard Biener rguenth at gcc dot gnu.org 2012-10-29 14:25:32 UTC --- Author: rguenth Date: Mon Oct 29 14:25:22 2012 New Revision: 192943 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192943 Log: 2012-10-29 Richard Guenther rguent...@suse.de PR middle-end/53695 * tracer.c (tracer): Fixup loop structure. * cfgloopmanip.c (force_single_succ_latches): Add assert. (fix_loop_structure): Re-compute loop latches and disambiguate loops with multiple latches if required. * gcc.dg/torture/pr53695.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr53695.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgloopmanip.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tracer.c
[Bug preprocessor/55115] [=4.5.0 regression] missing headers as fatal breaks cproto logic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55115 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-29 14:29:44 UTC --- (In reply to comment #1) If the headers do nothing, just delete them? If the headers do something, how can you preprocess the file without the info from the headers? That won't work, I believe cproto parses the errors produced by GCC and figures out which declarations are missing based on the errors, then creates a header containing those declarations. Adding an option just for cproto is definitely not a good idea, just fix cproto instead. The right answer seems to be to create a directory of empty files with the names of the missing headers and point GCC to it with -I then cproto can proceed as normal, and generate replacements for the empty files. Refusing to compile when a header is missing is a huge improvement on the old behaviour.
[Bug fortran/55117] New: Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 Bug #: 55117 Summary: Programs fails to read namelist (contains derived types objects) Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: pmarguin...@hotmail.com Created attachment 28553 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28553 Source code
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 --- Comment #1 from pmarguinaud at hotmail dot com 2012-10-29 14:32:32 UTC --- Created attachment 28554 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28554 Namelist
[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #24 from Richard Biener rguenth at gcc dot gnu.org 2012-10-29 14:33:08 UTC --- Fixed.
[Bug tree-optimization/55085] [4.8 regression] false positive -Warray-bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55085 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 --- Comment #2 from pmarguinaud at hotmail dot com 2012-10-29 14:34:02 UTC --- $ gfortran bat.F90 $ ./a.out At line 33 of file bat.F90 (unit = 4, file = 'NAMELIST') Fortran runtime error: Internal namelist read error I tried 4.6.1, 4.6.2 and latest snapshot of 4.7. All the same.
[Bug rtl-optimization/55092] [4.8 Regression] LRA aggravates var-tracking scalability problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55092 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug debug/55094] [4.7/4.8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2224
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55094 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||i686-pc-linux-gnu Target Milestone|--- |4.7.3
[Bug lto/55102] The options -flto and -On do not behave as described in GCC docs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55102 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-29 CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2012-10-29 14:38:24 UTC --- Yes, fact is that -O0 disables local optimizations before LTO streaming. It also disables IPA pass local analysis phase which means that even if enabling -O3 at WPA / LTRANS stages you will _not_ get IPA transforms enabled. Eventually we'd want to enable all IPA analysis phases at all -O levels...
[Bug tree-optimization/55104] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:269
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55104 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.8.0 Summary|ice in inline_call, at |[4.8 Regression] ice in |ipa-inline-transform.c:269 |inline_call, at ||ipa-inline-transform.c:269
[Bug rtl-optimization/55106] ice: Maximum number of LRA constraint passes is achieved (15)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55106 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2012-10-29 14:39:24 UTC --- Fixed.
[Bug preprocessor/55115] [=4.5.0 regression] missing headers as fatal breaks cproto logic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55115 --- Comment #3 from Pierre Poissinger pierre.poissinger at gmail dot com 2012-10-29 14:42:09 UTC --- Hi, Typically: The header is used, and contains all the 'visible' functions found in source BUT it's only needed: a) To perform real compilation: To check that function called are called correctly b) As export/header for the lib. cproto only preproc the file via -E option. Quick 'real life' example: myfuncs.h: Auto generated proto, generated out of a.c and b.c a.c: Define a(), calls b() - include 'myfuncs.h' b.c: Define b() - include 'myfuncs.h' = the include of the generated myfuncs.h file is to avoid local definitions + allow early check if functions signature changes for whatever reasons. Now - myfuncs.h being auto generated, during first build, prototyping will fail quickly due to Missing headers... This create some kind of a Chicken/Egg problem :-) If adding an option is annoying: Maybe then the 'fatal' should not be enforced if run is limited to preproc only, aka '-E' ?
[Bug rtl-optimization/55106] ice: Maximum number of LRA constraint passes is achieved (15)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55106 --- Comment #4 from Vladimir Makarov vmakarov at gcc dot gnu.org 2012-10-29 14:42:21 UTC --- Author: vmakarov Date: Mon Oct 29 14:42:05 2012 New Revision: 192944 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192944 Log: 2012-10-29 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/55106 * g++.dg/pr55106.C: New. Added: trunk/gcc/testsuite/g++.dg/pr55106.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/55108] bad compile-time evaluation of members of initialized union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55108 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||arm-linux-gnueabihf Component|c |target --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2012-10-29 14:44:21 UTC --- Works for me on x86_64.
[Bug tree-optimization/55110] [4.8 Regression] Internal compiler error in vectorizable_reduction, at tree-vect-loop.c:4633
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55110 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0 Summary|Internal compiler error in |[4.8 Regression] Internal |vectorizable_reduction, at |compiler error in |tree-vect-loop.c:4633 |vectorizable_reduction, at ||tree-vect-loop.c:4633
[Bug tree-optimization/55111] [4.8 Regression] ICE: tree check: expected ssa_name, have integer_cst in live_on_edge, at tree-vrp.c:89
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55111 Richard Biener 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 | Target Milestone|--- |4.8.0 Summary|ICE: tree check: expected |[4.8 Regression] ICE: tree |ssa_name, have integer_cst |check: expected ssa_name, |in live_on_edge, at |have integer_cst in |tree-vrp.c:89 |live_on_edge, at ||tree-vrp.c:89 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2012-10-29 14:46:08 UTC --- Mine then, even if patch and backtrace look unrelated.
[Bug lto/55112] internal compiler error: in simplify_subreg, at simplify-rtx.c:5424
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55112 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||lto Target||powerpc-eabispe --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2012-10-29 14:47:10 UTC --- Did you compile the object file with -O0?
[Bug preprocessor/55115] [=4.5.0 regression] missing headers as fatal breaks cproto logic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55115 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-10-29 14:47:12 UTC --- (In reply to comment #2) (In reply to comment #1) If the headers do nothing, just delete them? If the headers do something, how can you preprocess the file without the info from the headers? That won't work, I believe cproto parses the errors produced by GCC and figures out which declarations are missing based on the errors, then creates a header containing those declarations. That seems an odd way to generate missing declarations. Missing headers may lead to different code being compiled because of undefined macros, feature test macros, pragmas, etc. If the header is missing, then ignoring the error will produce exactly the same result as commenting out the #include. Anyway, not a bug.
[Bug lto/55113] internal compiler error: in emit_library_call_value_1, at calls.c:3739
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55113 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2012-10-29 14:48:06 UTC --- Did you compile the object files with -O0?
[Bug middle-end/55114] [4.8 Regression] gcc.dg/builtins-53.c ICEs on mips64 soft-float
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55114 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||mips64 Target Milestone|--- |4.8.0
[Bug middle-end/55116] [4.8 Regression] LRA failed to decompose ASHIFT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55116 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x32-*-* Target Milestone|--- |4.8.0
[Bug preprocessor/55115] [=4.5.0 regression] missing headers as fatal breaks cproto logic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55115 --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-10-29 14:53:24 UTC --- (In reply to comment #3) Now - myfuncs.h being auto generated, during first build, prototyping will fail quickly due to Missing headers... This create some kind of a Chicken/Egg problem :-) So do touch myfuncs.h before the first file is built. Or invoke gcc -E in a temp file for which you comment out the #include myfuncs.h. Or make cproto do any of this automatically. Or even better, use libClang http://clang.llvm.org/docs/Tooling.html to do what you want instead of parsing GCC errors, which are likely to change in unexpected ways.
[Bug preprocessor/55115] [=4.5.0 regression] missing headers as fatal breaks cproto logic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55115 Pierre Poissinger pierre.poissinger at gmail dot com changed: What|Removed |Added Status|RESOLVED|WAITING Resolution|INVALID | --- Comment #6 from Pierre Poissinger pierre.poissinger at gmail dot com 2012-10-29 14:54:40 UTC --- (In reply to comment #2) Adding an option just for cproto is definitely not a good idea, just fix cproto instead. cproto use gcc via 'gcc -E' and is actually limit itself at grabbing func signature. The right answer seems to be to create a directory of empty files with the names of the missing headers and point GCC to it with -I then cproto can proceed as normal, and generate replacements for the empty files. Yes - but that smells like a complex task to overcome a change of 'functionality' that was there for decades in nearly every compiler :-) Refusing to compile when a header is missing is a huge improvement on the old behaviour. Refuse to compile: Yes - I agree Refuse to preproc: Seems a little bit harsh... and breaks stuffs actually
[Bug preprocessor/55115] [=4.5.0 regression] missing headers as fatal breaks cproto logic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55115 --- Comment #7 from Pierre Poissinger pierre.poissinger at gmail dot com 2012-10-29 14:59:51 UTC --- (In reply to comment #4) That seems an odd way to generate missing declarations. Missing headers may lead to different code being compiled because of undefined macros, feature test macros, pragmas, etc. We don't compile... Prototyping only use the preproc result to retrieve function signatures. When compilation do occurs - headers have been generated and all is fine... If the header is missing, then ignoring the error will produce exactly the same result as commenting out the #include. Yes - but that mean to hack around to bypass a good idea.. Anyway, not a bug. That's why I say regression (it is) and enhancement :-)
[Bug preprocessor/55115] [=4.5.0 regression] missing headers as fatal breaks cproto logic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55115 --- Comment #8 from Pierre Poissinger pierre.poissinger at gmail dot com 2012-10-29 15:03:14 UTC --- (In reply to comment #5) Or even better, use libClang http://clang.llvm.org/docs/Tooling.html to do what you want instead of parsing GCC errors, which are likely to change in unexpected ways. Did GCC team told me to go on clang side to fix my gcc issues ? :-D
[Bug preprocessor/55115] [=4.5.0 regression] missing headers as fatal breaks cproto logic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55115 --- Comment #9 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-10-29 15:13:33 UTC --- (In reply to comment #8) (In reply to comment #5) Or even better, use libClang http://clang.llvm.org/docs/Tooling.html to do what you want instead of parsing GCC errors, which are likely to change in unexpected ways. Did GCC team told me to go on clang side to fix my gcc issues ? :-D Just trying to help! :-D GCC is not really ready for this type of use. But you can try to develop a gcc plugin: http://gcc.gnu.org/wiki/plugins, and contribute to GCC any functionality missing for your plugin. But I honestly think the workarounds Jonathan and I have proposed should be more than enough to fix your problem.
[Bug debug/54971] SRA pessimizes debug info by not creating debug stmts for fields without replacements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54971 --- Comment #14 from Richard Biener rguenth at gcc dot gnu.org 2012-10-29 15:19:53 UTC --- I think it has something like that, but it only is effective if there is any scalarization and the intermediate copies are turned into dead code this way. I still think we should write aggregates only accessed whole (and not address taken) into SSA form ;)
[Bug tree-optimization/55104] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:269
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55104 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #1 from Igor Zamyatin izamyatin at gmail dot com 2012-10-29 15:22:50 UTC --- Caused by r192821
[Bug preprocessor/55115] [=4.5.0 regression] missing headers as fatal breaks cproto logic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55115 --- Comment #10 from Pierre Poissinger pierre.poissinger at gmail dot com 2012-10-29 15:24:04 UTC --- No issues - made me smile :-) I know there are way around, just first tried the upstream path to see if there are any quick ways to ensure that we won't run into issues when we will finally use a more recent gcc. This was mostly due to thing in gcc doc that seems to indicate such problems are not new, aka, deps gen have 'support' for generated header files. (except that it's pretty useless for -E type of usage since it suppress preproc out): From http://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html#Preprocessor-Options -MG In conjunction with an option such as -M requesting dependency generation, -MG assumes missing header files are generated files and adds them to the dependency list without raising an error. The dependency filename is taken directly from the #include directive without prepending any path. -MG also suppresses preprocessed output, as a missing header file renders this useless. This feature is used in automatic updating of makefiles.
[Bug debug/54971] SRA pessimizes debug info by not creating debug stmts for fields without replacements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54971 --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-29 15:25:36 UTC --- The intermediate copies should be DSE-able, as shown when the #c14 testcases are changed to have a resp. x on all RHSs.
[Bug lto/55118] New: Missed forward propagation of addresses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55118 Bug #: 55118 Summary: Missed forward propagation of addresses Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: hubi...@gcc.gnu.org When compiling tramp3d we end up overestimating function bodies because many of array accesses and C++ casts are split into multiple instructions. I.e.: _3 = expr_1(D)-left_m; freq:1.00 size: 1 time: 1 Will be eliminated by inlining Accounting size:1.00, time:1.00 on new predicate:(op0 changed) (not inlined) _5 = LeafFunctorFieldUniformRectilinearMeshMeshTraits3, double, UniformRectilinearTag, CartesianTag, 3 , double, BrickView, EvalLeaf3 ::apply (_3, f_4(D)); freq:1.00 size: 4 time: 13 here left_m is IMO the first field of the structure so _3 will compile to no code and should have size 1. But I do not see why it is not an function argument. Other common pattern is _5 = MEM[(const struct Domain *)D.660972].D.123571.domain_m[i_4].D.118841; freq:3.00 size: 1 time: 1 Accounting size:1.00, time:3.00 on predicate:(true) _6 = MEM[(struct Domain *)_1(D)].D.123571.domain_m[i_4].D.118841; freq:3.00 size: 1 time: 1 Accounting size:1.00, time:3.00 on predicate:(true) _7 = MEM[(const Element_t[2] )_5]; freq:3.00 size: 1 time: 1 Accounting size:1.00, time:3.00 on predicate:(true) where _5 can be folded into _7 computation. it is easy to search for = occurences in the dump and most of them are foldable. Honza
[Bug lto/55118] Missed forward propagation of addresses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55118 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-10-29 Blocks|54776 | AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2012-10-29 15:37:53 UTC --- I will investigate what we can do. I ripped out the old propagation stuff because we miscompiled things. The first case cannot be simplified without lowering expr_1(D)-left_m to expr_1(D) which will cause issues with __builtin_object_size handling. The 2nd case is because we cannot express dereferencing _5 with TBAA type Element_t[2] when trying to inline-expand it's address. That is, MEM[(const Element_t[2] ) MEM[(const struct Domain *)D.660972].D.123571.domain_m[i_4].D.118841 ]; does not simplify because of the variable-offset address. The only case we can simplify it is if D.118841 has type Element_t[2] but this is usually not the case as far as I remember. I'll still look into the details.
[Bug ada/55119] New: Ada.Directories only handles files under 2GB
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55119 Bug #: 55119 Summary: Ada.Directories only handles files under 2GB Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: si...@pushface.org In adaint.c, __gnat_stat_to_attr says /* st_size may be 32 bits, or 64 bits which is converted to long. We don't return a useful value for files larger than 2 gigabytes in either case. */ attr-file_length = statbuf.st_size; /* all systems */ where attr-file_length is a long. This fails with large files on 64-bit filesystems (eg, Mac OS X). I _think_ that a simple fix would be, in adaint.h, to define file_attributes.file_length as a long long.
[Bug c++/55120] New: Inaccessible virtual base constructor does not prevent generation of default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55120
Bug #: 55120
Summary: Inaccessible virtual base constructor does not prevent
generation of default constructor
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ndkrem...@gmail.com
The following code should fail to compile but does not:
struct V {};
struct B : private virtual V {};
struct D : B {};
int main() {
D d;
}
According to N3376 section 12.1 paragraph 5, the defaulted default constructor
for D should be defined as deleted, as the default constructor for the virtual
base V is inaccessible from D.
[Bug gcov-profile/55121] New: ICE in if-convertion with PGO (ARM)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55121 Bug #: 55121 Summary: ICE in if-convertion with PGO (ARM) Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile AssignedTo: unassig...@gcc.gnu.org ReportedBy: christophe.l...@st.com Created attachment 28555 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28555 patch 1 Hi, As discussed in http://gcc.gnu.org/ml/gcc/2012-10/msg00330.html then http://gcc.gnu.org/ml/gcc/2012-10/msg00341.html there is an ICE when compiling SPEC2k's GAP bench with GCC for ARM using profiling data. My tests are based upon SVN rev #191819, with 4 patches (attached) submitted by Matthew Gretton-Dann. You can reproduce the ICE with: $ /cc1 -fpreprocessed eval.i -quiet -dumpbase eval.c -march=armv7-a -mtune=cortex-a9 -mthumb -mfpu=neon -mvectorize-with-neon-quad -mfloat-abi=softfp -mtls-dialect=gnu -auxbase-strip eval.o -g -O3 -version -fprofile-use=YYY -fno-common -o eval.s eval.c: In function 'Ge': eval.c:792:1: internal compiler error: in df_compact_blocks, at df-core.c:1570 0x6917c1 df_compact_blocks() /work1/lyon/Work/ARM/Linaro/sources/gcc-fsf-hot-cold-pgo/gcc/df-core.c:1570 0x62c3f6 compact_blocks() /work1/lyon/Work/ARM/Linaro/sources/gcc-fsf-hot-cold-pgo/gcc/cfg.c:165 0x659b89 relink_block_chain(bool) /work1/lyon/Work/ARM/Linaro/sources/gcc-fsf-hot-cold-pgo/gcc/cfgrtl.c:3112 0xeb7061 reorder_basic_blocks /work1/lyon/Work/ARM/Linaro/sources/gcc-fsf-hot-cold-pgo/gcc/bb-reorder.c:2172 0xeb71b8 rest_of_handle_reorder_blocks /work1/lyon/Work/ARM/Linaro/sources/gcc-fsf-hot-cold-pgo/gcc/bb-reorder.c:2237 It could be that calls to merge_blocks() in merge_if_block() should be guarded by e.g. can_merge_blocks_p (combo_bb, join_bb). Adding this line before calling merge_blocks (combo_bb, join_bb); makes the compilation succeed. However, the resulting code is still not functional but that problem may come from another module of the bench. Also attached: eval.i and eval.gcda
[Bug gcov-profile/55121] ICE in if-convertion with PGO (ARM)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55121 --- Comment #1 from christophe.lyon at st dot com 2012-10-29 16:03:16 UTC --- Created attachment 28556 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28556 patch2
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||janus at gcc dot gnu.org --- Comment #3 from janus at gcc dot gnu.org 2012-10-29 16:03:22 UTC --- I can confirm that I see the error with 4.3, 4.7 and trunk. Slightly reduced test case: *** IMPLICIT NONE TYPE TC INTEGER :: E END TYPE TYPE TB TYPE(TC) :: C INTEGER :: D END TYPE INTEGER :: A TYPE(TB) :: B(1:10) NAMELIST /N/ A, B OPEN (4,FILE='NAMELIST') READ (4,NML=N) END *** N A=12, B(1)%D=4 / *** What's funny is that the error e.g. depends on the presence of the component 'C', although it is not referenced in the namelist at all. Furthermore the error only occurs if 'A' is also in the namelist.
[Bug gcov-profile/55121] ICE in if-convertion with PGO (ARM)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55121 --- Comment #2 from christophe.lyon at st dot com 2012-10-29 16:03:56 UTC --- Created attachment 28557 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28557 patch3
[Bug gcov-profile/55121] ICE in if-convertion with PGO (ARM)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55121 --- Comment #3 from christophe.lyon at st dot com 2012-10-29 16:04:42 UTC --- Created attachment 28558 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28558 patch4
[Bug gcov-profile/55121] ICE in if-convertion with PGO (ARM)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55121 --- Comment #4 from christophe.lyon at st dot com 2012-10-29 16:05:30 UTC --- Created attachment 28559 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28559 pre-processed source
[Bug gcov-profile/55121] ICE in if-convertion with PGO (ARM)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55121 --- Comment #5 from christophe.lyon at st dot com 2012-10-29 16:06:24 UTC --- Created attachment 28560 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28560 profiling data
[Bug c++/55120] Inaccessible virtual base constructor does not prevent generation of default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55120
--- Comment #1 from Nick Krempel ndkrempel at gmail dot com 2012-10-29
16:08:49 UTC ---
Not so clear this is a bug, as the default constructor for D could be generated
in the following form:
struct D : B {
D() : B(), ::V() {}
}
Note the reference to V via the global scope, which is essential for it to
compile.
[Bug fortran/53544] Derived-type components in namelist group declaration produces error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53544 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||janus at gcc dot gnu.org Resolution||INVALID --- Comment #3 from janus at gcc dot gnu.org 2012-10-29 16:10:17 UTC --- (In reply to comment #2) I think that ct%a is a structure component and does not qualify as the name of a variable. Right. Also our error message is not worse than that of other compilers, so I think this can be closed as INVALID.
[Bug middle-end/55078] [4.8 Regression] FAIL: g++.dg/torture/pr46154.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55078 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org 2012-10-29 16:15:14 UTC --- I will have a look.
[Bug rtl-optimization/55122] New: ICE: maximum number of LRA constraint passes is achieved (15)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55122
Bug #: 55122
Summary: ICE: maximum number of LRA constraint passes is
achieved (15)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: antoine.balest...@gmail.com
Hello !
I'm using GCC 4.8.0 as of 20121029 (r192944) at -O3 and in 32 bit mode :
$ cat lra.c
int i, a;
unsigned long long b;
void f(void)
{
for(i = 0; i 15; i++)
b *= b;
b *= a ? 0 : b;
}
$ xgcc -w -O3 -m32 lra.c
lra.c: In function ‘f’:
lra.c:10:1: internal compiler error: Maximum number of LRA constraint passes is
achieved (15)
}
^
0x8e59de lra_constraints(bool)
../../srcdir/gcc/lra-constraints.c:3264
0x8d6913 lra(_IO_FILE*)
../../srcdir/gcc/lra.c:2281
0x88c38a do_reload
../../srcdir/gcc/ira.c:4624
0x88c598 rest_of_handle_reload
../../srcdir/gcc/ira.c:4736
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug middle-end/55116] [4.8 Regression] LRA failed to decompose ASHIFT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55116 --- Comment #2 from Vladimir Makarov vmakarov at gcc dot gnu.org 2012-10-29 16:37:08 UTC --- Author: vmakarov Date: Mon Oct 29 16:36:57 2012 New Revision: 192949 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192949 Log: 2012-10-29 Vladimir Makarov vmaka...@redhat.com PR middle-end/55116 * rtlanal.c (strip_address_mutation): Add SUBREG case. Modified: trunk/gcc/ChangeLog trunk/gcc/rtlanal.c
[Bug tree-optimization/55104] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:269
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55104
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #2 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-10-29 16:40:17 UTC ---
#include algorithm
#include vector
using std::vector;
bool gr(const vectorint a, const vectorint b)
{
return a.size() b.size();
}
void foo(vectorvectorint p1)
{
sort(p1.begin(), p1.end(), gr);
}
[Bug rtl-optimization/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-29 CC||dje at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #12 from David Edelsohn dje at gcc dot gnu.org 2012-10-29 16:59:08 UTC --- Confirmed. What's the status of reviewing and committing the patch?
[Bug libstdc++/55123] New: [C++11] Construction of shared_ptrconst T from unique_ptrconst T fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55123
Bug #: 55123
Summary: [C++11] Construction of shared_ptrconst T from
unique_ptrconst T fails
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: yegor.dereven...@gmail.com
Hello,
construction of a shared_ptr from a unique_ptr to a const object seems not to
work, although it should. Preprocessed file is attached.
[yegor@tomato tmp]$ cat test.cpp
#include memory
void f() {
std::unique_ptrconst int y;
std::shared_ptrconst int x = std::move(y);
}
[yegor@tomato tmp]$ g++ -c -std=c++11 -save-temps test.cpp
In file included from
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/x86_64-unknown-linux-gnu/bits/c++allocator.h:34:0,
from
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/bits/allocator.h:48,
from
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/memory:65,
from test.cpp:1:
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/ext/new_allocator.h:
In instantiation of ‘struct __gnu_cxx::new_allocatorconst int’:
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/bits/allocator.h:89:11:
required from ‘class std::allocatorconst int’
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/bits/shared_ptr_base.h:329:14:
required from ‘struct std::_Sp_counted_deleterconst int*,
std::default_deleteconst int, std::allocatorconst int,
(__gnu_cxx::_Lock_policy)2u::_My_Deleter’
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/bits/shared_ptr_base.h:374:24:
required from ‘class std::_Sp_counted_deleterconst int*,
std::default_deleteconst int, std::allocatorconst int,
(__gnu_cxx::_Lock_policy)2u’
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/bits/shared_ptr_base.h:625:39:
required from ‘static std::_Sp_counted_base_Lp*
std::__shared_count_Lp::_S_create_from_up(std::unique_ptr_Up, _Ep,
typename std::enable_if(! std::is_reference_Del::value)::type*) [with _Tp =
const int; _Del = std::default_deleteconst int; __gnu_cxx::_Lock_policy _Lp =
(__gnu_cxx::_Lock_policy)2u; typename std::enable_if(!
std::is_reference_Del::value)::type = void]’
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/bits/shared_ptr_base.h:549:43:
required from ‘std::__shared_count_Lp::__shared_count(std::unique_ptr_Up,
_Ep) [with _Tp = const int; _Del = std::default_deleteconst int;
__gnu_cxx::_Lock_policy _Lp = (__gnu_cxx::_Lock_policy)2u]’
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/bits/shared_ptr_base.h:855:4:
required from ‘std::__shared_ptr_Tp, _Lp::__shared_ptr(std::unique_ptr_Up,
_Ep) [with _Tp1 = const int; _Del = std::default_deleteconst int; _Tp =
const int; __gnu_cxx::_Lock_policy _Lp = (__gnu_cxx::_Lock_policy)2u]’
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/bits/shared_ptr.h:259:36:
required from ‘std::shared_ptr_Tp::shared_ptr(std::unique_ptr_Up, _Ep)
[with _Tp1 = const int; _Del = std::default_deleteconst int; _Tp = const
int]’
test.cpp:5:44: required from here
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/ext/new_allocator.h:83:7:
error: ‘const _Tp*
__gnu_cxx::new_allocator_Tp::address(__gnu_cxx::new_allocator_Tp::const_reference)
const [with _Tp = const int; __gnu_cxx::new_allocator_Tp::const_pointer =
const int*; __gnu_cxx::new_allocator_Tp::const_reference = const int]’
cannot be overloaded
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/ext/new_allocator.h:79:7:
error: with ‘_Tp*
__gnu_cxx::new_allocator_Tp::address(__gnu_cxx::new_allocator_Tp::reference)
const [with _Tp = const int; __gnu_cxx::new_allocator_Tp::pointer = const
int*; __gnu_cxx::new_allocator_Tp::reference = const int]’
[yegor@tomato tmp]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/src/gcc-4.7.2/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id
--with-ppl --enable-cloog-backend=isl --disable-ppl-version-check
--disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default
--enable-plugin --with-plugin-ld=ld.gold
[Bug libstdc++/55123] [C++11] Construction of shared_ptrconst T from unique_ptrconst T fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55123 --- Comment #1 from Yegor Derevenets yegor.derevenets at gmail dot com 2012-10-29 17:09:49 UTC --- Created attachment 28561 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28561 Preprocessed test.cpp
[Bug debug/54402] [4.8 Regression] var-tracking does not scale
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-29 17:13:45 UTC --- Created attachment 28562 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28562 gcc48-pr54402.patch For the go1 testcases, the issue really is that with reload the large function is not using frame pointer, while with LRA it is. And with frame pointer, the issue is that because there is the stack check bb before prologue (but, generally, any shrink wrapped function with the hfp setting prologue not in succ of entry bb) and vt_initialize was trying to be extra conservative, we wouldn't do the hfp to argp replacements, and ended up with a VALUE (for hard frame pointer in one of the blocks) with 1173 locs, mostly reverse_op of other values. This patch fixes the particular issue by not requiring the fp setter to be in the entry bb successor (and I've just in case added there a check that it doesn't trigger on fp restore). If we hit this kind of issue on some other testcase with a non-sp/hfp value, I'd say what we could do is mark somehow what locs values are reverse ops, and let functions like find_base_term or get_addr always ignore all reverse op locations (perhaps if reverse ops were guaranteed to be always at the end of the locs chain, find_base_term or get_addr could just stop on the first reverse op location). The question is how to do that, the structure contains just 3 pointers and thus there is no place to stick something on, perhaps there could be some extra location chain entry with some magic value that would be ignored or similar.
[Bug middle-end/55027] simplify vector multiplication by 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55027
--- Comment #3 from Marc Glisse glisse at gcc dot gnu.org 2012-10-29 17:17:01
UTC ---
Author: glisse
Date: Mon Oct 29 17:16:51 2012
New Revision: 192954
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192954
Log:
2012-10-29 Marc Glisse marc.gli...@inria.fr
PR middle-end/55027
gcc/
* tree.c (real_zerop, real_onep, real_twop, real_minus_onep):
Handle VECTOR_CST.
testsuite/
* gcc.dg/pr55027.c: New testcase.
Added:
trunk/gcc/testsuite/gcc.dg/pr55027.c (with props)
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c
Propchange: trunk/gcc/testsuite/gcc.dg/pr55027.c
('svn:eol-style' added)
Propchange: trunk/gcc/testsuite/gcc.dg/pr55027.c
('svn:keywords' added)
[Bug middle-end/55027] simplify vector multiplication by 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55027 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Marc Glisse glisse at gcc dot gnu.org 2012-10-29 17:20:37 UTC --- Fixed. See this email for potential bugs introduced by this patch: http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02596.html
[Bug debug/54402] [4.8 Regression] var-tracking does not scale
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-29 17:24:15 UTC --- Created attachment 28563 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28563 gcc48-pr54402-2.patch Just for completeness, I'm attaching my earlier attempt to fix the reflect/check compile time, but unfortunately that only gave speedup from around 49minutes to 19minutes. With the huge number of locs values before gcc48-pr54402.patch the problem was that find_base_term was extremely expensive, and not cached in any way. Once var-tracking finishes initialization, what is find_base_term of some value shouldn't IMHO change.
[Bug c++/55120] Inaccessible virtual base constructor does not prevent generation of default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55120 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 2012-10-29 17:42:20 UTC --- This is http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#7 which was closed as NAD saying This is what was intended but I'm not sure what this is. Jason?
[Bug libstdc++/55123] [C++11] Construction of shared_ptrconst T from unique_ptrconst T fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55123 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-10-29 AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-29 18:06:39 UTC --- This is basically the same problem as prevents std::vectorconst int, but since using an allocator for that shared_ptr(unique_ptr) constructor is an implementation detail and not required I suppose it should work. The problem is that (unlike boost::shared_ptr) we don't have separate _Sp_counted_deleter and _Sp_counted_deleter_with_allocator.
[Bug tree-optimization/55124] New: ICE in find_or_generate_expression, at tree-ssa-pre.c:2803
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55124
Bug #: 55124
Summary: ICE in find_or_generate_expression, at
tree-ssa-pre.c:2803
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: antoine.balest...@gmail.com
Using GCC 4.8.0 20121029 :
$ cat daexpr.c
int a, b;
long c;
void f2(void)
{
unsigned long k = 1;
foo(b ? k = 0 : 0);
b = ((c = b) ? (k ? : (c = 0)) : a) * c;
}
void f1(void)
{
f2();
a = b | c;
}
$ xgcc -O3 -w daexpr.c
daexpr.c: In function ‘f1’:
daexpr.c:13:6: internal compiler error: in find_or_generate_expression, at
tree-ssa-pre.c:2803
void f1(void)
^
0xb86241 find_or_generate_expression
../../srcdir/gcc/tree-ssa-pre.c:2803
0xb863cb create_expression_by_pieces
../../srcdir/gcc/tree-ssa-pre.c:2862
0xb86201 find_or_generate_expression
../../srcdir/gcc/tree-ssa-pre.c:2800
0xb863cb create_expression_by_pieces
../../srcdir/gcc/tree-ssa-pre.c:2862
0xb86f2b insert_into_preds_of_block
../../srcdir/gcc/tree-ssa-pre.c:3097
0xb87de3 do_regular_insertion
../../srcdir/gcc/tree-ssa-pre.c:3387
0xb8859b insert_aux
../../srcdir/gcc/tree-ssa-pre.c:3601
0xb885fe insert_aux
../../srcdir/gcc/tree-ssa-pre.c:3611
0xb885fe insert_aux
../../srcdir/gcc/tree-ssa-pre.c:3611
0xb886d8 insert
../../srcdir/gcc/tree-ssa-pre.c:3634
0xb8bb49 do_pre
../../srcdir/gcc/tree-ssa-pre.c:4710
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug tree-optimization/55124] ICE in find_or_generate_expression, at tree-ssa-pre.c:2803
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55124 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-10-29 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2012-10-29 18:19:50 UTC --- Mine.
[Bug rtl-optimization/55122] [4.8 Regression] ICE: maximum number of LRA constraint passes is achieved (15)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55122 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org Target Milestone|--- |4.8.0 Summary|ICE: maximum number of LRA |[4.8 Regression] ICE: |constraint passes is|maximum number of LRA |achieved (15) |constraint passes is ||achieved (15)
[Bug libstdc++/55123] [C++11] Construction of shared_ptrconst T from unique_ptrconst T fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55123
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-29
18:23:58 UTC ---
Actually the fix is trivial, we never need allocator_Tp , so can just ensure
we never instantiate allocator_Tp, then it doesn't matter if _Tp is const.
--- bits/shared_ptr_base.h.orig 2012-10-29 18:22:44.904507722 +
+++ bits/shared_ptr_base.h 2012-10-29 18:22:46.654191961 +
@@ -622,7 +622,7 @@
_S_create_from_up(std::unique_ptr_Tp, _Del __r,
typename std::enable_if!std::is_reference_Del::value::type* = 0)
{
- return new _Sp_counted_deleter_Tp*, _Del, std::allocator_Tp,
+ return new _Sp_counted_deleter_Tp*, _Del, std::allocatorvoid,
_Lp(__r.get(), __r.get_deleter());
}
@@ -633,7 +633,7 @@
{
typedef typename std::remove_reference_Del::type _Del1;
typedef std::reference_wrapper_Del1 _Del2;
- return new _Sp_counted_deleter_Tp*, _Del2, std::allocator_Tp,
+ return new _Sp_counted_deleter_Tp*, _Del2, std::allocatorvoid,
_Lp(__r.get(), std::ref(__r.get_deleter()));
}
[Bug libstdc++/55123] [C++11] Construction of shared_ptrconst T from unique_ptrconst T fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55123 --- Comment #4 from Yegor Derevenets yegor.derevenets at gmail dot com 2012-10-29 18:35:45 UTC --- Confirm, the patch works for me.
[Bug c/55125] New: declaration of the struct's array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55125
Bug #: 55125
Summary: declaration of the struct's array
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ha...@yahoo.com
Created attachment 28564
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28564
at the requests of workers :)
1. gcc version
hak1r@HPBM ~/Dropbox/progs $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --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 --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --enable-targets=all --disable-werror
--with-arch-32=i686 --with-tune=generic --enable-checking=release
--build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
2. system info
hak1r@HPBM ~/Dropbox/progs $ uname -a
Linux HPBM 3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26 21:32:50 UTC 2012 i686
i686 i386 GNU/Linux
3. and my trick
hak1r@HPBM ~/Dropbox/progs $ gcc main.c
main.c: In function ‘main’:
main.c:9:9: warning: initialization from incompatible pointer type [enabled by
default]
main.c:9:9: warning: (near initialization for ‘(anonymous)’) [enabled by
default]
main.c:9:9: warning: excess elements in scalar initializer [enabled by default]
main.c:9:9: warning: (near initialization for ‘(anonymous)’) [enabled by
default]
main.c:7:7: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions.
Preprocessed source stored into /tmp/ccUJNmU4.out file, please attach this to
your bugreport.
4. source file
main.c:
1 #include stdlib.h
2
3 int main(int argc, char **argv) {
4 const struct {
5 char foo;
6 const char **bar;
7 } baz[] = {
8 { 'a', (const char **){ NULL } },
9 { 'b', (const char **){ qux, NULL } }
10 };
11 return 0;
12 }
13
[Bug c++/55120] Inaccessible virtual base constructor does not prevent generation of default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55120 --- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-10-29 19:20:26 UTC --- (In reply to comment #2) This is http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#7 which was closed as NAD saying This is what was intended but I'm not sure what this is. Not being Jason, but this one made curious: I think the this refers to In short, it looks like a class with a virtual private base can't be derived from.. I double-checked by contacting Mike who confirmed that There's no special treatment for access in indirect virtual base classes
[Bug target/54805] __gthread* on VxWorks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54805 --- Comment #1 from rbmj at verizon dot net 2012-10-29 19:22:09 UTC --- Ping? Robert Mason
[Bug tree-optimization/55006] [4.8 Regression] aermod.f90 is miscompiled with '-m64 -O2 -funroll-loops' after revision 192526
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55006 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #3 from Igor Zamyatin izamyatin at gmail dot com 2012-10-29 19:25:26 UTC --- It's also can be seen for x86_64-unknown-linux-gnu. In particular, 447.dealII fails with -O3 and -funroll-loops
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #7 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-10-29 19:26:21 UTC --- Author: aoliva Date: Mon Oct 29 19:26:16 2012 New Revision: 192957 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192957 Log: PR debug/54693 * config/i386/i386.c (add_parameter_dependencies): Stop backward scan at the insn before the incoming head. (ix86_dependencies_evaluation_hook): Skip debug insns. Stop if first_arg is head. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #8 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-10-29 19:27:11 UTC --- Author: aoliva Date: Mon Oct 29 19:27:09 2012 New Revision: 192958 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192958 Log: PR debug/54693 * loop-unroll.c (loop_exit_at_end_p): Skip debug insns. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-unroll.c
[Bug debug/54551] DF resets some DEBUG_INSNs unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54551 --- Comment #7 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-10-29 19:27:39 UTC --- Author: aoliva Date: Mon Oct 29 19:27:31 2012 New Revision: 192959 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192959 Log: PR debug/54551 PR debug/54693 * valtrack.c (dead_debug_global_find): Accept NULL dtemp. (dead_debug_global_insert): Return new entry. (dead_debug_global_replace_temp): Return early if REG is no longer in place, or if dtemp was already substituted. (dead_debug_promote_uses): Insert for all defs and replace all debug uses at once. (dead_debug_local_finish): Release used after promotion. (dead_debug_insert_temp): Stop if dtemp is NULL. Modified: trunk/gcc/ChangeLog trunk/gcc/valtrack.c
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #9 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-10-29 19:27:39 UTC --- Author: aoliva Date: Mon Oct 29 19:27:31 2012 New Revision: 192959 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192959 Log: PR debug/54551 PR debug/54693 * valtrack.c (dead_debug_global_find): Accept NULL dtemp. (dead_debug_global_insert): Return new entry. (dead_debug_global_replace_temp): Return early if REG is no longer in place, or if dtemp was already substituted. (dead_debug_promote_uses): Insert for all defs and replace all debug uses at once. (dead_debug_local_finish): Release used after promotion. (dead_debug_insert_temp): Stop if dtemp is NULL. Modified: trunk/gcc/ChangeLog trunk/gcc/valtrack.c
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #10 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-10-29 19:36:52 UTC --- Author: aoliva Date: Mon Oct 29 19:36:47 2012 New Revision: 192961 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192961 Log: gcc/ChangeLog: PR debug/54693 * tree-ssa-threadedge.c (thread_around_empty_block): Copy debug temps from predecessor before threading. gcc/testsuite/ChangeLog: PR debug/54693 * gcc.dg/guality/pr54693.c: New. Added: trunk/gcc/testsuite/gcc.dg/guality/pr54693.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-threadedge.c
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #11 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-10-29 19:37:31 UTC --- Author: aoliva Date: Mon Oct 29 19:37:25 2012 New Revision: 192962 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192962 Log: PR debug/54693 * gcc/valtrack.c (dead_debug_insert_temp): Defer rescan of newly-emitted debug insn. Modified: trunk/gcc/ChangeLog trunk/gcc/valtrack.c
[Bug c/55125] segfault when declaration of the struct's array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55125
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2012-10-29
19:41:01 UTC ---
Can't reproduce with gcc4.7/trunk. BTW, to quash that warning, better write:
{ 'b', (const char *[]){ qux, NULL } }.
[Bug tree-optimization/55124] ICE in find_or_generate_expression, at tree-ssa-pre.c:2803
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55124 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org 2012-10-29 19:44:22 UTC --- Started with http://gcc.gnu.org/viewcvs?view=revisionrevision=189321
[Bug lto/48427] ICE: tree check: expected array_type, have pointer_type in array_ref_low_bound, at expr.c:6253
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48427 Dmitry Gorbachev d.g.gorbachev at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #3 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2012-10-29 19:47:23 UTC --- Works with GCC 4.7/4.8.
[Bug debug/38226] Configure time option --with-stabs does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38226 Dmitry Gorbachev d.g.gorbachev at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX Known to fail|| --- Comment #2 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2012-10-29 19:49:43 UTC --- No interest in this bug.
[Bug libstdc++/55123] [C++11] Construction of shared_ptrconst T from unique_ptrconst T fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55123 --- Comment #5 from Marc Glisse glisse at gcc dot gnu.org 2012-10-29 19:50:59 UTC --- The standard doesn't say anything about it, but it would also be possible to tweak one of the address overloads in allocator so there is no ambiguity when both types are the same. No idea if that's desirable though, I haven't followed the allocator work.
[Bug libstdc++/55126] New: Libstdc++-v3 fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55126 Bug #: 55126 Summary: Libstdc++-v3 fails to compile Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@verizon.net Hello everyone, libstdc++-v3 fails to compile, with the following error message: In file included from ../../../../../gcc/libstdc++-v3/src/c++98/complex_io.cc:25:0: /home/rbmj/build/powerpc-wrs-vxworks/libstdc++-v3/include/complex: In function 'std::basic_ostream_CharT, _Traits std::operator(std::basic_ostream_CharT, _Traits, const std::complex_Tp) [with _Tp = float; _CharT = char; _Traits = std::char_traitschar]': /home/rbmj/build/powerpc-wrs-vxworks/libstdc++-v3/include/complex:529:5: internal compiler error: Segmentation fault } ^ 0xa582bf crash_signal ../../gcc/gcc/toplev.c:333 0xa43264 emit_case_dispatch_table ../../gcc/gcc/stmt.c:1919 0xa4a219 expand_sjlj_dispatch_table(rtx_def*, vec_ttree_node**) ../../gcc/gcc/stmt.c:2292 0x81bde9 sjlj_emit_dispatch_table ../../gcc/gcc/except.c:1363 0x81bde9 sjlj_build_landing_pads ../../gcc/gcc/except.c:1420 0x81bde9 finish_eh_generation() ../../gcc/gcc/except.c:1454 0x784ef6 gimple_expand_cfg ../../gcc/gcc/cfgexpand.c:4600 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make[5]: *** [complex_io.lo] Error 1 This is a regression, as it successfully compiled with revision 191596, but with 192956 has the above error message. I wasn't sure whether to file this under libstdc++ or the c++ front end. Build configuration: ../gcc/configure --prefix=/usr --target=powerpc-wrs-vxworks --with-gnu-as --with-gnu-ld --with-headers --disable-shared --disable-libssp --disable-multilib --with-float=hard --enable-languages=c,c++ --enable-libstdcxx --enable-threads=vxworks --without-gconv --disable-libgomp --disable-nls --disable-libmudflap --with-cpu-PPC603 --disable-symvers
[Bug c++/55127] New: [4.8 regression] Incorrect dependent scope error with partial specialisation of non-type parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55127
Bug #: 55127
Summary: [4.8 regression] Incorrect dependent scope error
with partial specialisation of non-type parameter
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gccb...@qo.cx
The current GCC snapshot in Debian unstable seems to reject valid code (mininal
test case attached).
In a template function context, accessing a nested type of a template
instantiation of an unrelated(!) template class may be flagged as requiring a
'typename' for being a dependent scope.
AFAICS, it only happens in case of the instantiated template being partially
specialised for a non-type template parameter, like bool here:
struct some_class
{
static const bool is_valid_type = true;
};
template typename Type
, bool Valid = Type::is_valid_type
struct wrapper;
template typename Type
struct wrapper Type, true { ... };
template typename T
int fun()
{
wrapper some_class ::type x; // fails w/ 4.8.0
}
$ g++-snapshot -c -o typename-bug.o typename-bug.cpp
typename-bug.cpp: In function 'void fun()':
typename-bug.cpp:29:3: error: need 'typename' before
'wrappersome_class::type' because 'wrappersome_class' is a dependent scope
wrappersome_class::type x;
^
typename-bug.cpp:29:29: error: expected ';' before 'x'
wrappersome_class::type x;
^
typename-bug.cpp: In instantiation of 'void fun() [with T = int]':
typename-bug.cpp:34:12: required from here
typename-bug.cpp:29:3: error: dependent-name 'wrappersome_class::type' is
parsed as a non-type, but instantiation yields a type
wrappersome_class::type x;
^
typename-bug.cpp:29:3: note: say 'typename wrappersome_class::type' if a type
is meant
A possible workaround is to partially specialise via a type parameter (as shown
in the attached file with WORKAROUND being defined).
The failing GCC version reports:
Using built-in specs.
COLLECT_GCC=g++-snapshot
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/i486-linux-gnu/4.8.0/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20121008-1'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id
--with-system-zlib --disable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-snap/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-snap
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-snap
--with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-targets=all --with-arch-32=i586 --with-tune=generic
--disable-werror --enable-checking=yes --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.8.0 20121008 (experimental) [trunk revision 192192] (Debian
20121008-1)
Code is accepted by all other GCC variants in Debian testing/unstable:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.7-3'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran --prefix=/usr --program-suffix=-4.4
--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.4 --libdir=/usr/lib --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-targets=all
--with-arch-32=i586 --with-tune=generic --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.4.7 (Debian 4.4.7-3)
Using built-in specs.
COLLECT_GCC=g++-4.6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.6/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-12'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --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 --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --enable-targets=all --with-arch-32=i586
[Bug c++/55127] [4.8 regression] Incorrect dependent scope error with partial specialisation of non-type parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55127 --- Comment #1 from Philipp A. Hartmann gccbugs at qo dot cx 2012-10-29 20:17:32 UTC --- Created attachment 28565 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28565 minimal test-case (and workaround) Without WORKAROUND being defined, GCC 4.8 fails with the mentioned error message. Otherwise with WORKAROUD defined all tested versions accept the code.
[Bug c/53066] Wshadow should not warn for shadowing an extern function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53066 --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-10-29 20:17:34 UTC --- Author: manu Date: Mon Oct 29 20:17:23 2012 New Revision: 192963 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192963 Log: 2012-10-29 Manuel López-Ibáñez m...@gcc.gnu.org PR c/53066 c/ * c-decl.c (warn_if_shadowing): Do not warn if a variable shadows a function, unless the variable is a function or a pointer-to-function. gcc/ * tree.h (FUNCTION_POINTER_TYPE_P): New. testsuite/ * gcc.dg/Wshadow-4.c: New. * gcc.dg/Wshadow-4.h: New. Added: trunk/gcc/testsuite/gcc.dg/Wshadow-4.c trunk/gcc/testsuite/gcc.dg/Wshadow-4.h Modified: trunk/gcc/ChangeLog trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.h
[Bug c/53066] Wshadow should not warn for shadowing an extern function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53066 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-10-29 20:20:15 UTC --- FIXED in GCC 4.8
[Bug libstdc++/55123] [C++11] Construction of shared_ptrconst T from unique_ptrconst T fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55123 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-29 20:32:41 UTC --- I've previously considered removing the address(const_reference) overload when is_samereference,const_reference, but doing so would not help most code (e.g. std::vector) work with user-defined allocators that haven't made the same (not-required-by-the-standard) change. That wouldn't be a problem for this specific bug, as shared_ptr explicitly uses std::allocator in the relevant code, but I'd rather just use allocatorvoid instead of allocator_Tp anyway. Feel free to open an issue (either here or the LWG) suggesting a change to std::allocator ... but I'm juggling too many other things to do that change without a PR or DR to force me to do it :)
[Bug c++/55126] Libstdc++-v3 fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55126 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Component|libstdc++ |c++ --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-29 20:35:52 UTC --- if the C++ front-end segfaults it's a front-end bug (or maybe target)
[Bug middle-end/54386] Unaligned mem load wrongly generated for inlined inline/static function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54386
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Target|sh*-*-* |sh*-*-* arm*
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-10-29
Ever Confirmed|0 |1
--- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org 2012-10-29 20:38:08
UTC ---
I've checked this issue again on rev 192482. It seems to be target
independent, as it also happens on ARM.
The following:
static inline int readint (int* x)
{
return *x;
}
int test (int* x)
{
return readint (x);
}
compiles to (-O2):
test:
ldrbr3, [r0]
ldrbr1, [r0, #1]
ldrbr2, [r0, #2]
orrr3, r3, r1, asl #8
ldrbr0, [r0, #3]
orrr3, r3, r2, asl #16
orrr0, r3, r0, asl #24
bxlr
[Bug c++/55128] New: auto changes storage from .data to .rodata
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55128
Bug #: 55128
Summary: auto changes storage from .data to .rodata
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ricil...@gmail.com
This is probably related to #49673 (as in, it's probably a case which was not
fixed by the fix to that bug.) I noticed it while mucking about with
compile-time array generation.
In this little extract, a and b are identical, except that b is automatically
typed. I can't see any reason why the type wouldn't be exactly the same as a's,
and the DWARF debugging information shows them as having the same type.
However, a ends up in .rodata (expected) and b in .data (unexpected). I have a
stronger expectation which is that both would be in the same section, but I'm
pretty sure that .rodata is correct.
code:
#include array
constexpr std::arraydouble, 1 makearray(double d) {
return std::arraydouble, 1{{d}};
}
extern const std::arraydouble, 1 a = makearray(1);
extern const auto b = makearray(1);
General ASM with -O3 -S:
.file auto1.cc
.globl b
.data
.align 8
.type b, @object
.size b, 8
b:
.long 0
.long 1072693248
.globl a
.section.rodata
.align 8
.type a, @object
.size a, 8
a:
.long 0
.long 1072693248
.ident GCC: (Ubuntu/Linaro 4.7.2-4precise1) 4.7.2
.section.note.GNU-stack,,@progbits
[Bug regression/55129] New: removal of gcc-core tarballs leads to huge extraction times
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55129 Bug #: 55129 Summary: removal of gcc-core tarballs leads to huge extraction times Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: lxl...@yopmail.com now that gcc-core and all other tarballs are merged into a single, huge 83 MB bzip2 tarball, i waste serious time whenever i rebuild my linux distro in qemu. unpacking the official .bz2 tarball on qemu/mips takes nearly 2 hours (!) since it is unlikely that i could convince you to go back to the former distribution strategy, i suggest shipping the tarballs additionally in .xz format, which is 3-4 times faster to extract. i compared speeds of the official gcc 4.7.0 bzip2 tarballs vs a .xz version i made out of the former. /dev/shm $ cp ~/Downloads/gcc-4.7.2.tar.bz2 . /dev/shm $ time tar xf gcc-4.7.2.tar.bz2 real0m19.381s user0m18.866s sys 0m2.616s /dev/shm $ tar cJf gcc-4.7.2.tar.xz gcc-4.7.2 /dev/shm $ la gcc-4.7.2.tar.xz -rw-r--r-- 1 roger users 66696632 Oct 29 21:50 gcc-4.7.2.tar.xz /dev/shm $ la gcc-4.7.2.tar.bz2 -rw-r--r-- 1 roger users 82884636 Oct 29 21:44 gcc-4.7.2.tar.bz2 /dev/shm $ rm -rf gcc-4.7.2 /dev/shm $ time tar xf gcc-4.7.2.tar.xz real0m7.410s user0m7.225s sys 0m1.695s even on this high-end 3.1Ghz system the .xz version is 3 times faster. since the tarball is also a good bit smaller (66 vs 82 MB, could be further reduced by using higher compression options), i strongly suggest adding .xz to the official releases, to accommodate for the heavily increased tarball sizes.
[Bug regression/55129] removal of gcc-core tarballs leads to huge extraction times
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55129 --- Comment #1 from Roger Meyer lxllol at yopmail dot com 2012-10-29 21:19:32 UTC --- before you suggest using the .tar.gz instead: that one is 100 MB and increases download times and needed storage space significantly. .xz is the best of both world, fast extraction speeds and small tarballs.
[Bug libstdc++/55123] [C++11] Construction of shared_ptrconst T from unique_ptrconst T fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55123 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-29 21:49:31 UTC --- Author: redi Date: Mon Oct 29 21:49:19 2012 New Revision: 192964 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192964 Log: PR libstdc++/55123 * include/bits/shared_ptr_base.h (__shared_count::_S_create_from_up): Do not instantiate allocator with element_type. * testsuite/20_util/shared_ptr/cons/55123.cc: New. Added: trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/55123.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/shared_ptr_base.h
[Bug regression/55129] removal of gcc-core tarballs leads to huge extraction times
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55129 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 2012-10-29 21:56:01 UTC --- (In reply to comment #1) before you suggest using the .tar.gz instead: that one is 100 MB and increases download times and needed storage space significantly. .xz is the best of both world, fast extraction speeds and small tarballs. I think this has been suggested already, and the people in charge were not opposed to the idea. But... someone needs to step up, and offer themselves to update all the relevant scripts. Best place to offer your help is g...@gcc.gnu.org (use a clear subject line, so the people in charge will actually read your email).
[Bug libstdc++/55123] [C++11] Construction of shared_ptrconst T from unique_ptrconst T fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55123 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-29 21:56:25 UTC --- Author: redi Date: Mon Oct 29 21:56:12 2012 New Revision: 192965 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192965 Log: PR libstdc++/55123 * include/bits/shared_ptr_base.h (__shared_count::_S_create_from_up): Do not instantiate allocator with element_type. * testsuite/20_util/shared_ptr/cons/55123.cc: New. Added: branches/gcc-4_7-branch/libstdc++-v3/testsuite/20_util/shared_ptr/cons/55123.cc Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/include/bits/shared_ptr_base.h
