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] PR fortran/35723: Some fixes to restricted-expression handling


Hi,

I'd like to give an update on the status here; as Paul has already worked out a patch for PR 35680, I think the only remaining "issue" here is losing the error messages as pointed out by Dominique.

From my point of view, I would like to get this patch in without the error suppressing that causes these losses (but with the "clean-up" of gfc_suppress_error) and commit in addition Dominique's test to prevent regressing in the future. I will then open a PR for the duplication of error messages and work on this further as a seperate problem (the patch as attached fixes the PR and some related problems not in bugzilla, with or without the error suppressing).

What do you think? Is the patch without error suppressing and including Dominique's test ok for trunk if no regressions occur for the final version?

Yours,
Daniel

Daniel Kraft wrote:
this is more a compilation of several patches to form some more or less working and compact unit.

1) I used Tobias' one-line patch from PR 35723 to allow PARAMETER symbols in restricted expressions. This fixes the original PR.

2) I added checking of reference-chain subscripts (array and substring) for EXPR_VARIABLEs to expr.c:check_restricted to fix the accepts-invalid Tobias mentioned along with the patch (I probably should check the indices for EXPR_SUBSTRINGs, too, right?). This was however not a problem introduced by the patch but in fact another bug as demonstrated by my accepts-invalid attached to the PR even for an unpatched gcc.

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:

INTEGER :: i = 1, v(42)
INTEGER :: arr(SIZE(v, i))

that should be rejected, right? I propose to defer this to a new PR as it will probably involve not trivial changes and is not really related to the PR being worked on.

4) To fix the duplicated error message problem reported also in the PR, I added a suppress-errors to a function probably not supposed to report errors; on the way, I found that handling the global gfc_suppress_error is not consistent in the code and that some methods would change it and fail to reset on return. I did some clean-up there and believe it is better now (in addition to fixing the duplicate message problem).

I probably should change the test-case names to restricted_expression_123.f90. What do you think? Any other comments? Running a regression test now, but I believe there should not be any (from a previous run where only one failure was introduced I fixed in the meantime).

Do you think this patch is ok with my mentioned points (changing the test names and adding the check for EXPR_SUBSTRINGs) if no regressions? In any case, I would not backport this to 4.3 as it is a more or less complicated patch. Or should I?

Yours,
Daniel



--
Done:  Arc-Bar-Cav-Rog-Sam-Val-Wiz
To go: Hea-Kni-Mon-Pri-Ran-Tou


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