http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57916
--- Comment #2 from Alexey Tourbin ---
> Thanks for the patch, do you have a GCC opyright assignment in place?
I don't have a copyright assignmet, but I'm willing to undergo the procedure
(and perhaps to sign an assignment for all future changes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57373
Bud Davis changed:
What|Removed |Added
CC||bdavis at gcc dot gnu.org
--- Comment #2 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #17 from Max Reitz ---
(In reply to Andreas Schwab from comment #16)
> That's exactly what I wrote.
Ah, okay, sorry I misunderstood.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57922
Bug ID: 57922
Summary: Memory leak with allocatable polymorphics
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57921
--- Comment #4 from Steve Ellcey ---
Digging around on the SPEC web page led me to this:
http://www.spec.org/cpu2006/Docs/400.perlbench.html
Known portability issues
There are some known aliasing issues. The internal data structures that
repres
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #16 from Andreas Schwab ---
That's exactly what I wrote.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57921
Andrew Pinski changed:
What|Removed |Added
Keywords||alias
--- Comment #3 from Andrew Pinski
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57921
--- Comment #2 from Steve Ellcey ---
Created attachment 30519
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30519&action=edit
Test case cut down from perl benchmark in SPEC 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57921
--- Comment #1 from Steve Ellcey ---
Created attachment 30518
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30518&action=edit
What the CSE phase generated after checkin r200133
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57921
Bug ID: 57921
Summary: Alias change causes perl from SPEC 2006 to abort on
MIPS
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #15 from Max Reitz ---
(In reply to Andreas Schwab from comment #14)
> The relevant option is -ffreestanding, not -nostdlib.
If you're referring to me, I'll be glad to cite my OP for you :D
> Compiling the attached trivial memcpy imp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57591
--- Comment #3 from acrux ---
same failure with gcc-4.8-20130711
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #14 from Andreas Schwab ---
The relevant option is -ffreestanding, not -nostdlib.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #13 from Max Reitz ---
(In reply to Brooks Moses from comment #12)
> Now, if this replacement still happens when you compile with -nostdlib, that
> would be a bug since it becomes legal code in that case. But that's
> somewhat of a se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #12 from Brooks Moses ---
(In reply to Paulo J. Matos from comment #11)
> A non-bug? If you write a memcpy function by hand and call it memcpy, gcc
> replaces the function body by a call to memcpy which generates an infinite
> loop. Ho
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57810
--- Comment #2 from Po-Chun Chang ---
Patch sent to gcc-patches@:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00662.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57805
--- Comment #2 from Po-Chun Chang ---
Patch sent to gcc-patches@:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00661.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57523
schaiba at gmail dot com changed:
What|Removed |Added
CC||schaiba at gmail dot com
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57920
Bug ID: 57920
Summary: [c++11] Linux: std::random_device reads too much from
/dev/urandom
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57909
--- Comment #5 from Georg-Johann Lay ---
You can write r201005 and bugzilla will link it for you :-)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57909
--- Comment #6 from Yvan Roux ---
Nice feature, I'll try to remember it ;)
Thanks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #32 from Martin Liška ---
Sorry for late answer, proposed patch works for me.
Thanks,
Martin
(In reply to Ian Lance Taylor from comment #10)
> Created attachment 30323 [details]
> Possible patch
>
> Can you see if this patch fixes t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57909
Yvan Roux changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57919
Bug ID: 57919
Summary: [C++11] Alias templates cause partial specialization
to erroneously fail
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57895
--- Comment #3 from Tobias Burnus ---
Author: burnus
Date: Wed Jul 17 12:57:41 2013
New Revision: 201008
URL: http://gcc.gnu.org/viewcvs?rev=201008&root=gcc&view=rev
Log:
2013-07-17 Mikael Morin
Tobias Burnus
PR fortra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57895
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56665
Andre Schmitt changed:
What|Removed |Added
CC||excitari at gmail dot com
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57918
Bug ID: 57918
Summary: Options -funroll-loops, -funroll-all-loops are
described twice
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57917
--- Comment #5 from Jonathan Wakely ---
Your code is equivalent to:
int i; // uninitialized
i = 1; // now it's initialized
This should not give a warning.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57917
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57917
Nishant Sharma changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57917
--- Comment #2 from Nishant Sharma ---
(In reply to Jonathan Wakely from comment #1)
> GCC 4.2 is ancient and no longer supported.
>
> This is not "critical", it's your code that has a bug, not the compiler.
>
> You don't use A::isABC in the pro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35862
--- Comment #26 from Uroš Bizjak ---
(In reply to Tobias Burnus from comment #24)
> [Somehow printf doesn't like my long double/__float128 example and prints
> 0.0 (long double) or garbage numbers (__float128).]
You should use %25.22Lf instead o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57917
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
Jonathan Wakely changed:
What|Removed |Added
CC||nishant.031 at gmail dot com
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57916
--- Comment #1 from Jonathan Wakely ---
Thanks for the patch, do you have a GCC opyright assignment in place?
Please see
http://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html#list.copyright
for details on contributing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35862
--- Comment #25 from Tobias Burnus ---
Rounding on input. Patch, which sets the CPU rounding mode and relies on strtof
to honour it: http://gcc.gnu.org/ml/fortran/2013-07/msg00042.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57894
--- Comment #2 from Tobias Burnus ---
Patch: http://gcc.gnu.org/ml/fortran/2013-07/msg00038.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57917
Nishant Sharma changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57917
Bug ID: 57917
Summary: -Wuninitialized
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #11 from Paulo J. Matos ---
(In reply to Brooks Moses from comment #10)
> Other than the documentation issues, this seems like a non-bug.
A non-bug? If you write a memcpy function by hand and call it memcpy, gcc
replaces the function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57909
--- Comment #3 from Yvan Roux ---
Validation ends without any regression on ARM targets (armv5, a9, a9hf, a15).
42 matches
Mail list logo