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:
ebotca...@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...
