Adding UNION/MAP -- Feedback and tips pls!

[Tobias Burnus]

Thomas Koenig wrote:
> Am 04.03.2013 21:34, schrieb N.M. Maclaren:
>
> (quoting documentation about DEC UNIONs for Fortran)
>
>> "However, if you overlay one variable with another smaller variable,
>> that portion of the initial variable is retained that is not overlaid.
>> Depending on the application, the retained portion of an overlaid 
>> variable
>> may or may not contain meaningful data and can be utilized at a later
>> point in the program."
>
> Ouch. This seems to be at odds with C's unions, where it is not 
> allowed to do
> type punning.

My impression is that it is the same, but badly written. Namely, the 
other bits are (usually) not touched if one modifies a smaller variable, 
but the content of the remaining bits may contain arbitrary data. I 
think that what happens in practice.

In any case, a reasonable specification should demand that changing one 
union member makes the other undefined. I think that avoids some 
pitfalls. It should also be roughly in line with Fortran's equivalence, 
C's union, GCC's -fstrict-aliasing, and Intel's UNION extension.

Intel's documentation states the following:

"With union declarations, only one map declaration within a union 
declaration can be associated at any point in time with the storage 
location that they share. Whenever a field within another map 
declaration in the same union declaration is referenced in your program, 
the fields in the prior map declaration become undefined and are 
succeeded by the fields in the map declaration containing the newly 
referenced field."

http://software.intel.com/sites/products/documentation/doclib/stdxe/2013/composerxe/compiler/fortran-mac/GUID-1CC04793-AF79-4E0F-AC78-DD4CF985C23F.htm

* * *

Otherwise, I concur that the proposed extension should be handled as 
Cray pointers: When "UNION" is encountered, a compile-time error is 
printed, which mentions that some flag like "-funion" (or some similar 
name) is required.

* * *

Regarding the syntax, I think it would help to create a specification 
which syntax is supported. That specification should end up in the 
gfortran documentation, but it also helps with the implementation.

Namely the syntax of UNION and MAP in BNF notation, including the 
constraints and a description of the restrictions.

I assume that for the fields, one uses "data-component-def-stmt" (as 
defined in the Fortran standard). However, one has to think about the 
following:
* ALLOCATABLE (ifort and PGI reject them; we better do as well!)
* TYPE (ifort requires a sequence type, PGI gives an internal error)
* CLASS
* POINTER (ifort accepts pointer, PGI has an internal error)
* Default initialization (ifort accepts it)
* Other attributes which valid for data-component-def-stmt like PRIVATE, 
PUBLIC, CONTIGUOUS, CODIMENSION/coarray-spec, DIMENSION
(* Procedure pointers? Does not apply if one only allows 
data-component-def-stmts)

Component access:
* Component reference shall use "%", as we agreed upon (a note should 
state that the pre-Fortran-90 vendor extension uses ".", which is not 
supported). [Side remark: ifort also supports "%", PGI only "."]

Issues related to initialization: What happens when both maps have a 
default initialization or both are initialized via DATA; how are 
structure constructors handled of derived types with UNION components? 
In which TYPEs are UNIONs allowed: sequence types, types with C binding, 
or extensible types? I think one should rule out the latter; 
alternatively, one has to deal with KIND and LEN components in MAPs, 
which becomes ugly. Assignment: It probably requires blind memory 
copying of the right-hand side (which is the reason that allocatables 
cannot be supported).

Some words on storage association are also needed, similar to my quote 
above from Intel's documentation.

Is there something else?

Tobias