I've been testing the gm2 development branch (based on gcc-12)
against lto and non lto builds.

  git clone git://gcc.gnu.org/git/gcc.git gcc-git
  cd gcc-git
  git checkout devel/modula-2

I'm using the configure options:

    CXXFLAGS="-g" CFLAGS="-g $PROFILE" ${absdir}/configure \
            --prefix=$HOME/${INSTALLDIR} \
            --libexecdir=$HOME/${INSTALLDIR}/lib \
            --enable-threads=posix \
            --enable-clocale=gnu --enable-languages=${LANGUAGES} \
            --disable-multilib  --enable-checking \
            --enable-long-longx \
            --enable-bootstrap

and building using: make -j 12.

Without lto the repro above (from Dec 9th) passes all gm2 regressions
on the amd64 architecture and does not introduce any regression tests
for the languages (c,c++,go,fortran).

With lto there are no extra errors introduced compared between other
languages.  However I do see many large set regression test failures
in gm2 when lto is enabled.  I'm using the configure arguments:

    CXXFLAGS="-g" CFLAGS="-g $PROFILE" ${absdir}/configure \
            --prefix=$HOME/${INSTALLDIR} \
            --libexecdir=$HOME/${INSTALLDIR}/lib \
            --enable-threads=posix \
            --enable-clocale=gnu --enable-languages=${LANGUAGES} \
            --disable-multilib  --enable-checking \
            --enable-long-longx \
            --enable-bootstrap \
            --with-build-config=bootstrap-lto-lean

and building with

   make -j 12 profiledbootstrap-lean

The good news is that I can test and hunt for the large set failures
(diff the execution of the cc1gm2 built with/without lto) and also good
that gm2 builds with lto.  [Interestingly there has been a problem with
large sets and sparc64 and a 64 bit powerppc variant - so hopefully this
could all be the same bug.. maybe].  From some time ago I have a python
script which will run two copies of gdb/cc1gm2 and single step both in
lock step and dump out when they differ.

Aside from the bug(s) above it is looking pretty stable - and was
wondering when or if it would be a good time to merge gm2 into the
trunk?

In the meantime I'll hunt the gm2/lto bug above and keep git merging
(approx weekly) and feed in small patches to the gm2 development
branch,

regards,
Gaius

Reply via email to