https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #20 from Eric Gallager ---
(In reply to Martin Sebor from comment #19)
> That's a valid concern. Issuing a warning (either at the same time as or in
> lieu of the folding) would be a way to detect and prevent these kinds of
> problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #19 from Martin Sebor ---
That's a valid concern. Issuing a warning (either at the same time as or in
lieu of the folding) would be a way to detect and prevent these kinds of
problems. Exposing it to enough code (like in a whole dis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #18 from joseph at codesourcery dot com ---
I don't expect people to do such comparisons with addresses of local
variables directly. It is plausible that they have a memmove-like
function, and once it gets inlined the compiler can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #17 from Martin Sebor ---
Just to be clear: my suggestion to fold the relational expressions is only for
incoming pointers with addresses of local variables that GCC already assumes
cannot be synthesized (I assume it does that on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #16 from joseph at codesourcery dot com ---
I think the most likely case for code using such comparisons is not a
mistake, but code doing something like memmove - code that checks whether
two arrays overlap, and which one comes firs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #15 from Martin Sebor ---
I agree that comparison of the intptr_t values would be preferable over
extending the pointer inequality semantics. It's the intended mechanism for
this sort query. It makes code that relies on the ordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #14 from Marc Glisse ---
(In reply to Florian Weimer from comment #13)
> I don't see why I cast should magically fix this issue,
In libstdc++, std::less does such a cast, there were discussions about it
at that time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #13 from Florian Weimer ---
(In reply to Marc Glisse from comment #12)
> (In reply to Florian Weimer from comment #11)
> > GCC on ELF provides defined address ordering for separate objects via linker
> > ordering and section attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #12 from Marc Glisse ---
(In reply to Florian Weimer from comment #11)
> GCC on ELF provides defined address ordering for separate objects via linker
> ordering and section attributes. I think part of these extensions is that
> it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #11 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #9 from Marc Glisse ---
(In reply to Martin Sebor from comment #8)
> I also agree that diagnosing all these unspecified (or undefined in C) cases
> would be helpful as they (at least in the straightforward instances) are
> most likely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #8 from Martin Sebor ---
(In reply to rguent...@suse.de from comment #5)
> Does "unspecified" allow p > q != !(p <= q)? I think so (it's not
> implementation defined).
The exact C++ words that apply here are:
(4.3) Otherwise [if t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #7 from rguenther at suse dot de ---
On Wed, 24 Jul 2019, glisse at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
>
> --- Comment #6 from Marc Glisse ---
> When we compare p>=a where a is an array (cha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #6 from Marc Glisse ---
When we compare p>=a where a is an array (char a[3];), we can assume that p
points somewhere into the array and fold it to true (unless we decide that it
is too risky, and that for instance since we allow point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #5 from rguenther at suse dot de ---
On Tue, 23 Jul 2019, msebor at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
>
> --- Comment #4 from Martin Sebor ---
> The results of relational expressions (<, >,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #4 from Martin Sebor ---
The results of relational expressions (<, >, <=, and <=) involving pointers to
unrelated objects are undefined and unspecified in C and C++, respectively.
(See 6.5.8, p5 in C 11 and [expr.rel], p3 in C++ 17).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #2 from Martin Sebor ---
Yes, I meant &&. And yes, folding it either way is strictly valid in both C,
where the result of the relational expression is undefined, and C++ where it's
unspecified. But besides being inconsistent with th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #1 from Marc Glisse ---
> if (p >= a || p <= a + 3)
I think you mean &&.
I believe we could fold it to true or false as we wish: false because the
preexisting pointer cannot point to a local object, true because you are only
allowe
20 matches
Mail list logo
