View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Mon Oct 22, 2018 7:09 am Post subject: AMD backend failure |
|
|
The test code at https://www.dropbox.com/s/gqk5nsm9cu9756h/buga.7z?dl=0 , when I attempt to compile it with FTN95 8.30 using /64 and one of the checking options /check, /undef or /checkmate, causes the compiler to say:
Code: | S:\MATH\Luksan\SEC\TBED\F90\f9sp>ftn95 /64 /checkmate buga.f90
[FTN95/x64 Ver. 8.30.0 Copyright (c) Silverfrost Ltd 1993-2018]
0001) Subroutine tffu14 (n, x, f, next)
*** AMD backend failure:Failed to do register-memory emit for MULSD at 697
*** AMD backend failure:Failed to do register-memory emit for MULSD at 699
*** AMD backend failure:Failed to do register-memory emit for MULSD at 702
*** AMD backend failure:Failed to do register-memory emit for MULSD at 703
*** AMD backend failure:Failed to do memory-register emit for MOVSD at 783
5 ERRORS [<TFFU14> FTN95 v8.30.0]
*** Compilation failed |
The numbers may be code offsets; the source code has only 300 lines. I tried to remove small blocks of code so as to reduce the size of the source file, but those changes made the compiler behave normally. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Mon Oct 22, 2018 10:38 am Post subject: |
|
|
Thank you for the bug report. I have logged this for investigation.
If you need a temporary work-around then the fault occurs in Case(3) at about line 34. The 64 bit backend is not coping with the expression 5.0D0*(x(3:n-1:2)-x(4:n:2))**2.
For this kind of fault you can use the /explist and search for "failed". Then backtrack to find the source line within the listing. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Mon Oct 22, 2018 3:51 pm Post subject: |
|
|
Thanks, Paul, for the tip on using /exp to pinpoint the code causing the problem.
In this instance, using that tip turns out to be troublesome, since a single Fortran statement (involving array expressions) generates over 250 machine instructions, so finding the trouble-making sub-expression is not so easy.
The exp listing has this format:
00000dac(#13230,682,37): MULSD RAX,1 ***FAILED***
The first number is the code offset from the base address of the procedure, as I can see. The second number within parentheses is the number that appears in the compiler's error message, but I don't know how to interpret the value. Likewise, what are the other two numbers (#13230 and 37)? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Mon Oct 22, 2018 7:04 pm Post subject: |
|
|
I was thinking that it might be possible to get a work-around by rephrasing the statement but it may be more complex than that. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Fri May 01, 2020 4:34 pm Post subject: |
|
|
This issue was still on my list but on review the failure no longer occurs.
It might be down to a failure in my logging. Otherwise I assume that it has been fixed in some other context. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Sun May 03, 2020 11:32 am Post subject: |
|
|
Yes, Paul, recent versions of the compiler no longer exhibit the error that I reported for version 8.30.
Thanks. |
|
Back to top |
|
|
|