On 9/13/2021 7:29 AM, Aldy Hernandez wrote:
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.
The original issue was PRE hanging, so I'd lean towards keeping the test
as-is and instead twiddling any warning flags we can to make the
diagnostics go away.
jeff
