[Patch, Fortran] PR 36704/38290
Mon Dec 1 14:18:00 GMT 2008
>> this patch fixes two PRs (at least partially):
>> * PR 36704 - Procedure pointer as function result: This I was planning
>> to implement in 4.5, but when having a look at it over the weekend, I
>> found that certain cases (i.e. those using a RESULT statement, see
>> proc_ptr_12.f90) are really easy to implement, so maybe this could
>> still go into 4.4 (since it's more of a bugfix than a 'feature')? The
>> harder cases (without RESULT statement) I will then take care of
>> * PR 38290 - Procedure pointer assignment checking: This adds a few
>> additional checks for procedure pointer assignments and fixes comment
>> #2 from the PR, including an ICE, so it's even a 4.4 regression.
> From my point of view, those should be both ok.
thanks for the review!
> - if (gfc_add_flavor (&r->attr, FL_VARIABLE, r->name, NULL) == FAILURE
> - || gfc_add_result (&r->attr, r->name, NULL) == FAILURE)
> + if (gfc_add_result (&r->attr, r->name, NULL) == FAILURE)
> return MATCH_ERROR;
> Adding flavour FL_VARIABLE goes here without replacement (of course, it need
> to), but why was it needed in the first place?
Well, in Fortran 95 one could be sure that the RESULT statement was a
'normal' variable, i.e. FL_VARIABLE.
Now with procedure pointers this is not true any more, since they are
> Could this harm somehow?
At least there are no testsuite failures. If you find a case where it
would fail, please let me know. I will also try to find such cases.
One could add further checks at resolution stage, if they don't
> - if (sym->attr.flavor == FL_UNKNOWN) sym->attr.flavor =
> Ditto. What happens if the flavour is FL_UNKNOWN and would have been set to
> PROCEDURE? Why is this simply not needed?
Actually this was my own mistake. I wrongly added this line when
implementing procedure pointers, assuming that everything that appears
on the rhs of a procedure pointer assignment should be a procedure
(pointer). Of course this is how it *should* be. However, an
evil-minded person could put *anything* on the rhs, so one cannot
assume this, but has to demand it. I added checks for this in
More information about the Gcc-patches