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
On Sat, Jun 17, 2006 at 10:27:07AM -0700, Brooks Moses wrote:
> Steve Kargl wrote:
> >Arguments.
> > POINTER shall be a pointer and may be of any type.
> > Its pointer association status shall not be undefined.
> >
> >With the program the FX posted, gfortran needs to issue an
> >error and exit.
>
> 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.
> I don't think this _can_ always be diagnosed in the general case.
Strictly speaking you are correct that this isn't a constraint.
OTOH, in this case I'd argue that the "shall not be undefined."
should emit an error if it can be detected.
> We could possibly do something like automatically initializing all
> pointers to a value that means "undefined", but even that's tricky when
> they're deep in an array of derived types as in the given case. Any
> solution to that one ought, in my opinion, be written generally enough
> to handle initializing variable values to an "undefined" sentinel value
> as well.
I agree that (at least) pointers should be initialized (but
not necessarily SAVEd) to some specific value. Consider
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
If you look at the tree dump (removing the a bunch of junk), you find
MAIN__ ()
{
int4 * i;
{
logical4 D.901;
D.901 = i != 0B;
}
}
Personally, I would prefer
MAIN__ ()
{
int4 * i = OxDEADC0DE;
{
if (i == 0xDEADCODE) generate_error()
if (i == OB) return FALSE
else return TRUE
}
}
--
Steve