This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Combine location with block using block_locations
- From: Michael Matz <matz at suse dot de>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: Dehao Chen <dehao at google dot com>, Diego Novillo <dnovillo at google dot com>, Dodji Seketeli <dodji at redhat dot com>, gcc-patches at gcc dot gnu dot org, Jakub Jelinek <jakub at redhat dot com>, Jan Hubicka <hubicka at ucw dot cz>, David Li <davidxl at google dot com>, Tom Tromey <tromey at redhat dot com>, Jason Merrill <jason at redhat dot com>, Richard Henderson <rth at redhat dot com>
- Date: Wed, 12 Sep 2012 15:23:55 +0200 (CEST)
- Subject: Re: [PATCH] Combine location with block using block_locations
- References: <CAO2gOZXFkCpuFqXpPw6ju14BB=RBdt-kDhKsJgk4N41=Q19VHw@mail.gmail.com> <CAFiYyc0c3ZyLkbTGiiOOi0sCC0Ju9=PQLZ-BAOV2RFYVttzvCA@mail.gmail.com> <5049D5AD.5010405@google.com> <504A2EE0.8020704@google.com> <CAO2gOZWX+A3R0MGvWXYztBokQ=ezHNiS3vR0Cu9cbGPi_102ww@mail.gmail.com> <CAFiYyc0wGqgPR6Sqk2sOCg+LnhfFmk8dChb54oh=EjiTFzftyw@mail.gmail.com> <CAO2gOZVNK5uS7NJt1uV6S7nCMtoj+g23BJiH_=P6TLgkh4d1Sw@mail.gmail.com> <CAFiYyc1pA9+=_OE50rCSmKG4ftasrNYE8jRMt3gf_F+6ee9OVw@mail.gmail.com> <alpine.LNX.2.00.1209111500200.9940@wotan.suse.de> <CAFiYyc0vM+LZJ_6MRFud9c1LhyFsu2jf-E38FuDryoMo5G7iYw@mail.gmail.com> <CAO2gOZV8SP-sOVEJBEsvF+M3yiKwtw7yWarfhZ1xeCVYjE_7KA@mail.gmail.com> <alpine.LNX.2.00.1209111728160.9940@wotan.suse.de> <CAFiYyc2zQZwnGKtSxq5VGgQkN1TpSobwq9wt8GiwtwHKoWuOyA@mail.gmail.com> <alpine.LNX.2.00.1209121411120.9940@wotan.suse.de> <CAFiYyc0gqxhKPC_n+sT2U6GY-_uCFiRduvmsuJnp+JTjVip-tQ@mail.gmail.com>
Hi,
On Wed, 12 Sep 2012, Richard Guenther wrote:
> >> It hides a bug. If we replace anything in BLOCK_VARS then the risk
> >> is that you generate an infinite chain in some BLOCK_VARS list and
> >> thus get infinite loops somewhere in the compiler.
> >
> > That's what I said for using SET_PREVAIL. But his hack would
> > specifically not replace anything in TREE_CHAIN (and hence
> > BLOCK_VARS), and indeed not check anything either.
>
> Hm, but we shouldn't end up streaming any BLOCKs at this point (nor
> local TYPE_DECLs). Those are supposed to be in the local function
> sections only where no fixup for prevailing decls happens.
That's true, something is fishy with the patch, will try to investigate.
Ciao,
Michael.