This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, fortran] PR20441 -finit-local-zero
- From: Tobias Burnus <burnus at net-b dot de>
- To: Asher Langton <langton2 at llnl dot gov>
- Cc: "'fortran at gcc dot gnu dot org'" <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 20 Aug 2007 18:30:56 +0200
- Subject: Re: [PATCH, fortran] PR20441 -finit-local-zero
- References: <1953a4560708171312u705f5bf4ie9d8ce645d2f02b6@mail.gmail.com>
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" ...
Tobias
PS: I wonder whether it makes sense to have -finit-character=c to
initially character variables with, e.g. "XXXXXXXXXXXXXXXXXXXX".