- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Bug ID CMPLRIL0-33656
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you everyone for your help, it's really appreciated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Was one piece of many millions of line in thousands of executables, we worked around it long ago though. Thanks.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page