Mathinlines and GCC

[Andreas Jaeger]

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