The Go index0-out.go FAILs on mainline and the gcc-8 branch on many different
targets (aarch64-suse-linux-gnu,
arm-unknown-linux-gnueabi, arm-unknown-linux-gnueabihf,
ia64-suse-linux-gnu, powerpc64-suse-linux-gnu, riscv64-suse-linux-gnu,
s390x-ibm-linux-gnu according to gcc-testresults postings), while it PASSed on the gcc-7 branch.

The failure modes are various, however:

* On Solaris/x86 with /bin/as, I get

FAIL: ./index0-out.go compilation,  -O0 -g -fno-var-tracking-assignments 

   where as complains

Input string too long, limit 10240

  It turns out that the lines in question are of the form

	.weak	gcbits..baza{100000}ba

  i.e. 100000 'a' characters in a row.  Maybe the test can be modified to
  accomodate this restriction?

* On Solaris/x86 with gas and Solaris/SPARC, the test FAILs to execute instead:

FAIL: ./index0-out.go execution,  -O0 -g -fno-var-tracking-assignments 

  The test SEGVs.  While gdb gets royally confused, dbx shows what's going on:

t@1 (l@1) signal SEGV (no mapping at the fault address) in __go_init_main at 0x81b700e
0x081b700e: __go_init_main+0x000c:      call     import [PLT]   [ 0x80b04b0, .-0x106b5e ]
(dbx) where
current thread: t@1
=>[1] __go_init_main(0x0, 0x8a41f8a, 0x0, 0x0, 0x0, 0x0), at 0x81b700e 
  [2] main(0x0, 0xfe10a7d8, 0x8a41ff8, 0xfdffcc09), at 0xfdfffb0f 
  [3] kickoff(0x8801080, 0x0, 0x0, 0x8800b00, 0x0, 0x0), at 0xfdffcc70 
  [4] resumecontext(), at 0xfd0bf3a3 

  __go_init_main extends the stack way beyond the default stacksize limit of
  8 MB:
(gdb) x/7i __go_init_main
   0x81b7002 <__go_init_main>:  push   %ebp
   0x81b7003 <__go_init_main+1>:        mov    %esp,%ebp
   0x81b7005 <__go_init_main+3>:        push   %edi
   0x81b7006 <__go_init_main+4>:        push   %esi
   0x81b7007 <__go_init_main+5>:        push   %ebx
   0x81b7008 <__go_init_main+6>:        sub    $0x3d0b9c,%esp
=> 0x81b700e <__go_init_main+12>:
    call   0x80b04b0 <internal_cpu..import@plt>

  which breaks the next call.  However, even with ulimit -s unlimited, the problem
  remains.

* Even on Linux/x86_64 (Fedora 27) which has SplitStacks support, the test FAILs:

fatal error: unexpected signal during runtime execution

If the test depends on -fsplit-stack support, it should be marked as such.