Bug 58248 - [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
Summary: [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
Status: RESOLVED DUPLICATE of bug 57393
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-27 06:23 UTC by Zhendong Su
Modified: 2013-08-27 20:05 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zhendong Su 2013-08-27 06:23:15 UTC
The current gcc trunk produces wrong code 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.


$ gcc-trunk -v
gcc version 4.9.0 20130826 (experimental) [trunk revision 201986] (GCC) 
$ gcc-trunk -O2 reduced.c
$ a.out
1
$ gcc-4.8 -O3 reduced.c
$ a.out
1
$ gcc-trunk -O3 reduced.c
$ a.out
0
$ 


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


int printf (const char *, ...);

struct S
{
  int u;
}; 

int a = 1, b, c = 1, e, *f, *g;

static struct S d = {6};

void foo (int *p)
{
  c &= a != *p;
}

int main ()
{
  struct S h = d;
  int **i = &f;
  *i = g = &b;
  for (; h.u; h.u--)
    {
      for (e = 0; e < 2; e++)
        {
	  foo (*i);
	  *g = 0 > **i;
        }
      *f = 0;
    }
  printf ("%d\n", c);
  return 0;
}
Comment 1 Jakub Jelinek 2013-08-27 07:30:39 UTC
I get ICE instead, starting with r199048 .
Comment 2 Zhendong Su 2013-08-27 07:34:36 UTC
Jakub, perhaps you used the testcase from 58247, not the one below?  

I double checked and still get wrong code on this one.
Comment 3 Zhendong Su 2013-08-27 07:39:17 UTC
(In reply to Jakub Jelinek from comment #1)
> I get ICE instead, starting with r199048 .

This means that 58247 is probably indeed a dup of 57592, which also started with r199048 (according to the comment on 57592).
Comment 4 Jakub Jelinek 2013-08-27 07:41:17 UTC
No, the only change I've made to this testcase was instead of using
printf use if (c != 1) __builtin_abort ();.
If you can, next time please try to adjust the testcases such that they abort if miscompiled and exit with 0 exit status otherwise, gcc testsuite usually doesn't check for output from the testcases.
Comment 5 Zhendong Su 2013-08-27 07:55:25 UTC
(In reply to Jakub Jelinek from comment #4)
> No, the only change I've made to this testcase was instead of using
> printf use if (c != 1) __builtin_abort ();.

I checked the modified test case below: 

---------

struct S
{
  int u;
}; 

int a = 1, b, c = 1, e, *f, *g;

static struct S d = {6};

void foo (int *p)
{
  c &= a != *p;
}

int main ()
{
  struct S h = d;
  int **i = &f;
  *i = g = &b;
  for (; h.u; h.u--)
    {
      for (e = 0; e < 2; e++)
        {
	  foo (*i);
	  *g = 0 > **i;
        }
      *f = 0;
    }

  if (c != 1)
    __builtin_abort (); 

  return 0;
}

---------

The log: 

$ gcc-trunk -O3 small.c
$ a.out
Aborted (core dumped)
$ gcc-trunk -O2 small.c
$ a.out
$ gcc-4.8 -O3 small.c
$ a.out
$ 

> If you can, next time please try to adjust the testcases such that they
> abort if miscompiled and exit with 0 exit status otherwise, gcc testsuite
> usually doesn't check for output from the testcases.

Got it; will do.
Comment 6 Jakub Jelinek 2013-08-27 08:05:21 UTC
Are you sure your gcc isn't configured with --enable-checking=release ?
I really get:
pr58248.c: In function ‘main’:
pr58248.c:14:1: error: definition in block 2 follows the use
 main ()
 ^
for SSA_NAME: _126 in statement:
c.2_78 = _16 & _126;
pr58248.c:14:1: internal compiler error: verify_ssa failed
Comment 7 Joost VandeVondele 2013-08-27 09:09:39 UTC
(In reply to Jakub Jelinek from comment #6)
> Are you sure your gcc isn't configured with --enable-checking=release ?
> I really get:
> pr58248.c: In function ‘main’:
> pr58248.c:14:1: error: definition in block 2 follows the use
>  main ()
>  ^
> for SSA_NAME: _126 in statement:
> c.2_78 = _16 & _126;
> pr58248.c:14:1: internal compiler error: verify_ssa failed

which makes it very likely yet another dup of PR57393

*** This bug has been marked as a duplicate of bug 57393 ***
Comment 8 Zhendong Su 2013-08-27 19:54:27 UTC
(In reply to Jakub Jelinek from comment #6)
> Are you sure your gcc isn't configured with --enable-checking=release ?

Jakub, below is my gcc configure: 

Configured with: ../gcc-trunk/configure --enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-checking --with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk

Should I do "--enable-checking=release" instead of "--disable-checking"? 

> I really get:
> pr58248.c: In function ‘main’:
> pr58248.c:14:1: error: definition in block 2 follows the use
>  main ()
>  ^
> for SSA_NAME: _126 in statement:
> c.2_78 = _16 & _126;
> pr58248.c:14:1: internal compiler error: verify_ssa failed
Comment 9 Jakub Jelinek 2013-08-27 20:01:44 UTC
For testing bugs against trunk it is better to omit both --disable-checking and --enable-checking=release and just use the default.
Because otherwise the compiler doesn't perform various verifications and you could see a miscompilation which would otherwise be caught already at compile time.
Comment 10 Zhendong Su 2013-08-27 20:05:05 UTC
(In reply to Jakub Jelinek from comment #9)
> For testing bugs against trunk it is better to omit both --disable-checking
> and --enable-checking=release and just use the default.
> Because otherwise the compiler doesn't perform various verifications and you
> could see a miscompilation which would otherwise be caught already at
> compile time.

Okay, thanks Jakub.