https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064
Alex Coplan changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064
--- Comment #13 from Alex Coplan ---
(In reply to Richard Earnshaw from comment #12)
> (In reply to Alex Coplan from comment #11)
> > (In reply to Jakub Jelinek from comment #8)
> > > The IMHO UB case is for a != b when one address is at the sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064
--- Comment #12 from Richard Earnshaw ---
(In reply to Alex Coplan from comment #11)
> (In reply to Jakub Jelinek from comment #8)
> > The IMHO UB case is for a != b when one address is at the start of one
> > object and the other address is at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064
--- Comment #11 from Alex Coplan ---
(In reply to Jakub Jelinek from comment #8)
> The IMHO UB case is for a != b when one address is at the start of one
> object and the other address is at the end of another one
Just to dig a little deeper on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064
--- Comment #10 from Jakub Jelinek ---
IMHO it is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064
--- Comment #9 from Alex Coplan ---
So if f is UB, I suppose the question is whether the codegen for g is correct?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064
--- Comment #8 from Jakub Jelinek ---
The IMHO UB case is for a != b when one address is at the start of one object
and the other address is at the end of another one, which for zero sized
objects is more often because the start address is the s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064
--- Comment #7 from Alex Coplan ---
(In reply to Richard Biener from comment #6)
> Note whether a != b is probably undefined (but zero size objects are a GNU
> extension).
Just to clarify, are you saying this is undefined specifically for zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064
--- Comment #6 from Richard Biener ---
Note whether a != b is probably undefined (but zero size objects are a GNU
extension).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064
Alex Coplan changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Mikael Pettersson from comment #2)
> > Seems target-dependent. I can't reproduce on x86_64-linux-gnu or
> > sparc64-linux-gnu: both compile f() to r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064
--- Comment #3 from Andrew Pinski ---
(In reply to Mikael Pettersson from comment #2)
> Seems target-dependent. I can't reproduce on x86_64-linux-gnu or
> sparc64-linux-gnu: both compile f() to return 1 and g() to perform a runtime
> computation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
14 matches
Mail list logo
