Re: lrint / lrintf functions (slipping OT)

["Tim Prince" <tprince at computer dot org>]

----- Original Message -----
From: "Erik de Castro Lopo" <nospam@mega-nerd.com>
To: <gcc@gcc.gnu.org>
Sent: Saturday, October 20, 2001 7:29 PM
Subject: lrint / lrintf functions


> Hi all,
>
> I am currently using the above two C99 functions. If I turn off
optimisation
> ( -O0) I get an error stating that the functions can't be
found. If optimisation
> is turned on everything is fine.
>
> On my Linux system, these function are in <bits/mathinline.h>
which is
> automatically included when I include <math.h>. With
optimisation switch off
> it looks like the compiler fails to compile in a static version
of the lrint
> and lrintf functions.
Last I looked, glibc had its math.h set up not to include
<mathinline.h> when -O0 or -Os is selected.
>
> Is this the fault of gcc, the C library of something else?
>
> Using Linux 2.4.10 kernel, gcc-2.95, glibc-2.2.4.
I believe I recall that the C standard used to require the
availability of an external copy of each standard function, so
this would be a bug in glibc, even if gcc were to have a complete
internal implementation.
No, don't blame the kernel, or gcc; modify your glibc setup to do
it the way you want.  Can't you make a linkable version (using
options which invoke the inlines) like:

#include <math.h>
long int (lrint)(double x){return lrint(x);}

Hand optimize the .s file if you like, but I see advantages in
assuring that the in-lines and the external linkable versions
should be more consistent than they currently are. This is not to
deny that the external versions require more error checking than
the in-lines. All OT for gcc, even though the organizational
disconnect between the compiler and the library is contrary to
the standards.  But, glibc won't change unless a number of
influential users have demonstrated and agree upon an
improvement.

I'm considering doing a more complete libm of my own (GPL of
course), at least all the functions where I find something
lacking in one of the libraries commonly used with gcc, but I
don't expect anyone to adopt it.
>
> Thanks in advance,
> Erik