[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=gcc=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

[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  ---
Author: amodra
Date: Mon Oct 19 23:50:30 2015
New Revision: 229009

URL: https://gcc.gnu.org/viewcvs?rev=229009=gcc=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 #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=gcc=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

[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

[sch...@linux-m68k.org]

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

--- Comment #26 from Andreas Schwab  ---
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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #29 from Ian Lance Taylor  ---
I just committed that patch.

[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  ---
Author: ian
Date: Thu Oct  1 14:43:57 2015
New Revision: 228342

URL: https://gcc.gnu.org/viewcvs?rev=228342=gcc=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

--- Comment #27 from Ian Lance Taylor  ---
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

[sch...@linux-m68k.org]

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

--- Comment #24 from Andreas Schwab  ---
../../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

[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  ---
Author: ian
Date: Wed Sep 30 23:06:11 2015
New Revision: 228311

URL: https://gcc.gnu.org/viewcvs?rev=228311=gcc=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

[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=226848root=gccview=rev
Log:
More split-stack fixes

Backport rev 226443
2015-07-31  Alan Modra  amo...@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  amo...@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  amo...@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  amo...@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

[boger at us dot ibm.com]

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

--- Comment #21 from boger at us dot ibm.com ---
Created attachment 36142
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36142action=edit
Configure gold with split stack based on binutils version

This is an updated version of the previous patch, simplifying the test done in
gcc/configure.ac.  Instead of trying to link a program this just checks the
binutils version number on the ld.gold --version output.  The configure check
in libgo will fail if the gold linker doesn't have split stack support but only
on pp64le.  On ppc64 the version check should be sufficient to make sure the
right gold linker is there.

[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=36132action=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 us dot ibm.com]

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

--- Comment #19 from boger at us dot ibm.com ---
(In reply to Ian Lance Taylor from comment #18)
 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.

For ppc64le, some split stack support was recently added to the gold linker by
Alan, so if you try to use a gold linker that is too old, you will get an error
like this:

/usr/bin/ld.gold -o sss ss-callee.o ss-call.o  --defsym __morestack=0
/usr/bin/ld.gold: error: linker does not include stack split support required
by ss-call.o

But with one after he added the support, it does not get this error.  If it is
not gold then it doesn't get the error either.

However on ppc64 (BE, not LE) it never gets the error, old or new gold.  Alan
would have to answer why.  I don't know about other targets, I haven't tried
it.  

I suppose the test could be on the version number for the gold linker at least
for ppc64 LE or BE.

Sorry I probably messed up the ;; I will double check on that.

[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=226643root=gccview=rev
Log:
2015-08-15 Lynn Boger labo...@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 #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=226443root=gccview=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 #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

[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 #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

[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=36003action=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

[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

[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:  addir12,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:   mflrr0
   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:mtlrr0
   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

[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=35989action=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

[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

[sch...@linux-m68k.org]

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

--- Comment #4 from Andreas Schwab sch...@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

[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

[sch...@linux-m68k.org]

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

--- Comment #6 from Andreas Schwab sch...@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

[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 .)