Re: C aliasing rules question.

[Falk Hueffner <falk dot hueffner at student dot uni-tuebingen dot de>]

Dale Johannesen <dalej@apple.com> writes:

> On Sunday, May 18, 2003, at 02:46  PM, Falk Hueffner wrote:
> >> static inline int f_trunc(float f)
> >> {
> >>         f -= 0.5f;
> >>         f += (3<<22);
> >>         return *((int*)(char*)&f) - 0x4b400000;
> >
> > I don't think so. Even if it happens to work right now, I don't think
> > it should be supported in the long run. What's so bad about using a
> > union?
> 
> Every so often I just have to try again.
> 
> a) There's much existing code that looks like the above;

That's right. We provide -fno-strict-aliasing for it.

> b) A union is no more standard than the above;

Using a union is implementation defined, which is a lot better than
undefined.

> c) Most people think the above is legal, so we'll keep getting
> bug reports until it works in the obvious fashion;

Well, that also holds for 1 << 33 and a lot of other things.

> e) The examples in the C89 Rationale defending the type-based aliasing
> rules all involve multiple functions, situations where the compiler
> cannot tell whether things alias or not (lacking IPA, which is obviously
> not something you want to require).  That's not the case here.  It is
> just not that hard to tell that two references to the same, known
> address interfere, without losing optimization opportunities.

While it certainly is possible here, I am not convinced it can always
be reliably detected. IMHO, having this fail only in very obscure
cases is no better and maybe even worse than having it fail most of
the time.

-- 
	Falk