Compiler offset addresses missing(?)

I am doing some debug on the 64-bit code, looking for issues of my own making. I encountered an error that give me an error:

Argument number 2 of WINIO@ (continuation 2) should be a 32 bit integer at address 1c0088e9

Within file C-MASTER.exe in NEWMAIN at address 234 in CMAIN at address d06

My issue: I have the Listing file, and was looking for the offset, but found the following:

0138 subroutine newmain(init_in_sc) AT f66 0139 include 'my_windows.ins' AT f66 0140 C_EXTERNAL CLEARWIN_PARAM@ '__clearwin_param'(INSTRING,INSTRING) AT f66 0141 include 'cmaster_routines.ins' AT f66 . . . To the executable code . . . 0190 screen_title = 'C-Master' AT f66 0191 AT f66 0192 AT f66 0193 call CLEARTYPE_WINDOW_PARAMETERS(local_window_parameters) AT f66 0194 if(run_once) then AT f66 0195 run_once = .false. AT f66 0196 call set_all_max_lines@(6000L) AT f66 0197 call flush_memory_buffers ! send lingering internal data to the appropriate file(s) AT f66 0198 CALL CLEARTYPE_WINDOW_PARAMETERS(local_window_parameters) AT f66 0199 local_window_parameters%sc_function_address = loc(main_window_one_time_init) ! specialized init for the first window in the 'set' AT f66 0200 endif AT f66

The offset for each statement does not change. I looked at a number of other compilations in 64-bit, and the same condition exists, where the offset of the line of executable code is incorrect. I do like the indication of the continuation line being in error, but I cannot tell if it was a lower level routine that is being also counted, or if it is in the code as indicated. If the latter, this makes no sense, so I am confused.

This does suggest that /LIST is not working properly. I will put this down for investigation.

In the meantime try /EXPLIST to see if you can work out the offsets from the assembler listing.

It's a mixed bag.

Yes, /EXPlist does give me a better idea of where it is.

Unfortunately, the assembly code is physically separated from the actual source code. So while I can use this, it is a difficult slog to find the appropriate line in a set of lines all of whom are created similarly and differ in only one or two elements.

Bill

OK. If you use /DEBUG then that may provide a line number for the failure.

Yes, /DEBUG appears to give the line number within the file.

Just an FYI...

It might just be my system, but if I have /EXPLIST turned on as well, compilation is glacially slow.

Going back to /LIST goes faster (most of the time), but still really slow.

I modified the MAKE to allow me to select whether or not a listing file is created. For the production version, I'll have to balance speed with details.

The behaviour of FTN95 /64 /LIST has been greatly improved (maybe even fixed) for the next release. The same fix also provides the correct alignment for /EXPLIST.

In the meantime the offsets are only provided when /DEBUG is also applied.