Welcome to our forums
I see compiler option /zeroize was excluded from 8.20. What were the reasons for it to be present before and to be excluded now?
Dan
I am wondering why you think that /ZEROISE has been excluded. It is still available but it turns out that the documentation was incorrect (and is still incorrect in the online help). The corrected text can be found in the latest ftn95.chm as follows...
In the following description, local variables and arrays that are given the SAVE attribute are called static variables.
FTN95 presets the value of all static variables to zero. This is the case even when /ZEROISE is not applied. A related option /SAVE applies the SAVE attribute to all local variables and arrays.
/ZEROISE is provided for use with /UNDEF (and options such as /CHECKMATE that imply /UNDEF). Otherwise /ZEROISE has no impact on the code generated by FTN95.
When used together, /ZEROISE over-rides /UNDEF for static variables and presets these values to zero rather than the 'undefined' state. /ZEROISE is provided for use with Win32 and .NET but not for x64.
Quoted from PaulLaidler FTN95 presets the value of all static variables to zero.
I did not know this !!
There are quite a few nuances in this post. The Fortran standard does not require all this? I am not suggesting it should be changed.
For my usage, static variables that are not in a DATA statement are assumed undefined. Most of the variables I use are dynamic and all are assumed undefined. I do not use /ZERO as I have always assumed this is non-portable.
John
Dan
/ZEROISE has not yet been ported to 64 bits. In 8.0 and 8.1 it was accepted but did nothing. In 8.2 it is made clear that it has not yet been ported.
Thanks for the info and discussion, Paul and John.
Yes, this was with /64. Would be better to have error message for such still work in progress cases instead of
*** /ZEROISE is not available in FTN95/64
something like *** /ZEROISE is available under /32 but not yet ported to FTN95/64
As an additional and i feel good suggestion since Silverfrost already knows how to zeroise everything when program starts consider the command zeroise@ which will do the same by user request. This would be great additional diagnostics tool for the cases when program is doing repeating jobs and by some reason the second run gives different results when program run the code with or without exiting to Windows after first run. That is exactly the devilry i am fighting right now
/ZEROISE is not a useful option in FTN95. It was ported from FTN77 but implemented in a different way. The uncorrected documentation probably describes the FTN77 implementation.
Under FTN95 you get the corresponding preset to zero anyway without using /ZEROISE.
For 32 bits, /ZEROISE only has an impact when used with /UNDEF and there seems to me to be little or no value in this combination. It would mean that SAVEd variables are preset to zero whilst non-SAVEd variables are preset to 'undefined'.
So the SAVEd variables are not checked for undefined with /UNDEF ?
No. They are checked...
options(undef)
integer k
save k
!print*, k
call sub1()
print*, k
end
subroutine sub1()
integer k
save k
print*, k
end
Thanks Paul and Others for the clarification of the impact now of the /ZEROISE option which in 32 bit mode when used without /UNDEF now does nothing.
Paul, could you confirm that the action (inaction) now of using just /ZEROISE has been true for several of the recent releases (say from v8 onwards) and it is only now that the attempt to use /ZEROISE without /UNDEF is flagged up on compilation?
Many Thanks
Bill
The behaviour of /ZEROISE has not changed throughout the lifetime of FTN95. The only superficial change is that its use with /64 is now flagged as an error whilst before it was not flagged as an error but had no effect (with /64).
Thanks Paul -encouraging - some of my very early legacy code should still continue to work.
Note that using just /ZEROISE with 32 bit is with 8.2 now flagged as an error for the first time.
All the best
Bill
Bill
It should be flagged as a warning rather than an error and yes, the warning is new. Again the effect of /ZEROISE has not changed.
WARNING - /ZEROISE only has effect when combined with /UNDEF
As you say Warning and not error - Many Thanks
Bill
Just to check, variables in COMMON are also static?
Like John-Silver I always assumed that one had to initialise everything before use, and as several systems I used did not implement BLOCK DATA and I always had difficulty remembering the syntax of DATA statements, I got in the habit of having a subroutine where everything was initialised via assignment statements.
It turns out that in a single-document-interface Windows program with Clearwin+, approaching initialisation this way is useful because at any point one can reinitialise, say after a SAVE and a NEW with just a single subroutine call.
At the effort of extra programming, one might EQUIVALENCE an Array A(10,10,10) to a single array B(1000) and initialise B in a single loop rather that three nested loops.
It is now possible to simply write:
A = 0.0
Is this implemented as three nested loops, or is the array linearized first? If the latter, then is it better to continue my old practice? Not that it really matters to me, as FTN95 runs my problems indistinguishably from at infinite speed, but it might matter to someone.
As an example, the stiffness matrix for a numerically integrated cubic 32-node solid elastic 'brick' finite element is a 96x96 array, that is initialized to zero prior to the calculation for each element, of which there are hundreds, perhaps thousands, in an analysis.I can see benefits in initializing its 9216 values in one loop rather than 2 nested ones, but for simplicity and clarity doing it in one statement is appealling.
One can also EQUIVALENCE the whole of a named COMMON block to a single array, and initialize the whole lot in a single loop if the storage is contiguous, which I believe it has to be, although not if different variable types are mixed.
Eddie
Eddie
In order to provide an answer I would write a short test program and look at the output and the assembly list provided by /explist. To test if COMMON variables are preset set to zero I would just print them out without setting a value. Not fool-proof but a fairly safe test. Reading the assembly instructions is not easy but it is quicker than referring to the FTN95 source code.
Let me know how you get on.
Paul,
Yes, it does seem to initialised named and blank COMMON:
PROGRAM TEST_COMMON
COMMON / NAMED / A, B(2), I, J(2)
COMMON Q, R(2)
WRITE(*,*) A, B, I, J
WRITE(*,*) Q, R
END
as appropriate 0.000 and 0 values are output.
Now to look at the other issue.
Eddie
And again, it looks like one loop
mov eax,0.0
mov ecx,Z'0019a280'
lea edi,C
rep
stos
in:
PROGRAM TEST_INIT
DIMENSION C(100, 120, 140)
C = 0.0
END
Which looks to me like a good and efficient result (the hex value is the product of the 3 dimensions). Of course a warning is generated because C isn't used.
(32 bit only tried).
Eddie
Despite all the above comments, are there still plans to implement /Zeroise for 64-bit usage?
Our application is 'built on old sand' and trying to do a 64-bit release of it without /zero would give me 'anal jitters'!!!
K
Quoted from John-Silver Kenny, read Paul's initial reply (first comment on p.1).
It appears thqat /ZEROISE is effectively the default and included automatically for 64-bit compiler.
I guess it's just a question of you running your application and seeing what happens to start with !!!
hmmm,
unless i've completely misunderstood...
Paul said it's not implemented for the 64-bit compiler...yet...
K
Kenny
My understanding remains as follows...
/ZEROISE was incorrectly documented. What you expect to get with /ZEROISE, you get anyway.
/ZEROISE only has an impact when used with /UNDEF (for Win32 and .NET).
/ZEROISE (for use with /UNDEF) has not yet been implemented for x64.