View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Tue Feb 18, 2020 4:11 pm Post subject: |
|
|
Dietmar:
I think that your use of the word "static" can be a source of confusion, because the word does not even occur in the Fortran 2008 standard.
Now, "static" has a definite meaning in the C language, but it is not clear if you are using the word in precisely that sense.
There are several attributes of variables at issue:
1. Scope - local or global
2. Lifetime - during the entire run of the program, or only within a subprogram, or only within a block or construct.
3. Initialisation - uninitialised, initialised at program start, initialisation when data entity is created or defined by execution of statements. Initialisation can further be distinguished by whether the initialisation value is 0 (NULL for pointer variables, .TRUE./.FALSE. for logicals, etc.), default initial value for derived type components.
4. Visibility: public or private.
There are probably other properties that I have not listed.
Please state the attributes that you implied by saying "static", or clarify if you meant the C language meaning. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Wed Feb 19, 2020 9:04 am Post subject: |
|
|
Dietmar
I now have a better understanding of how /ZEROISE works.
For 32 bit executables /UNDEF sets SAVEd variables to the undefined state and you must add /ZEROISE if you want to avoid this.
Currently for 64 bit executables /UNDEF does not set SAVEd variables to the undefined state so /ZEROISE is currently redundant in this context.
p.s. 20 Feb 2020: This information for 64 bits is incorrect and requires further investigation.
Last edited by PaulLaidler on Thu Feb 20, 2020 9:15 am; edited 1 time in total |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Wed Feb 19, 2020 11:36 am Post subject: |
|
|
Paul, mecej4,
my intention of the discussion was to recommend SALFORD to please not drop the functionality of /ZEROISE for the 64 bit version of ftn95. For I am using it for 32 bit and find it very helpful
And I would like to use it for 64 bit applications, as well. However, for a big GUI application which we ported from 32 bit to 64 bit the lack of option /ZEROISE for 64 bit implies that I have to explicitly initialise many variables with the SAVED option set to value 0 in order to assure that the application does not stop (if built with /undef).
I tried to make this clear with the short example I mentioned. As mecej4 said the understanding of what is meant with static in fortran seems to be varying (I only used static to have an easy term for the case of variable j in my example being set as SAVED). For me the naming of option /ZEROISE was confusing, too. Let me finally remark that INTEL's ifort compiler does not complain when executing the app created by compiling my short example with option /check:uninit (checking for undefined variables).
Now I do not think it is necessary to proceed with the discussion (@mecej4: probably I had the C static in my mind; thanks for your precise information of what all could be meant with static which I was not aware of when using it).
I'm fine with the functionality of ftn95 32 bit with respect to /undef . And I hope that /ZEROISE will be supported by ftn95 64 bit , as well
Regards,
Dietmar
[/quote] |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Wed Feb 19, 2020 4:16 pm Post subject: |
|
|
Dietmar
I apologise for the confusion. I now see that my last post was incorrect. Somehow my testing had gone wrong. I will look further into this. |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Wed Feb 19, 2020 6:10 pm Post subject: |
|
|
Paul, mecej4,
one more note: mecej4 asked me what I would mean with static. He met the point
I meant the C static meaning and this as well for the options with respect to /undef and the processing of undefined variables while running an application having been built with /undef set. This explains my confusion with ftn95 /ZEROISE option.
You might want to look at the CPP code named C_UNDEF.cpp
Code: |
#include <STDIO.H>
main () {
static int j;
printf ("j=%d\n",j);
}
|
and build the corresponding executable with commands:
scc C_UNDEF.cpp /undef /link
scc C_UNDEF.cpp /undef /no_zeroise /link
Both commands create executable C_UNDEF.EXE. Running C_UNDEF.EXE built with the first command is successful: no complain about undefined variables. Running C_UNDEF.EXE built with the second command results in a runtime error (reference to undefined variable).
To me this behaviour is close to the compiler scc (setting static variables to 0). The additional option /no_zeroise is set if e.g. the static variables not explicitly initialised are intended to be trapped.
Regards,
Dietmar |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Thu Feb 20, 2020 12:30 pm Post subject: |
|
|
/ZEROISE has now been fixed for the next release after v8.61.
/64 /UNDEF /ZEROISE will preset SAVEd variables to zero. |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Fri Feb 21, 2020 9:25 am Post subject: |
|
|
Thanks, Paul,
I'm looking forward to make use of options /64 /UNDEF /ZEROISE in the release after v8.61
Regards,
Dietmar |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Thu Feb 27, 2020 11:01 pm Post subject: |
|
|
So was the bug mecej4 described finally fixed? Hell difficult to find the bugs with it. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Mon Mar 09, 2020 10:06 am Post subject: |
|
|
The line numbering failure reported by mecej4 at the start of this thread has now been fixed. The failure originates in FTN95 and the fix will appear in the next release of FTN95, the one after v8.61. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Tue Mar 10, 2020 5:06 am Post subject: |
|
|
Hopefully this fixes this entire problem, thanks. Just to doublecheck no traces of the bug is left, can you please look at the crashPL.for I have emailed you around June of last year which you and mecej4 helped to fix me. Just open it in debugger. Nothing else is necessary to do because just the first page of opened window in SDBG64 will expose this bug |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Tue Mar 10, 2020 8:56 am Post subject: |
|
|
Dan
I have just now stepped through the first 140 lines of your program and it all looks good to me. |
|
Back to top |
|
|
|