https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70170
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70170
--- Comment #12 from Martin Sebor ---
Author: msebor
Date: Sat Apr 2 17:14:48 2016
New Revision: 234698
URL: https://gcc.gnu.org/viewcvs?rev=234698=gcc=rev
Log:
PR c++/67376 - [5/6 regression] Comparison with pointer to past-the-end
of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70170
Martin Sebor changed:
What|Removed |Added
Assignee|mpolacek at gcc dot gnu.org|msebor at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70170
--- Comment #10 from Jakub Jelinek ---
(In reply to Jason Merrill from comment #9)
> (In reply to Jakub Jelinek from comment #7)
> > A small problem is that the second argument to POINTER_PLUS_EXPR is not
> > signed, but unsigned (sizetype).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70170
--- Comment #9 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #7)
> A small problem is that the second argument to POINTER_PLUS_EXPR is not
> signed, but unsigned (sizetype). Which is why I wrote "negative", negative
> would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70170
--- Comment #8 from Marek Polacek ---
Ah, true... well there's wi::sign_mask so maybe that. But given Comment 5 I'll
hold off for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70170
--- Comment #7 from Jakub Jelinek ---
A small problem is that the second argument to POINTER_PLUS_EXPR is not signed,
but unsigned (sizetype). Which is why I wrote "negative", negative would mean
having the most significant bit set or so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70170
--- Comment #6 from Marek Polacek ---
-fno-delete-null-pointer-checks seems to change nothing. But the case you
mention is something I wanted to think about more before posting a real patch.
I suppose I could add a check that the offset part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70170
--- Comment #5 from Martin Sebor ---
It turns out that my patch for bug 67376 (still being tested) fixes this bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70170
--- Comment #4 from Jakub Jelinek ---
Shouldn't -fno-delete-null-pointer-checks disable that? Or maybe only if the
constant is "negative", because with -fno-delete-null-pointer-checks in theory
some object could live at address NULL and you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70170
--- Comment #3 from Marek Polacek ---
I think that to fix this, we need to add a new pattern to match.pd that deals
with "(ptr +p off) !=/== 0B". Thus something like:
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -2263,6 +2263,11 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70170
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70170
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70170
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
14 matches
Mail list logo
