Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:

> After this change, I'm seeing another issue: most 32-bit go execution
> tests fail like this on Solaris 11/x86:
>
> /vol/gcc/src/hg/trunk/local/libgo/runtime/malloc.goc:366: libgo assertion failure
> FAIL: go.go-torture/execute/array-1.go execution,  -O0 
>
> Running the test under truss, I find:
>
> 14261:	mmap(0xFF000000, 805306368, PROT_NONE, MAP_PRIVATE|MAP_ANON, -1, 0) Err#12 ENOMEM
>
> With truss -u (user function tracing), I see:
>
> 14285/1@1:	-> libgo:runtime_mallocinit()
> 14285/1@1:	  -> libgo:runtime_InitSizes()
> 14285/1@1:	  <- libgo:runtime_InitSizes() = 2
> 14285/1@1:	  -> libgo:runtime_SysReserve()
> 14285/1:	mmap(0xFF000000, 805306368, PROT_NONE, MAP_PRIVATE|MAP_ANON, -1, 0) Err#12 ENOMEM
> 14285/1@1:	  <- libgo:runtime_SysReserve() = -1
> 14285/1@1:	  -> libgo:__go_assert_fail()
>
> If I remove the adjustment in runtime/malloc.goc (runtime_mallocinit),
> the test passes:
>
> 14445/1:	mmap(0xFEF78114, 805306368, PROT_NONE, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xCE000000
>
> This stuff seems incredibly fragile, and I don't exactly understand
> why.

I don't understand why one case passes and the other fails.  In an
attempt to make this work better, I committed the appended patch.  It
will at least avoid asking for impossible situations, such as the one in
this example.  Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu (including the 32-bit tests, which I always run
anyhow).  Committed to mainline.

Ian