View previous topic :: View next topic |
Author |
Message |
ahalls_dsc
Joined: 12 Nov 2018 Posts: 16
|
Posted: Wed Jul 31, 2019 6:11 pm Post subject: Errors in x64 Checkmate; none in Win32 compilation |
|
|
Related to Topic 4055 which I started earlier...
I'm attempting to create a reproducable version of the code snippet I posted on Stack Overflow (available here). In doing so, I've encountered an issue.
First of all, my executable as it stands doesn't run (this will need some deeper investigation on my part -- as I've mentioned in my other post, I'm a newbie).
Second, the compilation works fine when the target is Checkmate Win32; when the target is Checkmate x64, the following error information is output:
Code: |
Compiling file: ddmodel14.for
C:\Projects\ML14_ERROR_20190731\ddmodel14.FOR(17) : comment 981 - Specifying the kind of the type LOGICAL with a constant is non-portable - 'SELECTED_INT_KIND(2)' would be better
Access violation:
The instruction at address 00587acc attempted to write to location 5e22f000
00587a8a amd_initialise_data [+0042]
004db82e fill_static_data(<ptr>char,int,<ptr>structᅣconstant_entity,int,int,enumᅣlogical [+0190]
004c73ee allocate_var_space(<ptr>structᅣscope) [+202a]
00417bb9 end_function(int) [+05ce]
00419a64 parse_end_statement(<ptr>char,int,<ref>int) [+0c04]
0041311f handle_token(<ptr>char,int,int,int,int,<ref>int) [+0e82]
004056b3 ProcessEntireLine(void) [+06cf]
004065fa compile(<ptr>char) [+0162]
eax=5e22f000 ebx=05906fb4 ecx=00000004
edx=00000004 esi=04002180 edi=5e22f000
ebp=03d4f030 esp=03d4f004 IOPL=0
ds=002b es=002b fs=0053
gs=002b cs=0023 ss=002b
flgs=00210246 [NC EP ZR SN DN NV]
0360/1120 TSTK=2 [ ]
00587acc rep
00587acd movsb
Compilation completed with no errors.
|
I've saved the code to a public git repo, available on Bitbucket here.
Using FTN95 v8.51.
Any help/advice will be much appreciated! |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Wed Jul 31, 2019 9:23 pm Post subject: |
|
|
I have had a brief look at your source files but I can't get it to build.
Can you provide something simpler? Maybe one file without the data file input. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Thu Aug 01, 2019 12:21 am Post subject: |
|
|
Paul, the source code that was provided via Bitbucket has several problems, but one source file triggers a compiler bug.
When FTN95 is run with /64 on file ddmodel14.for, the compiler aborts with an access violation. If the SAVE attribute is removed from Line-18 of that file, the access violation does not occur.
ahalls_dsc: The source code contains numerous errors of the type that beginners to Fortran tend to make. Here are a few:
1. The file unit number is used without specifying a value for it.
2. The format used for reading the data file is wrong. The nX format specifier is for skipping characters, not for reading into a character variable. The An format specifier is not suitable for reading integer data.
3. Some of the arrays are dimensioned improperly, as a result of which array bounds are exceeded.
I get the impression that the extent of understanding of Fortran that is displayed in the code is inadequate for the task being undertaken. Perhaps you can break down the task into smaller pieces and, with the help of a good Fortran text/manual, get the pieces to work before putting them back together. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Thu Aug 01, 2019 11:51 am Post subject: |
|
|
mecej4
I have added code in order to avoid the crash but there is currently a limit of 1GB for the static store. We will need to review this but the current fix still does not allow the SAVE attribute in this context. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Thu Aug 01, 2019 1:05 pm Post subject: |
|
|
Paul, a message followed by aborting the compilation is fine. Even the current response would be acceptable provided it was preceded by a printout of the current file, routine name and line number -- that information would have obviated my blind trials to see how to overcome the crash.
I am left wondering how the same program does not run into the 1GB limit when compiling without /64. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Thu Aug 01, 2019 2:52 pm Post subject: |
|
|
mecej4
I fully agree on both counts.
At the moment the line numbers are not fed into the backend where the error occurs so this will require a lot of work. But I agree it ought to be done. |
|
Back to top |
|
|
ahalls_dsc
Joined: 12 Nov 2018 Posts: 16
|
Posted: Thu Aug 01, 2019 3:13 pm Post subject: |
|
|
@mecej4 and Paul: thanks both for looking into this for me.
@mecej4 I have edited the code slightly in light of your comments; it now compiles fine without the SAVE attribute on array ddfuncval.
What confuses me (and may not you, if you could see the code) is that the x64 compilation works fine in the main program this has been taken from, with the original SAVE attribute intact.
Anyhow, thanks for the suggestion: I've been able to reproduce the exact error I'm getting in the main program. Back to the other thread. |
|
Back to top |
|
|
|