C aliasing rules question.

C aliasing rules question.

[Richard Guenther]

Hi!

gcc 3.3 now warns about

static inline int f_trunc(float f)
{
	f -= 0.5f;
	f += (3<<22);
	return *((int*)&f) - 0x4b400000;
}

to violate C aliasing rules (I see the code is broken as is), is
the following "fix" to the code ok (gcc doesnt warn anymore), as
char* is special wrt aliasing?

static inline int f_trunc(float f)
{
        f -= 0.5f;
        f += (3<<22);
        return *((int*)(char*)&f) - 0x4b400000;
}

Or is this still invalid? Is it at least ok to tell _gcc_ about the
aliasing?

Thanks,

Richard.

Re: C aliasing rules question.

[Falk Hueffner]

Richard Guenther <rguenth@tat.physik.uni-tuebingen.de> writes:

> static inline int f_trunc(float f)
> {
>         f -= 0.5f;
>         f += (3<<22);
>         return *((int*)(char*)&f) - 0x4b400000;
> }
> 
> Or is this still invalid?

Yes, you're still accessing an object of type "float" with an lvalue
of type "int".

> Is it at least ok to tell _gcc_ about the aliasing?

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?

-- 
	Falk

Re: C aliasing rules question.

[Dale Johannesen]

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;

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

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

d) This sequence occurs in SPEC (in code from gcc itself!).  Inability
to compile SPEC has immediately removed gcc from consideration as
the house compiler in two situations I know of, and probably a lot
more (nobody cares that it's nonstandard);

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.

Re: C aliasing rules question.

[Falk Hueffner]

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