This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Adding UNION/MAP -- Feedback and tips pls!
Doing a bit more light reading on type-punning wrt unions I came upon
the following (from
http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Structures-unions-enumerations-and-bit_002dfields-implementation.html#Structures-unions-enumerations-and-bit_002dfields-implementation):
"""
- A member of a union object is accessed using a member of a different
type (C90 6.3.2.3).
The relevant bytes of the representation of the object are treated as
an object of the type used for the access. See Type-punning. This may
be a trap representation.
"""
Further digging leads to the -fstrict-aliasing flag (from
http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Optimize-Options.html#Type%2dpunning)
which notes:
"""
Pay special attention to code like this:
union a_union {
int i;
double d;
};
int f() {
union a_union t;
t.d = 3.0;
return t.i;
}
The practice of reading from a different union member than the one
most recently written to (called “type-punning”) is common. Even with
-fstrict-aliasing, type-punning is allowed, provided the memory is
accessed through the union type. So, the code above will work as
expected.
"""
I'll leave interpretation about the implications of this to the experts.
v/r,
Russell
On Wed, Mar 6, 2013 at 2:21 PM, Russell Brennan
<RussellJBrennan@gmail.com> wrote:
> Perhaps I misunderstand how you are defining failure here... what
> would be the failure mode? Perhaps if you could provide an example of
> the ill-effects that could be seen as a result of this behavior it
> would clarify the issue?
>
> v/r,
>
> Russell
>
> On Wed, Mar 6, 2013 at 2:15 PM, N.M. Maclaren <nmm1@cam.ac.uk> wrote:
>> On Mar 6 2013, Russell Brennan wrote:
>>>>
>>>>
>>>> Ouch.
>>>>
>>>> This seems to be at odds with C's unions, where it is not allowed to do
>>>> type punning.
>>>
>>>
>>> As of gcc 4.4.6, the description above seems to match the C behavior:
>>
>>
>> Er, no. One simple test does not prove that it will always work; this
>> sort of thing is most likely to fail because it interacts in very nasty
>> ways with optimisation. C99 introduced a horribly ill-defined concept
>> called "effective types", which specifically allows type-dependent
>> optimisations. I have no idea whether gcc uses it at present, but it
>> might well do so in the future.
>>
>> Regards,
>> Nick Maclaren.
>>
>>