On Sun, Aug 2, 2020 at 1:00 PM Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
>
> Hi Ian,
>
> > This libgo patch updates the sources to the go1.15rc1 release
> > candidate.  As usual, the changes for this update are too large to
> > include in an e-mail message.  I've just included the highlights and
> > changes to GCC-specific files below.  Bootstrapped and ran Go
> > testsuite on x86_64-pc-linux-gnu.  Committed to mainline.
>
> this seems to have broken the libgo build with 32-bit compilers:
>
> $ files=`echo /vol/gcc/src/hg/master/local/libgo/go/time/tzdata/tzdata.go /vol/gcc/src/hg/master/local/libgo/go/time/tzdata/zipdata.go errors.gox syscall.gox | sed -e 's/[^ ]*\.gox//g' -e 's/[^ ]*\.dep//'`; /bin/ksh ./libtool --tag GO --mode=compile /var/gcc/regression/master/11.4-gcc-gas/build/./gcc/gccgo -B/var/gcc/regression/master/11.4-gcc-gas/build/./gcc/ -B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/ -isystem /vol/gcc/i386-pc-solaris2.11/include -isystem /vol/gcc/i386-pc-solaris2.11/sys-include   -fchecking=1  -minline-all-stringops  -O2 -g -I . -c -fgo-pkgpath=`echo time/tzdata.lo | sed -e 's/.lo$//'`  -o time/tzdata.lo $files
> libtool: compile:  /var/gcc/regression/master/11.4-gcc-gas/build/./gcc/gccgo -B/var/gcc/regression/master/11.4-gcc-gas/build/./gcc/ -B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/ -isystem /vol/gcc/i386-pc-solaris2.11/include -isystem /vol/gcc/i386-pc-solaris2.11/sys-include -fchecking=1 -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=time/tzdata /vol/gcc/src/hg/master/local/libgo/go/time/tzdata/tzdata.go /vol/gcc/src/hg/master/local/libgo/go/time/tzdata/zipdata.go  -fPIC -o time/.libs/tzdata.o
> terminate called after throwing an instance of 'std::bad_alloc'
>   what():  std::bad_alloc
> go1: internal compiler error: Abort
> mmap: Not enough space
>
> I'm seeing this on all of i386-pc-solaris2.11, sparc-sun-solaris2.11,
> and i686-pc-linux-gnu.  amd64-pc-solaris2.11 and sparcv9-sun-solaris2.11
> are ok, though (running make check right now).

This is fixed by this patch to the Go frontend that deletes lowered
constant strings.  If we lower a constant string operation in a
Binary_expression, we delete the strings.  This is safe because
constant strings are always newly allocated.

This is a hack to use much less memory when compiling the new
time/tzdata package, which has a file that contains the sum of over
13,000 constant strings.  We don't do this for numeric expressions
because that could cause us to delete an Iota_expression.

The Go frontend should have a cleaner approach to memory usage some day.

This also fixes PR go/96450.  Bootstrapped and tested on
x86_64-pc-linux-gnu and verified that I could build the time/tzdata
package on i686-pc-linux-gnu.  Committed to mainline.

Ian