http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60003
--- Comment #10 from Jakub Jelinek ---
Author: jakub
Date: Sat Feb 1 08:40:31 2014
New Revision: 207382
URL: http://gcc.gnu.org/viewcvs?rev=207382&root=gcc&view=rev
Log:
PR tree-optimization/60003
* gimple-low.c (lower_builtin_setjmp): S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59985
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60021
Bug ID: 60021
Summary: Inconsistent -Wsign-compare warnings for -O0 and -O1
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60021
--- Comment #1 from Chengnian Sun ---
Interestingly, if I remove the typedef "typedef long int64_t;", the warning is
gone.
$: cat s.c
void fn1(unsigned, char, long);
void fn1(unsigned p_26, char c, long l) { /**/
const char l_1051 = 0;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60003
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51219
--- Comment #6 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Sat Feb 1 09:24:42 2014
New Revision: 207383
URL: http://gcc.gnu.org/viewcvs?rev=207383&root=gcc&view=rev
Log:
/cp
2014-02-01 Paolo Carlini
PR c++/51219
* typeck2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51219
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60023
Bug ID: 60023
Summary: [4.9 Regression] ICE: verify_gimple failed: dead STMT
in EH table with -O3 -fnon-call-exceptions -mavx2
Product: gcc
Version: 4.9.0
Status: UNCONFIR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60022
Bug ID: 60022
Summary: macro _(Text) generates warning: implicit
declaration of function '_'
[-Wimplicit-function-declaration]
Product: gcc
Version: 4.8.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60022
--- Comment #1 from Andreas Schwab ---
If the macro isn't defined then nothing defined it. Most likely rpmfileutil.c
failed to include the right headers in the correct order.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60022
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60017
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60022
--- Comment #3 from Richard PALO ---
(In reply to Andreas Schwab from comment #1)
> If the macro isn't defined then nothing defined it. Most likely
> rpmfileutil.c failed to include the right headers in the correct order.
The order is correct as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60022
--- Comment #4 from Richard PALO ---
(In reply to Jakub Jelinek from comment #2)
> You can preprocess with -E -dD and look at what exactly was defined where
> and how the preprocessed line containing call to rpmlog looks like.
Here are the releva
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60022
--- Comment #5 from Richard PALO ---
I should add, that for grins, I tried changing this invocation from '_()' to
N_()' and the got over this one, but naturally blew on the next invocation
later in the source code.
Is this perhaps a "const char*"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59997
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60022
--- Comment #6 from Jakub Jelinek ---
Can you just attach the whole preprocessed rpmfileutil.i (with -E -dD) instead
of copying in small snippets?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60022
--- Comment #7 from Richard PALO ---
Created attachment 32009
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32009&action=edit
output from -E -dD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60022
--- Comment #8 from Richard PALO ---
(In reply to Richard PALO from comment #7)
> Created attachment 32009 [details]
> output from -E -dD
I'll see if I can make a concise test program to reproduce the issue.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60022
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56653
Gerald Pfeifer changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56653
--- Comment #2 from gerald at gcc dot gnu.org ---
Author: gerald
Date: Sat Feb 1 12:01:56 2014
New Revision: 207387
URL: http://gcc.gnu.org/viewcvs?rev=207387&root=gcc&view=rev
Log:
PR other/56653
* gcc_release: Avoid printing empty line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60022
--- Comment #10 from Richard PALO ---
(In reply to Jakub Jelinek from comment #9)
> In any case, not a GCC bug.
Great, is there an explanation as to why it works with gcc 4.7.3?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56653
Gerald Pfeifer changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56653
--- Comment #4 from gerald at gcc dot gnu.org ---
Author: gerald
Date: Sat Feb 1 12:28:18 2014
New Revision: 207388
URL: http://gcc.gnu.org/viewcvs?rev=207388&root=gcc&view=rev
Log:
PR other/56653
* gcc_release: Avoid printing empty line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59906
--- Comment #8 from Paul Thomas ---
Created attachment 32010
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32010&action=edit
Tentative patch for the PR
The line that compiled did not yield correct code. The testcase in the patch
runs corre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60024
Bug ID: 60024
Summary: global-buffer-overflow in init_regs_for_mode
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60019
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60024
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60023
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60013
--- Comment #2 from H.J. Lu ---
Still unfixed with r207387.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60025
Bug ID: 60025
Summary: Static member of class not found if class name ==
namespace name it's defined in
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60013
H.J. Lu changed:
What|Removed |Added
Attachment #32006|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350
Vladimir Krivopalov changed:
What|Removed |Added
CC||vladimir.krivopalov at gmail
dot c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60013
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60013
--- Comment #5 from H.J. Lu ---
This in compute_bb_predicates
while (!done)
{
done = true;
FOR_EACH_BB_FN (bb, my_function)
{
struct predicate p = false_predicate ();
edge e;
edge_iterato
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60013
--- Comment #6 from H.J. Lu ---
Like this:
diff --git a/gcc/ipa-inline-analysis.c b/gcc/ipa-inline-analysis.c
index 9a4c6df..991a10b 100644
--- a/gcc/ipa-inline-analysis.c
+++ b/gcc/ipa-inline-analysis.c
@@ -1881,9 +1881,12 @@ compute_bb_predicat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60013
H.J. Lu changed:
What|Removed |Added
Attachment #32011|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #4 from Josh Triplett ---
(In reply to Tom Tromey from comment #3)
> I noticed this behavior and was wondering if it is intended:
>
> bapiya. cat /tmp/q.c
> __attribute__((force)) int *p;
> int q = *p;
> bapiya. sparse -Wno-decl /tmp/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59100
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #4 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59906
--- Comment #9 from Paul Thomas ---
Author: pault
Date: Sat Feb 1 18:50:41 2014
New Revision: 207389
URL: http://gcc.gnu.org/viewcvs?rev=207389&root=gcc&view=rev
Log:
2014-02-01 Paul Thomas
PR fortran/59906
* trans-stmt.c (gfc_add_lo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60013
--- Comment #8 from Jakub Jelinek ---
That doesn't look correct, that will not clear done on any basic block that has
abnormal successor with ABNORMAL_DISPATCHER, which is a lot of basic blocks.
If the algorithm isn't supposed to follow abnormal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60004
--- Comment #6 from Mike Spear ---
(For the record, this bug was found by wcm...@lehigh.edu, even though I
reported it)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #18 from Paul Thomas ---
Author: pault
Date: Sat Feb 1 22:31:53 2014
New Revision: 207390
URL: http://gcc.gnu.org/viewcvs?rev=207390&root=gcc&view=rev
Log:
2014-02-01 Paul Thomas
PR fortran/59414
* trans-stmt.c (gfc_trans
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60026
Bug ID: 60026
Summary: ICE at -O3 on valid code (with the optimize pragma) on
x86_64-linux-gnu
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350
--- Comment #4 from David Krauss ---
Hmm, I recall preparing to submit a patch but not being able to decide which
header to modify.
Here's the aforementioned MIT-licensed code. The MIT license only requires
attribution which is satisfied by the c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350
--- Comment #5 from David Krauss ---
Just re-reading now, std::size_t should be std::uintptr_t, but I don't see
anything else that could cause UB. The bitwise "negative" arithmetic should be
OK because it's all on unsigned values.
And if GNU styl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350
--- Comment #6 from Vladimir Krivopalov
---
(In reply to David Krauss from comment #5)
> Just re-reading now, std::size_t should be std::uintptr_t, but I don't see
> anything else that could cause UB. The bitwise "negative" arithmetic should
> be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350
--- Comment #7 from David Krauss ---
Haha, it looks like the MSVC devs forgot to subtract 1. Typical.
I did test my code in a real arena allocator, by the way, so that sort of thing
would not have gotten through.
50 matches
Mail list logo
