[Bug go/66870] New: split stack issues on ppc64le and ppc64

[Bug go/66870] New: split stack issues on ppc64le and ppc64

[boger at us dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

            Bug ID: 66870
           Summary: split stack issues on ppc64le and ppc64
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
          Assignee: ian at airs dot com
          Reporter: boger at us dot ibm.com
                CC: amodra at gmail dot com, cmang at google dot com,
                    schwab@linux-m68k.org
  Target Milestone: ---
            Target: ppc64le, ppc64

Created attachment 35977
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35977&action=edit
Detect no_split_stack attribute when generating split stack prologue.

There are a few issues to be resolved with the split stack implementation on
ppc64le, ppc64, and disabling it correctly when building for ppc (32 bit BE).

1) When building on a system with glibc >= 2.18 and doing a multilib build, the
ppc 32 build incorrectly has the split stack flag set, causing an error during
the build.  This was identified in gcc-patches and a proposed fix suggested:

https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00963.html
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01038.html

(Note:  this seems to fix the problem but I don't understand why.  The setting
of the flag was simply moved past a few statements and I don't see why that
should affect the outcome, since the opt argument passed in this case is
&global_options.)

2) For functions with the _no_split_stack attribute set, the split stack code
generation was not always correct on ppc64le & ppc64.  I have a patch for that
which is attached.  This problem was not obvious when building on ppc64le
(where most of my testing was done) but occurs often when built on ppc64.

3) The file gcc/go/gospec.c generates options to be passed to the linker based
on a define of #TARGET_CAN_SPLIT_STACK but this define is never set for a build
for ppc64le or ppc64.  The first occurrence in the function
lang_specific_driver generates the fsplit-stack option when calling the linker,
the second occurrence sets -Wl,-u pthread_create.  I believe the setting of
this define has to be consistent with the result of rs6000_supports_split_stack
in gcc/common/config/rs6000/rs6000-common.c -- but that function depends on the
setting of rs6000_isa_flags which has not been updated by the time
lang_specific_driver is called.  I'm assuming it is wrong for these options not
to be generated and passed to the linker when using split stack?

4) I believe we always want to use the gold linker with gccgo on ppc64le and
ppc64 and probably ppc is OK too.  This is necessary to get the minimum storage
allocated for goroutines (which is the whole point of providing this option)
and also prevents errors with split stack that could happen in some cases. 
I've exchanged some notes with iant on this topic and he suggested this:

The -fuse-ld=gold option is newer than gccgo.  I suppose it would be
nice if:

* the GCC configure process checks whether -fuse-ld=gold works; if so:

  * -fuse-ld=gold is passed to the libgo configure/build

     >>> I think this is already done by the libgo configure -- or at least it
attempts to see if the linker associated with the gccgo it is using to build
libgo supports split stack and then sets the flag
libgo_cv_c_linker_supports_split_stack and that makes it all work.  So if we
build gccgo with the gold linker as its linker then this should just work.

  * -fuse-ld=gold is used by default by the gccgo driver program

     >>> Not sure how best to do this just for gccgo and not the other gcc
compilers.  I can keep looking but if anyone has a suggestion let me know.

There are probably other creative ways to do this by setting spec defines that
are only available for ppc64le, ppc64 builds but haven't figured it out yet.

[Bug go/66870] split stack issues on ppc64le and ppc64

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #1 from Ian Lance Taylor <ian at airs dot com> ---
The various issues in this bug are in different parts of the code base.  The
bug is assigned to me, but, to be clear, I have no plans to work on anything in
the PPC-specific code.

For x86, TARGET_CAN_SPLIT_STACK is defined in
gcc/config/i386/gnu-user-common.h.  The intent of the code in gospec.c is to
pass -fsplit-stack and -Wl,-u,pthread_create when linking.  When compiling,
split stack is turned on by the code in go_langhook_init_options_struct in
gcc/go/go-lang.c.  When linking, we want to pass -fsplit-stack so that
gcc/gcc.c uses STACK_SPLIT_SPEC.  If the target defines TARGET_CAN_SPLIT_STACK
for all cases where it might support it, I think the code will more or less
work even for cases where split stack is not supported.  If we don't pass those
options, then the split-stack code will not work entirely correctly because new
threads won't know their stack size.

