[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::fortran

Title:Digital Fortran
Notice:Read notes 1.* for important information
Moderator:QUARK::LIONEL
Created:Thu Jun 01 1995
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1333
Total number of notes:6734

1179.0. "Accvio when compiled /OPTIMIZE" by SWETSC::EKLUND (On a clear day you can see forever) Tue Feb 18 1997 08:36

    Hi,
    
    I have a program which when compiled /NOOPT runs ok but when compiled
    /OPTIMIZE crashes with an accvio. This is on VAX V6.1 using the newly
    announced V6.5 compiler. (The same problem occurrs on earlier compiler 
    versions back to V6.2 at least) 
    
    There is a save-set at SWETSC::F65.BCK if you could please take a look
    at it. You need to compile and link the DRR2 file and the @RUN. There
    are a lot of FORT-I messages but this is the smallest amount code we
    have for the time beeing which shows this problem.
    
    Please comment.
    
    -Johan
T.RTitleUserPersonal
Name		DateLines
1179.1QUARK::LIONELFree advice is worth every centTue Feb 18 1997 21:326
    This is a user programming error.  MODE calls ITOSTR passing IARR, an
    undeclared variable which is implicitly an integer scalar, but ITOSTR
    treats the argument as a 10-element array.  It overwrites storage which
    happens to be the argument list for a later call, causing the ACCVIO.
    
    				Steve
1179.2Many thanx for the fast help. /JohanSWETSC::EKLUNDOn a clear day you can see foreverWed Feb 19 1997 03:091
1179.3QUARK::LIONELFree advice is worth every centWed Feb 19 1997 08:1732
    Since I'm feeling generous today, I'll add a bit of instructional
    material. 
    
    First, how I found the problem..  The OpenVMS debugger made this really
    easy.  I compiled, linked and ran /DEBUG, and when the ACCVIO occurred,
    I looked at what the program was doing.  It was at the first
    instruction of a routine, fetching its single argument - which had an
    address of -1.  Looking at the memory pointed to by AP, I saw that the
    argument list had been overwritten with -1s.  Not good.  I did a
    SET SCOPE 1, E/I @PC to see the CALLG instruction in the caller to see
    who had called the routine.  That gave me the address in static
    storage where the compiler built its argument list.  I reran the
    program, set a breakpoint in the calling routine, and when it got
    there, set a watchpoint on the argument list, then typed GO.  Soon
    enough, I found the data being overwritten.  It was then a case of
    following the argument chain, checking declarations (or lack thereof)
    until I found the culprit.  SHOW SYMBOL/TYPE was useful here too.
    
    Second...  when a program changes behavior between /OPTIMIZE and
    /NOOPTIMIZE, it is more likely than not (indeed, a 90% or better
    chance) that it's due to a user programming error and not a compiler
    bug.  The most common causes are array bounds being exceeded or
    argument mismatches.  In this particular case, /CHECK=BOUNDS would not
    have helped, as the array was an argument and not adjustable (indeed,
    it was assumed-size).  But IMPLICIT NONE would have caught the problem.
    
    I'd like to suggest that, at a minimum, customers be asked to compile
    their programs with /CHECK=BOUNDS/WARN=DECLARATIONS and be able to
    compile with no errors before being submitted to us for possible
    compiler bugs.
    
    					Steve