https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457
Martin Sebor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457
Richard Biener changed:
What|Removed |Added
Target Milestone|10.3|10.4
--- Comment #19 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457
Richard Biener changed:
What|Removed |Added
Target Milestone|10.2|10.3
--- Comment #18 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|10.0|10.2
--- Comment #17 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457
--- Comment #16 from Martin Sebor ---
The warning code hasn't changed. What's different is that the MEM_REF that
-Warray-bounds doesn't handle isn't in the IL anymore. The
hppa2.0w-hp-hpux11.11 IL for the test case in comment #6 looks just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457
--- Comment #15 from Iain Sandoe ---
this is fixed for Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457
--- Comment #14 from Iain Sandoe ---
(In reply to Martin Sebor from comment #13)
> (In reply to Christophe Lyon from comment #10)
>
> Yes, the warning is intended and Glibc was just patched to avoid it:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457
--- Comment #13 from Martin Sebor ---
(In reply to Christophe Lyon from comment #10)
Yes, the warning is intended and Glibc was just patched to avoid it:
https://sourceware.org/ml/glibc-cvs/2019-q3/msg00459.html
(In reply to Iain Sandoe from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457
--- Comment #12 from Iain Sandoe ---
it looks like Wstringop-overflow-3.C also started failing at the same time as
Warray-bounds-8, presumably these are all connected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457
--- Comment #11 from Iain Sandoe ---
on Darwin, the Warray-bounds-4 is failing for c++98,14,17
Warray-bounds-8 has started failing between 274983 and 275034 with the same
kind of pattern - I can file a new PR if you regard the second as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457
--- Comment #10 from Christophe Lyon ---
Thanks for the pointer to the glibc discussion.
My understanding is that GCC's warning is legitimate, and won't be removed?
Since this breaks all my validations, I guess the best course of action on my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457
--- Comment #9 from Martin Sebor ---
The Glibc warning is being discussed on libc-alpha:
https://sourceware.org/ml/libc-alpha/2019-08/msg00774.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457
--- Comment #7 from dave.anglin at bell dot net ---
On 2019-08-28 2:27 p.m., msebor at gcc dot gnu.org wrote:
> I'm wondering if this test passed on hppa before r273783. Did GCC actually
> issue the expecting -Warray-bounds there?
Looking at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457
--- Comment #6 from Martin Sebor ---
The enhancement has been committed but it doesn't actually resolve the problem.
As it turns out, it's caused by VRP not issuing a -Warray-bounds for this
case. VRP runs before (not after as I suggested in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457
--- Comment #5 from Martin Sebor ---
Author: msebor
Date: Wed Aug 28 16:43:56 2019
New Revision: 274997
URL: https://gcc.gnu.org/viewcvs?rev=274997=gcc=rev
Log:
PR tree-optimization/91457 - inconsistent warning for writing past the end of
an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457
Martin Sebor changed:
What|Removed |Added
Keywords||patch
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457
--- Comment #1 from John David Anglin ---
Martin Sebor wrote on 2019-08-14:
I don't know about the flifetime-dse2.C test but the Warray-bounds-4.C warning
is the result of a recent enhancement to the strlen optimization, either
r274486 or
20 matches
Mail list logo