|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Fri Feb 07, 2020 1:38 pm Post subject: 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:
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Sat Feb 08, 2020 12:06 am Post subject: |
|
|
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 |
|
|
Robert
Joined: 29 Nov 2006 Posts: 446 Location: Manchester
|
Posted: Sat Feb 08, 2020 7:32 pm Post subject: |
|
|
It would appear not... |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2556 Location: Sydney
|
Posted: Sun Feb 09, 2020 6:26 am Post subject: |
|
|
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 |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Sun Feb 09, 2020 8:32 am Post subject: |
|
|
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 |
|
|
Robert
Joined: 29 Nov 2006 Posts: 446 Location: Manchester
|
Posted: Sun Feb 09, 2020 6:03 pm Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Tue Feb 11, 2020 8:54 am Post subject: |
|
|
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 |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Tue Feb 11, 2020 11:39 am Post subject: |
|
|
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
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 |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Tue Feb 11, 2020 2:09 pm Post subject: |
|
|
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 |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Tue Feb 11, 2020 2:49 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Wed Feb 12, 2020 8:36 am Post subject: |
|
|
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 |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Wed Feb 12, 2020 10:31 am Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Wed Feb 12, 2020 11:02 am Post subject: |
|
|
Dietmar
I have made a note that this needs investigating. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Mon Feb 17, 2020 12:42 pm Post subject: |
|
|
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 |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Tue Feb 18, 2020 1:09 pm Post subject: |
|
|
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 |
|
|
|
|
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
|