[Bug tree-optimization/106064] New: Wrong code comparing two global zero-sized arrays

[Bug tree-optimization/106064] New: Wrong code comparing two global zero-sized arrays

[acoplan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064

            Bug ID: 106064
           Summary: Wrong code comparing two global zero-sized arrays
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

For the following C code:

int a[0] = {};
int b[0] = {};
int f(void)
{
    return a != b;
}
int g(void)
{
    return (__UINTPTR_TYPE__)a != (__UINTPTR_TYPE__)b;
}

on AArch64 at -O2, we generate:

f:
        mov     w0, 1
        ret
g:
        mov     w0, 0
        ret

so f and g get optimized in contradictory ways. At least one of them must be
wrong.

[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays

[ktkachov at gcc dot gnu.org]

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.

[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays

[mikpelinux at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064

Mikael Pettersson <mikpelinux at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpelinux at gmail dot com

--- Comment #2 from Mikael Pettersson <mikpelinux at gmail dot com> ---
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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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

[acoplan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064

Alex Coplan <acoplan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #5 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Bisection shows this changed with
r9-5411-g93aa3c4aca3647645cd5bce724f9d2126de4b5ea on AArch64:

commit 93aa3c4aca3647645cd5bce724f9d2126de4b5ea (refs/bisect/bad)
Author: Jakub Jelinek <jakub@redhat.com>
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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
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

[acoplan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064

--- Comment #7 from Alex Coplan <acoplan at gcc dot gnu.org> ---
(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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[acoplan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064

--- Comment #9 from Alex Coplan <acoplan at gcc dot gnu.org> ---
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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
IMHO it is.

[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays

[acoplan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064

--- Comment #11 from Alex Coplan <acoplan at gcc dot gnu.org> ---
(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

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064

--- Comment #12 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
(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

[acoplan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064

--- Comment #13 from Alex Coplan <acoplan at gcc dot gnu.org> ---
(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

[acoplan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064

Alex Coplan <acoplan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #14 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Closing as invalid, then, given that (as Jakub says) f is UB and the codegen
for g is correct.