|Summary:||Add compiler flag to check for uninitalized values at runtime|
|Component:||fortran||Assignee:||Not yet assigned to anyone <unassigned>|
|Build:||Known to work:|
|Known to fail:||Last reconfirmed:||2007-04-18 07:14:46|
|Bug Depends on:|
Description tobias.burnus 2006-05-13 14:11:54 UTC
Currently, gfortran does not seem to have any option to catch uninitialized variables at run time. Example (from http://www.polyhedron.com/pb05/linux/diagnose.html): --------<UNIN1>------------ program uin1 integer x,y,a,b x=y a=b print *,x,a b=1 end --------------------------- Other compilers have an options to catch those, e.g.: ifort64-9.1 -C -check all -warn all,nodec,interfaces -gen_interfaces -traceback -fpe0 -fpstkchk UIN1.F ./a.out forrtl: severe (193): Run-Time Check Failure. The variable 'uin1_$Y' is being used without being defined NAG: f95 -C=all -C=undefined -info -g -gline UIN1.F ./a.out Reference to undefined variable Y Program terminated by fatal error In UIN1, line 5 of UIN1.F
Comment 1 tobias.burnus 2006-05-13 14:17:06 UTC
Post scriptum: In this case, using -Wuninitialized -O the compiler detects that the variable is uninitialized; however, for the other UIN*.FOR examples at polyhdron.com they are not detected at compile-time.
Comment 2 Tobias Burnus 2007-03-22 22:20:33 UTC
There are actually two run-time tests possible: a) Check only local variables (What to do about actual arguments to intent(in) dummy arguments? In the most cases this is wrong, however foo(read_argument=.false.,arg=uninitialized) is possible. Better don't check - or only optionally.) This seems to be done by ifort's -check uninit. b) Checking all calls, i.e. by passing additional information. This is done by NAG f95's -C=undefined. This is more comprehensive, but makes procedures compiled -C=undefined incompatible to those compiled without. Ideally, gfortran should offer both options.
Comment 3 Tobias Burnus 2007-06-21 16:58:37 UTC
Dump a valid program which contains equivalence to show a harder case for the checks (NAG f95 chokes on it). program main implicit none integer :: i, it, jt real :: tt equivalence (jt,tt) dimension it(10) do i=1,10 tt=i print *, tt, jt it(i)=jt end do end
Comment 4 Tobias Burnus 2007-06-22 13:15:40 UTC
(In reply to comment #3) > Dump a valid program which contains equivalence to show a harder case for the > checks (NAG f95 chokes on it). Actually this is wrong according to the Section 16.5.6 of the F2003 standard: "When a variable of a given type becomes defined, all associated variables of different type become undefined." There then follows an exception that allows REAL and COMPLEX to be equivalenced and not be undefined in this circumstance. Thus one should check for this as well (but having a note in the documentation for this case would make sense too.)