Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

'check uninitialized variables' option not working

LRaim
New Contributor I
638 Views

The variable LCCONT (char*1) is not defined but in debugging mode, notwithstanding the option 'check uninitialized variables' is active , no exception is raised when  following statement is executed in debug mode: 

LCHAR = ICARD(JED)
IF(LCHAR .NE. LCCONT) GOTO 200

 To make comparison no warning is issued by Intel compiler at compilation time.

Instead a very old version of a Lahey compiler issues the following nice message:
 Internal subprogram name(ANALYZE_ICARD)
   2005-W: "V9SYNCHK.FOR", line 577: LCCONT is used but never set.

When such a warning will be available from Intel ??? This will save a lot of time.

 

0 Kudos
7 Replies
andrew_4619
Honored Contributor II
638 Views

check unit is a run time  not a compile time check I recall and is not that extensive in its application. Is LCCONT a local variable?

 

0 Kudos
LRaim
New Contributor I
638 Views

I am stating 2 things.

1) At run time (Visual Studio Professional 2012 with Intel(R) Visual Fortran Compiler XE 15.0.1.148 [IA-32] ) no exception is raised.

2) I can't understand why, at compilation, a simple warning as that issued by the Lahey compiler is not generated by the Intel compiler.

Regards 

0 Kudos
mecej4
Honored Contributor III
638 Views

The compiler default is to optimize, not check. If you are developing code or suspect that the code has bugs, you have to ask for checks.

program uninit
implicit none
integer :: jed,lchar,lccont,icard
jed=15
LCHAR = ICARD(JED)
IF(LCHAR .NE. LCCONT) GOTO 200
write(*,*)'Equal'
200 continue
end

integer function icard(j)
implicit none
integer j
icard=2*j+7
return
end

Compile with /check:all and run, to see:

forrtl: severe (194): Run-Time Check Failure. The variable \'_UNINIT$LCCONT\' is being used in \'s:\lang\uninit.f90(6,10)\' without being defined
Image              PC        Routine            Line        Source
libifcoremd.dll    63FE4165  Unknown               Unknown  Unknown
uninit.exe         00301082  _MAIN__                     6  uninit.f90
uninit.exe         003011BF  Unknown               Unknown  Unknown

 

0 Kudos
andrew_4619
Honored Contributor II
638 Views

If the variable is not local the compiler could have no way of knowing when compiling at the time you touch a variable in a source if the code path to get their (in some other source) would mean it was uninitialised or not.

And even if it is local consider that  a variable could in initialised or by code that is conditional on other values that are determined at run time. 

0 Kudos
LRaim
New Contributor I
638 Views

This is an example of the piece of code in question. 

 PROGRAM UNINIT
 IMPLICIT REAL*8(A-H,O-Z), CHARACTER*1(L)
 CHARACTER*1 ICARD(80)
 CHARACTER*1 LBLANK/' '/
 ICARD = LBLANK
 JED = 17
 LCHAR = ICARD(JED)
 IMATCH = 0
 IF(LCHAR .EQ. LCCONT) IMATCH = 1
 WRITE(*,6000) LCHAR,LCCONT,IMATCH
6000 FORMAT(2X,' LCHAR ',Z2.2,' LCCONT ',Z2.2,' IMATCH ',I2)
 READ(*,*) LCHAR
 STOP
 END
=====================================

Runtime error checking is set to (/check:all) .

The result is :

   LCHAR 20 LCCONT 00 IMATCH  0

and no Runtime check failure is issued.


 

 

0 Kudos
Steven_L_Intel1
Employee
638 Views

/check:unint handles only procedure local scalars. We know it could be improved.

0 Kudos
LRaim
New Contributor I
638 Views

Steve Lionel (Intel) wrote:

/check:unint handles only procedure local scalars. We know it could be improved.

Perhaps LCHAR and LCCONT are not local scalars ?

0 Kudos
Reply