[Bug middle-end/57748] [4.7/4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 --- Comment #32 from Bernd Edlinger --- Ok, now I dared to propose my patch on the gcc-patches list: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00363.html as I can see now both tests fail even on gcc-4.6 (ubuntu 12.04)
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #196 from Markus Trippelsdorf --- (In reply to Jan Hubicka from comment #195) > Today there was two fixes for bugs that produce undefined symbols like one > you see. > Does the problem still exist on current mainline? Are you using profile > feedback? The problem is gone on current mainline. (And yes I'm using profile feedback.)
[Bug c++/24702] Koenig found functoid ref, but "cannot be used as a function"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24702 --- Comment #10 from Jonathan Wakely --- I wouldn't hold your breath unfortunately. There are at least two opposing views on how to "fix" ADL within the standard committee and no consensus on what (if anything) should be done.
[Bug tree-optimization/58326] [4.9 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:551
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58326 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener --- Mine.
[Bug ipa/58329] [4.9 Regression] ld: Invalid symbol type for plabel (.libs/libstdc++.lax/libc++11convenience.a/system_error.o, std::error_category::default_error_condition(int) const [clone .localalia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329 --- Comment #3 from Jan Hubicka --- > I wouldn't be surprised. > > I don't have assembler output or preprocessed source yet. There is > some alias > support in gas for HP-UX but I believe it may not work when we have a > call using > a function descriptor (plabel). On AIX David fixed the output machinery so the aliases now go well even for descriptors. There local calls don't use them. Do you think you can take a look what is needed for HPUX? We may just add target machinery to disable local aliases on targets that can't do aliases. I hoped that the targets either do not have runtime interposition in dynamic libraries or they do have working notion of alias. Thanks, Honza
[Bug middle-end/57748] [4.7/4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 --- Comment #33 from Richard Biener --- My point is that > - mode = TYPE_MODE (TREE_TYPE (tem)); > - if (TREE_CODE (tem) == MEM_REF > - && mode != BLKmode > - && ((align = get_object_alignment (tem)) > - < GET_MODE_ALIGNMENT (mode)) > - && ((icode = optab_handler (movmisalign_optab, mode)) is wrong because it asks if we can do a V2DFmode (the mode of the whole struct!) unaligned store which the backend says, yes!, and it builds a V2DFmode store for us to use. But the _access_ is V1DFmode! The access is not to 'tem' but to 'to'! Using the mode of 'tem' is just wrong to use for movmisalign.
[Bug tree-optimization/58294] [4.9 Regression] ice in update_ssa_across_abnormal_edges, at tree-inline.c:1892
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58294 Kostya Serebryany changed: What|Removed |Added CC||kcc at gcc dot gnu.org --- Comment #4 from Kostya Serebryany --- we see this while building chromium
[Bug tree-optimization/54855] Unnecessary duplication when performing scalar operation on vector element
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54855 --- Comment #8 from Marc Glisse --- Just adding a link to the latest message of the conversation, for future reference: http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00824.html
[Bug tree-optimization/58326] [4.9 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:551
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58326 --- Comment #5 from Richard Biener --- I think the issue is latent - the bitmap with changed blocks fed to rewrite_into_loop_closed_ssa is the blocks scanned for _uses_, but as far as I can see unloop sets the blocks that had a non-trivial update of their loop-father which doesn't seem to be the right set as the interesting block is not marked. Reverting the patch papers over the issue as then the cfgcleanup done passes an empty bitmap to loop-closed-ssa-rewrite which fixes up the previous mistake. Adding verify_loop_closed_ssa into rewrite_into_loop_closed_ssa shows the bogous IL is appearing after unloop_loops (loop_closed_ssa_invalidated, &irred_invalidated); /* We can not use TODO_update_ssa_no_phi because VOPS gets confused. */ if (loop_closed_ssa_invalidated && !bitmap_empty_p (loop_closed_ssa_invalidated)) rewrite_into_loop_closed_ssa (loop_closed_ssa_invalidated, TODO_update_ssa); else update_ssa (TODO_update_ssa); (just looked at the -O2 code for now)
[Bug libstdc++/51965] Redundant move constructions in heap algorithms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51965 --- Comment #9 from Marc Glisse --- Most recent discussion about this: http://gcc.gnu.org/ml/libstdc++/2013-07/msg00105.html
[Bug tree-optimization/58294] [4.9 Regression] ice in update_ssa_across_abnormal_edges, at tree-inline.c:1892
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58294 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #5 from Jan Hubicka --- Thanks, I saw this problem too while compiling chromium but then it went away and we didn't really managed to simplify it to a testcase. The problem here is that there is PHI sitting on a EH receiver (from setjmp) and we are inlining speculatively inlined call that may throw while original call didn't. It seems to be bug that is there for years. I am not quite sure what to do in this scenario sort of going out of SSA for this particular symbol and back to SSA again (that probably would go with markin it for update) Curiously enough your patch does not contain any calls that ipa-devirt would change. I am looking into it
[Bug rtl-optimization/58295] [4.8/4.9 regression] Missed zero-extension elimination in the combiner
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58295 Chung-Ju Wu changed: What|Removed |Added CC||jasonwucj at gmail dot com --- Comment #2 from Chung-Ju Wu --- (In reply to Eric Botcazou from comment #1) > combiner was indeed clever enough to do it. The QI subreg is clearly > problematic for the ARM here (and probably most RISC architectures). Yes. This problem also happens on our Andes nds32 architecture. (The 'nds32' port is still awaiting for GWP approval before it may be committed. But one can find its initial patch: http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01441.html) As long as we revert r191928, which is the fix for pr54457, and design the pattern in nds32.md to recognize the insn that combiner created, the redundant insn 10 can be eliminated.
[Bug ipa/58332] New: error: inlined_to pointer is set but no predecessors found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58332
Bug ID: 58332
Summary: error: inlined_to pointer is set but no predecessors
found
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
Target: x86_64-linux-gnu
The following testcase:
static inline int foo (int x) { return x + 1; }
__attribute__ ((__optimize__ (0))) int bar (void) { return foo (100); }
ICEs after r202187 with:
foo.c:2:71: error: inlined_to pointer is set but no predecessors found
__attribute__ ((__optimize__ (0))) int bar (void) { return foo (100); }
^
_ZL3fooi/0 (int foo(int)) @0x7f6911eac000
Type: function definition analyzed
Visibility: prevailing_def_ironly
References:
Referring:
Function int foo(int)/0 is inline copy in int bar()/1
Availability: local
Function flags: body local
Called by:
Calls:
/tmp/foo.c:2:71: internal compiler error: verify_cgraph_node failed
0x918f05 verify_cgraph_node(cgraph_node*)
/home/richards/gcc/wide-int/gcc/gcc/cgraph.c:2866
0x910531 verify_symtab_node(symtab_node_def*)
/home/richards/gcc/wide-int/gcc/gcc/symtab.c:772
0x910598 verify_symtab()
/home/richards/gcc/wide-int/gcc/gcc/symtab.c:789
0x921389 compile()
/home/richards/gcc/wide-int/gcc/gcc/cgraphunit.c:2146
0x9214b1 finalize_compilation_unit()
/home/richards/gcc/wide-int/gcc/gcc/cgraphunit.c:2209
0x697554 cp_write_global_declarations()
/home/richards/gcc/wide-int/gcc/gcc/cp/decl2.c:4364
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
I'm not saying we did the right thing before that either,
just that it didn't ICE :-)
[Bug ipa/58332] error: inlined_to pointer is set but no predecessors found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58332 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-09-06 Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jan Hubicka --- Hmm, indeed, it is a latent problem that we inlined into !optimize function. I suppose all calls should be marged as uninlinable when this happens and we are not early inlining. I will look into that.
[Bug c++/58333] New: "performance" regression when using -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58333
Bug ID: 58333
Summary: "performance" regression when using -std=c++0x
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mendola at gmail dot com
Created attachment 30753
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30753&action=edit
Preprocessed files (with and without -std=c++0x)
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-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 --disable-werror --with-arch-32=i686
--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.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
I'm attaching the preprocessed file, using or not the -std=c++0x, what you can
see in the following test case that if compiled with -std=c++0x the
"benchmarked" piece of code runs 1.5 seconds slower (8.9 seconds vs 10.4
seconds).
If in the code the "chrono" call is removed then with or without -std=c++0x the
running time are the same.
#include
#include
#include
#include
int main() {
cpu_set_t myAffinityMask;
CPU_ZERO( &myAffinityMask );
CPU_SET(0, &myAffinityMask );
sched_setaffinity(0, sizeof(myAffinityMask), &myAffinityMask);
volatile float* myMemoryA = new float[(1<<24)];
volatile float* myMemoryB = new float[(1<<24)];
struct timeval myStart;
struct timeval myStop;
struct timeval myResult;
gettimeofday(&myStart, 0);
for (size_t i = 0; i < (1<<24); ++i) {
myMemoryA[i] = i;
myMemoryB[i] = i+1;
}
delete []myMemoryA;
delete []myMemoryB;
for (size_t j = 0; j < 100; ++j) {
volatile float* myMemoryA = new float[(1<<24)];
volatile float* myMemoryB = new float[(1<<24)];
for (size_t i = 0; i < (1<<24); ++i) {
myMemoryA[i] *= sqrtf(myMemoryB[i]);
}
delete []myMemoryA;
delete []myMemoryB;
}
gettimeofday(&myStop, 0);
timersub(&myStop,&myStart,&myResult);
std::cout << "Time: " << myResult.tv_sec*1000 + myResult.tv_usec/1000.0 <<
std::endl;
boost::chrono::time_point t1 =
boost::chrono::high_resolution_clock::now();
std::cout << "t1: " << t1 << std::endl;
}
[Bug middle-end/58094] [4.9 Regression] IPA devirt testsuite errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58094 --- Comment #4 from Jan Hubicka --- Author: hubicka Date: Fri Sep 6 10:13:37 2013 New Revision: 202316 URL: http://gcc.gnu.org/viewcvs?rev=202316&root=gcc&view=rev Log: PR middle-end/58094 * cgraph.h (symtab_semantically_equivalent_p): Declare. * tree-tailcall.c: Include ipa-utils.h. (find_tail_calls): Use it. * ipa-pure-const.c (check_call): Likewise. * ipa-utils.c (recursive_call_p): New function. * ipa-utils.h (recursive_call_p): Dclare. * symtab.c (symtab_nonoverwritable_alias): Fix formatting. (symtab_semantically_equivalent_p): New function. * Makefile.in (tree-tailcall.o): Update dependencies. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/cgraph.h trunk/gcc/ipa-pure-const.c trunk/gcc/ipa-utils.c trunk/gcc/ipa-utils.h trunk/gcc/symtab.c trunk/gcc/tree-tailcall.c
[Bug rtl-optimization/58295] [4.8/4.9 regression] Missed zero-extension elimination in the combiner
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58295 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- So perhaps you should just look at combiner dump and see what insns it tried and failed to match and see if you couldn't add some of them into the affected backends.
[Bug tree-optimization/58294] [4.9 Regression] ice in update_ssa_across_abnormal_edges, at tree-inline.c:1892
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58294 --- Comment #6 from Richard Biener --- (In reply to Jan Hubicka from comment #5) > Thanks, I saw this problem too while compiling chromium but then it went > away and we didn't really managed to simplify it to a testcase. > > The problem here is that there is PHI sitting on a EH receiver (from setjmp) > and we are inlining speculatively inlined call that may throw while original > call didn't. It seems to be bug that is there for years. I am not quite sure > what to do in this scenario sort of going out of SSA for this particular > symbol and back to SSA again (that probably would go with markin it for > update) > > Curiously enough your patch does not contain any calls that ipa-devirt would > change. > > I am looking into it The fix is to preserve this "nonthrowing". That's how I made it work for the abnormal edge case. Thus, wrap it in a NOTHROW region?
[Bug fortran/58334] New: preprocessor behavior diffs under line continuation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58334 Bug ID: 58334 Summary: preprocessor behavior diffs under line continuation Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: rimvydas.jas at gmail dot com Sometimes tedious to detect, happens only on continued part of line. Look like incorrect detection of strings Not part of std, but depends on placement. Sample: $ cat def_test.F90 program foo implicit none character(len=16) :: a,b,c a="XXX" b="& &XXX" c="XXX & & XXX" write(0,*) 'a=',a,' b=',b,' c=',c endprogram foo gfortran def_test.F90 -Wall -Wextra -DXXX=program && ./a.out a=XXX b=program c=XXX program
[Bug tree-optimization/58294] [4.9 Regression] ice in update_ssa_across_abnormal_edges, at tree-inline.c:1892
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58294 --- Comment #7 from Jan Hubicka --- > The fix is to preserve this "nonthrowing". That's how I made it work Yes, this was my first tought, too. > for the abnormal edge case. Thus, wrap it in a NOTHROW region? I think we would have to invent it, since we have only must_not_throw. Let me analyze this a bit furhter. Honza
[Bug middle-end/58199] [4.9 regression] ICE in dump_type_inheritance_graph
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58199 Jan Hubicka changed: What|Removed |Added Status|NEW |RESOLVED CC||hubicka at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Jan Hubicka --- Should be fixed for some time already; we iced when graph was empty.
[Bug tree-optimization/58311] [4.9 Regression] ICE: SIGSEGV in hash_table::find_slot_with_hash() with -fdevirtualize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58311 --- Comment #2 from Jan Hubicka --- Author: hubicka Date: Fri Sep 6 10:33:48 2013 New Revision: 202317 URL: http://gcc.gnu.org/viewcvs?rev=202317&root=gcc&view=rev Log: PR tree-optimization/58311 * ipa-devirt.c (gate_ipa_devirt): Only execute when optimizing. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-devirt.c
[Bug target/58269] [4.9 Regression] ICE when building libobjc on x86_64-apple-darwin* after revision 201915
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269 --- Comment #8 from Kirill Yukhin --- Author: kyukhin Date: Fri Sep 6 10:36:30 2013 New Revision: 202318 URL: http://gcc.gnu.org/viewcvs?rev=202318&root=gcc&view=rev Log: PR target/58269 * config/i386/i386.c (ix86_conditional_register_usage): Proper initialize extended SSE registers. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug tree-optimization/58311] [4.9 Regression] ICE: SIGSEGV in hash_table::find_slot_with_hash() with -fdevirtualize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58311 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jan Hubicka --- Fixed.
[Bug ipa/58329] [4.9 Regression] ld: Invalid symbol type for plabel (.libs/libstdc++.lax/libc++11convenience.a/system_error.o, std::error_category::default_error_condition(int) const [clone .localalia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329 --- Comment #4 from Jan Hubicka --- *** Bug 58293 has been marked as a duplicate of this bug. ***
[Bug middle-end/58293] FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58293 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||hubicka at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jan Hubicka --- This will be another issue with local aliases not being output correctly on PA. Lets track it in the other PR *** This bug has been marked as a duplicate of bug 58329 ***
[Bug tree-optimization/58294] [4.9 Regression] ice in update_ssa_across_abnormal_edges, at tree-inline.c:1892
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58294 --- Comment #8 from Richard Biener --- (In reply to Jan Hubicka from comment #7) > > The fix is to preserve this "nonthrowing". That's how I made it work > > Yes, this was my first tought, too. > > > for the abnormal edge case. Thus, wrap it in a NOTHROW region? > > I think we would have to invent it, since we have only must_not_throw. > Let me analyze this a bit furhter. Well, must_not_throw would work, too. Richard. > Honza
[Bug tree-optimization/58294] [4.9 Regression] ice in update_ssa_across_abnormal_edges, at tree-inline.c:1892
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58294 --- Comment #9 from Jan Hubicka --- > Well, must_not_throw would work, too. It will wind up in producing EH receiver with terminate, probably not what we want.
[Bug target/58269] [4.9 Regression] ICE when building libobjc on x86_64-apple-darwin* after revision 201915
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269 --- Comment #9 from Iain Sandoe --- patch for the remainder of the fix posted at: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00384.html
[Bug tree-optimization/58294] [4.9 Regression] ice in update_ssa_across_abnormal_edges, at tree-inline.c:1892
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58294
--- Comment #10 from Richard Biener ---
(In reply to Jan Hubicka from comment #9)
> > Well, must_not_throw would work, too.
> It will wind up in producing EH receiver with terminate, probably not what
> we want.
I think it is. Because if you have
try
{
.
try
{
bogously-nothrow-call ();
}
catch
{
}
...
}
catch
{
... verify not from bogously-nothrow-call
}
we'll optimize away the inner try/catch and get into the wrong handler
if we try to wire things up after inlining bogously-nothrow-call.
Better terminate if the region indeed did throw (usually it's just
not optimized good enough).
[Bug target/58269] [4.9 Regression] ICE when building libobjc on x86_64-apple-darwin* after revision 201915
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269 --- Comment #10 from Paolo Carlini --- My x86_64-linux builds too are broken in libobj/sendmsg.c. Thus the issue isn't limited to *-darwin.
[Bug target/58269] [4.9 Regression] ICE when building libobjc on x86_64-apple-darwin* after revision 201915
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269 --- Comment #11 from Iain Sandoe --- (In reply to Paolo Carlini from comment #10) > My x86_64-linux builds too are broken in libobj/sendmsg.c. Thus the issue > isn't limited to *-darwin. hmm there appears to be a second issue - also showing on Darwin (perhaps related to 202286) - my test was against 202275.
[Bug target/58269] [4.9 Regression] ICE when building libobjc on x86_64-apple-darwin* after revision 201915
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug c++/58252] [4.9 Regression] ice in gimple_get_virt_method_for_binfo with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58252 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug fortran/34547] [4.8/4.9 regression] NULL(): Fortran 2003 changes, accepts invalid, ICE on invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.8.2
[Bug c++/57043] [4.7/4.8/4.9 Regression] converting overloaded complex function pow in C++11 is ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57043 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.7.4
[Bug ipa/58329] [4.9 Regression] ld: Invalid symbol type for plabel (.libs/libstdc++.lax/libc++11convenience.a/system_error.o, std::error_category::default_error_condition(int) const [clone .localalia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug target/58269] [4.9 Regression] ICE when building libobjc on x86_64-apple-darwin* after revision 201915
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269 --- Comment #12 from Paolo Carlini --- Yes, confirmed that on x86_64-linux r202286 is the culprit.
[Bug ipa/58329] [4.9 Regression] ld: Invalid symbol type for plabel (.libs/libstdc++.lax/libc++11convenience.a/system_error.o, std::error_category::default_error_condition(int) const [clone .localalia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329 --- Comment #5 from dave.anglin at bell dot net --- On 6-Sep-13, at 3:54 AM, hubicka at ucw dot cz wrote: > I hoped that the targets > either do not have runtime interposition in dynamic libraries or > they do > have working notion of alias. The PA-RISC HP-UX linker interposes import and export stubs in dynamic libraries. Whether there is a working notion of alias is somewhat unclear and involves digging into the linker code. The HP assembler doesn't support aliases. There is some support in gas. I will try to look at the testcase assembler code tonight. Dave -- John David Anglindave.ang...@bell.net
[Bug tree-optimization/58294] [4.9 Regression] ice in update_ssa_across_abnormal_edges, at tree-inline.c:1892
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58294 --- Comment #11 from Jan Hubicka --- > Better terminate if the region indeed did throw (usually it's just > not optimized good enough). I tihnk that is difference in between throw() and nothrow attribute. The first produce must not throw region and has thus code size&runtime overhead, nothrow should avoid that. (plus there is new standard way of doing nothrow now, right?)
[Bug target/58269] [4.9 Regression] ICE when building libobjc on x86_64-apple-darwin* after revision 201915
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269
--- Comment #13 from Dominique d'Humieres ---
> Yes, confirmed that on x86_64-linux r202286 is the culprit.
See pr58139 comments #6 to #11.
I have successfully bootstrapped r202312 on x86_64-apple-darwin10 with the
following patch:
--- /opt/gcc/_clean/gcc/config/i386/i386.c2013-08-28 18:59:22.0
+0200
+++ /opt/gcc/work/gcc/config/i386/i386.c2013-09-06 10:46:46.0 +0200
@@ -4218,7 +4218,7 @@ ix86_conditional_register_usage (void)
/* If AVX512F is disabled, squash the registers. */
if (! TARGET_AVX512F)
-for (i = FIRST_EXT_REX_SSE_REG; i < LAST_EXT_REX_SSE_REG; i++)
+for (i = FIRST_EXT_REX_SSE_REG; i <= LAST_EXT_REX_SSE_REG; i++)
fixed_regs[i] = call_used_regs[i] = 1, reg_names[i] = "";
}
@@ -5708,7 +5708,8 @@ ix86_function_arg_regno_p (int regno)
if (TARGET_MACHO)
{
- if (SSE_REGNO_P (regno) && TARGET_SSE)
+ if (SSE_REGNO_P (regno) && TARGET_SSE
+ && ! EXT_REX_SSE_REGNO_P (regno))
return true;
}
else
@@ -34466,7 +34467,7 @@ ix86_hard_regno_mode_ok (int regno, enum
/* OImode move is available only when AVX is enabled. */
return ((TARGET_AVX && mode == OImode)
- || VALID_AVX256_REG_MODE (mode)
+ || (TARGET_AVX && VALID_AVX256_REG_MODE (mode))
|| VALID_SSE_REG_MODE (mode)
|| VALID_SSE2_REG_MODE (mode)
|| VALID_MMX_REG_MODE (mode)
Note that the first hunk is r202318 and that without the second hunk, bootstrap
fails with
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
libiberty/md5.o differs
libiberty/regex.o differs
[Bug ipa/58329] [4.9 Regression] ld: Invalid symbol type for plabel (.libs/libstdc++.lax/libc++11convenience.a/system_error.o, std::error_category::default_error_condition(int) const [clone .localalia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329
--- Comment #6 from Jan Hubicka ---
> The PA-RISC HP-UX linker interposes import and export stubs in dynamic
> libraries.
> Whether there is a working notion of alias is somewhat unclear and
> involves digging
> into the linker code. The HP assembler doesn't support aliases.
> There is some
> support in gas.
OK, perhaps we want to disable local aliases then.
#if !defined (ASM_OUTPUT_DEF)
# if !defined(ASM_OUTPUT_WEAK_ALIAS) && !defined (ASM_WEAKEN_DECL)
error_at (DECL_SOURCE_LOCATION (decl),
"alias definitions not supported in this configuration");
return;
# else
if (!DECL_WEAK (decl))
{
if (lookup_attribute ("ifunc", DECL_ATTRIBUTES (decl)))
error_at (DECL_SOURCE_LOCATION (decl),
"ifunc is not supported in this configuration");
else
error_at (DECL_SOURCE_LOCATION (decl),
"only weak aliases are supported in this configuration");
return;
}
# endif
#endif
perhaps we want to simply check for ASM_OUTPUT_DEF in symtab and refuse
to use local aliases then? I think the other macros alow only weak aliases.
Honza
[Bug rtl-optimization/58295] [4.8/4.9 regression] Missed zero-extension elimination in the combiner
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58295
--- Comment #4 from Ling-hua Tseng ---
(In reply to Jakub Jelinek from comment #3)
> So perhaps you should just look at combiner dump and see what insns it tried
> and failed to match and see if you couldn't add some of them into the
> affected backends.
It's exactly what I did. Unfortunately, the combinder doesn't give any other
chance to eliminate that redundant zero extension. The cases tried by the
combinder are:
1. (set (reg:SI) (zero_extend:SI (plus:QI (mem:QI) (const_int
2. (set (reg:QI) (plus:QI (mem:QI) (const_int)))
3. (set (reg:QI) (plus:QI (subreg:QI) (const_int)))
4. (set (reg:CC) (compare:CC (subreg:QI) (const_int)))
5. (set (reg:CC) (compare:CC (plus:QI (mem:QI) (const_int
6. (set (reg:SI) (leu:SI (subreg:QI) (const_int)))
7. (set (reg:SI) (leu:SI (subreg:QI) (const_int)))
8. (set (reg:SI) (leu:SI (plus:QI ...)))
You know 1 & 2 are impossible to most RISC targets, and making all other ones
recognizable is lying GCC that your target supports QImode
arithmetic/comparison. Telling GCC a lie here will result in some code
generation bugs. For example, you will find a fail case in
gcc/testsuite/gcc.c-torture/execute/980617-1.c while you are running a test if
you provide a QImode comparison in the machine description. Here is the source
code of that test case:
void foo (unsigned int * p)
{
if ((signed char)(*p & 0xFF) == 17 || (signed char)(*p & 0xFF) == 18)
return;
else
abort ();
}
int main ()
{
int i = 0x30011;
foo(&i);
exit (0);
}
The MSB 16 bits contain 0x0003, and the LSB 16 bits contain 0x0011. Using -O3
to compile this code, you will find that GCC simplifies the expression '(signed
char)(*p & 0xFF) == 17 || (signed char)(*p & 0xFF) == 18' to an SImode
subtraction and a QImode comparison.The result is incorrect, because the target
only supports SImode comparisons, i.e., you actually generate an SImode
hardware instruction for the pattern of a QImode comparison, and the MSB 16-bit
is still dirty. Hence 3 ~ 8 are not the ones we can match them in the RTL
combination pass.
Therefore, we can conclude that the original case tried by the combiner is the
best way to merge/reduce the redundant zero extension insn.
[Bug middle-end/58335] New: S/390: reload vs lra regression - testcase builtin-in-setjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58335 Bug ID: 58335 Summary: S/390: reload vs lra regression - testcase builtin-in-setjmp Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: krebbel at gcc dot gnu.org The following testcase fails when compiling with LRA enabled and succeeds without LRA: FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O1 main: .LFB1: .loc 1 16 0 stmg%r6,%r15,48(%r15) .LCFI2: larl%r13,.L13 lgr%r14,%r15 aghi%r15,-240 .LCFI3: aghi%r14,-64 std%f8,0(%r14) std%f10,8(%r14) std%f12,16(%r14) std%f14,24(%r14) std%f9,32(%r14) std%f11,40(%r14) std%f13,48(%r14) std%f15,56(%r14) lgr%r11,%r15 .LCFI4: .loc 1 17 0 aghi%r15,-32 lgr%r2,%r15 aghi%r2,160 stg%r2,160(%r11) .LVL0: .loc 1 19 0 larl%r1,.LC1 mvc0(5,%r2),0(%r1) .loc 1 21 0 larl%r1,buf la%r3,176(%r11) 176+r11 is stored as framepointer stg%r3,0(%r1) larl%r3,.L4 stg%r3,8(%r1) stg%r15,24(%r1) stg%r13,32(%r1) lhi%r1,0 .loc 1 23 0 stg%r2,168(%r11) j.L5 .LVL1: .L4: .loc 1 21 0 lghi%r1,-160 la%r11,0(%r1,%r11)When restoring r11 only 160 is subtracted lhi%r1,1 .L5: .loc 1 21 0 is_stmt 0 discriminator 4 ltr%r1,%r1 je.L6 .loc 1 23 0 is_stmt 1 lhi%r0,0 larl%r1,.LC1 lg%r2,168(%r11) Wrong value loaded here clst%r1,%r2 segfault here During LRA the elimination offset for r34 %fp to r11 changes from 160 to 176. The first insn gets the update but not the second. From a first glance the reason appears to be that the insn for "lghi %r1,-160" it self is generated by a reload using a pseudo register which equals -160. This register does not seem to get the update after the offset changed.
[Bug target/58269] [4.9 Regression] ICE when building libobjc on x86_64-apple-darwin* after revision 201915
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269
--- Comment #14 from Iain Sandoe ---
(In reply to Dominique d'Humieres from comment #13)
> > Yes, confirmed that on x86_64-linux r202286 is the culprit.
>
> See pr58139 comments #6 to #11.
> @@ -34466,7 +34467,7 @@ ix86_hard_regno_mode_ok (int regno, enum
>
>/* OImode move is available only when AVX is enabled. */
>return ((TARGET_AVX && mode == OImode)
> - || VALID_AVX256_REG_MODE (mode)
> + || (TARGET_AVX && VALID_AVX256_REG_MODE (mode))
> || VALID_SSE_REG_MODE (mode)
> || VALID_SSE2_REG_MODE (mode)
> || VALID_MMX_REG_MODE (mode)
>
assuming that the patch above is applied to deal with pr58139,
Are you saying that:
- if (TARGET_MACHO)
-{
- if (SSE_REGNO_P (regno) && TARGET_SSE)
-return true;
-}
- else
-{
- if (TARGET_SSE && SSE_REGNO_P (regno)
- && (regno < FIRST_SSE_REG + SSE_REGPARM_MAX))
-return true;
-}
+ if (TARGET_SSE && SSE_REGNO_P (regno)
+ && (regno < FIRST_SSE_REG + SSE_REGPARM_MAX))
+return true;
gives a compare fail for you?
[Bug target/58269] [4.9 Regression] ICE when building libobjc on x86_64-apple-darwin* after revision 201915
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269
--- Comment #15 from Dominique d'Humieres ---
(In reply to Iain Sandoe from comment #14)
> assuming that the patch above is applied to deal with pr58139,
Indeed!
> Are you saying that:
> - if (TARGET_MACHO)
> -{
> - if (SSE_REGNO_P (regno) && TARGET_SSE)
> -return true;
> -}
> - else
> -{
> - if (TARGET_SSE && SSE_REGNO_P (regno)
> - && (regno < FIRST_SSE_REG + SSE_REGPARM_MAX))
> -return true;
> -}
> + if (TARGET_SSE && SSE_REGNO_P (regno)
> + && (regno < FIRST_SSE_REG + SSE_REGPARM_MAX))
> +return true;
> gives a compare fail for you?
No: I did not test it although the initial fix worked for me). The comparison
failures occur with r202318 and the patch for pr58139 only. These failures are
fixed by the patch
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -5708,7 +5708,8 @@ ix86_function_arg_regno_p (int regno)
if (TARGET_MACHO)
{
- if (SSE_REGNO_P (regno) && TARGET_SSE)
+ if (SSE_REGNO_P (regno) && TARGET_SSE
+ && ! EXT_REX_SSE_REGNO_P (regno))
return true;
}
else
from comment #6.
[Bug rtl-optimization/58295] [4.8/4.9 regression] Missed zero-extension elimination in the combiner
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58295 --- Comment #5 from Eric Botcazou --- > Therefore, we can conclude that the original case tried by the combiner is > the best way to merge/reduce the redundant zero extension insn. Yes and, although x86 is the dominant architecture, it shouldn't be allowed to penalize all the others. I think we should restrict the effect of r191928, in particular it makes little sense as-is if you also define PROMOTE_MODE as on most RISC architectures.
[Bug c++/58336] New: internal compiler error when using a static int for the size of a char array within a class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58336
Bug ID: 58336
Summary: internal compiler error when using a static int for
the size of a char array within a class
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: holger.brunck at keymile dot com
Hi,
I hit a compiler error when compiling the following code with g++ 4.7.2:
static int b = 5;
class A
{
public :
A();
};
A::A() {
char c[b];
}
--
This compilation example is with a powerpc cross compiler, but a x86 compiler
shows the same result.
powerpc-gcc -v -save-temps -g -c file.cpp
Using built-in specs.
COLLECT_GCC=powerpc-gcc
Target: powerpc-linux
Configured with:
/opt/eldk/build/eldk-rel-v5.4-2013-08-02-9a46fd5-powerpc/tmp/work-shared/gcc-4.7.2-r20/gcc-4.7.2/configure
--build=x86_64-linux --host=i686-eldk-linux --target=powerpc-linux
--prefix=/opt/eldk-5.4/powerpc/sysroots/i686-eldk-linux/usr
--exec_prefix=/opt/eldk-5.4/powerpc/sysroots/i686-eldk-linux/usr
--bindir=/opt/eldk-5.4/powerpc/sysroots/i686-eldk-linux/usr/bin/powerpc-linux
--sbindir=/opt/eldk-5.4/powerpc/sysroots/i686-eldk-linux/usr/bin/powerpc-linux
--libexecdir=/opt/eldk-5.4/powerpc/sysroots/i686-eldk-linux/usr/libexec/powerpc-linux
--datadir=/opt/eldk-5.4/powerpc/sysroots/i686-eldk-linux/usr/share
--sysconfdir=/opt/eldk-5.4/powerpc/sysroots/i686-eldk-linux/etc
--sharedstatedir=/opt/eldk-5.4/powerpc/sysroots/i686-eldk-linux/com
--localstatedir=/opt/eldk-5.4/powerpc/sysroots/i686-eldk-linux/var
--libdir=/opt/eldk-5.4/powerpc/sysroots/i686-eldk-linux/usr/lib/powerpc-linux
--includedir=/opt/eldk-5.4/powerpc/sysroots/i686-eldk-linux/usr/include
--oldincludedir=/opt/eldk-5.4/powerpc/sysroots/i686-eldk-linux/usr/include
--infodir=/opt/eldk-5.4/powerpc/sysroots/i686-eldk-linux/usr/share/info
--mandir=/opt/eldk-5.4/powerpc/sysroots/i686-eldk-linux/usr/share/man
--disable-silent-rules --disable-dependency-tracking
--with-libtool-sysroot=/opt/eldk/build/eldk-rel-v5.4-2013-08-02-9a46fd5-powerpc/tmp/sysroots/i686-nativesdk-eldk-linux
--with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix
--disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu
--enable-libstdcxx-pch --program-prefix=powerpc-linux- --without-local-prefix
--enable-lto --enable-libssp --disable-bootstrap --disable-libmudflap
--with-system-zlib --with-linker-hash-style=gnu --enable-linker-build-id
--with-ppl=no --with-cloog=no --enable-checking=release
--enable-cheaders=c_global
--with-gxx-include-dir=/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/include/c++
--with-build-time-tools=/opt/eldk/build/eldk-rel-v5.4-2013-08-02-9a46fd5-powerpc/tmp/sysroots/x86_64-linux/usr/powerpc-linux/bin
--with-sysroot=/opt/eldk-5.4/powerpc/sysroots/powerpc-linux
--with-build-sysroot=/opt/eldk/build/eldk-rel-v5.4-2013-08-02-9a46fd5-powerpc/tmp/sysroots/generic-powerpc
--disable-libunwind-exceptions --disable-libssp --disable-libgomp
--disable-libmudflap
--with-mpfr=/opt/eldk/build/eldk-rel-v5.4-2013-08-02-9a46fd5-powerpc/tmp/sysroots/i686-nativesdk-eldk-linux
--with-mpc=/opt/eldk/build/eldk-rel-v5.4-2013-08-02-9a46fd5-powerpc/tmp/sysroots/i686-nativesdk-eldk-linux
--enable-nls --enable-__cxa_atexit --with-long-double-128
Thread model: posix
gcc version 4.7.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-g' '-c'
/opt/keymile/ELDK/eldk_5_4-km.git/powerpc/sysroots/i686-eldk-linux/usr/bin/powerpc-linux/../../libexec/powerpc-linux/gcc/powerpc-linux/4.7.2/cc1plus
-E -quiet -v -iprefix
/opt/keymile/ELDK/eldk_5_4-km.git/powerpc/sysroots/i686-eldk-linux/usr/bin/powerpc-linux/../../lib/powerpc-linux/gcc/powerpc-linux/4.7.2/
-D_GNU_SOURCE -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux
-D__linux -Asystem=linux -Asystem=unix -Asystem=posix file.cpp -g
-fworking-directory -fpch-preprocess -o file.ii
ignoring nonexistent directory
"/opt/keymile/ELDK/eldk_5_4-km.git/powerpc/sysroots/i686-eldk-linux/usr/bin/powerpc-linux/../../lib/powerpc-linux/gcc/powerpc-linux/4.7.2/../../../../../powerpc-linux/include"
ignoring duplicate directory
"/opt/keymile/ELDK/eldk_5_4-km.git/powerpc/sysroots/i686-eldk-linux/usr/bin/powerpc-linux/../../lib/powerpc-linux/gcc/../../../lib/powerpc-linux/gcc/powerpc-linux/4.7.2/include"
ignoring duplicate directory
"/opt/keymile/ELDK/eldk_5_4-km.git/powerpc/sysroots/i686-eldk-linux/usr/bin/powerpc-linux/../../lib/powerpc-linux/gcc/../../../lib/powerpc-linux/gcc/powerpc-linux/4.7.2/include-fixed"
ignoring nonexistent directory
"/opt/keymile/ELDK/eldk_5_4-km.git/powerpc/sysroots/i686-eldk-linux/usr/bin/powerpc-linux/../../lib/powerpc-linux/gcc/../../../lib/powerpc-linux/gcc/powerpc-linux/4.7.2/../../../../../powerpc-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/keymile/ELDK
[Bug c++/58336] internal compiler error when using a static int for the size of a char array within a class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58336 --- Comment #1 from Paolo Carlini --- I can't reproduce this on x86_64 neither -m64 nor -m32
[Bug middle-end/58094] [4.9 Regression] IPA devirt testsuite errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58094 --- Comment #5 from Jan Hubicka --- Author: hubicka Date: Fri Sep 6 15:02:03 2013 New Revision: 202337 URL: http://gcc.gnu.org/viewcvs?rev=202337&root=gcc&view=rev Log: PR middle-end/58094 * ipa-inline.c (has_caller_p): New function. (want_inline_function_to_all_callers_p): Use it. (sum_callers, inline_to_all_callers): Break out from ... (ipa_inline): ... here. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c
[Bug bootstrap/58304] gcc dev branch compilation Failed at libstdc++-v3 (used gcc 4.7.3 to compile)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58304 Harsha changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #6 from Harsha --- Hi Paolo, I compiled it successfully :) The texinfo pacakge was missing. After installing it and pulling the latest revision and recompiling it. Things worked. Thanks for your support.
[Bug target/58269] [4.9 Regression] ICE when building libobjc on x86_64-apple-darwin* after revision 201915
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269 Jack Howarth changed: What|Removed |Added CC||howarth at nitro dot med.uc.edu --- Comment #16 from Jack Howarth --- Trunk still ICEs on x86_64-apple-darwin12... /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20130906/libobjc/sendmsg.c:848:1: internal compiler error: in check_rtl, at lra.c:2034 } ^ using... r202335 | hubicka | 2013-09-06 10:39:17 -0400 (Fri, 06 Sep 2013) | 3 lines * i386.c (ix86_hard_regno_mode_ok): AVX modes are valid only when AVX is enabled.
[Bug c++/19476] Missed null checking elimination with new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476 --- Comment #13 from Marc Glisse --- Without adding an attribute, can we identify those operator new that may not return 0? Is DECL_IS_OPERATOR_NEW && !TREE_NOTHROW good enough, or completely wrong? I am basing this on: "If the request succeeds, the value returned shall be a non-null pointer value (4.10)" "If an allocation function declared with a non-throwing exception-specification (15.4) fails to allocate storage, it shall return a null pointer. Any other allocation function that fails to allocate storage shall indicate failure only by throwing an exception". If the test is correct, adding one case to tree_expr_nonzero_warnv_p, gimple_stmt_nonzero_warnv_p (and maybe others as well?) should be easy.
[Bug bootstrap/54452] "no makeinfo case" in classpath/doc still fails when makeinfo is not present
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54452 Harsha changed: What|Removed |Added CC||harsha.patankar at gmail dot com --- Comment #1 from Harsha --- on ubuntu install texinfo package: sudo apt-get install texinfo Then try compiling again.
[Bug c++/19476] Missed null checking elimination with new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476 Paolo Carlini changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org| --- Comment #14 from Paolo Carlini --- In my experience, the only way to actually make progress on these old issues is actually posting a patch even if incomplete, etc, in other terms the straw-man approach: http://en.wikipedia.org/wiki/Straw_man_proposal
[Bug libstdc++/58338] New: Add noexcept to functions with a narrow contract
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338 Bug ID: 58338 Summary: Add noexcept to functions with a narrow contract Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Hello, the standard only requires a noexcept specifier on functions with a wide contract, to allow some debug implementations of functions with a narrow contract. However, it also explicitly gives permission to strengthen the exception specification of non-virtual functions. I believe libstdc++ should add noexcept whereever it can, since this is supposed to help with performance. Functions like vector::front seem like good candidates. I wouldn't mind if the debug version had a different exception specification, but that doesn't even seem necessary since libstdc++ aborts instead of throwing. https://groups.google.com/a/isocpp.org/d/msg/std-discussion/lkRyImxouC0/kZpWqI0MjXsJ
[Bug lto/58298] [4.9 regression] ICE in mentions_vars_p_field_decl, at lto/lto.c:1392
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58298
Yufeng Zhang changed:
What|Removed |Added
CC||yufeng at gcc dot gnu.org
--- Comment #3 from Yufeng Zhang ---
I briefly saw the issue on aarch64 and arm, but I think it has been fixed by
the following commit:
commit 8d4e699477b53778f0e933cb77d71e28a1e70536
Author: hubicka
Date: Mon Sep 2 14:45:06 2013 +
* lto.c (mentions_vars_p_field_decl, lto_fixup_prevailing_decls):
DECL_FIELD_OFFSET can contain an reference to variable.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@202174
138bc75d-0d04-0410-961f-82ee72b054a4
diff --git a/gcc/lto/ChangeLog b/gcc/lto/ChangeLog
index cf31c21..fe8e463 100644
--- a/gcc/lto/ChangeLog
+++ b/gcc/lto/ChangeLog
@@ -1,5 +1,10 @@
2013-08-31 Jan Hubicka
+ * lto.c (mentions_vars_p_field_decl, lto_fixup_prevailing_decls):
+ DECL_FIELD_OFFSET can contain an reference to variable.
+
+2013-08-31 Jan Hubicka
+
* lto.c (tree_with_vars): Turn into vector.
(MAYBE_REMEMBER_WITH_VARS): Change to...
(CHECK_VAR): ... this one.
diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index 1d1350b..0cea778 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -1389,7 +1389,7 @@ mentions_vars_p_field_decl (tree t)
{
if (mentions_vars_p_decl_common (t))
return true;
- CHECK_NO_VAR (DECL_FIELD_OFFSET (t));
+ CHECK_VAR (DECL_FIELD_OFFSET (t));
CHECK_NO_VAR (DECL_BIT_FIELD_TYPE (t));
CHECK_NO_VAR (DECL_QUALIFIER (t));
CHECK_NO_VAR (DECL_FIELD_BIT_OFFSET (t));
@@ -3207,7 +3207,7 @@ lto_fixup_prevailing_decls (tree t)
LTO_SET_PREVAIL (DECL_FUNCTION_PERSONALITY (t));
if (CODE_CONTAINS_STRUCT (code, TS_FIELD_DECL))
{
- LTO_NO_PREVAIL (DECL_FIELD_OFFSET (t));
+ LTO_SET_PREVAIL (DECL_FIELD_OFFSET (t));
LTO_NO_PREVAIL (DECL_BIT_FIELD_TYPE (t));
LTO_NO_PREVAIL (DECL_QUALIFIER (t));
LTO_NO_PREVAIL (DECL_FIELD_BIT_OFFSET (t));
[Bug c++/58337] New: Mangling of nullptr_t values do not follow ABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58337
Bug ID: 58337
Summary: Mangling of nullptr_t values do not follow ABI
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
The C++ ABI document (available at
http://mentorembedded.github.io/cxx-abi/abi.html#mangle.expr-primary) specifies
a mangling for the nullptr literal.
The mangling that GCC produces is not consistent with the form specified by the
ABI; namely, "LDn0E" is generated by GCC instead of "LDnE".
ICC mangles using the ABI-specified form: "LDnE".
Note that nullptr_t is not an integer type. It is contrary to the specification
to apply the production for integer literals to a literal of type nullptr_t.
### SMALL SOURCE (main.cpp):
typedef decltype(nullptr) NullPtrType;
template void foo();
template <> void foo() { }
### ACTUAL MANGLED NAME:
> g++-4.8 -std=c++11 -c main.cpp -o main.o && nm main.o
T _Z3fooILDn0EEvv
### EXPECTED MANGLED NAME:
_Z3fooILDnEEvv
### g++ -v:
> g++-4.8 -v
Using built-in specs.
COLLECT_GCC=g++-4.8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.1-2ubuntu1~12.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64 --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.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04)
[Bug target/58269] [4.9 Regression] ICE when building libobjc on x86_64-apple-darwin* after revision 201915
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269
--- Comment #17 from Iain Sandoe ---
(In reply to Jack Howarth from comment #16)
> Trunk still ICEs on x86_64-apple-darwin12...
>
> /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20130906/libobjc/sendmsg.c:848:1:
> internal compiler error: in check_rtl, at lra.c:2034
> }
> ^
> using...
>
> r202335 | hubicka | 2013-09-06 10:39:17 -0400 (Fri, 06 Sep 2013) | 3 lines
>
> * i386.c (ix86_hard_regno_mode_ok): AVX modes are valid only when
>
> AVX is enabled.
I have 202322 built with
/* OImode move is available only when AVX is enabled. */
return ((TARGET_AVX && mode == OImode)
- || VALID_AVX256_REG_MODE (mode)
+ || (TARGET_AVX && VALID_AVX256_REG_MODE (mode))
|| VALID_SSE_REG_MODE (mode)
|| VALID_SSE2_REG_MODE (mode)
|| VALID_MMX_REG_MODE (mode)
and
- if (TARGET_MACHO)
-{
- if (SSE_REGNO_P (regno) && TARGET_SSE)
-return true;
-}
- else
-{
- if (TARGET_SSE && SSE_REGNO_P (regno)
- && (regno < FIRST_SSE_REG + SSE_REGPARM_MAX))
-return true;
-}
+ if (TARGET_SSE && SSE_REGNO_P (regno)
+ && (regno < FIRST_SSE_REG + SSE_REGPARM_MAX))
+return true;
it bootstrapped successfully and is in testing at present.
[Bug target/58269] [4.9 Regression] ICE when building libobjc on x86_64-apple-darwin* after revision 201915
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269 --- Comment #18 from Mike Stump --- On Sep 6, 2013, at 8:43 AM, howarth at nitro dot med.uc.edu wrote: >* i386.c (ix86_hard_regno_mode_ok): AVX modes are valid only when > >AVX is enabled. llvm has: // The first 8 512-bit vector arguments are passed in ZMM registers. CCIfNotVarArg>>>, just after the sse registers… conceptually, I wonder if gcc is missing that.
[Bug libstdc++/58338] Add noexcept to functions with a narrow contract
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338 --- Comment #2 from Paolo Carlini --- ... patches welcome!
[Bug c++/58201] [4.9 Regression] Undefined reference to `B::B(void const**)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58201 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot com --- Comment #12 from Paolo Carlini --- The fix caused a regression: FAIL: g++.dg/template/cond2.C -std=gnu++98 (test for warnings, line 9) FAIL: g++.dg/template/cond2.C -std=gnu++11 (test for warnings, line 9) as described here too: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00425.html I'm a bit worried, because normally we don't check in the testsuite that those messages about the instantiation point have the right line number, thus, we may well have a pretty serious diagnostic regression, beyond the specific failure.
[Bug bootstrap/58304] gcc dev branch compilation Failed at libstdc++-v3 (used gcc 4.7.3 to compile)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58304 --- Comment #7 from Paolo Carlini --- FYI, I don't think installing texinfo may have done the trick. More likely, you had a tree with temporary glitches, can happen, when many changes are committed.
[Bug target/58269] [4.9 Regression] ICE when building libobjc on x86_64-apple-darwin* after revision 201915
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269 --- Comment #21 from Mike Stump --- Don't know… I'd assume there exists a paper somewhere that says it. :-)
[Bug ipa/58329] [4.9 Regression] ld: Invalid symbol type for plabel (.libs/libstdc++.lax/libc++11convenience.a/system_error.o, std::error_category::default_error_condition(int) const [clone .localalia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329 --- Comment #8 from John David Anglin --- Created attachment 30755 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30755&action=edit Assembler output
[Bug c++/58317] Calling a method while preparing to call the constructor should be illegal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58317
--- Comment #2 from Oleg Smolsky ---
Hey Jonathan, here is a simpler and more natural way to rewrite your example:
struct A {
static int f() { return 0; }
A(int) { }
};
int main() {
A a(A::f()); // it is static!
}
So, do you happen do have a reference to the Standard? Or is it one of the
things that are not mentioned explicitly?
[Bug rtl-optimization/58295] [4.8/4.9 regression] Missed zero-extension elimination in the combiner
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58295 --- Comment #6 from H.J. Lu --- (In reply to Eric Botcazou from comment #5) > Yes and, although x86 is the dominant architecture, it shouldn't be allowed > to penalize all the others. I think we should restrict the effect of > r191928, in particular it makes little sense as-is if you also define > PROMOTE_MODE as on most RISC architectures. We can limit the transformation to (truncate:SI (op:DI (x:DI) (y:DI))).
[Bug target/58269] [4.9 Regression] ICE when building libobjc on x86_64-apple-darwin* after revision 201915
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269 --- Comment #20 from Jack Howarth --- (In reply to Iain Sandoe from comment #19) The full commit where this was added to llvm is at http://permalink.gmane.org/gmane.comp.compilers.llvm.cvs/153081 and references http://software.intel.com/en-us/intel-isa-extensions (and I assume http://download-software.intel.com/sites/default/files/319433-015.pdf).
[Bug bootstrap/58186] LTO profiledbootstrap fails in stage feedback for fortran/frontend-passes.c with "edge ... has no corresponding call_stmt"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58186
Uroš Bizjak changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|--- |FIXED
Target Milestone|--- |4.9.0
--- Comment #5 from Uroš Bizjak ---
(In reply to Jan Hubicka from comment #4)
> This ought to be fixed now. Does it still reproduce to you?
Yes, the profiledbootstrap is OK in r202335, although following patch is needed
to avoid "may be used undefined" warning:
--cut here--
Index: ipa-prop.c
===
--- ipa-prop.c (revision 202335)
+++ ipa-prop.c (working copy)
@@ -3526,7 +3526,7 @@ ipa_modify_call_arguments (struct cgraph_edge *cs,
{
tree expr, base, off;
location_t loc;
- unsigned int deref_align;
+ unsigned int deref_align = 0;
bool deref_base = false;
/* We create a new parameter out of the value of the old one, we can
--cut here--
[Bug bootstrap/58340] [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340 --- Comment #1 from Gerald Pfeifer --- Created attachment 30757 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30757&action=edit Assembly file
[Bug fortran/58339] New: ASSOCIATE construct to arrays: Wrong results (pointer to array/array descriptor issue?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58339 Bug ID: 58339 Summary: ASSOCIATE construct to arrays: Wrong results (pointer to array/array descriptor issue?) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org >From Arjen Markus, posted at https://groups.google.com/forum/#!topic/comp.lang.fortran/IMON4ZcWlCk The following program should print 1.0 0.0 2.0 0.0 etc. - and it does so with Cray ftn, pgf95 and ifort, but with gfortran, the output is mangled. I am suspicious that it will require the new array descriptor (i.e. non-element-based strides) but I might be wrong. Possibly related to PR 58085. program assoc implicit none type point real :: x, y end type point type(point), dimension(10) :: array !real, dimension(:), pointer :: x associate( x => array%x, y => array%y ) x = (/ 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0, 10.0 /) y = 0.0 end associate write(*,'(2f10.4)') array end program assoc
[Bug target/58269] [4.9 Regression] ICE when building libobjc on x86_64-apple-darwin* after revision 201915
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269 --- Comment #19 from Iain Sandoe --- (In reply to Mike Stump from comment #18) > On Sep 6, 2013, at 8:43 AM, howarth at nitro dot med.uc.edu > wrote: > >* i386.c (ix86_hard_regno_mode_ok): AVX modes are valid only when > > > >AVX is enabled. > > llvm has: > > // The first 8 512-bit vector arguments are passed in ZMM registers. > CCIfNotVarArg CCIfSubtarget<"hasAVX512()", > CCAssignToReg<[ZMM0, ZMM1, ZMM2, ZMM3, ZMM4, ZMM5, ZMM6, > ZMM7], > > just after the sse registers… conceptually, I wonder if gcc is missing that. On the basis that clang (Darwin11, Darwin12) defines the ABI - we should see about this. Presumably, this should be disabled for OS versions where gcc-4.2/gcc-4.0 are the "system compiler". As of now, the documentation does not refer to this - the web page still points to the older psABI. Is there an official update to the System V psABI covering these regs?
[Bug ipa/58329] [4.9 Regression] ld: Invalid symbol type for plabel (.libs/libstdc++.lax/libc++11convenience.a/system_error.o, std::error_category::default_error_condition(int) const [clone .localalia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329 --- Comment #7 from John David Anglin --- Created attachment 30754 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30754&action=edit Preprocessed source
[Bug libquadmath/58327] Problem of quadmath in connection with SDL2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58327
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1 from Tobias Burnus ---
(In reply to Ulrich Weber from comment #0)
> extern "C" {
> #include "quadmath.h"
> }
> #include "SDL2\SDL.h"
> #include
Does the result change if you flip the order of the include files?
[Bug libstdc++/58338] Add noexcept to functions with a narrow contract
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler --- I'm also very much in favor of this suggestion.
[Bug libstdc++/58341] Doc conflicts with standard on forbidden range of `result` in copy_backward()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58341 --- Comment #2 from Kristian Spangsege --- And more importantly, here: http://cplusplus.github.io/LWG/lwg-defects.html#1206
[Bug fortran/58331] [OOP] Bogus rank checking with explicit-/assumed-size arrays and CLASS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58331 --- Comment #1 from Tobias Burnus --- Untested patch: --- a/gcc/fortran/interface.c +++ b/gcc/fortran/interface.c @@ -2135 +2135,2 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual, - || (actual->rank != 0 && !(is_elemental || formal->attr.dimension)) + || (actual->rank != 0 && !(is_elemental || formal->attr.dimension +|| CLASS_DATA (formal)->attr.dimension))
[Bug libstdc++/58341] Doc conflicts with standard on forbidden range of `result` in copy_backward()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58341 --- Comment #1 from Kristian Spangsege --- Important related information here: http://en.cppreference.com/w/Talk:cpp/algorithm/copy_backward
[Bug libquadmath/58327] Problem of quadmath in connection with SDL2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58327 Tobias Burnus changed: What|Removed |Added Target||*-*-mingw* --- Comment #2 from Tobias Burnus --- For what it is worth: It works under x86-64 Linux with GCC 4.9. I assume that you do not link SDL2 but you just #include the file - is that correct?
[Bug c++/58317] Calling a method while preparing to call the constructor should be illegal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58317
--- Comment #3 from Oleg Smolsky ---
Also, clang gives a warning:
struct A {
int f() const { return 1000; }
A(int arg) : member(arg) { }
int member;
};
namespace {
int func(const A &a)
{
return a.f();
}
}
int main() {
A a(func(a)); // warning: variable 'a' is uninitialized when used
// within its own initialization
// [-Wuninitialized]
return a.member;
}
[Bug c++/58317] Calling a method while preparing to call the constructor should be illegal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58317 --- Comment #4 from Paolo Carlini --- If the actual topic is warning for self-initialization, or something like that, we have one or even two bugs already in Bugzilla ;)
[Bug fortran/58324] Bogus END-of-line error with list-directed I/O of file without trailing sequential record marker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58324
Tobias Burnus changed:
What|Removed |Added
Keywords||wrong-code
CC||burnus at gcc dot gnu.org,
||jvdelisle at gcc dot gnu.org
Summary|Incorrect iostat while |Bogus END-of-line error
|reading SEQUENTIAL file |with list-directed I/O of
||file without trailing
||sequential record marker
Known to fail||4.1.0, 4.9.0
--- Comment #1 from Tobias Burnus ---
Reduced test case - fails with:
Fortran runtime error: End of file
integer :: i
open(99, access='stream', form='unformatted')
write(99) "5 a"
close(99)
open(99, access='sequential', form='formatted')
read(99, *) i
end
The following happens. finish_list_read has:
if (dtp->u.p.at_eol)
{
dtp->u.p.at_eol = 0;
return;
}
err = eat_line (dtp);
if (err == LIBERROR_END)
hit_eof (dtp);
where eat_line has:
do
c = next_char (dtp);
while (c != EOF && c != '\n');
if (c == EOF)
return LIBERROR_END;
return 0;
and next_char ends with:
dtp->u.p.at_eol = (c == '\n' || c == EOF);
return c;
And hit_eof has:
generate_error (&dtp->common, LIBERROR_END, NULL);
[Bug libstdc++/58341] New: Doc conflicts with standard on forbidden range of `result` in copy_backward()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58341 Bug ID: 58341 Summary: Doc conflicts with standard on forbidden range of `result` in copy_backward() Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: kristian.spangsege at gmail dot com The documentation of copy_backward() in conflicts with the C++ standard on the forbidden range of `result`. The documentation states that `result` must not be within the range [`first`, `last`). The standard instead requires that `result` is not within the range (`first`, `last`]. It is probably just a typo. See C++11 (2011-09-01) section 25.3.1/13.
[Bug bootstrap/58340] [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-06 Ever confirmed|0 |1 --- Comment #2 from Marc Glisse --- I am seeing exactly the same on x86_64-unknown-linux-gnu (using --disable-libvtv since that is broken too).
[Bug bootstrap/58340] New: [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340 Bug ID: 58340 Summary: [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: gerald at pfeifer dot com Created attachment 30756 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30756&action=edit Preprocessed source file I started to see a new failure on my nightly amd64-unknown-freebsd8.0 tester: /scratch/tmp/gerald/gcc-HEAD/gcc/cp/pt.c: In function ‘tree_node* maybe_get_template_decl_from_type_decl(tree)’: /scratch/tmp/gerald/gcc-HEAD/gcc/cp/pt.c:7064:1: internal compiler error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623 maybe_get_template_decl_from_type_decl (tree decl) ^ This happens in stage3-bubble. /scratch/tmp/gerald/OBJ-0906-1848/./prev-gcc/xg++ -B/scratch/tmp/gerald/OBJ-0906-1848/./prev-gcc/ -B/scratch/tmp/gerald/gcc-ref8-amd64/x86_64-unknown-freebsd8.4/bin/ -nostdinc++ -B/scratch/tmp/gerald/OBJ-0906-1848/prev-x86_64-unknown-freebsd8.4/libstdc++-v3/src/.libs -B/scratch/tmp/gerald/OBJ-0906-1848/prev-x86_64-unknown-freebsd8.4/libstdc++-v3/libsupc++/.libs -I/scratch/tmp/gerald/OBJ-0906-1848/prev-x86_64-unknown-freebsd8.4/libstdc++-v3/include/x86_64-unknown-freebsd8.4 -I/scratch/tmp/gerald/OBJ-0906-1848/prev-x86_64-unknown-freebsd8.4/libstdc++-v3/include -I/scratch/tmp/gerald/gcc-HEAD/libstdc++-v3/libsupc++ -L/scratch/tmp/gerald/OBJ-0906-1848/prev-x86_64-unknown-freebsd8.4/libstdc++-v3/src/.libs -L/scratch/tmp/gerald/OBJ-0906-1848/prev-x86_64-unknown-freebsd8.4/libstdc++-v3/libsupc++/.libs -c -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -Icp -I/scratch/tmp/gerald/gcc-HEAD/gcc -I/scratch/tmp/gerald/gcc-HEAD/gcc/cp -I/scratch/tmp/gerald/gcc-HEAD/gcc/../include -I/scratch/tmp/gerald/gcc-HEAD/gcc/../libcpp/include -I/home/gerald/8-amd64/include -I/scratch/tmp/gerald/gcc-HEAD/gcc/../libdecnumber -I/scratch/tmp/gerald/gcc-HEAD/gcc/../libdecnumber/dpd -I../libdecnumber -I/scratch/tmp/gerald/gcc-HEAD/gcc/../libbacktrace /scratch/tmp/gerald/gcc-HEAD/gcc/cp/pt.c -o cp/pt.o
[Bug bootstrap/58340] [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #3 from Jeffrey A. Law --- Just to be sure, what version of the trunk are both of you using?
[Bug tree-optimization/58342] New: ICE in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58342
Bug ID: 58342
Summary: ICE in propagate_threaded_block_debug_into, at
tree-ssa-threadedge.c:623
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O2 and -O3 with -g on x86_64-linux (both 32-bit and 64-bit modes).
This is a regression from 4.8.x.
This may be the same as 58340, but I couldn't reproduce the ICE using the
testcase for 58340 (see below for pt.ii).
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130906 (experimental) [trunk revision 202308] (GCC)
$
$ gcc-trunk -m32 -O2 -c small.c
$ gcc-trunk -O2 -c small.c
$ gcc-4.8 -O2 -g -c small.c
$ gcc-trunk -O2 -g -c small.c
small.c: In function ‘main’:
small.c:8:5: internal compiler error: in propagate_threaded_block_debug_into,
at tree-ssa-threadedge.c:623
int main ()
^
0xa93f53 propagate_threaded_block_debug_into(basic_block_def*,
basic_block_def*)
../../gcc-trunk/gcc/tree-ssa-threadedge.c:623
0xa94ca2 thread_across_edge(gimple_statement_d*, edge_def*, bool,
vec*, tree_node* (*)(gimple_statement_d*,
gimple_statement_d*))
../../gcc-trunk/gcc/tree-ssa-threadedge.c:1019
0x9fcc34 dom_opt_leave_block
../../gcc-trunk/gcc/tree-ssa-dom.c:1898
0xd46ebf walk_dominator_tree(dom_walk_data*, basic_block_def*)
../../gcc-trunk/gcc/domwalk.c:241
0x9faa02 tree_ssa_dominator_optimize
../../gcc-trunk/gcc/tree-ssa-dom.c:827
0x9faa02 execute
../../gcc-trunk/gcc/tree-ssa-dom.c:951
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.
$
$
$ gcc-trunk -O2 -g -c pt.ii
$
-
int a, b, c, d;
int foo (int x, int y)
{
return y == 0 ? x : 1 % y;
}
int main ()
{
c = 0 || a;
for (;;)
b = foo (d, c) && 1;
return 0;
}
[Bug bootstrap/58340] [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340
--- Comment #4 from Zhendong Su ---
I wasn't able to reproduce the ICE using the given testcase (pt.ii) with trunk
revision 202308, but I encountered an ICE (at -O2 and -O3 with -g) in the same
source location. It's reported as 58342 with the following small reduced test:
--
int a, b, c, d;
int foo (int x, int y)
{
return y == 0 ? x : 1 % y;
}
int main ()
{
c = 0 || a;
for (;;)
b = foo (d, c) && 1;
return 0;
}
[Bug tree-optimization/58343] New: ICE in dfs_enumerate_from, at cfganal.c:1036
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58343
Bug ID: 58343
Summary: ICE in dfs_enumerate_from, at cfganal.c:1036
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O1 and above on x86_64-linux (both 32-bit and 64-bit modes).
This is a regression from 4.8.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130906 (experimental) [trunk revision 202308] (GCC)
$ gcc-trunk -O0 small.c
$ gcc-4.8 -O1 small.c
$ gcc-trunk -O1 small.c
small.c: In function ‘main’:
small.c:3:5: internal compiler error: in dfs_enumerate_from, at cfganal.c:1036
int main ()
^
0x608c4b dfs_enumerate_from(basic_block_def*, int, bool (*)(basic_block_def
const*, void const*), basic_block_def**, int, void const*)
../../gcc-trunk/gcc/cfganal.c:1036
0xa96d66 determine_bb_domination_status
../../gcc-trunk/gcc/tree-ssa-threadupdate.c:825
0xa96d66 thread_through_loop_header
../../gcc-trunk/gcc/tree-ssa-threadupdate.c:995
0xa96d66 thread_through_all_blocks(bool)
../../gcc-trunk/gcc/tree-ssa-threadupdate.c:1279
0x9fabab tree_ssa_dominator_optimize
../../gcc-trunk/gcc/tree-ssa-dom.c:849
0x9fabab execute
../../gcc-trunk/gcc/tree-ssa-dom.c:951
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.
$
-
int a;
int main ()
{
int b = a;
for (a = 1; a > 0; a--)
;
lbl:
if (b && a)
goto lbl;
return 0;
}
[Bug middle-end/58344] New: ICE with segfault at -O1 and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58344
Bug ID: 58344
Summary: ICE with segfault at -O1 and above on x86_64-linux-gnu
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O1 and above on x86_64-linux (both 32-bit and 64-bit modes).
This is a regression from 4.8.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130906 (experimental) [trunk revision 202308] (GCC)
$ gcc-trunk -O0 -c small.c
$ gcc-4.8 -O1 -c small.c
$ gcc-trunk -O1 -c small.c
small.c: In function ‘foo’:
small.c:9:7: internal compiler error: Segmentation fault
bar (a[0]);
^
0x924b2f crash_signal
../../gcc-trunk/gcc/toplev.c:335
0x6daba0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
../../gcc-trunk/gcc/expr.c:9758
0x5fc8ca expand_expr
../../gcc-trunk/gcc/expr.h:444
0x5fc8ca store_one_arg
../../gcc-trunk/gcc/calls.c:4502
0x6024f2 expand_call(tree_node*, rtx_def*, int)
../../gcc-trunk/gcc/calls.c:3042
0x6dbc2e expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
../../gcc-trunk/gcc/expr.c:10234
0x612b6f expand_call_stmt
../../gcc-trunk/gcc/cfgexpand.c:2180
0x612b6f expand_gimple_stmt_1
../../gcc-trunk/gcc/cfgexpand.c:2218
0x612b6f expand_gimple_stmt
../../gcc-trunk/gcc/cfgexpand.c:2370
0x6139b3 expand_gimple_basic_block
../../gcc-trunk/gcc/cfgexpand.c:4204
0x61557c gimple_expand_cfg
../../gcc-trunk/gcc/cfgexpand.c:4723
0x61557c execute
../../gcc-trunk/gcc/cfgexpand.c:4937
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.
$
---
struct U {};
static struct U a[1];
extern void bar (struct U);
void foo ()
{
bar (a[0]);
}
[Bug ipa/58345] New: ICE with SIGFPE at -O1 on x86_64-linux-gnu (affecting trunk and 4.8)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58345 Bug ID: 58345 Summary: ICE with SIGFPE at -O1 on x86_64-linux-gnu (affecting trunk and 4.8) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: su at cs dot ucdavis.edu The following code causes an ICE when compiled with the current gcc trunk and 4.8 at -O1 only on x86_64-linux (both 32-bit and 64-bit modes). This is a regression from 4.7.x. $ gcc-trunk -v Using built-in specs. COLLECT_GCC=gcc-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --enable-languages=c,c++,objc,obj-c++,fortran,lto --with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk Thread model: posix gcc version 4.9.0 20130906 (experimental) [trunk revision 202308] (GCC) $ gcc-trunk -O0 -c small.c $ gcc-trunk -O2 -c small.c $ gcc-trunk -O3 -c small.c $ gcc-trunk -Os -c small.c $ gcc-4.7 -O1 -c small.c $ gcc-trunk -O1 -c small.c small.c: In function ‘foo’: small.c:7:6: internal compiler error: Floating point exception void foo () ^ 0x924b2f crash_signal ../../gcc-trunk/gcc/toplev.c:335 0x77ecd3 fold_array_ctor_reference ../../gcc-trunk/gcc/gimple-fold.c:2816 0x77ecd3 fold_ctor_reference ../../gcc-trunk/gcc/gimple-fold.c:2964 0x7827d2 fold_const_aggregate_ref_1(tree_node*, tree_node* (*)(tree_node*)) ../../gcc-trunk/gcc/gimple-fold.c:3066 0x78443b fold_const_aggregate_ref ../../gcc-trunk/gcc/gimple-fold.c:3088 0x78443b maybe_fold_reference ../../gcc-trunk/gcc/gimple-fold.c:272 0x784df6 gimple_fold_call ../../gcc-trunk/gcc/gimple-fold.c:1091 0x784df6 fold_stmt_1 ../../gcc-trunk/gcc/gimple-fold.c:1200 0x9763c9 fold_marked_statements ../../gcc-trunk/gcc/tree-inline.c:4380 0x980ff6 tree_function_versioning(tree_node*, tree_node*, vec*, bool, bitmap_head_def*, bool, bitmap_head_def*, basic_block_def*) ../../gcc-trunk/gcc/tree-inline.c:5354 0xd85e62 save_inline_function_body ../../gcc-trunk/gcc/ipa-inline-transform.c:368 0xd85e62 inline_transform(cgraph_node*) ../../gcc-trunk/gcc/ipa-inline-transform.c:425 0x880e6f execute_one_ipa_transform_pass ../../gcc-trunk/gcc/passes.c:2039 0x880e6f execute_all_ipa_transforms() ../../gcc-trunk/gcc/passes.c:2079 0x636160 expand_function ../../gcc-trunk/gcc/cgraphunit.c:1702 0x63809d expand_all_functions ../../gcc-trunk/gcc/cgraphunit.c:1814 0x63809d compile() ../../gcc-trunk/gcc/cgraphunit.c:2151 0x638729 finalize_compilation_unit() ../../gcc-trunk/gcc/cgraphunit.c:2228 0x516813 c_write_global_declarations() ../../gcc-trunk/gcc/c/c-decl.c:10125 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. $ gcc-4.8 -O1 -c small.c small.c: In function ‘foo’: small.c:7:6: internal compiler error: Floating point exception void foo () ^ 0x7b925f crash_signal ../../gcc-4.8.1/gcc/toplev.c:332 0x678f55 fold_array_ctor_reference ../../gcc-4.8.1/gcc/gimple-fold.c:2819 0x678f55 fold_ctor_reference ../../gcc-4.8.1/gcc/gimple-fold.c:2967 0x67bd77 fold_const_aggregate_ref_1(tree_node*, tree_node* (*)(tree_node*)) ../../gcc-4.8.1/gcc/gimple-fold.c:3069 0x67cd43 fold_const_aggregate_ref ../../gcc-4.8.1/gcc/gimple-fold.c:3091 0x67cd43 maybe_fold_reference ../../gcc-4.8.1/gcc/gimple-fold.c:277 0x67d434 gimple_fold_call ../../gcc-4.8.1/gcc/gimple-fold.c:1096 0x67d434 fold_stmt_1 ../../gcc-4.8.1/gcc/gimple-fold.c:1202 0x7ee097 fold_marked_statements ../../gcc-4.8.1/gcc/tree-inline.c:4237 0x7f42b6 tree_function_versioning(tree_node*, tree_node*, vec*, bool, bitmap_head_def*, bool, bitmap_head_def*, basic_block_def*) ../../gcc-4.8.1/gcc/tree-inline.c:5299 0xb3d7c2 save_inline_function_body ../../gcc-4.8.1/gcc/ipa-inline-transform.c:351 0xb3d7c2 inline_transform(cgraph_node*) ../../gcc-4.8.1/gcc/ipa-inline-transform.c:408 0x7319c7 execute_one_ipa_transform_pass ../../gcc-4.8.1/gcc/passes.c:2172 0x7319c7 execute_all_ipa_transforms() ../../gcc-4.8.1/gcc/passes.c:2208 0x59f876 expand_function ../../gcc-4.8.1/gcc/cgraphunit.c:1633 0x5a0d06 expand_all_functions ../../gcc-4.8.1/gcc/cgraphunit.c:1744 0x5a0d06 compile() ../../gcc-4.8.1/gcc/cgraphunit.c:2042 0x5a10b9 finalize_compilation_unit() ../../gcc-4.8.1/gcc/cgraphunit.c:2119 0x4e0453 c_write_global_declarations() ../../gcc-4.8.1/gcc/c/c-decl.c:10118 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gc
[Bug ipa/58346] New: ICE with SIGFPE at -O1 and above on x86_64-linux-gnu (affecting trunk, 4.8, 4.7, and 4.6)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58346
Bug ID: 58346
Summary: ICE with SIGFPE at -O1 and above on x86_64-linux-gnu
(affecting trunk, 4.8, 4.7, and 4.6)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk, 4.8,
and 4.7 at -O1 and above (at only -O1 for 4.6) on x86_64-linux (both 32-bit and
64-bit modes).
This should be related to 58345 (the backtraces are almost identical), but
affects also 4.6 and 4.7 as well as more optimization levels.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130906 (experimental) [trunk revision 202308] (GCC)
$ gcc-trunk -O0 -c small.c
$ gcc-trunk -O1 -c small.c
small.c: In function ‘main’:
small.c:20:5: internal compiler error: Floating point exception
int main ()
^
0x924b2f crash_signal
../../gcc-trunk/gcc/toplev.c:335
0x77ecd3 fold_array_ctor_reference
../../gcc-trunk/gcc/gimple-fold.c:2816
0x77ecd3 fold_ctor_reference
../../gcc-trunk/gcc/gimple-fold.c:2964
0x7827d2 fold_const_aggregate_ref_1(tree_node*, tree_node* (*)(tree_node*))
../../gcc-trunk/gcc/gimple-fold.c:3066
0x78443b fold_const_aggregate_ref
../../gcc-trunk/gcc/gimple-fold.c:3088
0x78443b maybe_fold_reference
../../gcc-trunk/gcc/gimple-fold.c:272
0x784df6 gimple_fold_call
../../gcc-trunk/gcc/gimple-fold.c:1091
0x784df6 fold_stmt_1
../../gcc-trunk/gcc/gimple-fold.c:1200
0x9763c9 fold_marked_statements
../../gcc-trunk/gcc/tree-inline.c:4380
0x983404 optimize_inline_calls(tree_node*)
../../gcc-trunk/gcc/tree-inline.c:4475
0xd85fa3 inline_transform(cgraph_node*)
../../gcc-trunk/gcc/ipa-inline-transform.c:436
0x880e6f execute_one_ipa_transform_pass
../../gcc-trunk/gcc/passes.c:2039
0x880e6f execute_all_ipa_transforms()
../../gcc-trunk/gcc/passes.c:2079
0x636160 expand_function
../../gcc-trunk/gcc/cgraphunit.c:1702
0x63809d expand_all_functions
../../gcc-trunk/gcc/cgraphunit.c:1814
0x63809d compile()
../../gcc-trunk/gcc/cgraphunit.c:2151
0x638729 finalize_compilation_unit()
../../gcc-trunk/gcc/cgraphunit.c:2228
0x516813 c_write_global_declarations()
../../gcc-trunk/gcc/c/c-decl.c:10125
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.
$
-
struct U {};
static struct U b[1] = { };
int a, **c, d, *e, f;
extern void bar (int, int, int, struct U);
extern void foobar (int, int, int);
extern int baz (int, int);
static void foo ()
{
bar (d, 0, 0, b[0]);
foobar (0 >= f, 0, 0);
**c = 0 == a;
baz (**c, 0);
baz (0, *e);
*e = baz (0, 0);
}
int main ()
{
foo ();
return 0;
}
[Bug bootstrap/58340] [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340 --- Comment #5 from Marc Glisse --- (In reply to Jeffrey A. Law from comment #3) > Just to be sure, what version of the trunk are both of you using? 202346 for me. Configured with --prefix=... --with-system-zlib --disable-nls --enable-libstdcxx-time=yes --disable-libvtv, built with make -j 6, on an up-to-date debian testing.
