%F90-F-FATAL, **Internal compiler error: specification exception signal raised**

[pweaver]

Code: Select all

$ tcpip show ver

  VSI TCP/IP Services for OpenVMS x86_64 Version X6.0
  on a QEMU Standard PC (Q35 + ICH9, 2009) running OpenVMS E9.2-1

$ fortran/version
VSI Fortran X8.5-0002 (GEM 50X2N) for X86 systems

I have a program with 13 subroutines in one .FOR that has been compiled on VAX and AXP with no issues. On X86 I throws an error pointing to the last END in the whole file. After a lot of experimenting I got it down to

The program

Code: Select all

        real*16 bytes
        bytes = 1
        type *, bytes
        end

Fails to compile with

Code: Select all

$ for/f77 test8

        end
........^
%F90-F-FATAL, **Internal compiler error: specification exception signal raised** Please report this error along with the circumstances in which it occurred in a Software Prob
lem Report.  Note: File and line given may not be explicit cause of this error.
at line number 4 in file DKB0:[PWEAVER]test8.for;37

If I change the REAL*16 to REAL*8 then it compiles. I extracted all the subroutines into individual .FOR files and compiled each one. A subroutine that has "real*16 last_record,next_record" compiles fine.

[arne_v]

Long term solution is obviously that all of VMS get build with the native compilers.

Minimum should be a warning like "FORT-W-RANRES 128 bit numeric types produce random results".

I don't like the convert 128 bit to 64 bit solution. The developer chose 128 bit for some reason.

But if I have understood the problem correct, then building just the relevant RTL natively would solve the problem. And it would also act as a start on the overall VMS. Obviously there is the risk of problems if some RTL are build with native compilers while most of VMS Is build with cross compilers. I don't know. VSI will know.

[joukj]

With my background in scientific programming : Long term seems long.

The problem is that 64-bit complex variables count for VSI as 128-bit and not as a 2-member array of 64-bit. So they are affected. Most software I saw in the university uses "double precision" and complex numbers.
So this is a show stopper for them.

[jreagan]

Thanks for all the feedback. I'll have something done that helps in the short-term.

As for mixing-and-matching cross-built pieces with native-built pieces, the long term maintenance issues for that could horrible. We have hand-built some RTLs natively in house. For example, we hand-built a Math RTL using the native optimizing C compiler and have done some early performance testing. Same with pieces of the CRTL. Mostly as tests for the compilers

And I'll point out that Windows doesn't have any sort of 128b floating. "long double" in C just gets turned into "double". [Not to say that Windows is an example we should follow]

[arne_v]

I would not worry so much about C. I think this is mostly a Fortran problem.

There must be many more Fortran programs using REAL*16 than C programs assuming that long double is 128 bits.

And Fortran got complex - C does not.

Added in 6 minutes 27 seconds:
And sure compiling various pieces different would be a long term maintenance nightmare.

But it would not be a long term solution. It would just be a stop gap solution until the rest of VMS get native build.

I have no idea how your release plan looks like, but allow my to pick some random versions and dates out of thin air:

V9.2-4 (January 2025) with some native build RTL rest cross build
V9.3 (November 2025) with everything native build

That would give a maintenance problem for only 10 months.

And it would solve a problem.

There may be people relying on 128 bit real and 64+64 bit complex.

And there is the perception issue. This type of bug does not support the overall message to VMS customers "copy your stuff to VMS x86-64, build and you are up and running".

Added in 1 minute 2 seconds:
Not particular relevant, but GFortran on Windows does support REAL*16.

[jreagan]

Uh, our C has complex but yes, few use it. clang has it also.

[arne_v]

You are correct.

C has had complex.h since C99.