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:

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.

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.

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)?

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.

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.

Yes, Paul, recent versions of the compiler no longer exhibit the error that I reported for version 8.30.

Thanks.