Patchwork Fix RTL load motion bug with -fnon-call-exceptions

login
register
mail settings
Submitter Eric Botcazou
Date July 20, 2014, 8:59 p.m.
Message ID <11623327.7xI96XU0YT@polaris>
Download mbox | patch
Permalink /patch/371942/
State New
Headers show

Comments

Eric Botcazou - July 20, 2014, 8:59 p.m.
We have a testcase that is miscompiled at -O3 by our GCC 4.9-based compiler, 
although it isn't by the pristine GCC 4.9 compiler.  You need a specific 
combination of events (aggressive inlining, -fnon-call-exceptions, memory 
accesses marked MEM_NOTRAP_P) which causes RTL load motion to wrongly delete a 
MEM_NOTRAP_P load because there is another load from the same address but 
without MEM_NOTRAP_P, the root cause being that simple_mem will return true 
for the former but false for the latter.  Setting MEM_NOTRAP_P is a best 
effort thing so not setting it should not lead to wrong code.

Tested on x86-64/Linux, applied on the mainline.


2014-07-20  Eric Botcazou  <ebotcazou@adacore.com>

	* cse.c (exp_equiv_p) <MEM>: For GCSE, return 0 for expressions with
	different trapping status if -fnon-call-exceptions is enabled.

Patch

Index: cse.c
===================================================================
--- cse.c	(revision 212833)
+++ cse.c	(working copy)
@@ -2687,6 +2687,13 @@  exp_equiv_p (const_rtx x, const_rtx y, i
 	     the same attributes share the same mem_attrs data structure.  */
 	  if (MEM_ATTRS (x) != MEM_ATTRS (y))
 	    return 0;
+
+	  /* If we are handling exceptions, we cannot consider two expressions
+	     with different trapping status as equivalent, because simple_mem
+	     might accept one and reject the other.  */
+	  if (cfun->can_throw_non_call_exceptions
+	      && (MEM_NOTRAP_P (x) != MEM_NOTRAP_P (y)))
+	    return 0;
 	}
       break;