https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
Royi changed:
What|Removed |Added
CC||royiavital at yahoo dot com
--- Comment #16 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85285
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85280
--- Comment #2 from Thomas Koenig ---
Looking backwards... r257361 fails, r254161 is OK.
Some more bisection to follow...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226
--- Comment #17 from Vittorio Romeo ---
Was the patch merged in trunk?
The following still fails to compile on 20180407
template
int foo()
{
([i = Is]{}(), ...);
return 0;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85292
Bug ID: 85292
Summary: multiple definition of default argument emitted
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85291
--- Comment #1 from Segher Boessenkool ---
I cannot reproduce this. What is the failing insn?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85289
simon at pushface dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85291
Bug ID: 85291
Summary: ICE in extract_insn, at recog.c:2304
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064
--- Comment #23 from Thomas Koenig ---
(In reply to Jakub Jelinek from comment #22)
> It isn't just about compiler generated temporaries, you could e.g. have a
> BLOCK construct inside of DO CONCURRENT and local variables in there,
This would a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064
--- Comment #22 from Jakub Jelinek ---
It isn't just about compiler generated temporaries, you could e.g. have a BLOCK
construct inside of DO CONCURRENT and local variables in there, those also need
to be private, or automatic variables in functi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85290
--- Comment #3 from Thorsten Otto ---
When compiling the attached source file, which includes a header file marked as
system header (same happens when include some real file from a system header
path), specifying -Wdeclaration-after-statement, no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85290
--- Comment #2 from Thorsten Otto ---
Created attachment 43880
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43880&action=edit
Source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85290
--- Comment #1 from Thorsten Otto ---
Created attachment 43879
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43879&action=edit
header file marked as system header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85290
Bug ID: 85290
Summary: Defining identifiers to themselves in system headers
prevents diagnostics from being emitted.
Product: gcc
Version: 7.3.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85186
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #6 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85289
Bug ID: 85289
Summary: Fails to build libgcc.a multilib for v8-m.base/nofp
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85078
--- Comment #7 from Jan Hubicka ---
Created attachment 43878
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43878&action=edit
patch
Hi,
this patch makes the testcase to work by rebuilding type inheritance graph. It
is one extra walk over t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064
--- Comment #21 from Thomas Koenig ---
(In reply to Jakub Jelinek from comment #20)
> Does autopar break this (i.e. create the loop) even without the ANNOTATE, or
> does it give up on the analysis?
It just gives up.
The following patch
Remov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85287
--- Comment #4 from Segher Boessenkool ---
Nope, different issue, this one in rs6000 target code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85287
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85288
Bug ID: 85288
Summary: profiledbootstrap failure on aarch with
-freorder-blocks-and-partition; bogus warning with
--save-temps
Product: gcc
Version: unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064
--- Comment #20 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #19)
> (In reply to Thomas Koenig from comment #15)
> > Do I understand correctly that creating all compiler-generated
> > temporary variables inside a block in DO CON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064
--- Comment #19 from Jakub Jelinek ---
(In reply to Thomas Koenig from comment #15)
> Do I understand correctly that creating all compiler-generated
> temporary variables inside a block in DO CONCURRENT would solve the
> problem?
>
> If so, it m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85287
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85280
Thomas Koenig changed:
What|Removed |Added
Component|target |bootstrap
Summary|[8 Regressi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064
--- Comment #18 from Thomas Koenig ---
(In reply to Dominique d'Humieres from comment #17)
> > The original test case works fine with gcc-6 with multiple invocations,
> > so this is at least a gcc-8 regression.
>
> AFAICT the code is parallelize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
Nicolas Koenig changed:
What|Removed |Added
Attachment #42494|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85287
Segher Boessenkool changed:
What|Removed |Added
Target|ppc64-linux-gnu |powerpc*-*-*
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84828
--- Comment #6 from Martin Liška ---
I have a very similar issue:
$ g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/pr84828.C /dev/null
-mno-sse -Og
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/pr84828.C: In function
‘void foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85287
Bug ID: 85287
Summary: ICE in in extract_insn, at recog.c:2304 on ppc64 with
-fstack-clash-protection
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85286
Bug ID: 85286
Summary: ICE in exact_div, at poly-int.h:2139
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85286
Martin Liška changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83606
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81773
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064
--- Comment #17 from Dominique d'Humieres ---
> The original test case works fine with gcc-6 with multiple invocations,
> so this is at least a gcc-8 regression.
AFAICT the code is parallelized with gcc-8 only.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #1 from Jan Hubicka ---
Pat, can you try to figure out what value of min-speedup is neeed to recover
from this regression?
It woul be nice to know what is the particular inline decision causing trouble
and what are the esitmated benef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85285
Bug ID: 85285
Summary: [6/7/8 Regression] ICE with flexible array in union
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85078
--- Comment #6 from Jan Hubicka ---
The problem is that we build type inheritance graph earlier and at that time
there are still virtual functions in the callgraph that are optimized out
before free-lang-data. Their types however remain in ODR h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |8.0
Summary|DO CONCURRENT inc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84058
--- Comment #7 from Jan Hubicka ---
Created attachment 43876
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43876&action=edit
Patch I am testing
Turns out that those are mostly artifacts of the fact that basically all of
cfg-cleanup has be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85284
--- Comment #2 from Jakub Jelinek ---
Seems this goes wrong during ivopts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82976
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85284
--- Comment #1 from Jakub Jelinek ---
Slightly more reduced:
static int p[48], v;
int
main ()
{
p[32] = 1;
for (int i = 48; i--;)
{
if (!p[i])
continue;
if ((i & 7) > 2)
break;
v = i & 1;
}
if (v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85284
Jakub Jelinek changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85284
Bug ID: 85284
Summary: [7/8 Regression] Loop miscompilation starting with
r238367
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85283
Bug ID: 85283
Summary: Generates 20 lines of assembly while only one assembly
instruction is enough.
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: n
47 matches
Mail list logo