http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52111
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-02-05
16:43:38 UTC ---
(In reply to comment #4)
> >> Thus, the compiler is not required to diagnose it - and, seemingly,
> >> the Cray compiler doesn't.
Regarding the first part of the sentence, the Fortran standard (here: Fortran
2008) has in "1.5 Conformance":
"A processor conforms to this part of ISO/IEC 1539 if: [...]
(3) it contains the capability to detect and report the use within a submitted
program unit of an additional form or relationship that is not permitted by the
numbered syntax rules or constraints, including the deleted features described
in Annex B"
Thus, for those the standard requires the compiler ("processor") to diagnose
invalid programs (at compile time).
However, it is often not possible to detect invalid code at compile time - or
either not reliably or not in all cases. Thus, the standard does not require
the diagnoses in general - and also not in this case.
How much a compiler checks is a matter of quality of implementation - and
settings. With -Wall or/and -std=f2008 or/and -pedantic, one increases the
change that issues are reported, but - with warnings - one get also a lot of
output for perfectly valid code.
> I think I understand this statement. And if I change my code like this:
[...]
> Then I think program should fail because solveLeft_sub is called with
> class(solverAbstract_t) as passed dummy argument. This is not conform with the
> subroutine.
> In any case gfortran is right, but compiling my new program with Cray there is
> no error. And as you mentionend this is ok, because argument checking is not
> necessary.
> But is it correct that program execution is not stopped by an error?
> In my opinion at runtime there is the above mentioned problem.
There is a problem, however, if one does not access an nonexisting component of
the array or a nonexisting type-bound procedures, one usually gets away with
it. If not, one gets wrong results or a the compiler crashes.
By default compilers do only minimal checking, restricted to the cases where
the standard requires some checking (e.g. allocating an already allocated
variables gives an error). The reason is that most people have somewhat correct
programs and want to run them fast.
Compilers do offer some additional run-time checking (e.g. gfortran's
-fcheck=all), but they can cost quite a bit of performance and they only check
a small subset of potential issues: Those which are commonly to be encountered
and which are somewhat simple to implement.
For your pointer issue, that's not the case: In principle, one should first
check whether the address of the proc-pointer points to a procedure of the
program (and not to a random memory address), then one had to check the
characteristics of the arguments. That's the rank, data type, attributes etc.
And for the type check one had to check whether the dynamic type is compatible
with the actual argument or the declared interface.
Well, doing so is rather difficult. I only know of one compiler which does
(optionally!) extensive checks - and I don't know whether it would detect this
issue.
It is much easier to detect this issue at compile time - that's probably why
the standard is written as it is. But even at compile time it can get
difficult: If one of the arguments in the proc-pointer interface is itself a
procedure interface, which takes again a procedure. One then needs to drill
deeper and deeper into the interface to check whether it correct. -- I am sure,
that it is possible to find cases where also gfortran fails to detect invalid
arguments.
For a compiler writer, it is already difficult enough to generate fast code
from valid programs. Providing an extensive and helpful diagnostic for invalid
code is even more difficult as there are even more ways to write invalid
programs than to write valid programs.
Closed as INVALID.
