forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

BUG in SDBG64
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Fri Feb 07, 2020 1:38 pm    Post subject: BUG in SDBG64 Reply with quote

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:

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
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sat Feb 08, 2020 12:06 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 444
Location: Manchester

PostPosted: Sat Feb 08, 2020 7:32 pm    Post subject: Reply with quote

It would appear not...
Back to top
View user's profile Send private message Visit poster's website
JohnCampbell



Joined: 16 Feb 2006
Posts: 2551
Location: Sydney

PostPosted: Sun Feb 09, 2020 6:26 am    Post subject: Reply with quote

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 ?
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Sun Feb 09, 2020 8:32 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 444
Location: Manchester

PostPosted: Sun Feb 09, 2020 6:03 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Tue Feb 11, 2020 8:54 am    Post subject: Reply with quote

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


Last edited by DanRRight on Tue Feb 11, 2020 1:14 pm; edited 2 times in total
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Tue Feb 11, 2020 11:39 am    Post subject: Reply with quote

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

http://forums.silverfrost.com/viewtopic.php?t=3641&highlight=zeroise

Paul says
Quote:
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
Code:
/undef /64

set. And what is even worse the application is stopped.
This is simply false. You might look at the code
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
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Tue Feb 11, 2020 2:09 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Tue Feb 11, 2020 2:49 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Wed Feb 12, 2020 8:36 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Wed Feb 12, 2020 10:31 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Wed Feb 12, 2020 11:02 am    Post subject: Reply with quote

Dietmar

I have made a note that this needs investigating.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Mon Feb 17, 2020 12:42 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Tue Feb 18, 2020 1:09 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group