[Patch, fortran] PR33664 - crash on invalid program

Tobias Schlüter tobias.schlueter@physik.uni-muenchen.de
Mon Oct 8 18:08:00 GMT 2007


Paul Richard Thomas wrote:
> The purpose of checking isym and esym is to establish whether or not
> the function has been resolved.  I realise upon writing this that
> e->value.function.name can substitute for both.  isym and esym are the
> symbols for either intrinsic or "external"(I believe but have not
> checked that it is actually everything that is not intrinsic.)
> functions.  The reason that they are different is, of course, that
> isym points to a gfc_intrinsic_sym, rather than a gfc_symbol.

Thanks, that makes a lot of sense.  It would perhaps be a worthwhile 
experiment to combine .isym and .esym into a single union, and to see 
all hell break loose because something assumed something different ;-)

> For the purposes of this patch, the lack of resolution and the
> impurity indicate that the symbol cannot be a function in a
> specification expression.

Why is that?  How does the lack of resolution indicate this?  (It could 
have its PURE attribute set during resolution, couldn't it?  Then the 
code would be legal.)

I'm also interested in these details out of self-interest,  My patch for 
PR 20851 broke resolution of some other permutations of valid objects. 
This problem is now PR33689.

Cheers,
- Tobi



More information about the Gcc-patches mailing list