Initializing a Structure containing a Union corrupts nearby memory - Suspected Compiler Bug

[James_Hale]

This code gives the following run-time error (ifort version (IFORT) 19.1.3.304 20200925) on RH Linux 8.3 and MacOS Big Sur 

forrtl: severe (62): syntax error in format, unit -5, file Internal Formatted Write

As far as I can tell, initializing the structure of type dbtimeseries that contains the 'timestruct' union union corrupts the memory that contains the internal representation of the (I3.3) in the statement

WRITE (templatenum_ch,'(I3.3)')loop_templates_i2

I've debugged, setting a breakpoint at MAIN__ then examined the memory of the structures. Debugging is made easier if the values are not zero, but recognisable hex values, although that changes the error message to an internal consistency check failure.

If the code seems strange, in the sense that you wouldn't write it this way if you were starting over, bear in mind that this is taken from a much larger program, and so rewriting wouldn't be as simple as just making edits to this short program.

Please forgive any etiquette fails on my part, I'm not a regular here.

CODE:

      PROGRAM wpgr_main_ex
      IMPLICIT NONE
      SAVE
C
      INTEGER*4		undef_r4ko
      PARAMETER 	(undef_r4ko	= INT('1f2f3f4f'X))
      INTEGER*4		undef_i4ko
      PARAMETER 	(undef_i4ko	= 0)
C
C|%DATATYPE TIMESTRUCT
C
      STRUCTURE 			/timestruct/
         UNION
            MAP
               INTEGER*4 time_i4f(2)
            END MAP
            MAP
               BYTE	time_byf(8)
            END MAP
            MAP
               INTEGER*8 time_i8
            END MAP
         END UNION
      END STRUCTURE

c     --------------------------------------------------
c     Database time series
c     --------------------------------------------------
      STRUCTURE /dbtimeseries/
         INTEGER*4 value_i4
         INTEGER*4 status_i4
         RECORD /timestruct/runtime_vb
      END STRUCTURE
c
c     "nulltime", to initialize structure / time /
c
      INTEGER*4 null_i4ko
      PARAMETER (null_i4ko = 0)

      BYTE null_byko
      PARAMETER (null_byko = 0)

      INTEGER*8 null_i8ko
      PARAMETER (null_i8ko = 0)

      RECORD /timestruct/nulltime_vbko
      PARAMETER (nulltime_vbko = timestruct((/null_i4ko,null_i4ko/),
     f (/null_byko,null_byko,null_byko,null_byko,
     f null_byko,null_byko,null_byko,null_byko/),
     f null_i8ko))
c
      RECORD /dbtimeseries/empty_timeseries_vbko
C
C It seems to be this line that makes or breaks the program
C I think that the intialization is done incorrectly and corrupts the format string
      PARAMETER (empty_timeseries_vbko = dbtimeseries(undef_r4ko,undef_i4ko,nulltime_vbko))
C
      CHARACTER*3 templatenum_ch
      INTEGER*2 loop_templates_i2
C
      loop_templates_i2 = 42
C     Crash here because the format has become corrupted
      WRITE (templatenum_ch,'(I3.3)')loop_templates_i2
      WRITE (*,*)'The answer is '//templatenum_ch
c
      END

EDIT, ifort config is,

-ccdefault fortran
-zero
-fpp
-m64
-align none
-extend-source
-warn noalign
-DIA64
-debug full
-mcmodel=medium
-threads
-align norecords
-warn usage
-warn truncated_source
-init=zero
-noauto

Build executable with,

ifort -g3 wpgr2.f -debug full -o wpgr2.exe

[mecej4]

Compiling and running with 19.1.3.311 on Windows with /debug gives abort with:

forrtl: severe (8): internal consistency check failure, file for_intrp_fmt.c, line 2745

and a traceback to the first source line containing WRITE.

[andrew_4619]

It didn't even know that old "record" stuff had a default constructor. I quick hunt around and the help didn't help. Given it is a non-standard feature the Intel help is the only place that can define expected functionality/behaviour, anyone got a link that works? This is more out of my own general interest than any specific need!

[Steve_Lionel]

Intel Fortran generally treats STRUCTURE/RECORD and standard derived types as interchangeable. So, yes, you can have a type constructor for a RECORD. However, I suspect that nobody thought about what it meant to have a constructor for a type containing unions. This is probably what is messing it up.

I recommend NOT using a constructor with a type containing a union.

[andrew_4619]

Yes Steve that was exactly the point I was thinking, in the example the same memory is being initialised three times in potentially different ways by the constructor. 

[mecej4]

Andrew, CVF 6.6C did not support all the options used by OP with this test code, but compiling with df /debug:full /opt:0 /noauto wpgr.f and running gave "The answer is 042", so that ancient compiler did understand and implement the embedding of UNIONs inside user defined Fortran types.

You could look at the CVF documentation for details, since you appear to be interested in this feature. There were some restrictions on using EQUIVALENCE with these nonstandard declarations.

[andrew_4619]

Thanks my interest is purely academic as if it does not work with /standard-semantic and /stand I won't touch it even with the proverbial "dirty" stick. The CVF docs do say:  STRUCTURE...END STRUCTURE
Statement: Defines the field names, types of data within fields, and order and
alignment of fields within a record structure. Fields and structures can be
initialized, but records cannot be initialized.     I am not sure what that means in practice but you can see with Union/Map the code is totally ambiguous  without some explicit rules being laid out. 

[Ron_Green · Accepted solution]

Bug ID CMPLRIL0-33656

[Ron_Green]

A few of the developers were surprised to see customers still using this. but they are looking at the issue. I posted the bug ID above for reference.

[James_Hale]

Thank you everyone for your help, it's really appreciated.

[Ron_Green]

James,

Your example does compile and run with our IFX compiler.  Since it is working with our "new" Fortran compiler, and this is not a frequently used extension we decided to close this issue against ifort.  Our recommendation is to use IFX for source files you have with this extension.  IFX object files are binary compatible with IFORT so you can also compile this 1 source with IFX and the rest with IFORT.

[James_Hale]

We have not tried ifx yet.

Was one piece of many millions of line in thousands of executables, we worked around it long ago though. Thanks.