Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3EA5BCC6.CFF7F7DE@phekda.freeserve.co.uk>
Date: Tue, 22 Apr 2003 23:05:58 +0100
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: Yet another try on nan in strto{f,d,ld}
References: <200304221509 DOT RAA06409 AT lws256 DOT lu DOT erisoft DOT se> <3EA5B9F8 DOT C6F193BE AT phekda DOT freeserve DOT co DOT uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

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/ ]