[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130827143922.GS20515@brightrain.aerifal.cx>
Date: Tue, 27 Aug 2013 10:39:23 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Optimized C memset
On Tue, Aug 27, 2013 at 04:34:31PM +0200, Luca Barbato wrote:
> On 27/08/13 16:21, Rich Felker wrote:
> > If you're saying testing __has_may_alias__ rather than __GNUC__ buys
> > us more portability, I don't see a reason to believe this. A
> > hypothetical non-GNUC compiler might need an actual pointer variable
> > (rather than cast through a pointer type with may_alias on it) to
> > avoid the aliasing violation, or it might require a special attribute
> > on the function indicating that the whole function has immunity from
> > the aliasing rules, or any number of other possibilities.
>
> You might decouple the two:
>
> - support may_alias
> - safe to compile code that may alias
>
> Just that the latter is harder to check.
Indeed. My current logic is that it's safe to compile code that may
alias if the compiler is ancient GCC (note: musl does not even
advertise support for pre-3.2 GCC) or if it supports may_alias. The
most likely negative consequence of the proposed code is that build
may completely fail on compilers that advertise themselves as __GNUC__
but fail to accept __attribute__((__may_alias__)). In this sense, a
configure check might be preferable, but I hate to get started with
those...
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
