On 2008-04-23 14:53:14 -0300, Fei Liu <fei.liu@[EMAIL PROTECTED]
> said:
> Michael Metcalf wrote:
>> "Fei Liu" <fei.liu@[EMAIL PROTECTED]
> wrote in message
news:funrc4$uv7$1@[EMAIL PROTECTED]
>>> Hello Group,
>>> I am trying to come up with a list of compiler/linker options so
that
>>> when the following code is run, a run time failure is generated. Or at
>>> least a compile time diagnosis is re****ted.
>>>
>>> The target compiler is Intel ifort. I would like to catch as many
>>> non-standard coding practice as possible at both compile time and run
>>> time.
>>>
>>> I currently use '-std -warn all -WB -Winline -traceback' but it does
>>> not catch the error in the following code.
>>>
>> In the general case your 'error' cannot be detected at either compile-
>> or run-time, other than by wearing your seat-belt:
>>
>> if(size(x) /= size(y)) print *, 'Ring the alarm bells!'
>>
>> Regards,
>>
>> Mike Metcalf
>>
> Thanks, in general I am looking for a set of stricter compiler/linker
> options that will help diagnose potential problems.
>
> Fei
There is always the option of usng a compiler which is intended to sup****t
debugging. Multiple compilers is always a good way to catch dodgy coding.
The Salford/Siverfrost compiler for Windows is one. Another is NAGWare V5
which sup****ts multiple platforms. Salford is free for personal use. NAG
is not. Lahey/Fujitsu is also good and not free. Windows and Linux if I
recall correctly. Checking for out of range subscripts for assumed size
("*" form) arrays, and some other tings, may not be compatible with third
party precompiled libraries because of the extra information that is
carried at run time.
Turning subscript checking and undefined variable checking on will cause
things
to run slower. Some folks prefer slow correct results to fast wrong ones.
Once the code is fully debugged you are free to turn the training wheels
off.
|
