[Bug middle-end/46685] [4.6 Regression] New stack alignment failures with -fpic

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685

--- Comment #11 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-12-02 11:30:54 UTC ---
> Alternatively, we could do something like:
> --- gcc/config/sparc/sparc.c.jj    2010-11-26 18:39:04.000000000 +0100
> +++ gcc/config/sparc/sparc.c    2010-11-29 15:35:00.727219374 +0100
> @@ -1066,8 +1066,13 @@ sparc_expand_move (enum machine_mode mod
>       are absolutely sure that X is in the same segment as the GOT.
>       Unfortunately, the flexibility of linker scripts means that we
>       can't be sure of that in general, so assume that _G_O_T_-relative
> -     accesses are never valid on VxWorks.  */
> -      if (GET_CODE (operands[1]) == LABEL_REF && !TARGET_VXWORKS_RTP)
> +     accesses are never valid on VxWorks.
> +     If the label is non-local, it might be placed in a different section
> +     from . and movMODE_pic_label_ref patterns require the label and .
> +     to be in the same section.  */
> +      if (GET_CODE (operands[1]) == LABEL_REF
> +      && !TARGET_VXWORKS_RTP
> +      && !LABEL_REF_NONLOCAL_P (operands[1]))
>      {
>        if (mode == SImode)
>          {
> 
> Not sure if even in current function it could happen that sparc_expand_move
> is asked for a label that is in the other partition.  I mean something like:
> __attribute__((noinline, noclone))
> void bar (void *x)
> {
>   asm volatile ("" : : "r" (x) : "memory");
> }
> 
> __attribute__((noinline, noclone))
> void baz (void)
> {
>   asm volatile ("" : : : "memory");
> }
> 
> __attribute__((noinline, noclone))
> int foo (int x)
> {
>   __label__ lab;
>   if (__builtin_expect (x, 0))
>     {
>       lab:
>       baz ();
>       return 2;
>     }
>   bar (&&lab);
>   return 1;
> }
> 
> int
> main (void)
> {
>   int x, i;
>   asm volatile ("" : "=r" (x) : "0" (0));
>   for (i = 0; i < 1000000; i++)
>     foo (x);
>   return 0;
> }
> 
> first compiled/linked with -O2 -fprofile-generate
> -freorder-blocks-and-partition -fpic, then executed, then compiled again with
> -O2 -fprofile-use -freorder-blocks-and-partition -fpic.  At least on
> x86_64-linux the baz () bb is .text.unlikely, while bar (&&lab) is .text
> section.  Now, I guess this wouldn't assemble on sparc-linux or Solaris, even
> before Honza's patch.

This testcase just crashes the compiler. :-)  But, yes, once the patchlet

Index: config/sparc/sparc.c
===================================================================
--- config/sparc/sparc.c    (revision 167365)
+++ config/sparc/sparc.c    (working copy)
@@ -9453,6 +9485,7 @@ sparc_file_end (void)
       DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN;
       DECL_VISIBILITY_SPECIFIED (decl) = 1;
       allocate_struct_function (decl, true);
+      cfun->is_thunk = 1;
       current_function_decl = decl;
       init_varasm_status ();
       assemble_start_function (decl, name);

is applied, your prediction is verified:

ebotcazou@grobluk:~/obj$ gcc/xgcc -Bgcc -O2 -fprofile-use
-freorder-blocks-and-partition -fpic pr46685.c
/tmp/ccg98MwA.s: Assembler messages:
/tmp/ccg98MwA.s:71: Error: operation combines symbols in different segments
/tmp/ccg98MwA.s:72: Error: operation combines symbols in different segments

> Or simply amend the second patch above and disable this optimization even for
> flag_reorder_blocks_and_partition.

This is good enough I'd think.  Testing...