This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]