[Bug middle-end/101674] New: gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite

[Bug middle-end/101674] New: gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite

[aldyh at gcc dot gnu.org]

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

            Bug ID: 101674
           Summary: gcc.dg/uninit-pred-9_b.c fails after jump threading
                    rewrite
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: aldyh at gcc dot gnu.org
  Target Milestone: ---

The ranger-based jump threader (commit
2e96b5f14e4025691b57d2301d71aa6092ed44bc) shuffles things around in such a way
as to confuse the -Wuninitialized pass.

[Bug middle-end/101674] gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
             Target|ppc64*-*-*                  |powerpc64*-*-*
   Last reconfirmed|                            |2021-07-29
                 CC|                            |msebor at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
I can confirm the test fails (despite the xfail):

FAIL: gcc.dg/uninit-pred-9_b.c bogus warning (test for bogus messages, line 25)

The xfail target should probably be powerpc64*-*-*.  Since the failure is on
line 25 would it make sense to xfail just that assertion?

[Bug middle-end/101674] gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite

[aldyh at gcc dot gnu.org]

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

--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #1)
> I can confirm the test fails (despite the xfail):
> 
> FAIL: gcc.dg/uninit-pred-9_b.c bogus warning (test for bogus messages, line
> 25)
> 
> The xfail target should probably be powerpc64*-*-*.  Since the failure is on
> line 25 would it make sense to xfail just that assertion?

Ahhh. Yes, that seems appropriate.  Feel free to commit it as obvious.  Thanks
for taking care of this.

[Bug middle-end/101674] gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Martin Sebor <msebor@gcc.gnu.org>:

https://gcc.gnu.org/g:2f6bdd51cfe15403085b69c133065ebda4af9bb9

commit r12-2600-g2f6bdd51cfe15403085b69c133065ebda4af9bb9
Author: Martin Sebor <msebor@redhat.com>
Date:   Thu Jul 29 10:11:18 2021 -0600

    Xfail just the failing assertion and correct target.

    Related to:
    PR middle-end/101674 - gcc.dg/uninit-pred-9_b.c fails after jump threading
rewrite

    gcc/testsuite:
            PR middle-end/101674
            * gcc.dg/uninit-pred-9_b.c: Xfail just the failing assertion and
            correct target.

[Bug middle-end/101674] gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Hans-Peter Nilsson <hp@gcc.gnu.org>:

https://gcc.gnu.org/g:309ddde04f2335f51062690328f03ce889be7e22

commit r12-2647-g309ddde04f2335f51062690328f03ce889be7e22
Author: Hans-Peter Nilsson <hp@bitrange.com>
Date:   Sat Jul 31 01:23:20 2021 +0200

    gcc.dg/uninit-pred-9_b.c: Xfail for MMIX too

    Looks like MMIX is the "correct target" too (cf. 2f6bdd51cfe15)
    and from
    https://gcc.gnu.org/pipermail/gcc-testresults/2021-July/710188.html
    it seems powerpc-ibm-aix7.2.3.0 is too, but I've not found
    other targets failing.

    gcc/testsuite:
            PR middle-end/101674
            * gcc.dg/uninit-pred-9_b.c: Xfail for mmix-*-* too.

[Bug middle-end/101674] gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Hans-Peter Nilsson <hp@gcc.gnu.org>:

https://gcc.gnu.org/g:92f7016940e5a7281e3fd7628fbf1360d900b581

commit r12-2843-g92f7016940e5a7281e3fd7628fbf1360d900b581
Author: Hans-Peter Nilsson <hp@axis.com>
Date:   Wed Aug 11 01:40:12 2021 +0200

    gcc.dg/uninit-pred-9_b.c: Xfail for CRIS too

    Adding to the growing list, for autotester accounting purposes.

    FWIW I see this fails for m68k too:
    https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/712395.html
    and moxie:
    https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/712389.html
    and pru:
    https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/712366.html

    testsuite:
            PR middle-end/101674
            * gcc.dg/uninit-pred-9_b.c: Xfail for cris-*-* too.

[Bug middle-end/101674] gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

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

--- Comment #6 from sandra at gcc dot gnu.org ---
Also fails for nios2 (line 20, same as powerpc64).  Are we really just xfailing
this everywhere instead of fixing the bug and/or testcase?  That kind of seems
like sweeping the whole mess under the rug, to me.  :-S

[Bug middle-end/101674] gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite

[vineet.gupta at linux dot dev]

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

Vineet Gupta <vineet.gupta at linux dot dev> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kito at gcc dot gnu.org,
                   |                            |palmer at gcc dot gnu.org,
                   |                            |vineet.gupta at linux dot dev

--- Comment #7 from Vineet Gupta <vineet.gupta at linux dot dev> ---
Failing for riscv as well !

[Bug middle-end/101674] gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Bumping MAX_CHAIN_LEN to 7 removes warnings of it being exceeded during
analysis but the diagnostic still happens.

[Bug middle-end/101674] gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
For the remaining superset_of path we now have

        ((m_16(D) != 0) AND (r_18(D) <= 19) AND (m_16(D) != 100) AND (n_15(D)
<= 9))
        OR ((l_22(D) > 100) AND (NOT (m_16(D) != 0)) AND (r_18(D) <= 19) AND
(m_16(D) != 100) AND (n_15(D) <= 9))

guarding the well-definedness of

        v_59 = PHI <v_58(25), r_18(D)(21)>

and

       ((r_18(D) <= 18))

guarding the use.  The use predicate fails to prove either of the definition
guards which possibly is because the use predicate does not cover the path
from the upthread PHIs to the PHI in question:

<bb 13> [local count: 716722667]:
# v_58 = PHI <v_57(11), v_17(D)(12)>    // related PHI
if (l_22(D) > 100)
  goto <bb 14>; [50.00%]
else
  goto <bb 24>; [50.00%]

<bb 14> [local count: 358361334]:
_6 = m_16(D) <= 99;
_7 = _1 & _6;
if (_7 != 0)
  goto <bb 25>; [37.31%]
else
  goto <bb 26>; [62.69%]

<bb 15> [local count: 183623112]:
# v_59 = PHI <v_58(25), r_18(D)(21)>   // main PHI
if (r_18(D) <= 18)
  goto <bb 16>; [52.89%]
else
  goto <bb 27>; [47.11%]

<bb 16> [local count: 88583700]:
blah (v_59);

here the related PHI def v_58 is marked as possibly undefined so we use
the predicates from its incoming edges (and one more related PHI in BB11).
But the use predicate of v_58 in the v_59 PHI def isn't taken into
account.  That one would be

        ((m_16(D) <= 99) AND (n_15(D) <= 9) AND (l_22(D) > 100))

but that still looks insufficent when combined with (r_18(D) <= 18) to prove

((m_16(D) != 0) AND (r_18(D) <= 19) AND (m_16(D) != 100) AND (n_15(D) <= 9))

in particular the m_16(D) != 0 predicate.  I'm also seeing a missed
simplifcation of NOT (m_16(D) != 0) but that will not help either.