Re: Can gcc.dg/torture/pr67828.c be an infinite loop?

[Aldy Hernandez via Gcc]

On 9/24/21 1:37 PM, David Brown wrote:
On 24/09/2021 10:03, Aldy Hernandez via Gcc wrote:
Hi folks.

My upcoming threading improvements turn the test below into an infinite
runtime loop:

int a, b;
short c;

int
main ()
{
   int j, d = 1;
   for (; c >= 0; c++)
     {
BODY:
       a = d;
       d = 0;
       if (b)
     {
       xprintf (0);
       if (j)
         xprintf (0);
     }
     }
   xprintf (d);
   exit (0);
}

On the false edge out of if(b) we thread directly to BODY, eliding the
loop conditional, because we know that c>=0 because it could never
overflow.

Since B is globally initialized to 0, this has the effect of turning the
test into an infinite loop.

Is this correct, or did I miss something?
Aldy



I am wondering about the claim that you can use "b" being 0 to optimise
the conditional.  If the compiler knows that this is the complete
program, that is fair enough.  But since "b" is not static, another
compilation unit could modify "b" before "main" is called.  (In C, it is
legal for another part of the code to call main() - perhaps the
implementation of xprintf does so.  And in C++, a global constructor
could change "b" before main() starts.)

In this case, it was on a thread where we knew we came through the c>=0 
conditional and we hadn't left the function.

Be that as it may, this was something else entirely.  The problem was a 
typo in the path solver that was causing it to use an incorrect range, 
which was then causing the elision.  It had nothing to do with promotion 
rules.  My bad.

Aldy