[Bug c/114206] New: GCC generates wrong-code

[Bug c/114206] New: GCC generates wrong-code

[congli at smail dot nju.edu.cn]

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

            Bug ID: 114206
           Summary: GCC generates wrong-code
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: congli at smail dot nju.edu.cn
  Target Milestone: ---

The program shown below presents a wrong code bug, where the correct results
should be "f(0, NULL) = 0" while `-Os -fno-tree-ccp -fno-tree-copy-prop
-fno-tree-forwprop -fno-tree-fre -fno-tree-vrp` prints "f(0, NULL) = 1".

```
#include <stdio.h>

int f(int t, const int *a) {
  const int b[4] = {0};

  if (t == 0) {
    return f(1, b);
  } else {
    return b == a;
  }
}

int main(void) {
  printf("f(0, NULL) = %d\n", f(0, NULL));
}
```

Compiler Explorer: https://gcc.godbolt.org/z/W164xWMrP 

We checked the assembly, finding that it is weird that the compiler generates a
`cmove` instruction. See explanations below:

```
f:
        leaq    -16(%rsp), %rax -> RAX = RSP-16
        testl   %edi, %edi      -> we called f(0, NULL); %edi = 0, ZF = 1
        cmove   %rax, %rsi      -> condition fulfilled; RSI=RAX=RSP-16; weird
generation
        cmpq    %rax, %rsi      -> RSI=RAX; ZF=1
        sete    %al             -> AL = 1
        movzbl  %al, %eax       -> EAX = 1 (error)
        ret
```

[Bug tree-optimization/114206] GCC generates wrong-code

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |tree-optimization

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think both 0 and 1 are correct here.

The question becomes does the address of b need to be different between
different calls of f. I am not 100% convinced it needs to be different.

[Bug tree-optimization/114206] recursive function call vs local variable addresses

[congli at smail dot nju.edu.cn]

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

--- Comment #2 from congli <congli at smail dot nju.edu.cn> ---
That's correct. But I think it is not that reasonable if we treat the `b` like
`b` is a `static const` variable rather than a `const` variable? Any documents
telling this?

[Bug tree-optimization/114206] recursive function call vs local variable addresses

[congli at smail dot nju.edu.cn]

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

--- Comment #3 from congli <congli at smail dot nju.edu.cn> ---
How about this one: https://gcc.godbolt.org/z/Wvhddb7nf?

We ensured the two `b`s are different at each f() call.

[Bug tree-optimization/114206] recursive function call vs local variable addresses

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #4 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> I think both 0 and 1 are correct here.
> 
> The question becomes does the address of b need to be different between
> different calls of f. I am not 100% convinced it needs to be different.

It looks like they needs to be different as they refer different objects and
the lifetime of both object has still not ended when comparing them.

[Bug tree-optimization/114206] recursive function call vs local variable addresses

[arsen at gcc dot gnu.org]

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

Arsen Arsenović <arsen at gcc dot gnu.org> changed:

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

--- Comment #5 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
(In reply to Xi Ruoyao from comment #4)
> It looks like they needs to be different as they refer different objects and
> the lifetime of both object has still not ended when comparing them.
this seems the case to me also

[Bug tree-optimization/114206] recursive function call vs local variable addresses

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-03-04

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
So we simplify this and RTL expand from

int f (int t, const int * a)
{
  const int b[4];
  _Bool _1;
  int _8;

  <bb 2> [local count: 1073741824]:
  if (t_3(D) == 0)
    goto <bb 3>; [49.25%]
  else
    goto <bb 4>; [50.75%]

  <bb 3> [local count: 528857912]:

  <bb 4> [local count: 1073741824]:
  # a_11 = PHI <a_5(D)(2), &b(3)>
  _1 = &b == a_11;
  _8 = (int) _1;
  b ={v} {CLOBBER(eos)};
  return _8;

We apply tail-recursion optimization here which coalescs both slots which
are used just by their address.  IIRC tail-recursion analysis uses alias
analysis to be able to handle some cases where TREE_ADDRESSABLE vars are
passed.

We miss considering variables live that are passed by reference (but otherwise
are "unused").

As you needed to cut off quite some optimizations to early simplify the
b == a compare this is a bit academic or needs much more obfuscation of the
compare to actually matter.

But yes, it's a bug.

[Bug tree-optimization/114206] [11/12/13/14 Regression] recursive function call vs local variable addresses

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.5.3
            Summary|recursive function call vs  |[11/12/13/14 Regression]
                   |local variable addresses    |recursive function call vs
                   |                            |local variable addresses
   Target Milestone|---                         |11.5
      Known to fail|                            |4.6.3, 4.7.3, 5.1.0

[Bug tree-optimization/114206] [11/12/13/14 Regression] recursive function call vs local variable addresses

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org
           Priority|P3                          |P2

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r0-92161-g33977f81620a3e495be87d0381544f8ad26b2782