>> Ok, that's what the patch does now: Always error for wrong result
>> type, then do the full interface check, but only give a warning with
>> -std=gnu and -std=legacy, and an error otherwise.
>>
>> Will do another regtest now. Are you okay with this version?
>
> Yes, looks good to me. Thanks for
Janus Weil wrote:
Ok, that's what the patch does now: Always error for wrong result
type, then do the full interface check, but only give a warning with
-std=gnu and -std=legacy, and an error otherwise.
Will do another regtest now. Are you okay with this version?
Yes, looks good to me. Thanks
2013/4/12 Tobias Burnus :
> Am 12.04.2013 00:17, schrieb Janus Weil:
>
>>> Hmm, I think I'd prefer to have for the arguments only a warning with
>>> -std=gnu - except for the function result value, which should always be
>>> an
>>> error. And also the "requires an explicit interface" checks should
Am 12.04.2013 00:17, schrieb Janus Weil:
Hmm, I think I'd prefer to have for the arguments only a warning with
-std=gnu - except for the function result value, which should always be an
error. And also the "requires an explicit interface" checks should always
use an error.
Why the distinction (a
>>> Thus, I think one should be strict about the requires-explicit-interface
>>> diagnostic (= new code, using F90+), but for interface mismatch (= could
>>> be
>>> old Fortran 66 code), it should be either disabled or - as currently -
>>> just
>>> be a warning.
>>
>> How about enabling it by defa
Am 11.04.2013 23:38, schrieb Janus Weil:
2013/4/11 Tobias Burnus :
Comment to Janus: It should be possible to disable the error check,
e.g. by making it a warning.
That's actually what the current code does: By default,
it only warns and does not print an error.
No, at least the type mismatch
2013/4/11 Tobias Burnus :
> Am 11.04.2013 16:23, schrieb Janus Weil:
>
>>> [Btw, I also thought about doing a full "gfc_compare_interfaces" in
>>> "resolve_global_procedure", but that would probably be too strict.]
>>
>> Comment to self: It's certainly more strict, but I think this is a
>> good thi
Am 11.04.2013 16:23, schrieb Janus Weil:
[Btw, I also thought about doing a full "gfc_compare_interfaces" in
"resolve_global_procedure", but that would probably be too strict.]
Comment to self: It's certainly more strict, but I think this is a
good thing. I just tried it and in fact it catches a
> [Btw, I also thought about doing a full "gfc_compare_interfaces" in
> "resolve_global_procedure", but that would probably be too strict.]
Comment to self: It's certainly more strict, but I think this is a
good thing. I just tried it and in fact it catches a number of cases
in the testsuite, whic
>> Ok, here is an updated patch, which does the discussed checking for
>> procedure pointer assignments. For this I have introduced a new
>> function 'gfc_explicit_interface_required', which checks all the items
>> in F08:12.4.2.2 and is loosely based on the present checks in
>> 'resolve_global_pro
>> One leftover problem: The patch currently fails on the auto_char_len_4
>> test case, which is not being rejected any more. Actually I'm not
>> fully convinced that the dg-errors there are correct: If the EXTERNAL
>> statements in auto_char_len_{1,2} do not trigger an "explicit
>> interface requi
Janus Weil wrote:
Ok, here is an updated patch, which does the discussed checking for
procedure pointer assignments. For this I have introduced a new
function 'gfc_explicit_interface_required', which checks all the items
in F08:12.4.2.2 and is loosely based on the present checks in
'resolve_globa
Am 10.04.2013 16:21, schrieb Janus Weil:
2013/4/7 Tobias Burnus :
Thus, the only place where the check can be is for:
f => ff
In your example, the explicit interface of "ff" is known thus it should
be
testable at resolution time of the proc-pointer assignment.
Right. However, strictly spe
2013/4/7 Tobias Burnus :
>>> Thus, the only place where the check can be is for:
>>>
>>>f => ff
>>>
>>> In your example, the explicit interface of "ff" is known thus it should
>>> be
>>> testable at resolution time of the proc-pointer assignment.
>>
>> Right. However, strictly speaking, the poi
Janus Weil wrote:
Thus, the only place where the check can be is for:
f => ff
In your example, the explicit interface of "ff" is known thus it should be
testable at resolution time of the proc-pointer assignment.
Right. However, strictly speaking, the pointer assignment as such is
probably
>> It is nontrivial to detect this in every case (e.g. passing a TYPE
>> actual to a CLASS formal arg), but at least we can easily detect it if
>> a polymorphic *actual* argument is involved (which means that the
>> corresponding formal arg must also be polymorphic).
>
>
> Sorry, I cannot follow he
Janus Weil:
here is a patch for an accepts-invalid problem: The Fortran standard
demands that a procedure with a polymorphic dummy arguments can only
be referenced with an explicit interface (see F08:12.4.2.2).
I concur.
It is nontrivial to detect this in every case (e.g. passing a TYPE
actua
Hi all,
here is a patch for an accepts-invalid problem: The Fortran standard
demands that a procedure with a polymorphic dummy arguments can only
be referenced with an explicit interface (see F08:12.4.2.2).
It is nontrivial to detect this in every case (e.g. passing a TYPE
actual to a CLASS forma
18 matches
Mail list logo
