forums.silverfrost.com

[DanRRight]

After installing latest 8.80 i get strange thing: simple programs work with the debugger but all my major very different codes work OK without debugger but get this immediately when i invoke them via debugger:



Added to FTN95 folder new SDBG64 with the latest beta Trace option (size 2,135,040) which worked OK with older pre-880 compiler and it also works with the simple demos but it does not work with my major larger codes

Returned temporally back to older compiler pre-8.80 version (by just renaming FTN95 folders. This suggests that something is wrong with the new installation specifically related to the debugger )

/* Worst day today, third such devilry for a day. Two other related to still not resolved abrupt crashes of my PC (always when a lot of programs are loaded)

[JohnCampbell]

Dan,

Perhaps you need to rebuild your .exe and .dll's with the new Ver 8.80 compiler (while retaining your old versions in an alternative path for recovery)

[Robert]

Is your code compiled with a debug option (like /debug or /check)?

[DanRRight]

Robert, Here is my BAT file. I used no second arguments added to the BAT when executed it so that compilation goes automatically to the first (called DEBUG ) compilation option

[Robert]

Version 8.80 dynamically allocates common blocks as they are used in 64-bits. sdbg64 needs to know where they are so that it can let this dynamic allocation complete. This looks like that is not happening correctly. Presumably an older sdbg64 (8.70 for example) produces the same effect.

[DanRRight]

John,
The BAT file rebuilds everything. If not use SDBG64 all works OK. Based on Robert's comment, either you do not use SDBG or do not use COMMON blocks . I still use them but less and less. And use them even inside modules just automatically often without any reason (taking them without modification from older codes which do approximately the same functions as new codes ) since compiler allows that and does not complain

[mecej4]

Dan,

Your batch file shows compilation commands for some files such as Iam64bit.for without /undef, whereas you do use /undef for others.

This, by itself, need not be of concern, but if an EXE is built out of OBJ files built with a mix of /undef and no /undef, problems could occur. This may be one cause of odd behaviour of the program when run from SDBG.

[DanRRight]

You are generally right but in my case here is the whole text of this subroutine

[mecej4]

That subroutine has, by itself, no need for /undef because it has only one variable and one executable statement that sets a value into that variable.

However, most Fortran compilers that support checking for undefined variables have a requirement that all the sources be compiled with /undef, if a single portion is compiled with /undef.

The consequences of our ignoring this requirement are not stated, so anything can happen. You have nothing to lose by adding /undef to all the compile commands in your batch file.

[JohnCampbell]

I got a similar "Access Violation" error with FTN95 /64 /check Ver 8.80.0.
Below is a simpler example that compiles, and reports the error,
but basically I incorrectly used an integer variable argument as an array name, which I think was interpreted as an external function.
/CHECK or /DEBUG did not report a problem with the usage.

[mecej4]

The compiler should be able to catch this error (scalar variable of known type followed by subscript expression within parentheses) at compile time.

Here is a fleshed out version:

[PaulLaidler]

Thanks. I have made a note of this.

[silverfrost]

The original issue is now fixed and a new sdbg64 can be downloaded from the usual place

[DanRRight]

Thanks, all works OK now

[PaulLaidler]

In future the program posted by mecej4 will produce a compile time warning when compiled with FTN95.