This is the mail archive of the
mailing list for the GCC project.
Re: [gfortran testsuite, committed] Re: gfortran.dg/forall_1.f90
- From: Brooks Moses <bmoses-nospam at cits1 dot stanford dot edu>
- To: gcc-patches at gcc dot gnu dot org
- Cc: fortran at gcc dot gnu dot org
- Date: Sun, 05 Jun 2005 13:33:15 -0700
- Subject: Re: [gfortran testsuite, committed] Re: gfortran.dg/forall_1.f90
- References: <email@example.com> <42A34AF5.firstname.lastname@example.org> <42A34C56.email@example.com>
FX Coudert wrote:
> > The test made the assumption that
> > if (i /= 0) i = 0
> > means that even if i is uninitialized in the beginning it will be zero
> > afterwards.
> Isn't this true? I think that if optimization doesn't respect that, it
> is a problem, isn't it?
This is not true.
According to the F95 (draft) standard, expressions shall only include
defined variables. If i is uninitialized (and thus undefined), the
above snippet is not standard-conforming code, and thus the result is
undefined. Further, unless the "i=0" statement is executed, i remains
undefined, and thus any code that accesses it in the future also has
There is certainly no requirement that, if the undefined logical
expression in the IF statement happens to be treated as TRUE, future
(undefined) accesses of i will happen to treat it as 0. In particular,
there is no requirement that the processor uniquely allocate any storage
location at all for i until it is first defined, so accessing it could
very easily be reading values from some other variable that gets changed
in the interim.
The "bmoses-nospam" address is valid; no unmunging needed.