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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57437
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57435
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
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|
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
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57418
David Binderman dcb314 at hotmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
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
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
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
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
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
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
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,
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?
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.
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
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
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.
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57268
Dinar Temirbulatov dtemirbulatov at gmail dot com changed:
What|Removed |Added
CC|
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
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
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/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++
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
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|
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
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:
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.
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
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
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) {
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
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;
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 =
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.
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
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 :(
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
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
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
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
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)
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
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
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.
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
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.
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.
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
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
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
: 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
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
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
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.
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
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
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.
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
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) {
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
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
--- 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
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
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:
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
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
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.
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
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
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
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
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|
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
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
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
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.
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
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
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57444
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC|
84 matches
Mail list logo
