Jeff has pointed out that after my change adding global ranges to the
path solver, torture/pr55107.c is failing. Before I start digging
deep into the IL, I'd like to make sure this is not either expected or
a bogus test.
Compiling this test on x86 with -Wall yields:
$ gcc -c -O2 pr55107.c -Wall
pr55107.c: In function ‘f’:
pr55107.c:32:51: warning: the omitted middle operand in ‘?:’ will
always be ‘true’, suggest explicit middle operand [-Wparentheses]
32 | ((a = d) ? b = 0 : (**p ? : 1) != (d != 1 ? : (a = 0)))
!= (k ? a : 0)
| ^
pr55107.c:33:11: warning: suggest parentheses around comparison in
operand of ‘!=’ [-Wparentheses]
32 | ((a = d) ? b = 0 : (**p ? : 1) != (d != 1 ? : (a = 0)))
!= (k ? a : 0)
|
~~~~~~~~~~~
33 | < (a *= c = k) && (**p = 0);
| ^~~~~~~~~~~~~~
pr55107.c:33:16: warning: operation on ‘a’ may be undefined [-Wsequence-point]
33 | < (a *= c = k) && (**p = 0);
| ^~
pr55107.c:33:16: warning: operation on ‘a’ may be undefined [-Wsequence-point]
pr55107.c:33:26: warning: value computed is not used [-Wunused-value]
33 | < (a *= c = k) && (**p = 0);
| ^~
pr55107.c:17:14: warning: ‘j’ is used uninitialized [-Wuninitialized]
17 | for (; *j; j++)
| ^~
So it looks like there's some undefined behavior going on, even before
my patch. I'd like to get some feedback, because this is usually the
type of problems I see in the presence of a smarter threader... things
get shuffled around, problematic code gets isolated, and warning
passes have an easier time (or sometimes harder time) diagnosing
things.
Thanks.
Aldy
On Fri, Sep 10, 2021 at 10:31 PM Jeff Law <jeffreya...@gmail.com> wrote:
>
> This change:
> 01b5038718056b024b370b74a874fbd92c5bbab3 is the first bad commit
> commit 01b5038718056b024b370b74a874fbd92c5bbab3
> Author: Aldy Hernandez <al...@redhat.com>
> Date: Thu Sep 9 20:30:28 2021 +0200
>
> Disable threading through latches until after loop optimizations.
>
> The motivation for this patch was enabling the use of global ranges in
> the path solver, but this caused certain properties of loops being
> destroyed which made subsequent loop optimizations to fail.
> Consequently, this patch's mail goal is to disable jump threading
> involving the latch until after loop optimizations have run.
> [ ... ]
>
>
> Is causing a regression on nds32le-elf -- perhaps others as well, this
> just happened to pop first in my tester.
>
> Tests that now fail, but worked before (4 tests):
>
> nds32-sim: gcc.dg/torture/pr55107.c -O2 (test for excess errors)
> nds32-sim: gcc.dg/torture/pr55107.c -O2 (test for excess errors)
> nds32-sim: gcc.dg/torture/pr55107.c -O2 -flto -fno-use-linker-plugin
> -flto-partition=none (test for excess errors)
> nds32-sim: gcc.dg/torture/pr55107.c -O2 -flto -fno-use-linker-plugin
> -flto-partition=none (test for excess errors)
>
> I suspect the underlying cause has
> a reasonable chance of causing problems on other ports.
>
> From the log file:
>
> /home/jlaw/jenkins/workspace/nds32le-elf/gcc/gcc/testsuite/gcc.dg/torture/pr55107.c:
> In function 'f':^M
> /home/jlaw/jenkins/workspace/nds32le-elf/gcc/gcc/testsuite/gcc.dg/torture/pr55107.c:19:21:
> warning: iteration 2147483646 invokes undefined behavior
> [-Waggressive-loop-optimizations]^M
> /home/jlaw/jenkins/workspace/nds32le-elf/gcc/gcc/testsuite/gcc.dg/torture/pr55107.c:19:17:
> note: within this loop^M
>
