[Bug tree-optimization/104754] New: gcc.dg/pr102892-1.c FAILs

[Bug tree-optimization/104754] New: gcc.dg/pr102892-1.c FAILs

[ro at gcc dot gnu.org]

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

            Bug ID: 104754
           Summary: gcc.dg/pr102892-1.c FAILs
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
                CC: aldyh at gcc dot gnu.org, hjl.tools at gmail dot com
  Target Milestone: ---
            Target: sparc*-sun-solaris2.11, mipsel-mti-elf,
                    s390x-ibm-linux-gnu,hppa2.0w-hp-hpux11.11,
                    m68k-unknown-linux-gnu

The gcc.dg/pr102892-1.c test FAILs on Solaris/SPARC (32 and 64-bit) since its
introduction:

+FAIL: gcc.dg/pr102892-1.c (test for excess errors)

Excess errors:
Undefined                       first referenced
 symbol                             in file
foo                                 /var/tmp//ccwHT.Oa.o

According to gcc-testresults, there are quite a number of other targets
affected
as well.

[Bug tree-optimization/104754] gcc.dg/pr102892-1.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0

[Bug tree-optimization/104754] gcc.dg/pr102892-1.c FAILs

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-03-03
                 CC|                            |amacleod at redhat dot com

--- Comment #1 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Confirmed on a cross to m68k-unknown-linux-gnu.

Interestingly this may actually be a regression against GCC11, at least on this
target (and possibly the others mentioned though I haven't checked).

The test verifies that there are no calls to foo().  On m68k the gate to foo()
flows through here (threadfull2 dump right before vrp2):

  <bb 3> [local count: 715863673]:
  # ivtmp.9_23 = PHI <ivtmp.9_24(11), ivtmp.9_7(9)>
  bar ();
  _2 = (void *) ivtmp.9_23;
  _1 = MEM[(long int *)_2];
  ivtmp.9_24 = ivtmp.9_23 + 4;
  if (_1 == 1)
    goto <bb 4>; [20.24%]
  else
    goto <bb 5>; [79.76%]

  <bb 4> [local count: 144890806]:
  foo ();

ivtmp.9_24 has been set previously in BB9 to:

  ivtmp.9_7 = (unsigned int) &b;

VRP2 can't seem to do anything with the above sequence, since it can't figure
out what _1 is.  I suppose it could, since there is enough information to to
get at "b" at -O3.

On x86, where the test passes, we have the following before vrp2:

 <bb 3> [local count: 477266310]:
  # c_4 = PHI <c_14(7)>
  bar ();
  _15 = (sizetype) c_4;
  _17 = MEM[(long int *)&b + _15 * 8];
  if (_17 == 1)
    goto <bb 4>; [20.24%]
  else
    goto <bb 5>; [79.76%]

  <bb 4> [local count: 96598701]:
  foo ();
  c_29 = c_4 + 1;
  goto <bb 8>; [100.00%]

which vrp2 can happily optimize to:

  <bb 6> [local count: 477266310]:
  bar ();
  _17 = 0;
  if (_17 == 1)
    goto <bb 3>; [20.24%]
  else
    goto <bb 4>; [79.76%]
...
...

 <bb 3> [local count: 96598701]:
  foo ();
  goto <bb 7>; [100.00%]

Thus leading to foo's demise by ccp4.

I haven't dug deep, but this is likely due to the pointer equivalence tracking
we use in evrp/VRP2 not being able to see that this is all funny talk for b[]:

  ivtmp.9_7 = (unsigned int) &b;
...
...
  # ivtmp.9_23 = PHI <ivtmp.9_24(11), ivtmp.9_7(9)>
  _2 = (void *) ivtmp.9_23;
  _1 = MEM[(long int *)_2];
  if (_1 == 1)

We have plans for a proper pointer range class for GCC13, though I wonder
whether we'll be able to handle the above gymnastics.

FWIW, the above transformation seems to be ivopts at play.

Whereas on x86 we go from:

 <bb 3> [local count: 715863673]:
  # c_19 = PHI <c_14(12), c_20(10)>
  bar ();
  _1 = b[c_19][0];
  if (_1 == 1)

to:

  <bb 3> [local count: 715863673]:
  # c_19 = PHI <c_14(12), c_20(10)>
  bar ();
  _23 = (sizetype) c_19;
  _1 = MEM[(long int *)&b + _23 * 8];
  if (_1 == 1)
    goto <bb 4>; [20.24%]

on m68k we transform the sequence to:

  <bb 3> [local count: 715863673]:
  # ivtmp.9_23 = PHI <ivtmp.9_24(12), ivtmp.9_7(10)>
  bar ();
  _2 = (void *) ivtmp.9_23;
  _1 = MEM[(long int *)_2];
  ivtmp.9_24 = ivtmp.9_23 + 4;
  if (_1 == 1)

Perhaps someone with more target-foo can opine.

[Bug tree-optimization/104754] gcc.dg/pr102892-1.c FAILs

[aldyh at gcc dot gnu.org]

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

--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
BTW, on GCC11, ivopts doesn't even get a whack at it.  The whole thing is
optimized away by .fre4:

int main ()
{
  long int a;
  long int c;

  <bb 2> [local count: 44232128]:
  if (a_9(D) <= 0)
    goto <bb 13>; [89.00%]
  else
    goto <bb 7>; [11.00%]

  <bb 13> [local count: 39366592]:
  bar ();
  bar ();

  <bb 7> [local count: 44232131]:
  return 0;

}

Perhaps this is a regression elsewhere.

[Bug tree-optimization/104754] gcc.dg/pr102892-1.c FAILs

[aldyh at gcc dot gnu.org]

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

--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Upon closer inspection, evrp in GCC11 and mainline are generating slightly
different code which keeps FRE from cleaning this up in mainline.

Mainline is transforming the conditional here:

 <bb 8> :
  # c_3 = PHI <0(2), c_2(7)>
  # a_4 = PHI <a_9(D)(2), a_12(7)>
  if (a_4 <= 0)
    goto <bb 6>; [INV]
  else
    goto <bb 9>; [INV]

...into a_4 != 1.

This doesn't make a lot of sense until you realize that the testcase is
invoking undefined behavior.  Well, it still doesn't make sense, but "a" is
uninitialized in the test:

  for (long a; a < 1; ++a)

We should either initialize a to 0, or remove the test altogether.

[Bug tree-optimization/104754] gcc.dg/pr102892-1.c FAILs

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|12.0                        |12.2

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 12.1 is being released, retargeting bugs to GCC 12.2.

[Bug tree-optimization/104754] gcc.dg/pr102892-1.c FAILs

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|12.3                        |12.4

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 12.3 is being released, retargeting bugs to GCC 12.4.