If you look at the encoding for the file. Usually it is in File|Save or similar. I was wondering if it was saved in Unicode and had characters above 255 (that is what the assert suggests). Some Latin characters can do this.

in this context I have had a problem, as well, with sdbg64 which crashes when trying to step into a subroutine. I created a sample consisting of two files, sdbg64_test.for

Code:

CALL SETTRV(32_2)
END

and sdbg64_test1.for

Code:

SUBROUTINE SETTRV (IDUM)
INTEGER*2 IDUM
IDUM=167 !+ õ
RETURN
END

. The second,sdbg64_test1.for, contains the German umlaut ä which is E4 (228) in ASCII.
Now compiling, linking and debugging for 64 bit, results in an error when trying to step into SETTRV (via sdbg64). A window with titlebar "Microsoft Visual C++ Runtime Library" pops up displaying "Debug Assertion failed!" and further on "Expression: c>= -1 && c <= 255". Doing the same with respect to the 32 versions for compiling, linking and debugging, I can step into subroutine SETTRV from sdbg and everything works fine. The same is true for the 64 bit scenario if I remove character ä from the code.

We are trying to port a bigger application and I am afraid we have lots of German umlaute in the coding ...

The version of ftn95 is
Version: 8.10.0
Built: Sat Feb 11 12:23:39 2017

Apart from the debugger issues, there is another issue with your test code that I hope you are aware of: you are passing a constant expression as the argument to the subroutine, which is attempting to change the value. If you fix this bug, do you still see the debugger problem?

I'm still interested to get a solution for my problem with SDBG64. All my files seem to be ANSI code. I get this message for some of my projects, not for all. Sometimes the message appears during the debug session also.

as far as I remember, we have introduced the notation 32_2 and 32_4 to distinguish between 2 byte and 4 byte integer constants when using INTEL compilers (for Windows and Linux operating systems). We then used this notation, as well, for the SALFORD version of the code to be compiled and were happy to have a common notation for 2 byte and 4 byte constants in both the INTEL and the SALFORD compile environment.

I would like to emphasize the previous entry: I am interested in a solution of my problem with sdbg64.

as far as I remember, we have introduced the notation 32_2 and 32_4 to distinguish between 2 byte and 4 byte integer constants when using INTEL compilers (for Windows and Linux operating systems). We then used this notation, as well, for the SALFORD version of the code to be compiled and were happy to have a common notation for 2 byte and 4 byte constants in both the INTEL and the SALFORD compile environment.

The point that John Campbell made is worth noting. The kind number suffixes _2 and _4 are not portable, and unless you use the /ALTkinds option, the meaning given by FTN95 is at variance with that given by Intel Fortran. In particular, the kind number 4 corresponds to 64-bit integers rather than 32-bit integers, as you intended, if you forget to use /ALT.

Try the following test program with the two compilers. Make runs using FTN95 with and without the /ALT option and compare the outputs.