Bug 32544 - [4.2 Regression] miscompiles Mesa's r300 DRI driver with -ftree-vrp
Summary: [4.2 Regression] miscompiles Mesa's r300 DRI driver with -ftree-vrp
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.2.1
: P1 normal
Target Milestone: 4.3.0
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2007-06-29 08:14 UTC by bero
Modified: 2009-03-30 22:10 UTC (History)
6 users (show)

See Also:
Host: i586-pc-linux-gnu
Target: i586-pc-linux-gnu
Build: i586-pc-linux-gnu
Known to work: 4.3.0
Known to fail: 4.2.5
Last reconfirmed: 2007-08-20 08:37:22


Attachments
Preprocessed source, bzip2-ed (78.10 KB, application/x-bzip2)
2007-06-29 08:16 UTC, bero
Details
miscompiles with gcc 4.2 -O2 (237 bytes, text/plain)
2007-08-07 22:33 UTC, Pascal "Pixel" Rigaux
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bero 2007-06-29 08:14:47 UTC
Mesa's r300 DRI driver produces incorrect output (garbles the display) if r300_state.c is compiled with -ftree-vrp (-O2 -fno-tree-vrp works fine; all files except r300_state.c can be compiled with normal -O2).
Comment 1 bero 2007-06-29 08:16:17 UTC
Created attachment 13804 [details]
Preprocessed source, bzip2-ed

Attaching preprocessed source of r300_state.c
Comment 2 Richard Biener 2007-06-29 08:46:12 UTC
Can you narrow it down to a specific function?
Comment 3 bero 2007-06-29 14:17:34 UTC
r300SetupPixelShader()
Comment 4 Richard Biener 2007-07-04 09:49:26 UTC
Sorry, I can't see what is wrong.  There is no effective difference in assembly
with/without -ftree-vrp.
Comment 5 Pascal "Pixel" Rigaux 2007-08-07 22:33:51 UTC
Created attachment 14038 [details]
miscompiles with gcc 4.2 -O2

here is a simple test case reproducing the issue.

eg:

% gcc -O2 ivopts-issue.c && ./a.out && gcc -O2 -fno-ivopts ivopts-issue.c && ./a.out 
0 0 1 2 
2 2 1 1
Comment 6 Pascal "Pixel" Rigaux 2007-08-07 22:41:19 UTC
more info: the tree-vrp issue is raised by ivopts pass:

without ivopts:

  D.1541_13 = 3 - i_31;
  D.1542_14 = (unsigned int) D.1541_13;
  D.1543_15 = D.1542_14 * 4;
  D.1544_16 = (int *) D.1543_15;

with ivopts:

  D.1607_62 = (int *) i_31;
  D.1608_63 = D.1607_62 * -4B;
  D.1544_64 = D.1608_63 + 12B;
  D.1544_16 = D.1544_64;

  vrp finds that D.1608_63 is 0, and so replaces D.1544_64 with 12

  D.1607_62 = (int *) i_31;
  D.1608_63 = D.1607_62 * -4B;
  D.1544_64 = D.1608_63 + 12B;
  D.1544_16 = D.1544_64;
Comment 7 Pascal "Pixel" Rigaux 2007-08-07 22:45:12 UTC
the following patch fixes the testcase ivopts-issue.c, but breaks everything else... someone else will find a correct patch :)

--- gcc-4.2.1/gcc/tree-ssa-loop-ivopts.c.pix    2006-10-06 21:32:04.000000000 +0200
+++ gcc-4.2.1/gcc/tree-ssa-loop-ivopts.c        2007-08-08 00:23:49.000000000 +0200
@@ -3061,7 +3061,9 @@ get_computation_aff (struct loop *loop,
       expr = fold_convert (ctype, expr);
     }
 
-  if (TYPE_UNSIGNED (utype))
+  if (POINTER_TYPE_P (utype))
+    uutype = ctype;
+  else if (TYPE_UNSIGNED (utype))
     uutype = utype;
   else
     {
Comment 8 Pascal "Pixel" Rigaux 2007-08-08 08:45:40 UTC
Known to work: 4.1.2 4.3.0
Known to fail: 4.2.1
Comment 9 Andrew Pinski 2007-08-08 09:07:24 UTC
This should work on the trunk also via the pointer plus branch merge where we no longer get a multiplication in a pointer type.
Comment 10 Richard Biener 2007-08-20 08:37:22 UTC
Confirmed.  (use -m32 on x86_64)
Comment 11 Mark Mitchell 2007-10-09 19:20:37 UTC
Change target milestone to 4.2.3, as 4.2.2 has been released.
Comment 12 Joseph S. Myers 2008-02-01 16:54:29 UTC
4.2.3 is being released now, changing milestones of open bugs to 4.2.4.
Comment 13 Joseph S. Myers 2008-05-19 20:23:19 UTC
4.2.4 is being released, changing milestones to 4.2.5.
Comment 14 Joseph S. Myers 2009-03-30 22:10:13 UTC
Closing 4.2 branch, fixed in 4.3.