[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064 Alex Coplan changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #14 from Alex Coplan --- Closing as invalid, then, given that (as Jakub says) f is UB and the codegen for g is correct.
[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays
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 start of one > > > object and the other address is at the end of another one > > > > Just to dig a little deeper on this, what makes this case UB? Is there > > something in the standard to this effect? > > As stated in #6, zero-sized objects are a GNU extension. I guess that means > we get to define what the behaviour should be :) Sure, but Jakub's reply seemed to get at some underlying principle as opposed to just saying "zero-sized objects are a GNU extension and we declare this case to be undefined".
[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays
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 the end of another one > > Just to dig a little deeper on this, what makes this case UB? Is there > something in the standard to this effect? As stated in #6, zero-sized objects are a GNU extension. I guess that means we get to define what the behaviour should be :)
[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays
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 this, what makes this case UB? Is there something in the standard to this effect?
[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064 --- Comment #10 from Jakub Jelinek --- IMHO it is.
[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays
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?
[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays
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 same as end address. For integral comparisons we try to be more conservative.
[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays
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 size objects or undefined in general for distinct objects? I thought for the latter == and != were ok, but < and such were UB.
[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays
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).
[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays
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 from Alex Coplan --- Bisection shows this changed with r9-5411-g93aa3c4aca3647645cd5bce724f9d2126de4b5ea on AArch64: commit 93aa3c4aca3647645cd5bce724f9d2126de4b5ea (refs/bisect/bad) Author: Jakub Jelinek Date: Tue Jan 15 09:11:00 2019 +0100 re PR tree-optimization/88775 (Optimize std::string assignment) PR tree-optimization/88775 * match.pd (cmp (convert1?@2 addr@0) (convert2? addr@1)): Optimize equal == 0 equality pointer comparisons some more if compared in integral types and either one points to an automatic var and the other to a global, or we can prove at least one points to the middle or both point to start or both point to end. * gcc.dg/tree-ssa/pr88775-1.c: New test. * gcc.dg/tree-ssa/pr88775-2.c: New test.
[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays
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 return 1 and g() to perform a runtime > > computation. But ppc64-linux-gnu and armv7l-linux-gnueabi behave as your > > aarch64 example: f() returns 1 and g() returns 0 (unconditionally, no > > runtime computations). > > Most likely section anchors is the cause of the difference between the > targets. > The ones which implement section anchors return different values between the > functions. Is suspect MIPS has similar behavior too. It is also most likely why aarch64 changed between 8 and 9 too.
[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays
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. But ppc64-linux-gnu and armv7l-linux-gnueabi behave as your > aarch64 example: f() returns 1 and g() returns 0 (unconditionally, no > runtime computations). Most likely section anchors is the cause of the difference between the targets. The ones which implement section anchors return different values between the functions. Is suspect MIPS has similar behavior too.
[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #2 from Mikael Pettersson --- 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. But ppc64-linux-gnu and armv7l-linux-gnueabi behave as your aarch64 example: f() returns 1 and g() returns 0 (unconditionally, no runtime computations).
[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||ktkachov at gcc dot gnu.org --- Comment #1 from ktkachov at gcc dot gnu.org --- This seems to have changed in the GCC 9 series. GCC 8.5 generates: f(): mov w0, 1 ret g(): mov w0, 1 ret b: a: Tagging as a claimed wrong-code bug.
