[Bug middle-end/57436] Linux kernel gives file system corruption when built with gcc 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57436 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #1 from Steven Bosscher steven at gcc dot gnu.org --- (In reply to Andreas Radke from comment #0) Any idea what this could be and how to track this down? It's a pretty nasty bug in gcc it seems to me. Jumping to conclusions like that isn't helpful (but unfortunately typical for kernel folk): It *may* be a bug in gcc, but it may just as well be a bug in the kernel. Relying on undefined behavior or stuff like that. Have you looked at some of the caveats in the GCC 4.8 relase notes? (See http://gcc.gnu.org/gcc-4.8/changes.html). The problem you're seeing could be related to the aggressive loop optimizations that GCC 4.8 has enabled. You could try -fno-aggressive-loop-optimizations. (IIRC it's enabled by default in recent linux kernel configurations, but I'm not sure.) Another common problem is alias violations. You could try compiling with -Wstrict-aliasing=2 and see if there are any real alias rules violations. If that all fails, you could try compile individual files (or all of XFS, perhaps) with -O1 or even just -O0, try to isolate the file that causes the breakage, and start comparing assembly. All that, assuming you have a file system you can repeatedly wreck, of course :-)
[Bug c++/57437] C++11: mutable lambdas; gcc 4.7-4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57437
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com ---
I can confirm the problem for my mingw-64-bit system using gcc 4.9.0 20130519
(experimental).
A variation of the program:
//-
#include vector
#include iostream
int main()
{
std::vectorint x{1, 2, 3};
auto y = [x] () mutable {
for (auto i: x)
i++;
return x;
};
for (const auto i : y()) {
std::cout i std::endl;
}
std::cout (1) std::endl;
for (const auto i : y()) {
std::cout i std::endl;
}
std::cout (2) std::endl;
}
//-
produces the output:
2
3
4
(1)
(2)
I *think* the following is going on here: The actual closure member x is
(incorrectly) considered as a local variable during RVO analysis, therefore the
first invocation invokes the move constructor on that member with the effect of
leaving an empty vector x within the closure.
The behavior looks incorrect to me: Neither 12.8 p31 b1 nor p32 can be applied
here, because x is neither a variable with automatic storage duration nor a
function parameter. It is correct the 5.1.2 p10 says
The identifier in a simple-capture is looked up using the usual rules for
unqualified name lookup (3.4.1); each such lookup shall find a variable with
automatic storage duration declared in the reaching scope of the local lambda
expression.
but this is an automatic variable *not* within the closure's function call
operator. And 5.1.2 p15
For each entity captured by copy, an unnamed nonstatic data member is declared
in the closure type.
is clear that x is considered a data member within the closure and RVO shall
not be applied to it.
[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 burnus at gcc dot gnu.org 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 burnus at gcc dot gnu.org --- (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=30207action=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=30208action=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 dcb314 at hotmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from David Binderman dcb314 at hotmail dot com --- (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 sch...@linux-m68k.org 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 sch...@linux-m68k.org --- 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 redi at gcc dot gnu.org 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 izamyatin at gmail dot com --- 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 redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-28 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- (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 redi at gcc dot gnu.org 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 redi at gcc dot gnu.org ---
(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 future
int main()
{
std::promisevoid 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 ro at gcc dot gnu.org 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 ro at gcc dot gnu.org --- 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 amylaar at gcc dot gnu.org --- 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 sch...@linux-m68k.org --- 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 rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon May 27 15:02:53 2013 New Revision: 199359 URL: http://gcc.gnu.org/viewcvs?rev=199359root=gccview=rev Log: 2013-05-27 Richard Biener rguent...@suse.de 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 rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue May 28 10:54:33 2013 New Revision: 199374 URL: http://gcc.gnu.org/viewcvs?rev=199374root=gccview=rev Log: 2013-05-28 Richard Biener rguent...@suse.de 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 juergen.reuter at desy dot de --- 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 amylaar at gcc dot gnu.org --- Created attachment 30209 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30209action=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 dtemirbulatov at gmail dot com changed:
What|Removed |Added
CC||dtemirbulatov at gmail dot com
--- Comment #3 from Dinar Temirbulatov dtemirbulatov at gmail dot com ---
(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 amker@138bc75d-0d04-0410-961f-82ee72b054a4
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 rguenth at gcc dot gnu.org 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 rguenth at gcc dot gnu.org --- 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=199375root=gccview=rev Log: 2013-05-28 Janus Weil ja...@gcc.gnu.org Tobias Burnus bur...@net-b.de PR fortran/57217 * interface.c (check_dummy_characteristics): Symmetrize type check. 2013-05-28 Janus Weil ja...@gcc.gnu.org Tobias Burnus bur...@net-b.de 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 redi at gcc dot gnu.org --- 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 juergen.reuter at desy dot de --- 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 vector
#include array
#include future
#include iostream
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;
vectordouble results(nThreads,0);
// For each data point...
for (uint k=0; knPoints; ++k) {
// ... launch the threads
vectorstd::futuredouble values;
for (uint w=0; wnThreads; ++w) {
values.push_back(std::async(TestFutures));
}
// ... and now read the results
for (uint w=0; wnThreads; ++w) {
results[w]+= values[w].get();
}
}
}
int main()
{
const uint nTimes=50;
for (uint k=0; knTimes; ++k) {
cout Cycle: k endl;
DoWork();
}
}
I compile it with gcc 4.7.2 (MinGW 4.7.2) in Qt 5.0.1, Qt Creator 2.6.2. Then I
run it, either in the debugger, or stand alone, release or debug version. If I
monitor the memory usage, it increases monotonically during the execution of
the loops. By increasing the variable nTimes in the main function, I can make
the program allocate an arbitrary amount of memory (I have tried up to 1Gb). I
monitor the memory usage with task manager or procexp.
If I then take the same code and compile it and run it under MS Visual Studio
Express 2012, the memory usage remains stable during the loop. This, I think,
is what you would expect, as the vector of futures should be destroyed after
each k-iteration.
I reported this in the MinGw bug forum and was redirected here.
Just to let you know, I still have the same issue if I substitute the vector of
futures with an array, i.e. this DoWork() routine:
void DoWork()
{
const uint nPoints=50;
const uint nThreads=100;
vectordouble results(nThreads,0);
// For each data point...
for (uint k=0; knPoints; ++k) {
// ... launch the threads
arraystd::futuredouble,nThreads values;
for (uint w=0; wnThreads; ++w) {
values[w]=std::async(TestFutures);
}
// ... and now read the results
for (uint w=0; wnThreads; ++w) {
results[w]+= values[w].get();
}
}
}
[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 redi at gcc dot gnu.org --- 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 rearnsha at gcc dot gnu.org 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 rguenth at gcc dot gnu.org 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 rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue May 28 13:36:25 2013 New Revision: 199380 URL: http://gcc.gnu.org/viewcvs?rev=199380root=gccview=rev Log: 2013-05-28 Richard Biener rguent...@suse.de 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 redi at gcc dot gnu.org ---
(In reply to DrD from comment #0)
// ... launch the threads
vectorstd::futuredouble values;
for (uint w=0; wnThreads; ++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 amylaar at gcc dot gnu.org --- (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 demonskull1 at gmail dot com ---
(In reply to Jonathan Wakely from comment #1)
(In reply to DrD from comment #0)
// ... launch the threads
vectorstd::futuredouble values;
for (uint w=0; wnThreads; ++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 howarth at nitro dot med.uc.edu ---
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 juergen.reuter at desy dot de --- 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 redi at gcc dot gnu.org --- 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 juergen.reuter at desy dot de --- 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 burnus at gcc dot gnu.org --- Author: burnus Date: Tue May 28 15:18:14 2013 New Revision: 199382 URL: http://gcc.gnu.org/viewcvs?rev=199382root=gccview=rev Log: 2013-05-28 Dominique d'Humieres domi...@lps.ens.fr PR fortran/57435 * module.c (check_for_ambiguous): Avoid null pointer deref. 2013-05-28 Tobias Burnus bur...@net-b.de 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 howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot med.uc.edu --- Comment #2 from Jack Howarth howarth at nitro dot med.uc.edu --- 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 redi at gcc dot gnu.org 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 ebotcazou at gcc dot gnu.org 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 ebotcazou at gcc dot gnu.org --- 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 redi at gcc dot gnu.org ---
If my guess is right you should be able to reproduce the unbounded memory usage
with this:
#include future
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 future
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 demonskull1 at gmail dot com --- (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 demonskull1 at gmail dot com ---
(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 future
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 future
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 amylaar at gcc dot gnu.org --- (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 gjl at gcc dot gnu.org changed: What|Removed |Added CC||gjl at gcc dot gnu.org --- Comment #5 from Georg-Johann Lay gjl at gcc dot gnu.org --- 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 redi at gcc dot gnu.org --- 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 ebotcazou at gcc dot gnu.org --- 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 demonskull1 at gmail dot com --- (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 redi at gcc dot gnu.org --- 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 demonskull1 at gmail dot com --- (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\bingcc -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 redi at gcc dot gnu.org changed: What|Removed |Added Target||i686-w64-mingw32 Status|WAITING |NEW CC||ktietz at gcc dot gnu.org --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org --- (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 burnus at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |burnus at gcc dot gnu.org --- Comment #19 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Tue May 28 18:30:03 2013 New Revision: 199388 URL: http://gcc.gnu.org/viewcvs?rev=199388root=gccview=rev Log: 2013-05-28 Tobias Burnus bur...@net-b.de PR fortran/37336 * resolve.c (gfc_resolve_finalizers): Remove not implemented * error. 2013-05-28 Tobias Burnus bur...@net-b.de 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 burnus at gcc dot gnu.org --- 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 howarth at nitro dot med.uc.edu --- 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 gjl at gcc dot gnu.org 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 redi at gcc dot gnu.org ---
Using Qt Creator I have confirmed the leak, and can reproduce it with this
#include pthread.h
#include unistd.h
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 mutex
#include unistd.h
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 dhazeghi at yahoo dot com --- 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 zackw at panix dot com --- Created attachment 30210 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30210action=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*, vectree_node*, va_gc, vl_embed*) ../../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 burnus at gcc dot gnu.org 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 dhazeghi at yahoo dot com --- (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 howarth at nitro dot med.uc.edu --- 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 dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-28 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- 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 dhazeghi at yahoo dot com --- (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 howarth at nitro dot med.uc.edu --- 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 mpolacek at gcc dot gnu.org 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 mpolacek at gcc dot gnu.org --- 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 pinskia at gcc dot gnu.org 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 pinskia at gcc dot gnu.org --- 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 pinskia at gcc dot gnu.org 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 pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-28 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- 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 pinskia at gcc dot gnu.org 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 mikestump at comcast dot net --- 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 dhazeghi at yahoo dot com --- Created attachment 30211 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30211action=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 Joost.VandeVondele at mat dot ethz.ch --- 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 Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- 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 daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- The same problem exists for gcc 4.9.0 20130519 (experimental).
