http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57435
Tobias Burnus changed:
What|Removed |Added
Keywords||ice-on-invalid-code
CC|
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=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=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=57418
David Binderman changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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=57437
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=57419
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=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=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=57439
--- Comment #3 from Andreas Schwab ---
You don't need stdio.h.
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=57411
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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=57268
Dinar Temirbulatov changed:
What|Removed |Added
CC||dtemirbulatov at gmail dot com
--- C
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=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=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=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=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 ---
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=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 #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=57432
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
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=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=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 #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=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=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=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 #8 from Jürgen Reuter ---
Somehow, your example works for me :(
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=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=57440
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
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
--- 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=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 #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=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=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=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=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 #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=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 #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
: 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 changed:
What|Removed |Added
Target||i686-w64-mingw32
Status|WAI
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=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.
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 ---
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 changed:
What|Removed |Added
Priority|P3 |P5
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=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=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 ---
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
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=57445
Tobias Burnus changed:
What|Removed |Added
Known to work||4.7.3
Target Milestone|---
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=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=57445
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=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=57442
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=57441
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |4.9.0
Summary|ICE in
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=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=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=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=57393
--- Comment #4 from Joost VandeVondele
---
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 changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57444
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
82 matches
Mail list logo
