Re: Updating phi nodes on deleting gimple statement
On December 16, 2021 7:33:37 AM GMT+01:00, Shubham Narlawar via Gcc wrote: >Hello, > > >I have a PHI node that defines a variable that is used in 1 statement. I >then delete the statement. I think I need to update the PHI node to no >longer reference that variable. I looked through some code and I don't see >a way to just remove an element from a PHI node and I see in the file >omp-expand.c what looks like creating a new PHI node and copying over all >of the elements. > >My question is: how do I update a PHI node per the above? Is it necessary - >if I don't do anything and leave the PHI node as is it appears to work, >though I don't know the implications of this. If I do need to update it, do >I recreate it and delete the old one? You don't need to do anything to the PHI node. Richard. >Thanks and Regards, >Shubham
gm2 development status (tracking gcc-12 20211209)
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
gcc-9-20211216 is now available
Snapshot gcc-9-20211216 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20211216/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 revision 6fa3bbe854f8a9066c390b802e6a69ef463ede7c You'll find: gcc-9-20211216.tar.xzComplete GCC SHA256=677e98e62d2bb4275c958b3ce6ecec3e1f9f88086bf6d7047579b94e943206d2 SHA1=a808fa464370009498cf9d13098f60207a42ac83 Diffs from 9-20211209 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: gm2 development status (tracking gcc-12 20211209)
On December 16, 2021 9:43:56 PM GMT+01:00, Gaius Mulley
wrote:
>
>
>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?
Merging early in stage1 would make most sense.
Richard.
>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
