This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Adding UNION/MAP -- Feedback and tips pls!
- From: Russell Brennan <RussellJBrennan at gmail dot com>
- To: "N.M. Maclaren" <nmm1 at cam dot ac dot uk>
- Cc: gcc at gcc dot gnu dot org, "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>
- Date: Wed, 6 Mar 2013 14:21:08 -0500
- Subject: Re: Adding UNION/MAP -- Feedback and tips pls!
- References: <51314549.6080902@earthlink.net> <Prayer.1.3.5.1303020815470.18790@hermes-1.csi.cam.ac.uk> <CAGkQGiL7Qg0RAqJrT5i4LDzjnsr3jQ42Ws2BQFDpPUHyQe3+WQ@mail.gmail.com> <CAKwh3qgyS0nRcGSE5UT+DN+11kjYRE9Vu7SsQ_AGPtuD7VV4dA@mail.gmail.com> <Prayer.1.3.5.1303021519480.2329@hermes-1.csi.cam.ac.uk> <CAAKgPaHZwaoSBVg-hNZxan-uAtnmEBjPxyv9iuh=xdOshFp1uQ@mail.gmail.com> <Prayer.1.3.5.1303041813340.19357@hermes-1.csi.cam.ac.uk> <CAAKgPaGtNQoA=2h+5Z8DmvgsEBKUKX78Ojwi_SY2RG8hUcksOg@mail.gmail.com> <Prayer.1.3.5.1303042034040.18634@hermes-1.csi.cam.ac.uk> <51378C6D.5060609@netcologne.de> <CAAKgPaEVESzYUh3FAuYx76=jtjBkaY5OwdztcNU=k4X+x5a8Ww@mail.gmail.com> <Prayer.1.3.5.1303061915001.1260@hermes-1.csi.cam.ac.uk>
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.
>
>