This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Mathinlines and GCC
- From: Andreas Jaeger <aj at suse dot de>
- To: libc-alpha at sourceware dot org
- Cc: rguenther at suse dot de, Uros Bizjak <ubizjak at gmail dot com>
- Date: Wed, 02 May 2012 21:23:49 +0200
- Subject: Mathinlines and GCC
The bug I mentioned earlier today with test-ifloat is according to the
GCC bugreport (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53190) a bug
in our inline functions:
"The asm that depends on some unknown-to-gcc global processor state should be
marked as volatile."
But Uros also said:
"As a side note, mathinline.h really needs some serious TLC, there are many
functions that are much better implemented with gcc builtin functions, not to
mention that x87 asm in 32bit case interferes *badly* with -mfpmath=sse.
Fortunately, there is -D__NO_MATH_INLINES, used in my projects from day one.
Really, there is no justification for mathinline.h to live, as far as gcc is
concerned."
So, for me the questions is: Shouldn't we cleanup the mathinline headers
and remove whatever functions a GCC of our choice (I would use the last
released one - 4.7) can optimize? Most inlines are only for GCC and if
GCC knows about it, it can do a better job.
So, my proposed fix for the lrintf bug would be to remove the lrintf
inline function from sysdeps/x86_64/fpu/bits/mathinline.h (and remove
some more as well).
What do you think?
Uros, thanks for your quick analysis!
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 NÃrnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix ImendÃrffer,HRB16746 (AG NÃrnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126