http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57444
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57337
Joost VandeVondele changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=57393
--- Comment #4 from Joost VandeVondele
---
still fails with r199397
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
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.
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57371
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57441
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |4.9.0
Summary|ICE in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57395
Andrew Pinski changed:
What|Removed |Added
Keywords|compile-time-hog|
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57442
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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 wi
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 b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57445
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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.
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 do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57445
Tobias Burnus changed:
What|Removed |Added
Known to work||4.7.3
Target Milestone|---
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: UN
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
--- 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=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
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 b
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;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56479
Georg-Johann Lay changed:
What|Removed |Added
Priority|P3 |P5
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.
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
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=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.
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
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57440
Jonathan Wakely changed:
What|Removed |Added
Target||i686-w64-mingw32
Status|WAI
: 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
--- 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 gc
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
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
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.
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.
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
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.
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
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
> libpt
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();
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57439
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57440
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
Jack Howarth changed:
What|Removed |Added
CC||howarth at nitro dot med.uc.edu
--- Commen
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
* mo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57421
--- Comment #8 from Jürgen Reuter ---
Somehow, your example works for me :(
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-
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.
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
wh
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
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-el
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 comme
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57432
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
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.
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: libstd
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 libr
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=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=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++
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://gc
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 Burn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56787
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57268
Dinar Temirbulatov changed:
What|Removed |Added
CC||dtemirbulatov at gmail dot com
--- C
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, an
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57411
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57412
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57439
--- Comment #3 from Andreas Schwab ---
You don't need stdio.h.
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?
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,
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57421
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57419
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57437
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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
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
Assign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57418
David Binderman changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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. test
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
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=57435
Tobias Burnus changed:
What|Removed |Added
Keywords||ice-on-invalid-code
CC|
82 matches
Mail list logo
