Adding UNION/MAP -- Feedback and tips pls!

[N.M. Maclaren]

On Mar 6 2013, Tobias Burnus wrote:
>>
>> (quoting documentation about DEC UNIONs for Fortran)
>
>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.

Sort-of.  It is at least usually true for unoptimised code, but whether
it is generally true for optimised is much less clear.  In particular,
it is likely to become untrue in any compiler that uses type-dependent
optimisation.  I haven't a clue about gcc/gfortran's internals in that
area, let alone what might happen in the future.

>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.

I agree, but that is NOT what the DEC UNION specification says.  And
that's the problem :-(

>Intel's documentation states the following:

Quite.

>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.

Personally, I prefer Thomas Koenig's flag name :-)

>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.
>
>  [ comments on details and the semantics omitted ]

Absolutely.  Language features with no proper specification are an
abomination.

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

The problem here is that that might not well help with porting programs,
if a significant number that use this facility rely on data preservation.
Do they?  I haven't a clue.

This was (and is!) the problem with Cray pointers.  The ones that use
them in a very simple fashion will usually work with most variants;
the ones that rely on the more extreme facilities won't, and usually
can't be ported without rewriting, either.


Aside:  There IS actually a very simple way to port DEC UNION code;
simply change them to structures (i.e. derived types).  That wastes
memory but, compared to the machines on which they were used, modern
ones have near-infinite memory.  I can't think of a circumstance under
which working DEC UNION code would fail with that trick.


Regards,
Nick Maclaren.