Mail Archives: djgpp-workers/2003/04/22/18:06:04
Hello.
Richard Dawe wrote:
>
> Martin Stromberg wrote:
> >
> > Richard said:
> > > > I mean the plain typecasts, like this:
> > > >
> > > > + double_t n = *(double_t *)(&tmp_d);
> > > >
> > > > or this:
> > > >
> > > > + return *(double *)(&n);
> > > [snip]
> > >
> > > As I understand it, restrict'ed variables are strictly aliased.
> >
> > Uuhhh... "strictly aliased"?
>
> restricted variables are strictly aliased. That doesn't mean that strictly
> aliased variables are restricted. ;)
>
> > Anyway, are you saying that tmp_d, n or *(double *)(&n) is strictly
> > aliased, restrict qualified or in anyway will become so when we add
> > restrict to the function's parameters? Why? Howcome? (Note that tmp_d
> > and n are local variables.)
>
> No. But if you're getting the compiler is generating warnings about strict
> aliasing, then it will generate a warning for this case. Below is an extract
> from gcc 3.2.2's manual, as show by "info Invoking 'Optimize Options'".
>
> ...
>
> -fstrict-aliasing'
> Allows the compiler to assume the strictest aliasing rules
> applicable to the language being compiled. For C (and C++), this
> activates optimizations based on the type of expressions. In
> particular, an object of one type is assumed never to reside at
> the same address as an object of a different type, unless the
> types are almost the same. For example, an `unsigned int' can
> alias an `int', but not a `void*' or a `double'. A character type
> may alias any other type.
Time to get a new mail client, I think. It cut off the last half of my
message:
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.
...
Bye, Rich =]
--
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]
- Raw text -