This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Patch, Fortran] PR fortran/35723: Some fixes to restricted-expression handling
- From: "Paul Richard Thomas" <paul dot richard dot thomas at gmail dot com>
- To: "Daniel Kraft" <d at domob dot eu>
- Cc: "Fortran List" <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 25 Sep 2008 18:39:38 +0200
- Subject: Re: [Patch, Fortran] PR fortran/35723: Some fixes to restricted-expression handling
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=gF/ftvNKeq81r3GK/7v/tyiPGSKdJ9U1GG6CW8Brfpk=; b=JJkHyLTL+80txmhj7fv7HjqYu4OnNqhhSV6zdAUXN2pFnrxATBmcq5perI8gbUzWkJ ig3nECwoNQ8YwWC/CbBNhddhScYOUf73f3jqrRdhuvwuWC/c/byaS22hkOabaIMOUu9r nFg6wzcweNDDuL8bHaPZU0XLbocCltskwm5vk=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=GWmSyiFyCrM35Ggj2bc7xassfgFeWr95rTKOusheJDUkXZvdGCqo3rDlrwLhTvmbFm 74B/JP4brFtV3ub6bNXNIrNfZT0pL7A7OSvZVdL++hgCxGCvYJrShWj7KZvP7QPt9y7f Pa5cjgPoRSbXNqI/YPgK5F4aX+/FuasgiXuSw=
- References: <48DBB095.1020401@domob.eu>
Daniel,
> 3) While working with runtime_subscript_dimension_3.f90, I discovered that
> argument lists of function calls are not checked, either. I added this
> check; for inquiry-type intrinsic calls it is disabled. I believe this is
> the best we can do to conform to the standard at the moment. This should not
> catch cases like:
I just encountered this in looking at PR35680. I fixed it by putting a
check_restricted into the argument checking of check_inquiry. It
leaves the remaining problem that when the declarations are in the
right order an ICE occurs - for reasons that are evident from the
dump-tree-original.
Maybe your patch fixes the "regression" in PR35680? If it doesn't,
you are in a good position to do so.
(I put regression in quotes because fixing one or more bugs in the
past has exposed this one which was latent.)
Cheers
Paul