https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #20 from Douglas Mencken ---
$ git bisect good
good: [270b838d816f8a2c372eac0121adcdf570feccfa] Regenerate .pot files.
Bisecting: 90 revisions left to test after this (roughly 7 steps)
[6f2116bed6e87668a914dc27fff34c7a68576d4e] P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84196
Martin Sebor changed:
What|Removed |Added
Keywords||accepts-invalid
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84196
Bug ID: 84196
Summary: invalid instantiation of a function template on a
vector type silently accepted
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84195
Bug ID: 84195
Summary: newlines in deprecated diagnostics
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #19 from Douglas Mencken ---
I got repo from git://gcc.gnu.org/git/gcc.git and begun to bisect it to find
the cause of regression
"good" here means reaching build of libstdc++-v3 after than problem libgcc
$ git bisect start
$ git bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68746
--- Comment #12 from dave.anglin at bell dot net ---
On 2018-01-31 3:17 AM, tkoenig at gcc dot gnu.org wrote:
> Is there anything than can be done to debug this?
> What happens if you compile the test with -g and
> run it under a debgger?
It's not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84190
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84194
Bug ID: 84194
Summary: fails to pack structs with template members
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84122
--- Comment #3 from Neil Carlson ---
Here's a related invalid example that gfortran accepts:
module mod
type foo(dim)
integer,len,public :: dim
integer :: array(dim)
end type
end module
PUBLIC/PRIVATE attributes are not valid attributes for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84186
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84122
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84192
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84193
Bug ID: 84193
Summary: Document the limitations of -fcheck-pointer-bounds
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84192
Bug ID: 84192
Summary: [7/8 Regression] ICE with statement expression
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
Bug 84141 depends on bug 84155, which changed state.
Bug 84155 Summary: [8 Regression] program hangs on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155
--- Comment #16 from Thomas Koenig ---
The statements are removed upon conversion to gimple:
--- Falsch/a.f90.004t.gimple2018-02-03 15:08:29.370147886 +0100
+++ Korrekt/a.f90.004t.gimple 2018-02-03 15:07:16.428178637 +0100
@@ -893,6 +893,9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
--- Comment #35 from Paul Thomas ---
Author: pault
Date: Sat Feb 3 14:06:44 2018
New Revision: 257356
URL: https://gcc.gnu.org/viewcvs?rev=257356&root=gcc&view=rev
Log:
2018-02-03 Paul Thomas
PR fortran/84141
PR fortran/8415
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155
--- Comment #15 from Paul Thomas ---
Author: pault
Date: Sat Feb 3 14:06:44 2018
New Revision: 257356
URL: https://gcc.gnu.org/viewcvs?rev=257356&root=gcc&view=rev
Log:
2018-02-03 Paul Thomas
PR fortran/84141
PR fortran/8415
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155
--- Comment #14 from paul.richard.thomas at gmail dot com ---
Hi Dominique,
Thanks for doing that. It was to have been my final step in the process.
I will commit the patch and then will go back to diagnose why an
unchanged tree dump yields dif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84191
Bug ID: 84191
Summary: Compiler ICEs when trying to resolve impossible
arithmetic operations
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155
--- Comment #13 from Dominique d'Humieres ---
> There is an important caveat to this fix, which has me very worried:
> On top of removal of uncalled code making the bug disappear, I cannot
> see any difference in the tree dump between the working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173
Javier Serrano Polo
changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|IN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81057
Volker Reichelt changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84184
--- Comment #11 from Eric Botcazou ---
> Why those are handled differently? First looks like it works, second does
> not. It was my main signal to file a bug against gcc as asymmetry looked
> fishy.
Because the problematic bitfield path is only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84190
--- Comment #2 from Marc Glisse ---
IIRC, the standard provides guarantees for volatile objects. Here, you are
accessing a non-volatile object through a volatile type, and if the compiler
can find out about the underlying object, it can ignore 'v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84190
--- Comment #1 from Bruno Haible ---
It works when I declare ys1, ys2, zs1, zs2 as 'volatile double' instead of
'double'. But I should not be needing to do this, because the only uses of
these 4 variables is as arguments to equalfn, which takes '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58479
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84190
Bug ID: 84190
Summary: [7 Regression] double arithmetic on x86 no longer
rounds to nearest
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57218
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed|2013-05-10 00:00:00 |2018-2-3
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57193
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed|2015-06-01 00:00:00 |2018-2-3
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
--- Comment #34 from Jürgen Reuter ---
So, to summarise all of our code, at least our basic and extended tests, work
again with this (second) patch by Paul Thomas, for all different kind types of
our default reals (64, 80, emulated 128 bit). Than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54063
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
Target Miles
34 matches
Mail list logo