[Bug go/66870] split stack issues on ppc64le and ppc64

[boger at us dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #2 from boger at us dot ibm.com ---
(In reply to Ian Lance Taylor from comment #1)
> The various issues in this bug are in different parts of the code base.  The
> bug is assigned to me, but, to be clear, I have no plans to work on anything
> in the PPC-specific code.
> 

Understood.

> For x86, TARGET_CAN_SPLIT_STACK is defined in
> gcc/config/i386/gnu-user-common.h.  The intent of the code in gospec.c is to
> pass -fsplit-stack and -Wl,-u,pthread_create when linking.  When compiling,
> split stack is turned on by the code in go_langhook_init_options_struct in
> gcc/go/go-lang.c.  When linking, we want to pass -fsplit-stack so that
> gcc/gcc.c uses STACK_SPLIT_SPEC.  If the target defines
> TARGET_CAN_SPLIT_STACK for all cases where it might support it, I think the
> code will more or less work even for cases where split stack is not
> supported.  If we don't pass those options, then the split-stack code will
> not work entirely correctly because new threads won't know their stack size.

In gcc.c there is STACK_SPLIT_SPEC which sets --wrap=pthread_create in the
LINK_COMMAND_SPEC if -fsplit-stack is set.  Is there a reason there are 2
different split stack dependent link options are being set in two different
ways?

[Bug go/66870] split stack issues on ppc64le and ppc64

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #3 from Ian Lance Taylor <ian at airs dot com> ---
> In gcc.c there is STACK_SPLIT_SPEC which sets --wrap=pthread_create in the LINK_COMMAND_SPEC if -fsplit-stack is set.  Is there a reason there are 2 different split stack dependent link options are being set in two different ways?


Sort of.  All uses of -fsplit-stack can and should pass
-Wl,--wrap=pthread_create to the linker.  That option does nothing if the
program is not threaded.  If the program is threaded it will cause the code in
libgcc/generic-morestack-thread.c to be used.

All uses of -fsplit-stack and -static for threaded code should pass
-Wl,-u,pthread_create to the linker.  Otherwise, in some cases, we may not pull
in the threading functions we need.  But, unlike the --wrap option, if the
program is not threaded, and not linked against -lpthread, this option will
cause the link to fail.  Go programs are always threaded, so it's safe to add
this in gospec.c.  It's not safe to add it in a link spec in gcc.c, unless we
have some way of determining from the link spec whether the program is
threaded.  (There is some discussion of why this is needed at
https://groups.google.com/d/msg/golang-nuts/y2RIy0XLJ24/uFIdOE8wPL8J .)

[Bug go/66870] split stack issues on ppc64le and ppc64

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #4 from Andreas Schwab <schwab@linux-m68k.org> ---
> past a few statements

Huh??

[Bug go/66870] split stack issues on ppc64le and ppc64

[boger at us dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #5 from boger at us dot ibm.com ---
(In reply to Andreas Schwab from comment #4)
> > past a few statements
> 
> Huh??

Here is your patch

diff --git a/gcc/go/go-lang.c b/gcc/go/go-lang.c
index ce4dd9b..d952e0f 100644
--- a/gcc/go/go-lang.c
+++ b/gcc/go/go-lang.c
@@ -158,10 +158,6 @@ go_langhook_init_options_struct (struct gcc_options *opts)
   opts->x_flag_errno_math = 0;
   opts->frontend_set_flag_errno_math = true;

-  /* We turn on stack splitting if we can.  */
-  if (targetm_common.supports_split_stack (false, opts))
-    opts->x_flag_split_stack = 1;
-
   /* Exceptions are used to handle recovering from panics.  */
   opts->x_flag_exceptions = 1;
   opts->x_flag_non_call_exceptions = 1;
@@ -295,6 +291,11 @@ go_langhook_post_options (const char **pfilename
ATTRIBUTE_UNUSED)
       && global_options.x_write_symbols == NO_DEBUG)
     global_options.x_write_symbols = PREFERRED_DEBUGGING_TYPE;

+  /* We turn on stack splitting if we can.  */
+  if (!global_options_set.x_flag_split_stack
+      && targetm_common.supports_split_stack (false, &global_options))
+    global_options.x_flag_split_stack = 1;
+
   /* Returning false means that the backend should be used.  */
   return false;
 }

Your change moved the if statement containing the call to
targetm_common.supports_split_stack to a different location in the file (past a
few statements) and re-added them along with a check for
global_options_set.x_flag_split_stack.

It looks to me that the values in the rs6000_isa_flags are still the same
whether you call supports_split_stack where it was or where you moved it to. 
I'm trying to fix some of the other issues mentioned in this bugzilla and even
with your fix I sometimes hit the original problem when building with m32.

[Bug go/66870] split stack issues on ppc64le and ppc64

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #6 from Andreas Schwab <schwab@linux-m68k.org> ---
> (past a few statements)

Huh?

@@ -158,10 +158,6 @@ go_langhook_init_options_struct (struct gcc_options *opts)
@@ -295,6 +291,11 @@ go_langhook_post_options (const char **pfilename

[Bug go/66870] split stack issues on ppc64le and ppc64

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-07-15
     Ever confirmed|0                           |1

--- Comment #7 from Alan Modra <amodra at gmail dot com> ---
The attached patch looks good, but it would be slightly better if the condition
"flags_split_stack && lookup_attribute (...) == 0" were used throughout
rs6000_emit_prologue.  Probably best implemented by assigning a new auto var at
the start of rs6000_emit_prologue then using that in place of flag_split_stack.

[Bug go/66870] split stack issues on ppc64le and ppc64

[boger at us dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #8 from boger at us dot ibm.com ---
Created attachment 35989
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35989&action=edit
Clean up checks for flag_split_stack and attribute no_split_stack

Made the change related to Alan's comment for my patch to rs6000.c.

[Bug go/66870] split stack issues on ppc64le and ppc64

[boger at us dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #9 from boger at us dot ibm.com ---
(In reply to Andreas Schwab from comment #6)
> > (past a few statements)
> 
> Huh?
> 
> @@ -158,10 +158,6 @@ go_langhook_init_options_struct (struct gcc_options
> *opts)
> @@ -295,6 +291,11 @@ go_langhook_post_options (const char **pfilename


Sorry about that.

Would you submit your change?

[Bug go/66870] split stack issues on ppc64le and ppc64

[boger at us dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #10 from boger at us dot ibm.com ---
Now that I am building on ppc64 with a new enough glibc, using my latest
patches for rs6000.c and Andreas' patch, and forcing the gold linker to be
used, I am hitting a testcase failure in the libgo fmt test.  

The failure is a segv, gdb shows this:

   0x10024aa0 <fmt.free.pN6_fmt.ss>:    ld      r0,-28736(r13)
   0x10024aa4 <fmt.free.pN6_fmt.ss+4>:  addi    r12,r1,-160
   0x10024aa8 <fmt.free.pN6_fmt.ss+8>:  nop
   0x10024aac <fmt.free.pN6_fmt.ss+12>: cmpld   cr7,r12,r0
   0x10024ab0 <fmt.free.pN6_fmt.ss+16>: blt-    cr7,0x10024b78
<fmt.free.pN6_fmt.ss+216>
   0x10024ab4 <fmt.free.pN6_fmt.ss+20>: rldicl. r9,r4,8,56
=> 0x10024ab8 <fmt.free.pN6_fmt.ss+24>: std     r4,56(r12)
   0x10024abc <fmt.free.pN6_fmt.ss+28>: std     r5,64(r12)
   0x10024ac0 <fmt.free.pN6_fmt.ss+32>: std     r6,72(r12)
   0x10024ac4 <fmt.free.pN6_fmt.ss+36>: std     r7,80(r12)

r12 does not contain the correct value.  If look below in this function where
the call to __morestack was, I see this:

0x10024b78 <fmt.free.pN6_fmt.ss+216>:   mflr    r0
   0x10024b7c <fmt.free.pN6_fmt.ss+220>:        std     r0,16(r1)
   0x10024b80 <fmt.free.pN6_fmt.ss+224>:        bl      0x1004ed18
<.__morestack>
   0x10024b84 <fmt.free.pN6_fmt.ss+228>:        ld      r0,16(r1)
   0x10024b88 <fmt.free.pN6_fmt.ss+232>:        mtlr    r0
   0x10024b8c <fmt.free.pN6_fmt.ss+236>:        blr
   0x10024b90 <fmt.free.pN6_fmt.ss+240>:        b       0x10024ab4
<fmt.free.pN6_fmt.ss+20>

For it to get to the code where the segv occurs, it must have taken the last
branch after the call to __morestack.  In reading the comments in the emit
prologue code in rs6000.c, it says that __morestack returns the value in r29
and that should be moved to r12, but I don't see that happening in this code.

Alan, can you look at this? I will send you the details on where it is.

[Bug go/66870] split stack issues on ppc64le and ppc64

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #11 from Alan Modra <amodra at gmail dot com> ---
I can reproduce the fail.  It is caused by shrink-wrapping.

[Bug go/66870] split stack issues on ppc64le and ppc64

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #12 from Alan Modra <amodra at gmail dot com> ---
Created attachment 36003
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36003&action=edit
fix shrink-wrap issue

The attached patch cures the shrink wrap problem.  I haven't yet bootstrapped
it but fmt.o looks good by inspection.

[Bug go/66870] split stack issues on ppc64le and ppc64

[boger at us dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #13 from boger at us dot ibm.com ---
Use of the gold linker on ppc64 (BE) with static linking results in these
warnings:
/usr/local/gold/bin/ld.gold: warning:
/usr/lib/gcc/ppc64-redhat-linux/4.8.3/../../../../lib64/libc.a(malloc.o): .opd
is not a regular array of opd entries
/usr/local/gold/bin/ld.gold: warning:
/usr/lib/gcc/ppc64-redhat-linux/4.8.3/../../../../lib64/libc.a(dl-lookup.o):
.opd is not a regular array of opd entries
/usr/local/gold/bin/ld.gold: warning:
/usr/lib/gcc/ppc64-redhat-linux/4.8.3/../../../../lib64/libc.a(printf_fp.o):
.opd is not a regular array of opd entries

I'm assuming these shouldn't be ignored?  Perhaps at this time we should not
allow split stack (with the gold linker) for ppc64 BE and only for ppc64 LE.

[Bug go/66870] split stack issues on ppc64le and ppc64

[boger at us dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #14 from boger at us dot ibm.com ---
I did bootstrap a build on ppc64 multilib, using Alan's latest and my patch and
Andreas' patch on a system with glibc >= 2.18.  (Without Andreas' patch it
won't bootstrap on the 32 bit build on this system.)

[Bug go/66870] split stack issues on ppc64le and ppc64

[boger at us dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #15 from boger at us dot ibm.com ---
I have submitted my patch to gcc-patches to check for the no_split_stack
attribute after revising it based on Alan's comments.

[Bug go/66870] split stack issues on ppc64le and ppc64

[amodra at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #16 from Alan Modra <amodra at gcc dot gnu.org> ---
Author: amodra
Date: Fri Jul 31 14:05:42 2015
New Revision: 226443

URL: https://gcc.gnu.org/viewcvs?rev=226443&root=gcc&view=rev
Log:
        PR target/66870
        * config/rs6000/rs6000.c (machine_function): Add split_stack_argp_used.
        (rs6000_emit_prologue): Set it.
        (rs6000_set_up_by_prologue): Specify r12 when split_stack_argp_used.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/rs6000/rs6000.c

[Bug go/66870] split stack issues on ppc64le and ppc64

[boger at us dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #17 from boger at us dot ibm.com ---
Created attachment 36132
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36132&action=edit
Configure gold linker with split stack if available

Attaching my patch to detect for split stack support within the gold linker
that is available by the gcc build, and then use it with gccgo compiles.  Here
are the steps:
- When configuring gcc, check for split stack support in the gold linker either
identified as the linker to use in the gcc build or found in the path at build
time.  This check currently only works on ppc64le; I couldn't get it to fail on
ppc64 even with older (2.24) gold linkers.  Not sure what might be wanted for
other targets.  If the support is there then HAVE_LD_GOLD_SUPPORTS_SPLIT_STACK
is defined.
- Modify the check in libgo configure to detect that the gold linker used with
the gccgo that was just built supports split stack, defining
LINKER_SUPPORTS_SPLIT_STACK if it is.
- Add -fuse-ld=gold to the linker spec if HAVE_LD_GOLD_SUPPORTS_SPLIT_STACK is
defined (not for m32).
- Define TARGET_CAN_SPLIT_STACK for Power targets if the glibc level is
correct.  This is needed by go/gospec.c to enable the -fsplit-stack option when
linking.  

Comments?

[Bug go/66870] split stack issues on ppc64le and ppc64

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #18 from Ian Lance Taylor <ian at airs dot com> ---
In the patch in comment #17, the code in gcc/configure.ac looks misplaced:
shouldn't it be before the ";;", and not add another ";;"?

Can you explain why the test in libgo/configure.ac will fail for a linker that
does not support split-stack?  I'm not quite seeing it.  I haven't tried it,
though.

[Bug go/66870] split stack issues on ppc64le and ppc64

[boger at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #20 from boger at gcc dot gnu.org ---
Author: boger
Date: Wed Aug  5 18:07:16 2015
New Revision: 226643

URL: https://gcc.gnu.org/viewcvs?rev=226643&root=gcc&view=rev
Log:
2015-08-15 Lynn Boger <laboger@linux.vnet.ibm.com>

        PR target/66870
        * gcc/config/rs6000/rs6000.c (rs6000_emit_prologue): Check
        for no_split_stack function attribute along with
        flag_split_stack.
        (rs6000_expand_split_stack_prologue): Likewise.



Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/rs6000/rs6000.c

[Bug go/66870] split stack issues on ppc64le and ppc64

[amodra at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #22 from Alan Modra <amodra at gcc dot gnu.org> ---
Author: amodra
Date: Thu Aug 13 05:25:02 2015
New Revision: 226848

URL: https://gcc.gnu.org/viewcvs?rev=226848&root=gcc&view=rev
Log:
More split-stack fixes

Backport rev 226443
2015-07-31  Alan Modra  <amodra@gmail.com>

        PR target/66870
        * config/rs6000/rs6000.c (machine_function): Add split_stack_argp_used.
        (rs6000_emit_prologue): Set it.
        (rs6000_set_up_by_prologue): Specify r12 when split_stack_argp_used.

Backport rev 223878
2015-05-30  Alan Modra  <amodra@gmail.com>

        * config/rs6000/rs6000.c (split_stack_arg_pointer_used_p): Scan
        correct block for use of r12.
        (rs6000_expand_split_stack_prologue): Error on r29 asm global reg.

Backport rev 223427
2015-05-20  Alan Modra  <amodra@gmail.com>

        * config/rs6000/rs6000.c (rs6000_emit_allocate_stack): Return
        stack adjusting insn.  Formatting.
        (rs6000_emit_prologue): Track stack adjusting insn, and use of
        r12.  If possible, emit first -fsplit-stack arg pointer insn
        before stack adjust.  Don't use r12 to save cr if split-stack.

Backport rev 223425
2015-05-20  Alan Modra  <amodra@gmail.com>

        * config/rs6000/rs6000.c (struct rs6000_stack): Correct comments.
        (direct_return): Test vrsave_size rather than vrsave_mask.
        (rs6000_emit_prologue): Likewise.  Remove redundant altivec tests.
        (rs6000_emit_epilogue): Likewise.

Revert bogus rs6000_function_ok_for_sibcall change that caused failure
of glibc build.

Revert rs6000_can_eliminate cosmetic change


Modified:
    branches/ibm/gcc-5-branch/gcc/config/rs6000/rs6000.c

[Bug go/66870] split stack issues on ppc64le and ppc64

[ian at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #23 from ian at gcc dot gnu.org <ian at gcc dot gnu.org> ---
Author: ian
Date: Wed Sep 30 23:06:11 2015
New Revision: 228311

URL: https://gcc.gnu.org/viewcvs?rev=228311&root=gcc&view=rev
Log:
        PR target/66870
        * config/rs6000/sysv4.h (TARGET_CAN_SPLIT_STACK_64BIT): Define.
        * configure.ac: Define HAVE_GOLD_ALTERNATE_SPLIT_STACK on Power
        based on gold linker version.
        * gcc.c: Add -fuse-ld=gold to STACK_SPLIT_SPEC if
        HAVE_GOLD_ALTERNATE_SPLIT_STACK defined.
        * configure, config.in: Regenerate.
go:
        * gospec.c (lang_specific_driver): Set appropriate split stack
        options for 64 bit compiles based on TARGET_CAN_SPLIT_STACK_64BIT.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config.in
    trunk/gcc/config/rs6000/sysv4.h
    trunk/gcc/configure
    trunk/gcc/configure.ac
    trunk/gcc/gcc.c
    trunk/gcc/go/ChangeLog
    trunk/gcc/go/gospec.c

[Bug go/66870] split stack issues on ppc64le and ppc64

[boger at us dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #25 from boger at us dot ibm.com ---
(In reply to Andreas Schwab from comment #24)
> ../../gcc/go/gospec.c: In function 'void
> lang_specific_driver(cl_decoded_option**, unsigned int*, int*)':
> ../../gcc/go/gospec.c:161:7: error: 'OPT_m32' was not declared in this scope
>   case OPT_m32:
>        ^
> Makefile:1077: recipe for target 'go/gospec.o' failed
> make[3]: *** [go/gospec.o] Error 1

What target are you building this on?
bootstrap, with or without multilib?

[Bug go/66870] split stack issues on ppc64le and ppc64

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #26 from Andreas Schwab <schwab@linux-m68k.org> ---
Just try any target.

[Bug go/66870] split stack issues on ppc64le and ppc64

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #27 from Ian Lance Taylor <ian at airs dot com> ---
Any target that doesn't have a -m32 option.  This does work on x86 targets,
since they have a -m32 option in their config/CPU/CPU.opt file.  Sorry for not
catching this.

[Bug go/66870] split stack issues on ppc64le and ppc64

[boger at us dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #28 from boger at us dot ibm.com ---
I could put back the #ifdef TARGET_CAN_SPLIT_STACK_64BIT around the OPT_m32
case if that is OK.

Doesn't fail on the builds for ppc64le or ppc64 either.

[Bug go/66870] split stack issues on ppc64le and ppc64

[ian at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #30 from ian at gcc dot gnu.org <ian at gcc dot gnu.org> ---
Author: ian
Date: Thu Oct  1 14:43:57 2015
New Revision: 228342

URL: https://gcc.gnu.org/viewcvs?rev=228342&root=gcc&view=rev
Log:
        PR go/66870
        * gospec.c (lang_specific_driver): Only look for OPT_m32 if
        TARGET_CAN_SPLIT_STACK_64BIT is defined.

Modified:
    trunk/gcc/go/ChangeLog
    trunk/gcc/go/gospec.c

[Bug go/66870] split stack issues on ppc64le and ppc64

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #29 from Ian Lance Taylor <ian at airs dot com> ---
I just committed that patch.

[Bug go/66870] split stack issues on ppc64le and ppc64

[boger at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #31 from boger at gcc dot gnu.org ---
Author: boger
Date: Thu Oct  8 19:21:45 2015
New Revision: 228623

URL: https://gcc.gnu.org/viewcvs?rev=228623&root=gcc&view=rev
Log:
        Backport of rev 228311

        PR target/66870
        * config/rs6000/sysv4.h (TARGET_CAN_SPLIT_STACK_64BIT): Define.
        * configure.ac: Define HAVE_GOLD_ALTERNATE_SPLIT_STACK on Power
        based on gold linker version.
        * gcc.c: Add -fuse-ld=gold to STACK_SPLIT_SPEC if
        HAVE_GOLD_ALTERNATE_SPLIT_STACK defined.
        * configure, config.in: Regenerate.
go:
        * gospec.c (lang_specific_driver): Set appropriate split stack
        options for 64 bit compiles based on TARGET_CAN_SPLIT_STACK_64BIT.



Modified:
    branches/ibm/gcc-5-branch/gcc/config.in
    branches/ibm/gcc-5-branch/gcc/config/rs6000/linux64.h
    branches/ibm/gcc-5-branch/gcc/config/rs6000/sysv4.h
    branches/ibm/gcc-5-branch/gcc/configure
    branches/ibm/gcc-5-branch/gcc/configure.ac
    branches/ibm/gcc-5-branch/gcc/gcc.c
    branches/ibm/gcc-5-branch/gcc/go/gospec.c

[Bug go/66870] split stack issues on ppc64le and ppc64

[amodra at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #32 from Alan Modra <amodra at gcc dot gnu.org> ---
Author: amodra
Date: Mon Oct 19 23:50:30 2015
New Revision: 229009

URL: https://gcc.gnu.org/viewcvs?rev=229009&root=gcc&view=rev
Log:
PR66870 PowerPC64 Enable gold linker with split stack

A powerpc-linux/powerpc64-linux biarch compiler can default to either
-m32 or -m64, and we need to notice both -m32 and -m64 on the gccgo
command line.  It's also possible to build a -m64 only compiler, so in
that case we can define TARGET_CAN_SPLIT_STACK.

gcc/
        PR go/66870
        * config/rs6000/sysv4.h (TARGET_CAN_SPLIT_STACK_64BIT): Don't define.
        * config/rs6000/linux64.h (TARGET_CAN_SPLIT_STACK): Define.
        (TARGET_CAN_SPLIT_STACK_64BIT): Define.
gcc/go/
        PR go/66870
        * gospec.c (saw_opt_m32): Rename to..
        (is_m64): ..this, initialised by TARGET_CAN_SPLIT_STACK_64BIT.
        Update uses.
        (lang_specific_driver): Set is_m64 if OPT_m64, clear if OPT_m32.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/rs6000/linux64.h
    trunk/gcc/config/rs6000/sysv4.h
    trunk/gcc/go/ChangeLog
    trunk/gcc/go/gospec.c

[Bug go/66870] split stack issues on ppc64le and ppc64

[boger at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #33 from boger at gcc dot gnu.org ---
Author: boger
Date: Wed Oct 28 16:00:46 2015
New Revision: 229493

URL: https://gcc.gnu.org/viewcvs?rev=229493&root=gcc&view=rev
Log:
Backport of r229009

PR66870 PowerPC64 Enable gold linker with split stack

A powerpc-linux/powerpc64-linux biarch compiler can default to either
-m32 or -m64, and we need to notice both -m32 and -m64 on the gccgo
command line.  It's also possible to build a -m64 only compiler, so in
that case we can define TARGET_CAN_SPLIT_STACK.

gcc/
        PR go/66870
        * config/rs6000/sysv4.h (TARGET_CAN_SPLIT_STACK_64BIT): Don't define.
        * config/rs6000/linux64.h (TARGET_CAN_SPLIT_STACK): Define.
        (TARGET_CAN_SPLIT_STACK_64BIT): Define.
gcc/go/
        PR go/66870
        * gospec.c (saw_opt_m32): Rename to..
        (is_m64): ..this, initialised by TARGET_CAN_SPLIT_STACK_64BIT.
        Update uses.
        (lang_specific_driver): Set is_m64 if OPT_m64, clear if OPT_m32. 

Modified:
    branches/ibm/gcc-5-branch/gcc/config/rs6000/linux64.h
    branches/ibm/gcc-5-branch/gcc/config/rs6000/sysv4.h
    branches/ibm/gcc-5-branch/gcc/go/gospec.c