BUG in SDBG64

I have often observed that when code is compiled with /64 and /check or /checkmate and run from SDBG64, the lines that can be breakpointed are often messed up. Today I found an example code that is short and easy to follow.

When I compile and open the program in SDBG64 8.50, I find that only two lines in the subroutine admit a breakpoint: Lines 16 (the declaration of the dummy argument A) and 38 (the last statement of the program) are displayed with a dot in column-1.

If the program is compiled with /64 and /checkmate and run, the program stops with 'undefined...' on the END statement of the subroutine. I am using the 8.51 compiler.

A related request: when an undefined variable is detected, the debugger or the error message only divulges the line number where the problem occurs. It would be nice to have the name of the undefined variable displayed as well, since otherwise one has to look up each variable in a lengthy expression to ascertain which element of the expression is undefined.

The test code:

      program xdgemv
      implicit none
      double precision a(1,1),x(1),y(1),alpha,beta
      alpha = 1d0
      beta  = 0d0
      x(1) = 4d0
      call dgemv('n',1,1,alpha,a,1,x,beta,y)
      print *,y
      end program

      subroutine dgemv (trans, m, n, alpha, a, lda, x, beta, y)
      implicit none
      double precision   alpha, beta
      integer            lda, m, n
      character*1        trans ! not used, but needed to reproduce bug
      double precision   a( lda, * ), x( * ), y( * ), temp
      double precision, parameter :: one = 1.0d0, zero = 0.0d0
      integer            j, jx, kx, leny
      leny = m
      kx = 1
      if( beta.ne.one )then
         if( beta.eq.zero )then
            y(1:leny) = zero
         else
            y(1:leny) = beta*y(1:leny)
         end if
      end if
      if( alpha.eq.zero ) return
      jx = kx
      do j = 1, n
         if( x(jx).ne.zero )then
            temp = alpha*x(jx)
            y(1:m) = y(1:m) + temp*a(1:m,j)
         end if
         jx = jx + 1
      end do
      return
      end

Good you found short example, mecej4, I had this bug too but was not able to shorten the code. Hope new version of compiler will fix this, please someone confirm this before I will try it

It would appear not...

But it does not appear to be working in my tests.

using SDBG64 and F7 to step through the program:

For ver 8.40, it reports on entry to dgemv to go to line 16 then to line 38, then reports an undefined variable. local variables in dgemv are not initialised.

For ver 8.51 FTN95 (ver 8.50 SDBG64), it reports on entry to dgemv to go to line 16 then to line 38, then returns to line 8. local variables in dgemv are not initialised.

For both recent versions of FTN95, SDBG64 does NOT appear to report it is processing through the lines of subroutine dgemv.

Robert, does Ver 8.6 of FTN95 / SDBG64 report a different result ?

I should point out that the fault could just as well lie in the debug information generated by the compiler and inserted into the OBJ file, rather than with the debugger itself. As far as we users can tell, there is no way to distinguish between the two possibilities.

The issue is still in 8.60 and 8.61 (not released yet). Curiously the issue isn't present when just using /debug.

This issue, and other similar problems, with sdbg64 not allowing lines to be breakpointed are down to incorrect debugging information. sdbg64 is just showing you what it has been told - and getting the blame.

The /debug /check is very important debug combination. Before it was often causing crashing of SDBG64 so I removed /check and was debugged codes without it. Recently after two years when /debug /check combination became stable I tried it again and found a lot of bugs i introduced in my codes...

As to this bug of not allowing some lines to be debugged -- it actually exists also even with the /debug alone in some codes. I have no small example but you can find the fact of that in my file crashPL.for I have sent around June of last year to Paul when we discussed some other bug. Just click on my batch file _A6432.bat, and it will compile and then open debugger automatically where you will immediately see on the first page a lot of such debug's miss lines

I would like to remark in this context that for me option /undef is very important, as well. And that option /ZEROISE is still missing for ftn95, Version 8.60 in the 64 bit case.

I would like to point out that in

https://forums.silverfrost.com/Forum/Topic/3236&highlight=zeroise

Paul says

FTN95 presets the value of all static variables to zero

and hence in my opinion there simply are no undefined static variables.

However, as /ZEROISE has not yet been implemented, currently statical variables which have not yet been initialised explicitly in the code, are marked as undefined, if running an application built with options

/undef /64

