https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71090
--- Comment #6 from Jonathan Wakely ---
If you mess with the order of system header directories then you mess up how
headers are found. So don't do that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67328
--- Comment #6 from Yuri Gribov ---
(In reply to Oleg Endo from comment #5)
> PR 67731 maybe related or dup?
Related but not a dup. This bug is caused by frontend folding two bitfield
accesses to a single comparison which prevented generation of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71090
bastl73 changed:
What|Removed |Added
CC||sebastian.bw at freenet dot de
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70012
--- Comment #5 from Iain Sandoe ---
(In reply to Bill Schmidt from comment #4)
> Created attachment 40568 [details]
> Proposed patch
>
> Attaching proposed patch. Iain, would you be able to test this on Darwin
> 32- and 64-bit and see whether i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79266
--- Comment #2 from Andrew Pinski ---
There might be a dup of this bug just filed a few days ago and that was marked
as a dup too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79266
--- Comment #1 from Josh Triplett ---
Following up: it looks like gcc -O1 does eventually complete, after several
minutes. -O3 is still running.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79266
Bug ID: 79266
Summary: excessive compile time for large static array (-O1)
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79265
Bug ID: 79265
Summary: -fsanitize=undefined inserts unnecessary null pointer
tests
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79257
--- Comment #4 from Martin Sebor ---
One thing I noticed that suggests another possible (and, IMO, the ideal for
this specific case) solution: the warning goes away and GCC emits far better
code when the controlling expression of the loop is (i !
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79264
Bug ID: 79264
Summary: ICE verify_type failed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230
--- Comment #18 from vehre at gcc dot gnu.org ---
Correct me when I am wrong, but should the pointer component really be
finalized automatically? I am in the opinion that pointer components are not
finalized automatically. That is one of the signi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70583
John David Anglin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79257
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70583
--- Comment #11 from John David Anglin ---
Author: danglin
Date: Sat Jan 28 18:08:22 2017
New Revision: 245008
URL: https://gcc.gnu.org/viewcvs?rev=245008&root=gcc&view=rev
Log:
PR testsuite/70583
* g++.old-deja/g++.abi/vtable2.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230
--- Comment #17 from vehre at gcc dot gnu.org ---
Ok, being the offender I tried to have a look into as soon as possible.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70583
--- Comment #10 from John David Anglin ---
Author: danglin
Date: Sat Jan 28 18:01:22 2017
New Revision: 245007
URL: https://gcc.gnu.org/viewcvs?rev=245007&root=gcc&view=rev
Log:
PR testsuite/70583
* g++.old-deja/g++.abi/vtable2.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79263
Bug ID: 79263
Summary: Several tests introduced in r244878 fail with -m32
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64895
--- Comment #14 from Dominique d'Humieres ---
> Between revisions r244915 and r244957 I got the following XPASS
I have forgotten to say that it is on x86_64-apple-darwin16.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64895
--- Comment #13 from Dominique d'Humieres ---
Between revisions r244915 and r244957 I got the following XPASS
XPASS: gcc.target/i386/fuse-caller-save-rec.c scan-assembler-not pop
XPASS: gcc.target/i386/fuse-caller-save-rec.c scan-assembler-not p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78663
--- Comment #4 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #3)
> Have you raised this with compiler-rt upstream already?
I don't believe that upstream supports the sanitisers for Darwin < 11.
However, as seen, they are quite ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230
--- Comment #16 from janus at gcc dot gnu.org ---
(In reply to janus from comment #15)
> r243479 shows no runtime error, r243480 does.
The dump with r243479 is identical to 6.2. So r243480 does actually improve the
situation, but fails to handle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664
--- Comment #9 from Aldy Hernandez ---
Created attachment 40613
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40613&action=edit
preprocessed testcase for reproducing on ppc64 and aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664
--- Comment #8 from Aldy Hernandez ---
FYI, on aarch64, the problem can be reproduced with:
./cc1 -quiet -I./ a.c -O3 -ffast-math -mcpu=cortex-a53
on ppc64 with:
./cc1 -quiet -I./ a.c -O3 -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||vehre at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230
--- Comment #14 from janus at gcc dot gnu.org ---
(In reply to janus from comment #12)
> r243483:
> 2016-12-09 Janus Weil
>
> PR fortran/61767
> * class.c (has_finalizer_component): Fix this function to detect only
> non-poin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230
--- Comment #13 from Dominique d'Humieres ---
> The problem seems located to the file evaluators_uti.f90 and occurred
> between revisions r243430 (2016-12-08, OK) and r243621 (2016-12-13,
> segfault).
Could it be r243483 (pr61767)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230
--- Comment #12 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #3)
> The problem seems located to the file evaluators_uti.f90 and occurred
> between revisions r243430 (2016-12-08, OK) and r243621 (2016-12-13,
> s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230
--- Comment #11 from Jürgen Reuter ---
(In reply to janus from comment #7)
> (In reply to Jürgen Reuter from comment #5)
> > Here is the promised reduced test case, 80 lines, and I do believe that this
> > is most likely causing the issues of all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230
--- Comment #10 from janus at gcc dot gnu.org ---
(In reply to janus from comment #8)
> Another variant, which removes the naming collision (and dimension
> attribute) in the character components, in order to make things clearer:
>
>
> program m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230
--- Comment #9 from janus at gcc dot gnu.org ---
(In reply to janus from comment #8)
> Or maybe we should rather call the finalization wrapper for the type
> 'data_t'
That's also what's happening to 'par_real' in the following case:
subroutin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230
--- Comment #8 from janus at gcc dot gnu.org ---
Another variant, which removes the naming collision (and dimension attribute)
in the character components, in order to make things clearer:
program main_ut
implicit none
type :: data_t
c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79262
--- Comment #1 from Andrew Pinski ---
Created attachment 40612
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40612&action=edit
The vector cost model improvement for ThunderX2 CN99xx
This changes the vector cost model to be more correct fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18438
--- Comment #14 from Andrew Pinski ---
(In reply to Maxim Kuvyrkov from comment #12)
> You are making an orthogonal point to this bug report: whether or not to
> vectorize such a loop. But if loop is vectorized, then on any
> microarchitecture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79262
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |6.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79262
Bug ID: 79262
Summary: [6/7 Regression] load gap with store gap causing
performance regression in 462.libquantum
Product: gcc
Version: 7.0
Status: UNCONFIRMED
K
37 matches
Mail list logo
