Home > Archive > Fortran > August 2005 > ifort to detect undefined variables?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
ifort to detect undefined variables?
|
|
|
| Hi there,
I'm quite annoied that the intel fortran compiler on linux I'm using can not
detect the undefined variables which will cause a lot of unpredictable
error and cost me a lot time to find it out.
Anyone can tell me what's the paramter to enable undefined variables
detecting? I'm not lucky in finding this either on intel website or google.
Thanks,
Sarah
| |
| glen herrmannsfeldt 2005-08-08, 5:03 pm |
| sarah wrote:
> I'm quite annoied that the intel fortran compiler on linux I'm using can not
> detect the undefined variables which will cause a lot of unpredictable
> error and cost me a lot time to find it out.
> Anyone can tell me what's the paramter to enable undefined variables
> detecting? I'm not lucky in finding this either on intel website or google.
It is rare to actually check for undefined variables at runtime.
The last compiler I used that did was WATFIV. It did it by setting all
the bytes to X'81', assuming that was rare enough. It worked pretty
well except for CHARACTER*1 where, with only 256 possible values, it is
fairly likely to be used. I believe it is a printable EBCDIC character.
Java compilers, at least from Sun, do a compile time check. It the
compiler can't prove that a variable is initialized before use the
compile will fail. Ones I know aren't good enough to pass
if(something) i=1; else i=2;
as initializing i. Still, if it catches some errors it is probably
worthwhile.
-- glen
| |
| Steve Lionel 2005-08-08, 5:03 pm |
| On Mon, 08 Aug 2005 10:36:14 -0700, sarah <navysky74@hotmail.com> wrote:
>I'm quite annoied that the intel fortran compiler on linux I'm using can not
>detect the undefined variables which will cause a lot of unpredictable
>error and cost me a lot time to find it out.
>
>Anyone can tell me what's the paramter to enable undefined variables
>detecting? I'm not lucky in finding this either on intel website or google.
Sarah,
Did you ask this in our user forum or in a request to Intel Premier Support?
We'd be glad to have helped you that way. See my signature below for links.
Our Linux compiler does not, at present, have the uninitialized variable
detection feature. Our Windows compiler does, but only in limited contexts.
We are working to support this across all platforms and usage models for a
future release.
Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
| |
| e p chandler 2005-08-08, 5:03 pm |
| sarah wrote:
"I'm quite annoied that the intel fortran compiler on linux I'm using
can not
detect the undefined variables which will cause a lot of unpredictable
error and cost me a lot time to find it out."
Other programs such as FTNCHEK
http://www.dsm.fordham.edu/~ftnchek/
might help you.
Click the _download_ link. They have a intel linux binary there or you
can compile from source.
I don't know whether this program deals with F9x but I've used it on
Fortran 77 and older code.
| |
| Ushnish Basu 2005-08-08, 5:03 pm |
| sarah <navysky74@hotmail.com> writes:
>
> Anyone can tell me what's the paramter to enable undefined variables
> detecting? I'm not lucky in finding this either on intel website or google.
>
Umm, "-implicitnone"?
--
Ushnish Basu ubasu@ce.berkeley.edu
+1 510 644-1906 www.ce.berkeley.edu/~ubasu
| |
| Rich Townsend 2005-08-08, 5:04 pm |
| Ushnish Basu wrote:
> sarah <navysky74@hotmail.com> writes:
>
>
>
>
> Umm, "-implicitnone"?
>
No, that will only help detect undeclared variables. Declaration and
initialization are two seperate issues.
cheers,
Rich
| |
|
|
"sarah" <navysky74@hotmail.com> wrote in message
news:dd8571$28j$1@nntp.itservices.ubc.ca...
> Hi there,
>
> I'm quite annoied that the intel fortran compiler on linux I'm using can
> not
> detect the undefined variables which will cause a lot of unpredictable
> error and cost me a lot time to find it out.
>
> Anyone can tell me what's the paramter to enable undefined variables
> detecting? I'm not lucky in finding this either on intel website or
> google.
>
> Thanks,
> Sarah
If you can do testing under Windows, the Salford Fortran 95 compiler, a free
download for personal use (www.salford.co.uk) does have this option.
If you go to the Polyhedron website (www.polyhedronc.o.uk) you can find a
review of compilers based on their diagnostic ability. If the Intel compiler
won't find a show-stopper you should be able to justify an employer paying
for a second, more suitable, compiler.
Most common is the option to guarantee that undefined variables are
initialised to zero, rather than picking up whatever binary pattern they
happen to inherit at the time. For most people, most of the time, this is
the default that they want, as non-zero initial values are usually known and
therefore explicitly coded.
The CDC compilers did this as the default in the 1970s - Fortran compilers
seem to have become regressive in this area.
| |
| Ushnish Basu 2005-08-08, 10:02 pm |
| Rich Townsend <rhdt@barVOIDtol.udel.edu> writes:
> Ushnish Basu wrote:
>
> No, that will only help detect undeclared variables. Declaration and
> initialization are two seperate issues.
>
Of course. I guess I misunderstood the sense in which the OP meant
"undefined".
Ushnish
> cheers,
>
> Rich
--
Ushnish Basu ubasu@ce.berkeley.edu
+1 510 644-1906 www.ce.berkeley.edu/~ubasu
| |
| Gordon Sande 2005-08-08, 10:02 pm |
|
> sarah wrote:
>
>
>
>
Lahey has the capability and a version for Linux. Lahey expect to be
paid for both their Windows and Linux versions if I read their web site
correctly
Or you could try the Salford FTN95pe and balance the price is right at
free against the need to run under Windows.
It depends on how expensive your time is and how much trouble a hidden
bug can cause.
| |
| Nachiket Gokhale 2005-08-08, 10:02 pm |
| sarah wrote:
> Hi there,
>
> I'm quite annoied that the intel fortran compiler on linux I'm using can not
> detect the undefined variables which will cause a lot of unpredictable
> error and cost me a lot time to find it out.
>
> Anyone can tell me what's the paramter to enable undefined variables
> detecting? I'm not lucky in finding this either on intel website or google.
>
> Thanks,
> Sarah
Probably, your best bet is valgrind. See http://www.valgrind.org. I
think it can detect undefined variables, but I'm not sure. I've mainly
used it to detect use of unallocated/uninitialised malloced memory in C/C++
-Nachiket.
| |
| glen herrmannsfeldt 2005-08-08, 10:02 pm |
| Max wrote:
(snip regarding undefined value detection)
> Most common is the option to guarantee that undefined variables are
> initialised to zero, rather than picking up whatever binary pattern they
> happen to inherit at the time. For most people, most of the time, this is
> the default that they want, as non-zero initial values are usually known and
> therefore explicitly coded.
The problem is that it doesn't help you identify real logic
errors in the program. I did once have a program that accidentally
worked because a variable was initialized non-zero. It failed when
run on a system that initialized to zero, and I then found the bug,
but that is unusual.
I once knew a system, a modified OS/360 MVT, that initialized
to X'81'. I believe the linker also had to be modified, as holes
(uninitialized data) in the object program may be filled at link
time. X'81' is not so bad for finding bugs, and I would
prefer that to X'00' unless the language defined initializing
to zero.
> The CDC compilers did this as the default in the 1970s - Fortran compilers
> seem to have become regressive in this area.
Initializing can be slow. I noticed recently on linux that malloc()
space isn't actually allocated until it is used. I had to use
calloc(), the initializing version, to actually allocate memory.
-- glen
| |
| Richard Maine 2005-08-08, 10:02 pm |
| In article <m13bpk6paz.fsf@yaman.ce.berkeley.edu>,
Ushnish Basu <ubasu@ce.berkeley.edu> wrote:
> Rich Townsend <rhdt@barVOIDtol.udel.edu> writes:
>
> Of course. I guess I misunderstood the sense in which the OP meant
> "undefined".
The Fortran standard defines the term "undefined". The usual first
assumption here is that people mean it as defined in the standard. Of
course, that first assumption isn't always correct, and it is worth
verifying when there is an indication that something else might be
meant, as has certainly happened more than once.
In the standard, "undefined" means, approximately, "does not have a
value". The fine points are a little more subtle, though. The meaning is
closer to "if the program ever tries to reference the value, then the
program is nonstandard and anything can happen." In practice, the
"anything" is most often just that it looks like some value, but
different compilers (or different runs with the same compiler) might
give different values. Basically, "undefined" is the standard's way of
saying that the the compiler can do whatever it wants, and that even
trying to figure out what the compiler did makes your code nonstandard.
None of this has anything to do with being implicitly typed.
| |
| glen herrmannsfeldt 2005-08-08, 10:02 pm |
| Richard Maine wrote:
(snip)
> The Fortran standard defines the term "undefined". The usual first
> assumption here is that people mean it as defined in the standard. Of
> course, that first assumption isn't always correct, and it is worth
> verifying when there is an indication that something else might be
> meant, as has certainly happened more than once.
> In the standard, "undefined" means, approximately, "does not have a
> value". The fine points are a little more subtle, though. The meaning is
> closer to "if the program ever tries to reference the value, then the
> program is nonstandard and anything can happen." In practice, the
> "anything" is most often just that it looks like some value, but
> different compilers (or different runs with the same compiler) might
> give different values. Basically, "undefined" is the standard's way of
> saying that the the compiler can do whatever it wants, and that even
> trying to figure out what the compiler did makes your code nonstandard.
In the past, the system (OS) would sometimes leave whatever was
previously stored in memory, maybe even results from a previous
program. For security reasons they usually don't do that now.
Ones complement machines or sign magnitude machines could initialize
to negative zero and trap on referencing it. Some machines can store
data with invalid parity and detect that. Both can be useful
for debugging.
The WATFIV test for X'81' would seem to violate the standard,
making an otherwise legal value illegal. (References are considered
a fatal error, except in WRITE statements where the field is filled
with U's.) I believe, though, that in many cases the tradeoff is
worthwhile.
-- glen
| |
| Peter Browry 2005-08-09, 9:03 am |
|
> Most common is the option to guarantee that undefined variables are
> initialised to zero, rather than picking up whatever binary pattern they
> happen to inherit at the time. For most people, most of the time, this is
> the default that they want, as non-zero initial values are usually known and
> therefore explicitly coded.
For me, that's not a desired feature but a very bad one!
Since zero usually is a "realistic" value, this may result in "realistic" but
erroneous results; thus this feature prevents finding of the code errors.
For this issue, a compiler which assigns "random" values to undefined variables
does a much better job.
BTW intel linux fortran finds undefined variables during compilation time
(not sure if all, eg regular variables, common blocks etc), but I have seem compilation
errors on undefined variables.
/Peter
| |
| Richard Edgar 2005-08-09, 9:03 am |
| Peter Browry wrote:
>
>
> For me, that's not a desired feature but a very bad one!
> Since zero usually is a "realistic" value, this may result in
> "realistic" but
> erroneous results; thus this feature prevents finding of the code errors.
I'll second that - it's a problem I've been caught by several times in
the past (particularly in older codes which made use of implicit
declaration, where a typo can create a new single-use variable).
> For this issue, a compiler which assigns "random" values to undefined
> variables does a much better job.
Better yet, assign silly values. e.g. floating point variables get set
to NaN, integers to HUGE. Best of all, if the compiler whinged loudly
about use-before-definition (although I imagine there are cases where
this is impossible until runtime, so the silly-value option would have
to be used).
Richard
| |
| Herman D. Knoble 2005-08-09, 9:03 am |
| Sarah: I assume that by "undefined" you also mean "uninitialized"
under Linux you can write a one line script to invoke Lahey LF95
to detect undefined (uninitialized) variables as follows:
# Compile using Lahey LF95 with debug options.
lf95 $1 $2 $3 $4 $5 --chkglobal -g --co --nsav --pca --warn
if you call this file, lfdebug
you can then issue, for example:
sh lfdebug myprog.f90
If you add the option: --staticlink
that is: sh ifdebug --staticlink myprog.f90
then you could get someone with Unix LF95 to compile your
program, email you the .exe and in this way check out
this Lahey compiler feature.
It was good to hear Steve indicate that the Intel compiler for
Linux will in time detect this kind of programming bug.
All the best.
Skip
On Mon, 08 Aug 2005 10:36:14 -0700, sarah <navysky74@hotmail.com> wrote:
-|Hi there,
-|
-|I'm quite annoied that the intel fortran compiler on linux I'm using can not
-|detect the undefined variables which will cause a lot of unpredictable
-|error and cost me a lot time to find it out.
-|
-|Anyone can tell me what's the paramter to enable undefined variables
-|detecting? I'm not lucky in finding this either on intel website or google.
-|
-|Thanks,
-|Sarah
| |
| sarah 2005-08-10, 10:02 pm |
| Gordon Sande wrote:
>
>
>
> Lahey has the capability and a version for Linux. Lahey expect to be
> paid for both their Windows and Linux versions if I read their web site
> correctly
>
> Or you could try the Salford FTN95pe and balance the price is right at
> free against the need to run under Windows.
>
> It depends on how expensive your time is and how much trouble a hidden
> bug can cause.
Thanks for all your kind help. Seems it'll need some time for me to figure
it out.
Sarah.
| |
| Dave Thompson 2005-08-14, 4:00 am |
| On Mon, 08 Aug 2005 11:36:26 -0700, glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:
> ... WATFIV [checked for undefined] by setting all
> the bytes to X'81', assuming that was rare enough. It worked pretty
> well except for CHARACTER*1 where, with only 256 possible values, it is
> fairly likely to be used. I believe it is a printable EBCDIC character.
>
lower-case a . I *think* the predecessor WATFOR also did this and
lower-case had not yet been assigned in EBCDIC then, but this is from
quite old and patchy memories.
- David.Thompson1 at worldnet.att.net
| |
| Gordon Sande 2005-08-14, 9:00 am |
|
Dave Thompson wrote:
> On Mon, 08 Aug 2005 11:36:26 -0700, glen herrmannsfeldt
> <gah@ugcs.caltech.edu> wrote:
>
>
>
> lower-case a . I *think* the predecessor WATFOR also did this and
> lower-case had not yet been assigned in EBCDIC then, but this is from
> quite old and patchy memories.
>
WatFor started on IBM/7040s which were a later designed version of the
IBM/7090 which seemed to have been designed to be less expensive to
produce while having the benefits of the modern technology, like the
second generation of transistors. Part of that was a parity check for
the memory.
WatFor observed that parity checks were so rare they only happened
during testing because they had be deliberately set. So they
initialized all variables to bad parity and stood back and waited for
any parity traps. When they happened they worked their way back through
the symbol tables and reported the results. I was told it was a small
hack at the time.
When they moved WatFor to IBM/360s they discovered that they had to
reproduce this useful and distinctive feature. But with multiprogramming
and swapping of partitions and all the rest of the modern operating
system notions they found that setting bad parity was no longer part
of the game. So they had to work hard which meant setting a user
distinctive bit pattern and checking for it all the time. No longer
a small trivial hack but something that took a fair bit of work to
achieve. For load and go student debugging the only real concern
was how fast the code generation could be run and whether the
error messages were adequate (and free of spelling errors).
> - David.Thompson1 at worldnet.att.net
| |
| glen herrmannsfeldt 2005-08-22, 3:57 am |
| Gordon Sande wrote:
(snip regarding WATFOR and WATFIV undefined value tests)
> When they moved WatFor to IBM/360s they discovered that they had to
> reproduce this useful and distinctive feature. But with multiprogramming
> and swapping of partitions and all the rest of the modern operating
> system notions they found that setting bad parity was no longer part
> of the game.
As far as I know, S/360 and successors provide no way to set
bad parity. It would probably be detected through a machine
check interrupt, not normally used by user programs.
(I did once have a job abend due to a machine check
interrupt in a place that charged real money. It took a while
to convince them that I shouldn't be charged for that one.)
> So they had to work hard which meant setting a user
> distinctive bit pattern and checking for it all the time. No longer
> a small trivial hack but something that took a fair bit of work to
> achieve. For load and go student debugging the only real concern
> was how fast the code generation could be run and whether the
> error messages were adequate (and free of spelling errors).
I have used it to find bugs in fairly large programs.
-- glen
| |
| Gordon Sande 2005-08-22, 7:02 pm |
| On 2005-08-22 05:48:00 -0300, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
> Gordon Sande wrote:
>
> (snip regarding WATFOR and WATFIV undefined value tests)
>
>
> As far as I know, S/360 and successors provide no way to set
> bad parity. It would probably be detected through a machine
> check interrupt, not normally used by user programs.
I had been lead to believe that bad parity could be set by use
of the machine DIAGNOSE instructions which were unique to each model
and certainly off bounds for user and system programs. They were for
hardware diagnostics only. I expect that documentation was a bit of
a bother to obtain.
| |
| glen herrmannsfeldt 2005-08-22, 7:02 pm |
| Gordon Sande wrote:
(snip regarding parity and S/360)
> I had been lead to believe that bad parity could be set by use
> of the machine DIAGNOSE instructions which were unique to each model
> and certainly off bounds for user and system programs. They were for
> hardware diagnostics only. I expect that documentation was a bit of
> a bother to obtain.
Mostly by reading the microcode, as I understand it.
Though the proper initialization of storage is described in
come of the manuals. Machines using ECC memory can generate
errors when writing unaligned data or data smaller than the
ECC block.
As far as undefined value checking, the parity (or ECC) might
be on a larger block that the data being referenced; eight
bytes on larger S/360s, and I believe two for the 360/40.
-- glen
|
|
|
|
|