This is the mail archive of the
mailing list for the glibc project.
[Bug string/20736] string2.h strcmp macro gratuitously adds __builtin_
- From: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 27 Oct 2016 17:22:49 +0000
- Subject: [Bug string/20736] string2.h strcmp macro gratuitously adds __builtin_
- Auto-submitted: auto-generated
- References: <email@example.com/bugzilla/>
--- Comment #3 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Aaron Sawdey from comment #2)
> I opened this bug because of the asymmetry between strncmp's macro that just
> expands in terms of strncmp, and the strcmp macro that expands to
> __builtin_strcmp. I can live with having to have a more complex workaround
> if I want to disable the expansion of __builtin_strcmp that I'm adding to
> The questions I suppose I was trying to ask are: why is there a difference
> between what these two macros do in this regard? Why does the strcmp macro
> feel it cannot leave the decision of what to do with the strcmp function
> call up to the compiler (i.e. expand builtin or don't)?
> If the answer is that the status quo is ok, I can live with that.
You have no guarantee of any symmetry in terms of the function implementation.
If I understand your particular case you just want to disable the use of
__builtin_strcmp from code compiled with gcc? That's just not possible for
glibc which is part of the implementation and may rely on all features the the
GNU C compiler.
To answer your other question, why __builtin_strcmp? Because the
microbenchmarks say it's faster in the mean for the machines using the generic
macro implementation. There is no other metric except for expert opinion and
the microbenchmarks in benchtests/ e.g. make bench. Keep in mind that we don't
enable these optimizations for all compilations, the compiler must be new
enough, we must know optimizations were requested, the optimization must not be
for size, we must know inlining is allowed, and it should not be C++.
If you have other opinions I'm happy to hear them, and you can run the
microbenchmarks yourself to determine an objective position on the matter;
which is the purpose of the benchmarks.
Note that for x86 the strcmp implementation does not use __builtin_strcmp at
all, only the generic version does.
Does that answer your question?
You are receiving this mail because:
You are on the CC list for the bug.