From: "Tim Prince" <tprince@computer.org>
To: "Erik de Castro Lopo" <nospam@mega-nerd.com>, <gcc@gcc.gnu.org>
Subject: Re: lrint / lrintf functions (slipping OT)
Date: Sat, 20 Oct 2001 22:25:00 -0000 [thread overview]
Message-ID: <009a01c159f0$bc553b50$f365323f@amr.corp.intel.com> (raw)
In-Reply-To: <20011021122931.78fa8cdf.nospam@mega-nerd.com>
----- 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
next prev parent reply other threads:[~2001-10-20 22:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-20 19:29 lrint / lrintf functions Erik de Castro Lopo
2001-10-20 22:25 ` Tim Prince [this message]
2001-10-20 22:39 ` lrint / lrintf functions (slipping OT) Erik de Castro Lopo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='009a01c159f0$bc553b50$f365323f@amr.corp.intel.com' \
--to=tprince@computer.org \
--cc=gcc@gcc.gnu.org \
--cc=nospam@mega-nerd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).