Re: Optimized C memset

[Rich Felker <dalias@aerifal.cx>]

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