Bug 58227 - [4.9 Regression] wrong code (hangs) at -O3 on x86_64-linux-gnu
Summary: [4.9 Regression] wrong code (hangs) at -O3 on x86_64-linux-gnu
Status: RESOLVED DUPLICATE of bug 58143
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: unknown
: P3 normal
Target Milestone: 4.9.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-23 07:34 UTC by Zhendong Su
Modified: 2014-10-16 01:09 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work: 4.8.1
Known to fail: 4.9.0
Last reconfirmed: 2013-08-23 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zhendong Su 2013-08-23 07:34:19 UTC
The current gcc trunk produces wrong code (that hangs) for the following testcase on x86_64-linux when compiled at -O3 in both 32-bit and 64-bit modes. 

This is a regression from 4.8.x.

It might be related to 58143, but 58143 also fails for 4.8. 


$ gcc-trunk -v
gcc version 4.9.0 20130822 (experimental) [trunk revision 201915] (GCC) 
$ gcc-4.8 -O3 reduced.c
$ a.out
$ gcc-trunk -O2 reduced.c
$ a.out
$ gcc-trunk -O3 reduced.c
$ a.out
^C
$ 


------------------------------------------

int a, b, d, e, f, *g, h, i;
volatile int c;

char foo (unsigned char p)
{
  return p + 1;
}

int bar () 
{
  for (h = 0; h < 3; h = foo (h))
    {
      c;
      for (f = 0; f < 1; f++)
	{
	  i = a && 0 < -2147483647 - h ? 0 : 1;
	  if (e)
	    for (; d;)
	      b = 0;
	  else
	    g = 0;
	}
    }
  return 0;
}

int main ()
{
  bar ();
  return 0;
}
Comment 1 Marek Polacek 2013-08-23 07:43:57 UTC
I think this invokes undefined behavior in third iteration, when h is 2.  Works with s/-2147483647/-2147483647L/.
Comment 2 Zhendong Su 2013-08-23 07:49:56 UTC
But similar to 58143, because of short circuiting (since a == 0), the expression "0 < -2147483647 - h ? 0 : 1" shouldn't be evaluated at all, correct?  Or maybe I'm mistaken?  

Thanks for looking into this Marek!
Comment 3 Marek Polacek 2013-08-23 07:58:28 UTC
Yes, sorry.  Loop invariant motion moves the condition here as well, I suppose (works with -fno-tree-loop-im).  Thus confirmed.
Comment 4 Bernd Edlinger 2013-08-27 12:00:21 UTC
OK, the latest patch from pr58143 seems to fix the deadlock here too.
Comment 5 Richard Biener 2013-10-15 08:15:44 UTC
Duplicate.

*** This bug has been marked as a duplicate of bug 58143 ***