http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56992
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56994
Bug #: 56994
Summary: Incorrect documentation for Fortran NEAREST intrinsic
function
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56682
--- Comment #1 from Andrew Pinski 2013-04-18
01:58:03 UTC ---
>-fsanitize=thread
I think it requires -fPIE but really it should not.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981
--- Comment #6 from Jerry DeLisle 2013-04-18
01:21:42 UTC ---
I like Jannes idea with the flags. Also, it seems that at the time we open a
file we know it is /dev/null or /dev/nul in some cases by the file name. It
would be very low over
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
--- Comment #10 from Leif Leonhardy 2013-04-18
01:17:31 UTC ---
"One proposed requirement on setjmp is that it be usable like any other
function, that is, that it be callable in *any* expression context, and that
the expression evaluate co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993
Bug #: 56993
Summary: power gcc built 416.gamess generates wrong result
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56992
--- Comment #1 from James Eder 2013-04-17 23:47:39
UTC ---
Created attachment 29892
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29892
testcase-min.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56992
Bug #: 56992
Summary: building Wine with -Og causes GCC to seg fault
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56847
--- Comment #8 from Han Shen 2013-04-17 23:42:22
UTC ---
Hi, any progress on this?
Thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866
--- Comment #12 from Marc Glisse 2013-04-17
21:49:15 UTC ---
(In reply to comment #11)
> If fixing broken gcc's XOP/FMA/FMA4-extensions on AMD-CPUs depends on my
> ability to extract a stand-alone-test from glibc-testsuite then I'm
> real
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56909
--- Comment #15 from Eric Botcazou 2013-04-17
21:35:54 UTC ---
> Why below output has '-march=pentiumpro'?
I think it's the autodetected arch, but maybe I'm confused. Never mind.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56989
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866
--- Comment #11 from Winfried Magerl 2013-04-17
21:02:38 UTC ---
Hi Mike,
On Wed, Apr 17, 2013 at 08:15:47PM +, mikpe at it dot uu.se wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866
>
> --- Comment #10 from Mikae
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56909
--- Comment #14 from Arthur Zhang 2013-04-17
21:02:14 UTC ---
(In reply to comment #13)
> > What is the benefit to use '--build=i686-pc-mingw32' than
> > '--with-arch=i686'?
>
> It doesn't force -march=i686 by default.
Why below outp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56909
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866
--- Comment #10 from Mikael Pettersson 2013-04-17
20:15:47 UTC ---
(In reply to comment #9)
> How to proceed?
Derive a stand-alone test case from the failing glibc module and whatever glibc
code it requires, then minimize it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56991
Bug #: 56991
Summary: constexpr std::initializer_list crashes on too complex
initialization
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56909
Arthur Zhang changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958
--- Comment #11 from Joost VandeVondele
2013-04-17 19:36:45 UTC ---
With these patches in, parallel compilation of multi-file cp2k becomes
significantly faster. Time for a full build goes from 70s to 50s. I think that
in a parallel build t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56990
Bug #: 56990
Summary: ICE: SIGFPE with -fsanitize=thread and empty struct
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: norma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56989
Bug #: 56989
Summary: wrong location in error message
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866
--- Comment #9 from Winfried Magerl 2013-04-17
18:41:06 UTC ---
Hi,
at least one confirmation. I've done some further checks about
float-errors in glibc and that FAM/FAM4 are the extension responsible
for the additional float-errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40986
Ludovic Brenta changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Known to work|4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56988
Bug #: 56988
Summary: ipa-cp incorrectly propagates a field of an aggregate
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: nor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53453
--- Comment #19 from mrs at gcc dot gnu.org 2013-04-17
16:21:39 UTC ---
I've sent a message to the gcc-patches list with a pointer to the gcc-patches
list for the work.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56814
--- Comment #7 from janus at gcc dot gnu.org 2013-04-17 16:15:06 UTC ---
Fixed on trunk with:
Author: janus
Date: Wed Apr 17 16:13:07 2013
New Revision: 198032
URL: http://gcc.gnu.org/viewcvs?rev=198032&root=gcc&view=rev
Log:
2013-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56718
Martin Jambor changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42371
Martin Jambor changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53453
m...@gcc.gnu.org changed:
What|Removed |Added
Known to work||4.7.4
--- Comment #18 from m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10474
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56987
Bug #: 56987
Summary: gcc/config/avr/avr.opt:80: "change" -> "changed"?
Classification: Unclassified
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56986
Bug #: 56986
Summary: config/epiphany/epiphany.opt:108: "floatig"
Classification: Unclassified
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35649
Trevor Morgan changed:
What|Removed |Added
Target|h8300-elf |h8300-elf, rx-elf, avr
--- Comm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981
--- Comment #5 from Tobias Burnus 2013-04-17
14:50:16 UTC ---
(In reply to comment #4)
> The reason why gfortran is slow here is that for non-regular files we use
> unbuffered I/O. If you write to a regular file instead of /dev/null, you'l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55149
--- Comment #5 from Paolo Carlini 2013-04-17
14:19:07 UTC ---
Likewise capturing VLAs is covered in N3639 (only capture by reference allowed)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320
--- Comment #9 from Paolo Carlini 2013-04-17
14:16:40 UTC ---
Sorry, the most recent paper in the series is actually N3639.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958
--- Comment #10 from Tobias Burnus 2013-04-17
13:50:58 UTC ---
Author: jb
Date: Wed Apr 17 10:19:40 2013
New Revision: 198023
URL: http://gcc.gnu.org/viewcvs?rev=198023&root=gcc&view=rev
Log:
PR 40958 Compress module files with zlib.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45688
--- Comment #4 from Manuel López-Ibáñez 2013-04-17
13:30:35 UTC ---
Actually, the bug was "version level functioning". Since it is obvious, I fixed
it.
http://gcc.gnu.org/r198028
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56948
David Edelsohn changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45688
Manuel López-Ibáñez changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #24 from Vincent Lefèvre 2013-04-17
12:34:40 UTC ---
BTW, since with the latest GCC versions (such as Debian's GCC 4.7.2), the
warning is no longer issued with -Wno-maybe-uninitialized, perhaps the bug
severity could be lowered to "e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #23 from Vincent Lefèvre 2013-04-17
12:24:56 UTC ---
(In reply to comment #21)
> When an unrecognized warning option is requested (e.g., -Wunknown-warning),
> GCC
> will emit a diagnostic stating that the option is not recognized.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56921
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56814
--- Comment #6 from janus at gcc dot gnu.org 2013-04-17 11:41:21 UTC ---
(In reply to comment #5)
> Alternative patch:
In contrast to the patch in comment #3, this one regtests cleanly ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #22 from Manuel López-Ibáñez 2013-04-17
11:31:29 UTC ---
(In reply to comment #20)
> (In reply to comment #18)
> > In fact, we should have removed the i=i idiom a long time ago. The correct
> > thing to do (as Linus says) is to initi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #21 from Manuel López-Ibáñez 2013-04-17
11:26:01 UTC ---
(In reply to comment #20)
> OK, so a solution would be to add a configure test for projects that don't
> want
> such warnings (while still using -Wall) to see whether
> -Wno-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #20 from Vincent Lefèvre 2013-04-17
11:17:14 UTC ---
(In reply to comment #18)
> In fact, we should have removed the i=i idiom a long time ago. The correct
> thing to do (as Linus says) is to initialize the variable to a sensible val
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981
--- Comment #4 from Janne Blomqvist 2013-04-17 10:50:07
UTC ---
The reason why gfortran is slow here is that for non-regular files we use
unbuffered I/O. If you write to a regular file instead of /dev/null, you'll see
us doing ~8 KB writes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45688
Shakthi Kannan changed:
What|Removed |Added
CC||skannan at redhat dot com
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45655
Shakthi Kannan changed:
What|Removed |Added
CC||skannan at redhat dot com
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56985
Bug #: 56985
Summary: gcc/fortran/resolve.c:920: "'%s' in cannot appear in
COMMON ..."
Classification: Unclassified
Product: gcc
Version: 4.8.1
Status: UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
--- Comment #9 from Richard Biener 2013-04-17
09:57:52 UTC ---
Created attachment 29889
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29889
patch
Untested patch. The patch handles setjmp similar to a non-local label,
thus force
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981
--- Comment #3 from Tobias Burnus 2013-04-17
09:39:58 UTC ---
(In reply to comment #2)
> There is a seek inside next_record_w_unf. That function is used for DIRECT
> I/O.
> Looks conceptually wrong to me for sequential unformatted. I won
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #19 from Manuel López-Ibáñez 2013-04-17
09:37:24 UTC ---
(In reply to comment #2)
> 1. Split the -Wuninitialized into two different warnings: one for which gcc
> knows that the variable is uninitialized and one for which it cannot d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #18 from Manuel López-Ibáñez 2013-04-17
09:31:59 UTC ---
In fact, we should have removed the i=i idiom a long time ago. The correct
thing to do (as Linus says) is to initialize the variable to a sensible value
to silence the warning:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44269
Shakthi Kannan changed:
What|Removed |Added
CC||skannan at redhat dot com
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
--- Comment #8 from Jakub Jelinek 2013-04-17
09:28:55 UTC ---
#include
#include
static sigjmp_buf env;
static inline int g (int x)
{
if (x)
{
fprintf (stderr, "Returning 0\n");
return 0;
}
else
{
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #17 from Ma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56644
--- Comment #7 from Markus Eisenmann
2013-04-17 09:17:36 UTC ---
At least this error is based on some libintl-macros, which will "redirect" some
stdio-functions (like vsnprintf ...) to their libintl-version(s); I.e. the
header-file libintl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40986
--- Comment #15 from Markus Schöpflin
2013-04-17 09:15:22 UTC ---
I have bisected the problem using the git gcc repository, unfortunately 121
commits are left after bisecting, as in between the last known good and the
first known bad commit the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
--- Comment #7 from rguenther at suse dot de
2013-04-17 09:07:10 UTC ---
On Wed, 17 Apr 2013, jakub at gcc dot gnu.org wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
>
> --- Comment #6 from Jakub Jelinek 2013-04-17
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56644
--- Comment #6 from Markus Eisenmann
2013-04-17 09:01:04 UTC ---
Created attachment 29888
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29888
Prevent redirect to some libintl-functions if NLS isn't requested
This Patch will undefi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56814
--- Comment #5 from janus at gcc dot gnu.org 2013-04-17 08:58:25 UTC ---
Alternative patch:
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c(revision 198007
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
--- Comment #6 from Jakub Jelinek 2013-04-17
08:56:00 UTC ---
I don't see how we could declare the testcase invalid, why would n need to be
volatile? It isn't live across the setjmp call, it is even declared after the
setjmp call, and it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50789
--- Comment #12 from rguenther at suse dot de
2013-04-17 08:53:21 UTC ---
On Wed, 17 Apr 2013, andrey.turetskiy at gmail dot com wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50789
>
> Andrey Turetskiy changed:
>
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
--- Comment #5 from Richard Biener 2013-04-17
08:48:33 UTC ---
So the questions are:
- is it desirable that uncprop does anything to SSA_NAME_VAR == NULL phis?
sure - it is all about improving out-of-SSA coalescing opportunities
and avo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #16 from Vincent Lefèvre 2013-04-17
08:40:09 UTC ---
(In reply to comment #3)
> A way to tell gcc a variable is not uninitialized is to perform
> self-initialization like
>
> int i = i;
>
> this will cause no code generation but i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50789
Andrey Turetskiy changed:
What|Removed |Added
CC||andrey.turetskiy at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|una
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56984
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53453
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot
73 matches
Mail list logo
