This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, fortran] PR20441 -finit-local-zero


On 8/20/07, Tobias Burnus <burnus@net-b.de> wrote:
> Hi Asher,
>
> Asher Langton wrote:
> > Here's a patch to add -finit-local-zero,
> Shouldn't also the derived variables be initialized?
>
> type bar
>   real :: r
>   complex :: z
>   integer :: i
>   character(len=5) :: c
>   logical :: l
> end type bar
> type(bar) :: t
>
> print *, t%r; print *, t%z; print *, t%i;
> print *, t%c; print *, t%l
> end
>
> With ifort and sunf95 they are set to zero; with "openf95 -zerouv" they
> are zero. NAG f95 gives partially zeros (?) but -nan works.
>
> I therefore think that -finit* also should initialize those. Replacing
> "integer :: i" by "integer :: i = 5" changes the behaviour of gfortran
> (independent of the -finit* options): Not only "i" is initalized but all
> other variables are initialized to zero. Using -finit-real=nan I would
> still expect NAN and not "0.0" ...

Hi Tobias,

I've thought about this quite a bit, and I haven't come up with a good
solution.  If some of the components have initializers, then I can add
initializers to the gfc_constructor for the remaining components (in
expr.c::gfc_default_initializer()).  However, I couldn't find a
straightforward way to avoid initializing derived types variables that
appear in equivalence statements, so this fails in
gfortran.dg/equiv_7.f90::derived_types().

Handling arbitrary derived types is tougher.  For a scalar derived
type, it would suffice to run through the components and generate some
initialization statements, but initializing arrays of derived types is
more difficult.  It can probably done by abusing the gfc_constructor
initializers and letting trans-expr.c::gfc_trans_assignment() handle
the scalarization, but I haven't figured out a clean way to do this.

For now, my inclination is to leave derived type initialization as a
TODO and document the -finit-* limitations in the manual.  If that's
acceptable, I'll put together a fresh patch with the added
documentation, as well as an -finit-character option.

-Asher


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]