Date: Tue, 27 Aug 2013 05:17:30 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Optimized C memset On Tue, Aug 27, 2013 at 10:52:55AM +0200, Jens Gustedt wrote: > Hello, > > Am Dienstag, den 27.08.2013, 04:30 -0400 schrieb Rich Felker: > > One aspect of this code that may appear ugly at first is the usage of > > the __GNUC__ macro. > > It not only *appears* to be ugly :) > > You already have a slight inconsistency in that at one point the code > depends on a particular version of "gcc" and other part only depends > on the fact that the __GNUC__ macro is set. That's intentional. The __may_alias__ attribute has existed since GCC 3.2 (I did the research just a little bit ago). Earlier versions of GCC certainly aren't capable of making optimization that could see cross-translation-unit aliasing, so it's "safe" to do without the attribute on such versions. > There are a lot of compilers out there faking to be a gcc of some > version and that are not always feature consistent with the gcc > version that they are claming to fake. ICC is notorious for that. So > to my opinion this is a dangerous path to follow. (I don't know about > any problems with the __may_alias__ attribute, though) 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? Note that even if we "wrongly" detect a compiler as supporting __may_alias__, as long as it doesn't give errors on unknown GCC attributes, the situation is no worse than what we have right now: aliasing violations that the compiler can't see without performing cross-translation-unit analysis. So the code couldn't break without a very fancy compiler, and I would expect any compiler providing such fancy optimization and claiming it's "GNU C" to support the GNU C feature for allowing aliasing in certain places. > 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 #if .... #define __has_may_alias__ #endif #ifdef __has_may_alias__ [use it] #endif is better than just #if .... [use it] #endif in any practical sense. 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. > 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... 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.