This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, fortran] PR55827 ICE with multiple fortran modules.
- From: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- To: Mikael Morin <mikael dot morin at sfr dot fr>, Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- Cc: gfortran <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 4 Jan 2013 05:46:54 +0100
- Subject: Re: [Patch, fortran] PR55827 ICE with multiple fortran modules.
- References: <50E5F8B4.6080507@sfr.fr>
Dear Mikael and Steve,
>From a quick read of your correspondence in the PR, you seem to have
covered all the angles between you.
OK for trunk.
As for the branches; yes, but.... how far back to go? I guess that
4.6 and 4.7 should be patched, if possible, since they are in current
use in distributions. However, I note that
class.c(gfc_fix_class_refs) is dated 2012-02-02 and was applied to
4.7.0 trunk. Is the bug present 4.6? I have neither tree loaded
since updating my system and so cannot check at the moment.
Thanks for the patch.
Paul
On 3 January 2013 22:31, Mikael Morin <mikael.morin@sfr.fr> wrote:
> Hello,
>
> here is a fix for PR fortran/55827 where we had a function expression
> (loaded from a module) whose symtree pointer was NULL. My attempt to have
> symtree properly set got me way too far, so this is fixing the unconditional
> usages of symtree based on Steve's patch in the PR. As noted in the PR, it
> looks bogus to have a NULL expr->symtree, but in fact
> expr->value.function.esym is set, and it is what is solely looked at, apart
> for the cases fixed in this patch.
>
> The trans-expr.c part initializes `sym' earlier and uses it instead of
> accessing `expr->symtree' directly.
>
> The class.c part creates a similar construct to initialize `ts' without
> accessing `expr->symtree' directly. I don't use Steve's way (returning
> early for a NULL symtree), because I remembered that `expr->symtree' could
> be a generic symbol, thus have invalid type for use to initialize `ts',
> contrary to `expr->value.function.esym'. It's better to always use `esym'
> when it is available. And then returning early on NULL symtree is not
> necessary any more.
>
> Regression tested on x86_64-unknown-linux-gnu. OK for trunk?
> Do we want it on the branches as well?
>
> Mikael
>
>
>
>
>
>
>
--
The knack of flying is learning how to throw yourself at the ground and miss.
--Hitchhikers Guide to the Galaxy