This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: [Patch, fortran] PR33664 - crash on invalid program

From: Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>
To: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
Cc: "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, gcc-patches List <gcc-patches at gcc dot gnu dot org>
Date: Sun, 07 Oct 2007 22:50:01 +0200
Subject: Re: [Patch, fortran] PR33664 - crash on invalid program
References: <339c37f20710071213p7ae97856l3fb447d048f0b0d2@mail.gmail.com>

Hi Paul,

Paul Richard Thomas wrote:

This is a little embarrassing.  The testcase tells all - the symbol n
is interpreted to be an error.  Hozever, being referenced in a
specification expression, it should be pure, which it is not.  The fix
is self-explanatory - note the test for purity is redundant but
provides a belt and braces approach.  char_result_7.f90 was exposed by
this patch to have an illegal part, where the character langth was
determined by an impure function.  This has been eliminated.

Bootstrapped and regtested on x86_ia64/fc5 and certified tonto-2.3
proof.  OK for trunk?

I'm embarassed to say that I don't understand the fix. What is the purpose of checking .isym and .esym? What is their purpose, anyway? I understand that they're the actual functions being called, but under which circumstances. I think this is a great time for you to bring some enlightenment to the obscure parts of gfortran :-)

Thanks,
- Tobi

Follow-Ups:
- Re: [Patch, fortran] PR33664 - crash on invalid program
  - From: Paul Richard Thomas

References:
- [Patch, fortran] PR33664 - crash on invalid program
  - From: Paul Richard Thomas

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]