set. And what is even worse the application is stopped. This is simply false. You might look at the code

      integer j
      save j   
      write(*,*) 'j=',j
      end

which stops in case of compiling it with options /undef /64 /link. If compiling it without /undef (but with /64 /link) then executing the corresponding executable shows the value j=0.

I remark this here because we have been porting an application from 32 to 64 bit which has stopped with a runtime error after some hours of execution. We used the /debug option to see the names of the routines involved. However, when using option /undef the application stopped because of many static variables having not been explicitly initialised. For this reason I would recommend to support option /ZEROISE for 64 bit, as well.

Regards Dietmar

I checked mecejs code for ftn95 Version8.60.

Using sdbg64 for the executable compiled with /debug a breakpoint may be set at the following lines (having a dot at column -1 in the debugger):

line 4-8, 16, 19-23,25, 28-33, 35-37

, but **not **at line 38 (end statement).

Now doing the same with the executable compiled with /checkmate instead of /debug, the debugger shows lines 4-8,16,38 (end statement) with a dot at column -1. The program stops with 'undefined' at the end statement.

Regards, Dietmar

Thanks for the report on Version 8.6, Dietmar.

Except when /opt has been used in combination with /debug (some Fortran compilers do not allow combining optimisation and production of debug information), every executable statement should admit being set as a breakpoint.

With /opt and a highly optimising compiler, the compiler may rearrange some operations and we may see the cursor move up when we step over to the 'next' statement. Similarly, certain source statements may have been optimised away, so it would be impossible to break on them.

In FTN95, /check and /checkmate both imply /debug, so /debug need not be explicitly requested.

Dietmar

I wonder if you are aware off the previous posts on /ZEROISE.

Basically:

1. The documentation was incorrect for many years. /ZEROISE was designed for FTN77 but is almost meaningless in 32 bit FTN95. The documentation is now correct. You are correct in saying that /64 /ZEROISE is currently not accepted.

2. SAVEd variables are always zeroised.

3. ALLOCATEd variables are currently zeroised.

4. /LOCAL_ZERO causes local variables to be zeroised.

Paul,

thanks for your information about 3) and 4) which I did not know.

However, my main focus was to express my unhappiness about the missing /ZEROISE option for ftn95 version 8.60 in case of using /64 /undef.

The question is: why is statical variable j in my example marked as undefined at runtime although it is intialised to 0 (implicitly by ftn95) and - as a consequence - stops the application? Thus I need to explicitly initialise all static variables if trying to use /undef for 64 bit applications.

Maybe I misunderstood the meaning of undefined. To my opinion a static variable implicitly set to 0 by ftn95 is defined and there would be no need for the /undef option to complain.

And that is why I tried to express my interest in option /ZEROISE even for 64 bit appliactions.

Regards, Dietmar

Dietmar

I have made a note that this needs investigating.

Dietmar

I am currently reviewing the implementation of /ZEROISE within FTN95 and can find no context where it makes a difference to the generated code.

Can you provide sample code that illustrates a case where using /ZEROISE makes a difference to the generated code? In other words, I am looking for 32 bit sample FTN95 code where adding /ZEROISE makes a difference.

Paul,

sorry for the confusion, maybe I did not make it clear enough what I intended to say.

The problem is **my ** understanding of what should be the default when using /undef in case of static variables:

every static variable is (implicitly) set to 0 by the compiler. Now the default if not having set /ZEROISE is that I am told that a static variable is undefined at runtime if having built the executable with option /undef and not with option /ZEROISE. This is simply not true to my opinion. The correct saying would be: there is a static variable which has not been initialised explicitly in the code or something like that. Now I am sort of penalized if I rely on the fact of the compilers functionality of impicitly setting static variables to 0. This has been kind of healed by introducing option /ZEROISE for 32 bit. I think for static variables the default behaviour when using /undef should be to not mark static variables as undefined and maybe to have a separate option for making them marked as undefined. I would not insist on the naming of the option but it is the functionality for static variables which confuses me.

That is why I think the lack of option /ZEROISE for 64 bit is an important limitation of the /undef functionality and that's why my recommendation to support /ZEROISE for 64 bit, too.

For 32 bit there is no problem with respect to the functionality. But for 64 bit in case of static variables it would be nice to support /ZEROISE, as well.

Regards, Dietmar

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.

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.

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]

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.

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

#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