[Bug fortran/57435] [4.8/4.9 Regression] Ice on invalid: check_for_ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57435 Tobias Burnus changed: What|Removed |Added Keywords||ice-on-invalid-code CC||burnus at gcc dot gnu.org Target Milestone|--- |4.8.1 --- Comment #5 from Tobias Burnus --- (In reply to Dominique d'Humieres from comment #3) > Likely due to revision 195065: Looks like (see PR 47203 / http://gcc.gnu.org/r195065). (In reply to Dominique d'Humieres from comment #4) > The following patch restores the 4.7 behavior: The patch looks good to me.
[Bug fortran/57217] [4.7/4.8/4.9 Regression][OOP] Accepts invalid TBP overriding - lacking arguments check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57217 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-05-28 Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org Ever confirmed|0 |1
[Bug debug/57389] ICE in dbx_reg_number, at dwarf2out.c:10507 on powerpc-spe target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57389 --- Comment #4 from chrbr at gcc dot gnu.org --- Created attachment 30207 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30207&action=edit Patch to avoid assertion This patches restores to the previous state that don't check regno parameters produced by dwarf_register_span. necessary only for the powerpc, I don't really understand the reason why it produces a parallel with both a hard_reg and a dbx.
[Bug debug/57389] ICE in dbx_reg_number, at dwarf2out.c:10507 on powerpc-spe target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57389 --- Comment #5 from chrbr at gcc dot gnu.org --- Created attachment 30208 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30208&action=edit Alternative to fix the root cause. This patch only produces dbx regno for the dbx regno locations. tested for the SH4, ARM, RS6000 configurations that caused problem at one time or the other. Posted at http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01613.html
[Bug tree-optimization/57418] [4.9 Regression] Another verify_ssa failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57418 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from David Binderman --- (In reply to Richard Biener from comment #1) > Probably a dup. Seems to be fixed by trunk from 20130527.
[Bug rtl-optimization/57439] New: [4.9 regression]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57439 Bug ID: 57439 Summary: [4.9 regression] Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: amylaar at gcc dot gnu.org Target: m68k-*-*
[Bug rtl-optimization/57439] [4.9 regression] FAIL: gcc.c-torture/execute/920501-6.c execution, -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57439 Andreas Schwab changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |4.9.0 Summary|[4.9 regression]|[4.9 regression] FAIL: ||gcc.c-torture/execute/92050 ||1-6.c execution, -O1 --- Comment #1 from Andreas Schwab --- Executing on host: /daten/aranym/gcc/gcc-20130528/Build/gcc/xgcc -B/daten/aranym/gcc/gcc-20130528/Build/gcc/ /daten/aranym/gcc/gcc-20130528/gcc/testsuite/gcc.c-torture/execute/920501-6.c -fno-diagnostics-show-caret -fdiagnostics-color=never -w -O1 -lm -o /daten/aranym/gcc/gcc-20130528/Build/gcc/testsuite/gcc/920501-6.x1(timeout = 300) spawn /daten/aranym/gcc/gcc-20130528/Build/gcc/xgcc -B/daten/aranym/gcc/gcc-20130528/Build/gcc/ /daten/aranym/gcc/gcc-20130528/gcc/testsuite/gcc.c-torture/execute/920501-6.c -fno-diagnostics-show-caret -fdiagnostics-color=never -w -O1 -lm -o /daten/aranym/gcc/gcc-20130528/Build/gcc/testsuite/gcc/920501-6.x1 PASS: gcc.c-torture/execute/920501-6.c compilation, -O1 Executing on aranym: LD_LIBRARY_PATH=:/daten/aranym/gcc/gcc-20130528/Build/gcc:/daten/aranym/gcc/gcc-20130528/Build/gcc timeout 600 /daten/aranym/gcc/gcc-20130528/Build/gcc/testsuite/gcc/920501-6.x1 (timeout = 300) Executed /daten/aranym/gcc/gcc-20130528/Build/gcc/testsuite/gcc/920501-6.x1, status 1 Output: bash: line 1: 2912 Aborted LD_LIBRARY_PATH=:/daten/aranym/gcc/gcc-20130528/Build/gcc:/daten/aranym/gcc/gcc-20130528/Build/gcc timeout 600 /daten/aranym/gcc/gcc-20130528/Build/gcc/testsuite/gcc/920501-6.x1 child process exited abnormally FAIL: gcc.c-torture/execute/920501-6.c execution, -O1 --- /daten/aranym/gcc/gcc-20130527/Build/gcc/testsuite/gcc/920501-6.s 2013-05-28 11:38:57.524381509 +0200 +++ /daten/aranym/gcc/gcc-20130528/Build/gcc/testsuite/gcc/920501-6.s 2013-05-28 11:39:09.113314268 +0200 @@ -236,15 +236,13 @@ main: jne .L22 move.l -72(%fp),%d0 move.l -68(%fp),%d1 -clr.l %d2 -move.l #123421,%d3 +move.b #-111,%d2 sub.l %d3,%d1 subx.l %d2,%d0 jne .L22 move.l -64(%fp),%d0 move.l -60(%fp),%d1 -clr.l %d2 -move.l #123427,%d3 +move.b #-105,%d2 sub.l %d3,%d1 subx.l %d2,%d0 jne .L22
[Bug c++/57437] [4.7/4.8/4.9 Regression] C++11: mutable lambdas; gcc 4.7-4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57437 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-28 Known to work||4.6.3 Summary|C++11: mutable lambdas; gcc |[4.7/4.8/4.9 Regression] |4.7-4.8 |C++11: mutable lambdas; gcc ||4.7-4.8 Ever confirmed|0 |1
[Bug tree-optimization/57337] [4.9 Regression] 416.gamess ICE on x86 after r199048
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57337 --- Comment #4 from Igor Zamyatin --- For the record - 191.fma3d from spec2K fails with similar error
[Bug c++/57419] Access control doesn't stop referring to a deleted function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57419 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-28 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- (In reply to David Krauss from comment #0) > Using reference-to-member syntax You mean taking its address, right? Access control shouldn't stop it being referred to, but it should result in substitution failure rather than an error.
[Bug libstdc++/57421] Error when linking static libstc++ due to missing future classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57421
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2013-05-28
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Jonathan Wakely ---
(In reply to Jürgen Reuter from comment #0)
> This is our libtool command which does the invocation. I hope that you don't
> need any parts of the code to track this down:
You could have simply provided a minimal testcase:
#include
int main()
{
std::promise p;
}
[Bug testsuite/57413] FAIL: gcc.dg/debug/dwarf2/discriminator.c scan-assembler on x86_64-apple-darwin10, Solaris/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57413 Rainer Orth changed: What|Removed |Added Target|x86_64-apple-darwin10 |x86_64-apple-darwin10, ||i386-pc-solaris2.* Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-28 CC||ro at gcc dot gnu.org Host|x86_64-apple-darwin10 |x86_64-apple-darwin10, ||i386-pc-solaris2.* Target Milestone|--- |4.9.0 Summary|FAIL: |FAIL: |gcc.dg/debug/dwarf2/discrim |gcc.dg/debug/dwarf2/discrim |inator.c scan-assembler on |inator.c scan-assembler on |x86_64-apple-darwin10 |x86_64-apple-darwin10, ||Solaris/x86 Ever confirmed|0 |1 Build|x86_64-apple-darwin10 |x86_64-apple-darwin10, ||i386-pc-solaris2.* --- Comment #1 from Rainer Orth --- Same failure on Solaris/x86 with Sun as.
[Bug rtl-optimization/57439] [4.9 regression] FAIL: gcc.c-torture/execute/920501-6.c execution, -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57439 --- Comment #2 from Jorn Wolfgang Rennecke --- I can-t build the m68k-elf toolchain - it gets an error trying to build libgloss. Hence, I don't have stdio.h. Could you attach a preprocessed testcase?
[Bug rtl-optimization/57439] [4.9 regression] FAIL: gcc.c-torture/execute/920501-6.c execution, -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57439 --- Comment #3 from Andreas Schwab --- You don't need stdio.h.
[Bug middle-end/57412] [4.9 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647: loop 1's latch does not have an edge to its header with -fopenmp -fipa-pure-const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57412 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener --- Author: rguenth Date: Mon May 27 15:02:53 2013 New Revision: 199359 URL: http://gcc.gnu.org/viewcvs?rev=199359&root=gcc&view=rev Log: 2013-05-27 Richard Biener PR middle-end/57412 * omp-low.c (expand_omp_atomic_pipeline): Use the correct latch block for the new loop. * gcc.dg/gomp/pr57412.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/gomp/pr57412.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/57411] [4.9 Regression] ICE: verify_ssa failed: definition in block 4 does not dominate use in block 11 with -fno-tree-dce -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57411 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Author: rguenth Date: Tue May 28 10:54:33 2013 New Revision: 199374 URL: http://gcc.gnu.org/viewcvs?rev=199374&root=gcc&view=rev Log: 2013-05-28 Richard Biener PR tree-optimization/57411 * tree-ssa-copy.c (may_propagate_copy): Cannot propagate virtual operands. * tree-ssa-dom.c (eliminate_const_or_copy): Special-case virtual operand propagation. * g++.dg/opt/pr57411.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/opt/pr57411.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-copy.c trunk/gcc/tree-ssa-dom.c
[Bug libstdc++/57421] Error when linking static libstc++ due to missing future classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57421 --- Comment #3 from Jürgen Reuter --- I'll try to cook it down as much as possible.
[Bug rtl-optimization/57439] [4.9 regression] FAIL: gcc.c-torture/execute/920501-6.c execution, -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57439 --- Comment #4 from Jorn Wolfgang Rennecke --- Created attachment 30209 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30209&action=edit experimental patch I've used -I to point the compiler to the include directory in the newlib sources, and from what I see them, the problem is that a narrow register is generated by using the original REGNO and the new narrow mode - this misses the big endian correction. This patch uses gen_lowpart_common, which should just DTRT regardless of endianness. A further observation is that previously a conversion to a DImode add of 4 was tried, and abandoned, presumably due to cost. A SImode add to the 32 bit lowpart would be more profitable, at least if the target supports addq.l . In general, we should try if a set or constant add with a destination that is a subreg that constitutes one (or more) full hard register(s) is the cheapest option.
[Bug rtl-optimization/57268] [4.9 Regression] c nested loops hang compiler in sched-deps.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57268
Dinar Temirbulatov changed:
What|Removed |Added
CC||dtemirbulatov at gmail dot com
--- Comment #3 from Dinar Temirbulatov ---
(In reply to Jakub Jelinek from comment #2)
> This is weird, I've tried to bisect it, r197678 still compiled it without
> hanging, r197681 ICEd somewhere in lra-constraints.c, but if I rebuild
> lra-constraints.o with -O0, it instead ICEs on frame reg uses during
> final_scan_insns (i.e. LRA hasn't replaced the frame pointer with hard frame
> pointer or stack pointer), r197696 still ICEs, r197700 hangs.
> BTW, doing -da before it hangs, I'm seeing right in *.split4 dump REG_EQUIV
> notes like:
> (insn 20109 70 20110 19 (set (reg/f:DI 38 r9 [19927])
> (plus:DI (reg/f:DI 7 sp)
> (const_int 16 [0x10]))) 254 {*leadi}
> (expr_list:REG_EQUIV (plus:DI (reg/f:DI 20 frame)
> (const_int -8 [0xfff8]))
> (nil)))
> wonder if it isn't a bug that RA hasn't replaced the eliminable register in
> the note with sp (or hfp).
Problem was triggered by
Author: amker
Date: Thu Apr 11 03:55:14 2013 +
PR target/56124
* ira-costs.c (scan_one_insn): Check whether the source rtx of
loading has side effect.
And the problem in my view is in the scheduling 2 pass, it creates too long
read dependents list without flushing.
[Bug tree-optimization/56787] [4.8/4.9 Regression] Vectorization fails because of CLOBBER statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56787 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- The clobbers are dead and useless btw, but we only remove clobbers from within remove_unused_locals which doesn't run inbetween after IPA inlining and right before RTL expansion (rightfully so). Vectorizing without removing the clobbers requires us to honor them at least for placement of aliasing vectorized stores / loads and also IV adjustments in case the clobber is a MEM of an SSA name and that is loop variant (now possible, but not on the 4.8 branch). So the simplest solution is to discard all clobbers inside the vectorized loop body.
[Bug fortran/57217] [4.7/4.8/4.9 Regression][OOP] Accepts invalid TBP overriding - lacking arguments check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57217 --- Comment #3 from janus at gcc dot gnu.org --- Fixed on trunk with: Author: janus Date: Tue May 28 11:21:44 2013 New Revision: 199375 URL: http://gcc.gnu.org/viewcvs?rev=199375&root=gcc&view=rev Log: 2013-05-28 Janus Weil Tobias Burnus PR fortran/57217 * interface.c (check_dummy_characteristics): Symmetrize type check. 2013-05-28 Janus Weil Tobias Burnus PR fortran/57217 * gfortran.dg/typebound_override_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_override_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/57217] [4.7/4.8/4.9 Regression][OOP] Accepts invalid TBP overriding - lacking arguments check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57217 --- Comment #4 from janus at gcc dot gnu.org --- Some follow-up items: * split type and rank check to provide better error messages (http://gcc.gnu.org/ml/fortran/2013-05/msg00039.html) * remove duplication in gfc_check_pointer_assign? (http://gcc.gnu.org/ml/fortran/2013-05/msg00046.html) * fix assumed-type/rank cases (http://gcc.gnu.org/ml/fortran/2013-05/msg00089.html)
[Bug libstdc++/57421] Error when linking static libstc++ due to missing future classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57421 --- Comment #4 from Jonathan Wakely --- I already did, that's the code I posted! The only switches needed are -std=c++11 -static-libstdc++
[Bug fortran/57373] ICE on invalid: insert_bbt(): Duplicate key found!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57373 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-28 CC||janus at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.3.4, 4.7.4, 4.8.0, 4.9.0 --- Comment #1 from janus at gcc dot gnu.org --- Confirmed. Happens also with: interface foo function A(0) function A() end interface
[Bug fortran/57364] [4.8/4.9 Regression][OOP] ICE gfc_enforce_clean_symbol_state
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57364 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-28 CC||janus at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/57421] Error when linking static libstc++ due to missing future classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57421 --- Comment #5 from Jürgen Reuter --- Well, we have Fortran 2003 code into which via Bind(C) some c++ code is linked. For static builds, on MAC OS X because of the properties of the single-pass linker we need to explicitly link the C++ static library libstc++. Using this with the flags you mentioned does not change anything, unfortunately.
[Bug libstdc++/57440] New: Memory usage with future and std containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57440
Bug ID: 57440
Summary: Memory usage with future and std containers
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gallardo.d.e at gmail dot com
Consider the following test code:
#include
#include
#include
#include
using std::vector;
using std::array;
using std::cout;
using std::endl;
typedef unsigned int uint;
double TestFutures()
{
return 1;
}
void DoWork()
{
const uint nPoints=50;
const uint nThreads=100;
vector results(nThreads,0);
// For each data point...
for (uint k=0; k > values;
for (uint w=0; w results(nThreads,0);
// For each data point...
for (uint k=0; k,nThreads> values;
for (uint w=0; w
[Bug libstdc++/57421] Error when linking static libstc++ due to missing future classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57421 --- Comment #6 from Jonathan Wakely --- I think you've misunderstood, I posted the minimum code and the switches needed to reproduce the bug, I wasn't suggesting a workaround.
[Bug target/57432] A mistake was appeared,when I build u-boot (arm-none-linux-gnueabi-gcc: Internal error: Bus error (program cc1))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57432 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-05-28 Ever confirmed|0 |1
[Bug tree-optimization/56787] [4.8 Regression] Vectorization fails because of CLOBBER statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56787 Richard Biener changed: What|Removed |Added Known to work||4.9.0 Target Milestone|4.8.1 |4.8.2 Summary|[4.8/4.9 Regression]|[4.8 Regression] |Vectorization fails because |Vectorization fails because |of CLOBBER statements |of CLOBBER statements --- Comment #4 from Richard Biener --- Author: rguenth Date: Tue May 28 13:36:25 2013 New Revision: 199380 URL: http://gcc.gnu.org/viewcvs?rev=199380&root=gcc&view=rev Log: 2013-05-28 Richard Biener PR tree-optimization/56787 * tree-vect-data-refs.c (vect_analyze_data_refs): Drop clobbers from the list of data references. * tree-vect-loop.c (vect_determine_vectorization_factor): Skip clobbers. (vect_analyze_loop_operations): Likewise. (vect_transform_loop): Remove clobbers. * gcc.dg/vect/pr56787.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/pr56787.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-loop.c
[Bug libstdc++/57440] Memory usage with future and std containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57440 --- Comment #1 from Jonathan Wakely --- (In reply to DrD from comment #0) > // ... launch the threads > vector > values; > for (uint w=0; w values.push_back(std::async(TestFutures)); > } One quick comment, without analysing the issue: No threads are launched in your program. Currently GCC's std::async always behaves as std::async(std::launch::deferred, ...) so to run in a new thread you need to explicitly call std::async(std::launch::async, TestFutures)
[Bug rtl-optimization/57439] [4.9 regression] FAIL: gcc.c-torture/execute/920501-6.c execution, -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57439 --- Comment #5 from Jorn Wolfgang Rennecke --- (In reply to Jorn Wolfgang Rennecke from comment #4) > Created attachment 30209 [details] > experimental patch bootstrap / regtest on i686-pc-linux-gnu and build/regtest for i686-pc-linux-gnu X sh-elf show no regressions. Can't regtest for m68k, though.
[Bug libstdc++/57440] Memory usage with future and std containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57440 --- Comment #2 from DrD --- (In reply to Jonathan Wakely from comment #1) > (In reply to DrD from comment #0) > > // ... launch the threads > > vector > values; > > for (uint w=0; w > values.push_back(std::async(TestFutures)); > > } > > One quick comment, without analysing the issue: > > No threads are launched in your program. Currently GCC's std::async always > behaves as std::async(std::launch::deferred, ...) so to run in a new thread > you need to explicitly call std::async(std::launch::async, TestFutures) Oh! thank you very much for the tip!
[Bug java/57424] extra multilib subdirectory level at r199345
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57424
--- Comment #1 from Jack Howarth ---
This problem is caused by following change in gcc trunk. In gcc-4_8-branch, the
generated Makefile in darwin_objdir/x86_64-apple-darwin12.3.0/i386/libjava/gcj
has...
dbexecdir = $(libdir)/i386/gcj-4.8.1-14
where libdir is...
libdir = ${exec_prefix}/lib
whereas now in gcc trunk we have...
dbexecdir = $(toolexeclibdir)/i386/gcj-4.9.0-14
where toolexeclibdir is...
toolexeclibdir = $(libdir)/i386
hence the duplication of i386 in the path.
[Bug libstdc++/57421] Error when linking static libstc++ due to missing future classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57421 --- Comment #7 from Jürgen Reuter --- Ok, true, now I got it. But now it really looks like a problem of the library, and not our linking procedure. About this I was not totally sure before.
[Bug libstdc++/57440] Memory usage with future and std containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57440 --- Comment #3 from Jonathan Wakely --- Also I can't reproduce this on GNU/Linux, the memory usage is bounded as expected. I'm surprised this even compiles with Mingw, are you using Mingw-w64 with libpthread-win32? Since it seems to be platform-specific it could be a resource leak of mutexes or condition variables, so my wild guess is that libpthread-win32 requires pthread_mutex_destroy or pthread_cond_destroy to be used. Does it make any difference if you add these to the very top of the source file, before including any headers? #define _GTHREAD_USE_MUTEX_INIT_FUNC #define _GTHREAD_USE_COND_INIT_FUNC
[Bug libstdc++/57421] Error when linking static libstc++ due to missing future classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57421 --- Comment #8 from Jürgen Reuter --- Somehow, your example works for me :(
[Bug fortran/57435] [4.8/4.9 Regression] Ice on invalid: check_for_ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57435 --- Comment #6 from Tobias Burnus --- Author: burnus Date: Tue May 28 15:18:14 2013 New Revision: 199382 URL: http://gcc.gnu.org/viewcvs?rev=199382&root=gcc&view=rev Log: 2013-05-28 Dominique d'Humieres PR fortran/57435 * module.c (check_for_ambiguous): Avoid null pointer deref. 2013-05-28 Tobias Burnus PR fortran/57435 Added: trunk/gcc/testsuite/gfortran.dg/use_29.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 Jack Howarth changed: What|Removed |Added CC||howarth at nitro dot med.uc.edu --- Comment #2 from Jack Howarth --- Are these failures limited to 'make bootstrap-lean' on your machines? What happens if you just use 'make' without arguments.
[Bug libstdc++/57440] Memory usage with future and std containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57440 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-05-28 Ever confirmed|0 |1
[Bug rtl-optimization/57439] [4.9 regression] FAIL: gcc.c-torture/execute/920501-6.c execution, -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57439 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-28 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Eric Botcazou --- > > Created attachment 30209 [details] > > experimental patch > > bootstrap / regtest on i686-pc-linux-gnu and > build/regtest for i686-pc-linux-gnu X sh-elf > show no regressions. Can't regtest for m68k, though. Is SH big-endian? The patch looks good but we need to test it on a big-endian platform. I can give it a try on PowerPC if that can help.
[Bug libstdc++/57440] Memory usage with future and std containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57440
--- Comment #4 from Jonathan Wakely ---
If my guess is right you should be able to reproduce the unbounded memory usage
with this:
#include
int f() { return 0; }
int main()
{
for (int i=0; i < 10; ++i)
std::async(f).get();
}
And you should not see it happen with this:
#define _GTHREAD_USE_MUTEX_INIT_FUNC
#define _GTHREAD_USE_COND_INIT_FUNC
#include
int f() { return 0; }
int main()
{
for (int i=0; i < 10; ++i)
std::async(f).get();
}
Please check and update the bug report, thanks.
[Bug libstdc++/57440] Memory usage with future and std containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57440 --- Comment #5 from DrD --- (In reply to Jonathan Wakely from comment #3) > Also I can't reproduce this on GNU/Linux, the memory usage is bounded as > expected. > > I'm surprised this even compiles with Mingw, are you using Mingw-w64 with > libpthread-win32? Since it seems to be platform-specific it could be a > resource leak of mutexes or condition variables, so my wild guess is that > libpthread-win32 requires pthread_mutex_destroy or pthread_cond_destroy to > be used. > > Does it make any difference if you add these to the very top of the source > file, before including any headers? > > #define _GTHREAD_USE_MUTEX_INIT_FUNC > #define _GTHREAD_USE_COND_INIT_FUNC It does compile in MinGw. Unfortunately the two #define lines don't help either. I forgot to mention that I had already been warned that the test code works OK in Linux, see: http://stackoverflow.com/questions/16489389/memory-usage-with-future-and-containers-in-qt-mingw
[Bug libstdc++/57440] Memory usage with future and std containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57440
--- Comment #6 from DrD ---
(In reply to Jonathan Wakely from comment #4)
> If my guess is right you should be able to reproduce the unbounded memory
> usage with this:
>
> #include
>
> int f() { return 0; }
>
> int main()
> {
> for (int i=0; i < 10; ++i)
> std::async(f).get();
> }
>
>
> And you should not see it happen with this:
>
> #define _GTHREAD_USE_MUTEX_INIT_FUNC
> #define _GTHREAD_USE_COND_INIT_FUNC
>
> #include
>
> int f() { return 0; }
>
> int main()
> {
> for (int i=0; i < 10; ++i)
> std::async(f).get();
> }
>
> Please check and update the bug report, thanks.
Hi Jonathan,
Thanks for your help. I just tried this code and the memory problem is there
with and without the #define lines.
I haven't managed to get this bug tested on Windows by anyone else yet. I have
tried in two different computers, though (not enough, I think).
Any suggestions?
[Bug rtl-optimization/57439] [4.9 regression] FAIL: gcc.c-torture/execute/920501-6.c execution, -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57439 --- Comment #7 from Jorn Wolfgang Rennecke --- (In reply to Eric Botcazou from comment #6) > Is SH big-endian? Yes, the default for sh-elf - which is what I have tested - is big endian.
[Bug rtl-optimization/56833] [4.9 Regression] Valid register is over written by postreload pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56833 Georg-Johann Lay changed: What|Removed |Added CC||gjl at gcc dot gnu.org --- Comment #5 from Georg-Johann Lay --- This PR looks similar to PR56442 for the 4.8 branch. Does your patch fix that problem, too?
[Bug libstdc++/57440] Memory usage with future and std containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57440 --- Comment #7 from Jonathan Wakely --- You didn't answer the question about which mingw compiler you are using, the standard mingw gcc does not support std::async.
[Bug rtl-optimization/57439] [4.9 regression] FAIL: gcc.c-torture/execute/920501-6.c execution, -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57439 --- Comment #8 from Eric Botcazou --- > Yes, the default for sh-elf - which is what I have tested - is big endian. Thanks, the patch is OK then.
[Bug libstdc++/57440] Memory usage with future and std containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57440 --- Comment #8 from DrD --- (In reply to Jonathan Wakely from comment #7) > You didn't answer the question about which mingw compiler you are using, the > standard mingw gcc does not support std::async. >From my first post: "I compile it with gcc 4.7.2 (MinGW 4.7.2) in Qt 5.0.1, Qt Creator 2.6.2." Is that what you need or are you after some other detail I have omitted?
[Bug libstdc++/57440] Memory usage with future and std containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57440 --- Comment #9 from Jonathan Wakely --- Some other detail. I don't care about Qt Creator, it's not a compiler, and the version of Qt is compeltely irrelevant because you're not using Qt. I don't believe you can be using Mingw 4.7.2, because that doesn't support std::async(). What does 'gcc -v' show?
[Bug libstdc++/57440] Memory usage with future and std containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57440 --- Comment #10 from DrD --- (In reply to Jonathan Wakely from comment #7) > You didn't answer the question about which mingw compiler you are using, the > standard mingw gcc does not support std::async. >From my first post: "I compile it with gcc 4.7.2 (MinGW 4.7.2) in Qt 5.0.1, Qt Creator 2.6.2." Is that what you need or are you after some other detail I have omitted?(In reply to Jonathan Wakely from comment #9) > Some other detail. I don't care about Qt Creator, it's not a compiler, and > the version of Qt is compeltely irrelevant because you're not using Qt. > > I don't believe you can be using Mingw 4.7.2, because that doesn't support > std::async(). What does 'gcc -v' show? I am using the MinGW copy that comes with Qt. If I go to the bin folder I obtain: C:\Qt\Qt5.0.1\Tools\MinGW\bin>gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=c:/qt/qt5.0.1/tools/mingw/bin/../libexec/gcc/i686-w64-mingw32/4.7.2/lto-wrapper.exe Target: i686-w64-mingw32 Configured with: ../../../src/gcc-4.7.2/configure --host=i686-w64-mingw32 --build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/temp/x32-4.7.2-posix-sjlj-r8/prefix --with-sysroot=/temp/x32-4.7.2-posix-sj lj-r8/prefix --enable-shared --enable-static --enable-targets=all --enable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-lto --enable -graphite --enable-cloog-backend=isl --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --disable-ppl-version-check --disable-cloog-version-c heck --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch-32=i6 86 --with-arch-64=nocona --with-tune-32=core2 --with-tune-64=core2 --with-host-libstdcxx='-static -lstdc++' --with-libiconv --with-system-zlib --with-gmp=/temp/mingw-prereq/i686-w64-mingw32-static --with-mpfr=/ temp/mingw-prereq/i686-w64-mingw32-static --with-mpc=/temp/mingw-prereq/i686-w64-mingw32-static --with-ppl=/temp/mingw-prereq/i686-w64-mingw32-static --with-cloog=/temp/mingw-prereq/i686-w64-mingw32-static --wi th-pkgversion='Built by MinGW-builds project' --with-bugurl=http://sourceforge.net/projects/mingwbuilds/ CFLAGS='-O2 -pipe -fomit-frame-pointer -I/temp/x32-4.7.2-posix-sjlj-r8/libs/include -I/temp/mingw-prereq/ x32-zlib/include -I/temp/mingw-prereq/i686-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -fomit-frame-pointer -I/temp/x32-4.7.2-posix-sjlj-r8/libs/include -I/temp/mingw-prereq/x32-zlib/include -I/temp/mingw-p rereq/i686-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/temp/x32-4.7.2-posix-sjlj-r8/libs/lib -L/temp/mingw-prereq/x32-zlib/lib -L/temp/mingw-prereq/i686-w64-mingw32-static/lib -L/temp/x32-4.7.2-posi x-sjlj-r8/prefix/opt/lib' Thread model: posix gcc version 4.7.2 (Built by MinGW-builds project) I am relatively new to MinGw (it shows), so I am not too familiar with the particularities of Qt's copy.
[Bug tree-optimization/57441] New: ICE in gimple-ssa-strength-reduction.c:3447 at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57441
Bug ID: 57441
Summary: ICE in gimple-ssa-strength-reduction.c:3447 at -O3
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
The following code causes current gcc trunk to ICE when built at -O3 on
x86_64-linux. This is a regression from gcc 4.8 which compiles successfully.
$ gcc-trunk -v
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-checking
--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 20130528 (experimental) [trunk revision 199374] (GCC)
$ gcc-trunk -O2 -c crash.c
$ gcc-4.8 -O3 -c crash.c
$ gcc-trunk -O3 -c crash.c
*** glibc detected ***
/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1: free():
invalid next size (fast): 0x01ecd450 ***
crash.c: In function ‘func_1’:
crash.c:11:1: internal compiler error: Aborted
func_1 ()
^
0x7cbaef crash_signal
../../gcc-trunk/gcc/toplev.c:333
0xb3246c analyze_candidates_and_replace
../../gcc-trunk/gcc/gimple-ssa-strength-reduction.c:3398
0xb3246c execute_strength_reduction
../../gcc-trunk/gcc/gimple-ssa-strength-reduction.c:3447
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, c, d, *e;
unsigned char b;
char
baz (char p1)
{
return p1 * a;
}
void func_65 ();
func_1 ()
{
func_65 ();
func_65 ();
}
void
func_65 ()
{
d = baz (b--);
if (*e)
b--;
c = 0;
}
[Bug libstdc++/57440] Memory usage with future and std containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57440 Jonathan Wakely changed: What|Removed |Added Target||i686-w64-mingw32 Status|WAITING |NEW CC||ktietz at gcc dot gnu.org --- Comment #11 from Jonathan Wakely --- (In reply to DrD from comment #10) > Target: i686-w64-mingw32 > Configured with: ../../../src/gcc-4.7.2/configure --host=i686-w64-mingw32 > --build=i686-w64-mingw32 --target=i686-w64-mingw32 > --prefix=/temp/x32-4.7.2-posix-sjlj-r8/prefix > --with-sysroot=/temp/x32-4.7.2-posix-sj > lj-r8/prefix --enable-shared --enable-static --enable-targets=all > --enable-multilib --enable-languages=c,c++,fortran,lto > --enable-libstdcxx-time=yes --enable-threads=posix Thanks, that's what I needed, it confirms it's mingw-w64 with pthread support. Kai, do you have any ideas for how to track down the "leak" here? My knowledge of mingw-w64 and Windows in general is close to zero.
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 Tobias Burnus changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |burnus at gcc dot gnu.org --- Comment #19 from Tobias Burnus --- Author: burnus Date: Tue May 28 18:30:03 2013 New Revision: 199388 URL: http://gcc.gnu.org/viewcvs?rev=199388&root=gcc&view=rev Log: 2013-05-28 Tobias Burnus PR fortran/37336 * resolve.c (gfc_resolve_finalizers): Remove not implemented * error. 2013-05-28 Tobias Burnus PR fortran/37336 * gfortran.dg/finalize_11.f90: New. * gfortran.dg/finalize_4.f03: Remove dg-error. * gfortran.dg/finalize_5.f03: Ditto. * gfortran.dg/finalize_6.f03: Ditto. * gfortran.dg/finalize_7.f03: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/finalize_11.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/finalize_4.f03 trunk/gcc/testsuite/gfortran.dg/finalize_5.f03 trunk/gcc/testsuite/gfortran.dg/finalize_6.f90 trunk/gcc/testsuite/gfortran.dg/finalize_7.f03
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 --- Comment #20 from Tobias Burnus --- The patch in comment 19 enables the FINAL parsing. Note: No actual finalization is done, yet. However, the first calls to the finalization subroutines will be added soon.
[Bug tree-optimization/57442] New: ICE in appears_later_in_bb, at tree-ssa-reassoc.c:2891
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57442
Bug ID: 57442
Summary: ICE in appears_later_in_bb, at tree-ssa-reassoc.c:2891
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: antoine.balestrat at gmail dot com
Hello !
Using GCC 4.9.0 as of 20130528 (on a x86_64 box) :
$ cat reassoc.c
short a;
unsigned b;
long c;
int d;
void f(void)
{
b = a ? : (a = b) - c + (d - (b + b));
}
$ xgcc -O1 reassoc.c
reassoc.c: In function ‘f’:
reassoc.c:6:6: internal compiler error: in appears_later_in_bb, at
tree-ssa-reassoc.c:2891
void f(void)
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug c++/57443] New: Catured variable hide the parameter if they have the same name in Lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57443
Bug ID: 57443
Summary: Catured variable hide the parameter if they have the
same name in Lambdas
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kou4307 at gmail dot com
Here is the Stack overflow link that i have shared the problem
(http://stackoverflow.com/questions/16798079/captured-variable-hides-passed-variable-in-lambda-how-to-unhide/16798406#16798406)
I will expand the example here
int main()
{
int a = 1;
std::cout<<[=,&a](int a,int b){return a+b;}(99,1);
return 0;
}
Here the output is 2 rather than 100.
as the answer in the link says this problem in present in gcc 4.7.2 and gcc 4.8
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #3 from Jack Howarth --- The trigger for this bug is the use of --disable-checking. The linker crash doesn't occur when --enable-checking=release or --enable-checking=yes is passed to configure instead.
[Bug other/56479] Register allocator can't allocate two 4-byte variables into 8 registers for inline asm on avr-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56479 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P5
[Bug libstdc++/57440] Memory usage with future and std containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57440
--- Comment #12 from Jonathan Wakely ---
Using Qt Creator I have confirmed the leak, and can reproduce it with this
#include
#include
int main()
{
for (int i=0; i < 10; ++i) {
pthread_mutex_t mx = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_lock(&mx);
pthread_mutex_unlock(&mx);
usleep(1);
}
}
This is a simplified version of the code in libstdc++, here's another leaky
program using libstdc++:
//#define _GTHREAD_USE_MUTEX_INIT_FUNC
#include
#include
int main()
{
for (int i=0; i < 10; ++i) {
std::mutex mx;
mx.lock();
mx.unlock();
usleep(1);
}
}
Uncommenting the first line fixes it, so we should define that macro in
libstdc++-v3/config/os/mingw32-w64/os_defines.h
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #4 from Dara Hazeghi --- Aha! I will try using plain make and leaving checking alone. I don't suppose this is documented anywhere? As to reporting the bug to Apple, is this in fact a linker bug, as opposed to a bad-code-generation bug?
[Bug c++/57444] New: ICE in instantiate_type for invalid use of member with using-declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57444
Bug ID: 57444
Summary: ICE in instantiate_type for invalid use of member with
using-declaration
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Case:
struct C
{
bool empty();
};
struct D : C
{
using C::empty;
};
int
main()
{
if(D().empty); // error expected but got ICE
}
Output:
a.cc: In function 'int main()':
a.cc:14:14: internal compiler error: in instantiate_type, at cp/class.c:7459
if(D().empty);
^
The output is OK after removing 'using C::empty;':
a.cc: In function 'int main()':
a.cc:13:14: error: cannot convert 'C::empty' from type 'bool (C::)()' to type
'bool'
if(D().empty);
^
A real example is using debug containers(std::__debug::vector/deque...) when
'empty()' is occasionally typoed as 'empty' in if-statement.
[Bug target/51980] ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51980
mgretton at gcc dot gnu.org changed:
What|Removed |Added
CC||mgretton at gcc dot gnu.org
--- Comment #7 from mgretton at gcc dot gnu.org ---
Testing the testcase in #4 with a recent trunk (gcc version 4.9.0 20130528
(experimental) (GCC)) gives the following results:
arm-none-eabi-gcc -march=armv7-a -mfpu=neon -mfloat-abi=softfp -O2 -mthumb:
sqrlen4D_16u8:
vmovd18, r0, r1 @ v16qi
vmovd19, r2, r3
vld1.64 {d16-d17}, [sp:64]
vabd.u8 q8, q9, q8
vmull.u8q9, d16, d16
vmull.u8q8, d17, d17
vuzp.32 q9, q8
vpaddl.u16 q9, q9
vmovq10, q9 @ v4si
vpadal.u16 q10, q8
vmovr0, r1, d20 @ v4si
vmovr2, r3, d21
bx lr
arm-none-eabi-gcc -march=armv7-a -mfpu=neon -mfloat-abi=hard -O2 -mthumb:
sqrlen4D_16u8:
vabd.u8 q1, q0, q1
vmull.u8q0, d2, d2
vmull.u8q8, d3, d3
vuzp.32 q0, q8
vpaddl.u16 q0, q0
vpadal.u16 q0, q8
bx lr
So code generation seems to be OK for hard-float ABI but the soft-float version
has some issues with an extra vmov between the vpaddl and vpadal.
[Bug tree-optimization/57315] LTO and/or vectorizer performance regression on salsa20 core, 4.7->4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57315 --- Comment #2 from Zack Weinberg --- Created attachment 30210 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30210&action=edit self-contained test case Here's a self-contained test case. $ gcc-4.7 -std=c99 -O2 -march=native salsa20-regr.c && ./a.out 875.178 keys/s $ gcc-4.8 -std=c99 -O2 -march=native salsa20-regr.c && ./a.out 808.869 keys/s $ gcc-4.7 -std=c99 -O3 -march=native salsa20-regr.c && ./a.out 867.879 keys/s $ gcc-4.8 -std=c99 -O3 -march=native salsa20-regr.c && ./a.out 800.794 keys/s $ gcc-4.7 -std=c99 -O3 -fwhole-program -march=native salsa20-regr.c && ./a.out 606.605 keys/s $ gcc-4.8 -std=c99 -O3 -fwhole-program -march=native salsa20-regr.c && ./a.out 571.935 keys/s These numbers are stable to within about 1 key/s. So there's a 6-8% regression from 4.7 to 4.8 regardless of optimization level, but also -O3 and -O3 -fwhole-program are inferior to -O2 for this program, with both compilers. (-O2 -fwhole-program is within noise of just -O2 for both.) With 4.8, -march=native on my computer expands to -march=corei7-avx -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt --param l1-cache-size=0 --param l1-cache-line-size=0 --param l2-cache-size=256 -mtune=corei7-avx
[Bug fortran/57445] New: [4.8/4.9 Regression][OOP] ICE in gfc_conv_class_to_class - for OPTIONAL polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57445 Bug ID: 57445 Summary: [4.8/4.9 Regression][OOP] ICE in gfc_conv_class_to_class - for OPTIONAL polymorphic array Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Found when working on FINALization. It compiles with GCC 4.7 but fails with GCC 4.8 and 4.9. The following ICEs when passing an optional polymorphic array as argument to an optional dummy argument: finalize_12.f90:12:0: internal compiler error: in gfc_conv_class_to_class, at fortran/trans-expr.c:740 call foo_opt(xca=xca)!, xc, xaa, xca) ^ 0x63c6f9 gfc_conv_class_to_class(gfc_se*, gfc_expr*, gfc_typespec, bool, bool, bool, bool) ../../gcc/fortran/trans-expr.c:740 0x637b72 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc/fortran/trans-expr.c:4423 module m implicit none type t integer :: i end type t contains subroutine opt(xa, xc, xaa, xca) type(t), allocatable, intent(out), optional :: xa class(t), allocatable, intent(out), optional :: xc type(t), allocatable, intent(out), optional :: xaa(:) class(t), allocatable, intent(out), optional :: xca(:) call foo_opt(xca=xca)!, xc, xaa, xca) end subroutine opt subroutine foo_opt(xa, xc, xaa, xca) type(t), allocatable, intent(out), optional :: xa class(t), allocatable, intent(out), optional :: xc type(t), allocatable, intent(out), optional :: xaa(:) class(t), allocatable, intent(out), optional :: xca(:) end subroutine foo_opt end module m
[Bug fortran/57445] [4.8/4.9 Regression][OOP] ICE in gfc_conv_class_to_class - for OPTIONAL polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57445 Tobias Burnus changed: What|Removed |Added Known to work||4.7.3 Target Milestone|--- |4.8.2 Known to fail||4.8.0, 4.9.0
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #5 from Dara Hazeghi --- (In reply to Dara Hazeghi from comment #4) > Aha! I will try using plain make and leaving checking alone. I don't > suppose this is documented anywhere? make (not bootstrap) with --enable-checking=release does work. I'll try again with bootstrap-lean to verify whether checking is the sole cause of the failure.
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #6 from Jack Howarth --- I've opened radar://14005298, "linker crash when building FSF gcc with --disable-checking" with a standalone test case of the failing linkage of cc1.
[Bug fortran/57445] [4.8/4.9 Regression][OOP] ICE in gfc_conv_class_to_class - for OPTIONAL polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57445 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-28 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- The assert was added at revision 192495.
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #7 from Dara Hazeghi --- (In reply to Jack Howarth from comment #6) > I've opened radar://14005298, "linker crash when building FSF gcc with > --disable-checking" with a standalone test case of the failing linkage of > cc1. Thanks a bunch! make bootstrap-lean works fine with --enable-checking=release, so the checking is definitely the cause here.
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #8 from Jack Howarth --- The darwin linker developer's analysis of the failing linkage of cc1 is below... The assertion is about the file libbackend.a(varasm.o). There are overlapping FDEs. If you run dwarfdump in verify mode, it will complain about it to:: [/tmp/newlinkerbug/lib]> dwarfdump --eh-frame --verify varasm.o -- File: varasm.o (x86_64) -- Verifying EH Frame... error: FDE row for address 0x5900 is not in the FDE address range. 0x20e0: FDE length: 0x001c CIE_pointer: 0x start_addr: 0x5900 __Z24default_no_named_sectionPKcjP9tree_node range_size: 0x (end_addr = 0x5900) DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop Instructions: 0x5900: CFA=rsp+8 rip=[rsp] 1 errors found in EH frame for varasm.o (x86_64). Dumping the whole file, there is an FD for a zero length function, so two FDEs have the same function start address: 0x20e0: FDE length: 0x001c CIE_pointer: 0x start_addr: 0x5900 __Z24default_no_named_sectionPKcjP9tree_node range_size: 0x (end_addr = 0x5900) DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop Instructions: 0x5900: CFA=rsp+8 rip=[rsp] 0x2100: FDE alength: 0x006c CIE_pointer: 0x start_addr: 0x5900 __Z24default_no_named_sectionPKcjP9tree_node range_size: 0x0154 (end_addr = 0x5a54) Instructions: 0x5900: CFA=rsp+8 rip=[rsp]
[Bug tree-optimization/57442] [4.9 Regression] ICE in appears_later_in_bb, at tree-ssa-reassoc.c:2891
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57442 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-28 CC||eraman at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Known to work||4.8.1 Target Milestone|--- |4.9.0 Summary|ICE in appears_later_in_bb, |[4.9 Regression] ICE in |at tree-ssa-reassoc.c:2891 |appears_later_in_bb, at ||tree-ssa-reassoc.c:2891 Ever confirmed|0 |1 Known to fail||4.9.0 --- Comment #1 from Marek Polacek --- Confirmed. Started with http://gcc.gnu.org/r199385
[Bug bootstrap/57395] GCC-4.7.2 compilation erroe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57395 Andrew Pinski changed: What|Removed |Added Keywords|compile-time-hog| Status|UNCONFIRMED |WAITING Last reconfirmed||2013-05-28 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- We need more than what you copied and pasted here. We need the full command which is failing and the configure and make options.
[Bug tree-optimization/57441] [4.9 Regression] ICE in gimple-ssa-strength-reduction.c:3447 at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57441 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.9.0 Summary|ICE in |[4.9 Regression] ICE in |gimple-ssa-strength-reducti |gimple-ssa-strength-reducti |on.c:3447 at -O3|on.c:3447 at -O3
[Bug tree-optimization/57371] Simplify (double)i != 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57371 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-28 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/57400] [4.9 Regression] ICE: verify_ssa failed (definition in block n follows the use)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57400 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.9.0 Summary|ICE: verify_ssa failed |[4.9 Regression] ICE: |(definition in block n |verify_ssa failed |follows the use)|(definition in block n ||follows the use)
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #9 from Mike Stump --- If you can attach the .s file for varasm.c that does result in the crash that would be good. If this is a regression, identifying the change that broken it would be handy. Thanks.
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #10 from Dara Hazeghi --- Created attachment 30211 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30211&action=edit varasm.s.gz varasm.s resulting in the crash
[Bug middle-end/57393] [4.9 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393 --- Comment #4 from Joost VandeVondele --- still fails with r199397
[Bug middle-end/57393] [4.9 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393 Bug 57393 depends on bug 57337, which changed state. Bug 57337 Summary: [4.9 Regression] 416.gamess ICE on x86 after r199048 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57337 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/57337] [4.9 Regression] 416.gamess ICE on x86 after r199048
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57337 Joost VandeVondele changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Joost VandeVondele --- fixed at r199385
[Bug c++/57444] ICE in instantiate_type for invalid use of member with using-declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57444 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler --- The same problem exists for gcc 4.9.0 20130519 (experimental).
