This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [gfortran,patch] Fix wrong-code for ASSOCIATED
Hello,
> On Sat, Jun 17, 2006 at 10:27:07AM -0700, Brooks Moses wrote:
>> > Steve Kargl wrote:
>>> > >With the program the FX posted, gfortran needs to issue an
>>> > >error and exit.
I agree that it would be nice if some error could be given,
at least in a diagnostic mode. I'm a bit unsure whether this should
happen by default or only in a diagnostic mode.
At least for associated() this does not seem to be a big performance
problem and it points at a programming error.
However, I don't know in how tiny the chance is that one allocates an
address which is equivalent to the magic string.
>> > Does it? I agree that it would be nice if it did, but I don't think it
>> > "needs to" diagnose this error -- this text you quote isn't a compiler
>> > constraint. The situation is exactly akin to referencing a variable
>> > with an undefined value, and we don't diagnose that in the general case.
Which is actually something I would also like to see.
> laptop:kargl[204] cat > e.f90
> integer, pointer :: i
> print *, associated(i)
> end
> laptop:kargl[205] gfc -o z e.f90
> laptop:kargl[206] ./z
> T
Which I think is completely sensible for a optimized compilation
and actually exactly the same as NAG's f95 is doing. (ifort, g95 and
Sun's f95 print "F".)
(I frankly don't know what is better, the "F" really hides the
programming error, but a nullify() is what may programmers intend.)
> Personally, I would prefer
> MAIN__ ()
> {
> int4 * i = OxDEADC0DE;
> {
> if (i == 0xDEADCODE) generate_error()
> if (i == OB) return FALSE
> else return TRUE
> }
> }
I wonder which magic string best, i.e. least likely to be encountered
with correctly assigned variables. 0xDEADC0DE, 0xFFFFFFFF, 0x0000001, etc.?
In addition, it should probably be generate_badpointer_error("i") that
way one sees the name of the uninitialied pointer.
* * *
What I would like to see in the long run is a general check for
uninitialized variables.
There I see also to stages:
(a) initialize real and complex values by a signalling NaN. This should
be comparably easy to implement and shouldn't cause a measurable
performance loss.
NAG does so with -nan
g95 with -freal=nan and G95_FPU_INVALID=1 run-time option.
(Actual, g95 allows to initialize real (and complex?) values with
NaN, +Inf, -Inf and zero, the latter is interesting for programs which
somehow think that every variables it automatically initialized with
0.0. In addition, it has for default initialization
-fpointer={null,invalid} -finteger=..., -flogical={true,false} and
-fzero -> -freal=zero -finteger=0 -flogical=false -fpointer=null.)
To this category of fast to implement and fast at runtime I would also
count the associated-MAGICSTRING test.
In the long run also:
(b) Real tests (better but with performance problems, in addition more
cumbersome to implement)
i) Pointer:
if(p == NULL || p == MAGICSTRING) generate_badpointer_error("p");
This should be before any print *, p, y = p + 2 etc.
Using the magic string this shouldn't cause any problems with calls
to subroutines etc.
ii) Integer, real, complex
Somethink like:
create a static boolean variable per variable (or one array for all),
maybe one could even replace the boolean by e.g. an integer and check it
for a magic value as well. If the variable is set, this boolean is set
to true. Then one checks if(!isset_var_i) generate_uninitialized("p")
iii) arrays
analogously, but one should really track it per array element (this is
actually the biggest omission in ifort's initialized checking).
If here not only the name of the variable but also the index could be
shown, it would help a lot with debugging.
In (i) to (iii) one would need to pass the information along the
arguments to the subroutines. Thus one would need to compile the whole
program which such checks.
Tobias