[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1377597040.25996.295.camel@eris.loria.fr>
Date: Tue, 27 Aug 2013 11:50:40 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: Optimized C memset
Am Dienstag, den 27.08.2013, 05:17 -0400 schrieb Rich Felker:
> So far, my experience is that compilers which advertise themseleves as
> "GNU C" compilers have all the semantic features of GCC 3 at the very
> least. Is this an invalid assumption?
for gcc versions less than 4, probably, I don't remember an exception
for that. For version in the 4, there are several such examples.
> > To make this easier to maintain, I'd suggest to introduce a special
> > feature test macro, something like __has_may_alias__, and have that
> > set at the beginning of the file in a section that is clearly
> > dedicated to compile time feature detection. Other compilers may have
> > different syntax for such a feature (a _Pragma comes in mind) and may
> > be detected quite differently than by gcc version numbering.
>
> Where would you suggest it be added? The result of the check is only
> used in one place, so I don't see how
I'd wouldn't have an #else case to the detection but do
#ifndef may_alias
# if 100*__GNUC__+__GNUC_MINOR__ >= 302
# define may_alias __attribute__((__may_alias__))
# endif
#endif
#ifdef may_alias
# define __has_may_alias__
#else
# define may_alias
#endif
This is not much more complicated than what you have and makes it easy
to add other cases, without having to maintain the __has_may_alias__
feature macro itself.
> If on the other hand you're suggesting that I should be more
> conservative and check not just for __GNUC__, but also for the
> availability of __may_alias__, in the actual code body (rather than
> just the typedefs), then it may make more sense.
yes, I thought in these lines. that code should be handled well by any
modern compiler that you can convince to not playing games with
aliasing, here. So the fact that you tested it with gcc-like compilers
is merely an artefact.
> > Such specific feature test macros is the way that clang goes, and from
> > my experience this is much easier to maintain and to understand when
> > you stumble on such #ifdef'ed code. You not only know that this needs
> > a special version of a compiler, but also for what reason.
>
> Oh, I agree it's much cleaner. Sadly, though, GCC doesn't seem to give
> us that information...
yes, for gcc you'd always have to detect features in the way you are
doing it know. But I'd think that feature detection should be
separated from the use of the features. The uses might be spread over
several places, but the detection should be done in one well
detectable spot in the source code.
Jens
--
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/ ::
:: AlGorille ::::::::::::::: office Nancy : +33 383593090 ::
:: ICube :::::::::::::: office Strasbourg : +33 368854536 ::
:: ::::::::::::::::::::::::::: gsm France : +33 651400183 ::
:: :::::::::::::::::::: gsm international : +49 15737185122 ::
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
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.
