[PATCH][PR debug/60655] Power/GCC: Reject cross-section symbol subtraction

Maciej W. Rozycki macro@codesourcery.com
Tue Sep 2 10:29:00 GMT 2014


Hi,

 Similarly to ARM, where this issue was seen originally, and likely many 
other targets, the Power ABI does not appear to have a relocation defined 
to support taking a difference of two symbols in different sections each. 
This is seen as a failure in gcc.c-torture/compile/pr60655-2.c:

Executing on host: powerpc-linux-gnu-gcc  -fno-diagnostics-show-caret -fdiagnostics-color=never   -O3 -g  -w -c  -o pr60655-2.o .../gcc/testsuite/gcc.c-torture/compile/pr60655-2.c    (timeout = 300)
/tmp/ccAfNLMj.s: Assembler messages:
/tmp/ccAfNLMj.s:932: Error: can't resolve `L0^A' {*ABS* section} - `.LANCHOR0' {.bss section}
/tmp/ccAfNLMj.s:932: Error: expression too complex
compiler exited with status 1
output is:
/tmp/ccAfNLMj.s: Assembler messages:
/tmp/ccAfNLMj.s:932: Error: can't resolve `L0^A' {*ABS* section} - `.LANCHOR0' {.bss section}
/tmp/ccAfNLMj.s:932: Error: expression too complex

FAIL: gcc.c-torture/compile/pr60655-2.c  -O3 -g  (test for excess errors)
Excess errors:
/tmp/ccAfNLMj.s:932: Error: can't resolve `L0^A' {*ABS* section} - `.LANCHOR0' {.bss section}
/tmp/ccAfNLMj.s:932: Error: expression too complex

Here's a port of the original ARM fix (commit 209269), that removes the 
failure for me.

 Regression-tested with the following powerpc-gnu-linux multilibs:

-mcpu=603e
-mcpu=603e -msoft-float
-mcpu=8540 -mfloat-gprs=single -mspe=yes -mabi=spe
-mcpu=8548 -mfloat-gprs=double -mspe=yes -mabi=spe
-mcpu=7400 -maltivec -mabi=altivec
-mcpu=e6500 -maltivec -mabi=altivec
-mcpu=e5500 -m64
-mcpu=e6500 -m64 -maltivec -mabi=altivec

 OK for trunk and 4.9?

2014-09-02  Maciej W. Rozycki  <macro@codesourcery.com>

	PR debug/60655
	* config/rs6000/rs6000.c (rs6000_const_not_ok_for_debug_p):
	Reject MINUS with SYM_REFs in different sections.

  Maciej

gcc-rs6000-minus-not-ok-for-debug.diff
Index: gcc-fsf-trunk-quilt/gcc/config/rs6000/rs6000.c
===================================================================
--- gcc-fsf-trunk-quilt.orig/gcc/config/rs6000/rs6000.c	2014-08-26 20:30:10.348973028 +0100
+++ gcc-fsf-trunk-quilt/gcc/config/rs6000/rs6000.c	2014-09-01 17:09:23.748927487 +0100
@@ -6974,7 +6974,13 @@ rs6000_delegitimize_address (rtx orig_x)
 
 /* Return true if X shouldn't be emitted into the debug info.
    The linker doesn't like .toc section references from
-   .debug_* sections, so reject .toc section symbols.  */
+   .debug_* sections, so reject .toc section symbols.
+
+   Also as a temporary fix for PR60655 we reject certain MINUS
+   expressions.  Ideally we need to handle most of these cases in
+   the generic part but currently we reject minus (..) (sym_ref).
+   We try to ameliorate the case with minus (sym_ref1) (sym_ref2)
+   where they are in the same section.  */
 
 static bool
 rs6000_const_not_ok_for_debug_p (rtx x)
@@ -6988,6 +6994,35 @@ rs6000_const_not_ok_for_debug_p (rtx x)
 	return true;
     }
 
+  if (GET_CODE (x) == MINUS)
+    {
+      tree decl_op0 = NULL;
+      tree decl_op1 = NULL;
+
+      if (GET_CODE (XEXP (x, 1)) == SYMBOL_REF)
+       {
+	 decl_op1 = SYMBOL_REF_DECL (XEXP (x, 1));
+	 if (decl_op1
+	     && GET_CODE (XEXP (x, 0)) == SYMBOL_REF
+	     && (decl_op0 = SYMBOL_REF_DECL (XEXP (x, 0))))
+	   {
+	     if ((TREE_CODE (decl_op1) == VAR_DECL
+		  || TREE_CODE (decl_op1) == CONST_DECL)
+		 && (TREE_CODE (decl_op0) == VAR_DECL
+		     || TREE_CODE (decl_op0) == CONST_DECL))
+	       return (get_variable_section (decl_op1, false)
+		       != get_variable_section (decl_op0, false));
+
+	     if (TREE_CODE (decl_op1) == LABEL_DECL
+		 && TREE_CODE (decl_op0) == LABEL_DECL)
+	       return (DECL_CONTEXT (decl_op1)
+		       != DECL_CONTEXT (decl_op0));
+	   }
+
+	 return true;
+       }
+    }
+
   return false;
 }
 



More information about the Gcc-patches mailing list