From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: Jan Hubicka <jh@suse.cz>
Cc: David Edelsohn <dje@watson.ibm.com>,
Zack Weinberg <zack@codesourcery.com>,
gcc@gcc.gnu.org, libstdc++@gcc.gnu.org
Subject: Re: basic-improvements merge status
Date: Tue, 17 Dec 2002 01:19:00 -0000 [thread overview]
Message-ID: <m3bs3lggk5.fsf@uniton.integrable-solutions.net> (raw)
In-Reply-To: <20021217085043.GR3138@kam.mff.cuni.cz>
Jan Hubicka <jh@suse.cz> writes:
| > David Edelsohn <dje@watson.ibm.com> writes:
| >
| > | >>>>> Zack Weinberg writes:
| > |
| > | Zack> David Edelsohn <dje@watson.ibm.com> writes:
| > | >> Any idea what change in GCC 3.4BIB is causing GCC to "optimize"
| > | >>
| > | >> (float) sin(x)
| > | >>
| > | >> as
| > | >>
| > | >> sinf(x)?
| > |
| > | Zack> I remember such an optimization being implemented but I can't find the
| > | Zack> change log entry for it. My recollection is that it was Jan Hubicka
| > | Zack> who coded it. Jan?
| > |
| > | Yes, it appears to be due to the builtins.def changes by Jan which
| > | assumes that all of those functions natively are available on every
| > | target. One cannot make that assumption. Testing for the existence of
| > | those functions on the target is not easy.
| >
| > I think this is a case where GCC's logic in apply transformations just
| > breaks down.
| >
| > | In most cases, the transformation will result in a linker error on
| > | systems which do not provide the function, but libstdc++-v3 graciously
| > | provides the symbols, creating a recursion in those definitions.
| >
| > I don't think libstdc++-v3 is at fault here. I think it is the
| > middle-end. That is, if as a programmer, I do know that the target is
| > lacking sinf() and consciously I did write "(float) sin(x)", then I
| > find it a diservice that GCC calls a sinf(). Really.
|
| Yes, I see that.
| But it is really not different from reusing memset() call for totally
| different purpose. You function is not valid C so it should use
| -fdisable-builtins.
Which function is not valid C?
Please, do remember that libtdc++-v3 is part of the compiler runtime
support, so your argument that it is not valid is pointless.
| > I see values for the mentioned transformation. But bindly applying it
| > is a -not- a service.
| In what conditions do you think we should apply that?
There ought to be a switch to tell the compiler which functions not to
use its transformations.
-- Gaby
next prev parent reply other threads:[~2002-12-17 9:14 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-16 13:52 David Edelsohn
2002-12-16 13:57 ` Zack Weinberg
2002-12-16 14:23 ` David Edelsohn
2002-12-16 14:27 ` Jan Hubicka
2002-12-16 14:47 ` Neil Booth
2002-12-16 15:10 ` Jan Hubicka
2002-12-17 0:50 ` Gabriel Dos Reis
2002-12-17 15:54 ` Richard Henderson
2002-12-17 16:14 ` Gabriel Dos Reis
2002-12-18 5:29 ` Jan Hubicka
2002-12-17 16:19 ` Matt Austern
2002-12-17 16:31 ` Phil Edwards
2002-12-16 21:32 ` Joseph S. Myers
2002-12-16 17:01 ` Mark Mitchell
2002-12-17 0:47 ` Gabriel Dos Reis
2002-12-17 0:54 ` Jan Hubicka
2002-12-17 1:19 ` Gabriel Dos Reis [this message]
2002-12-16 14:29 ` Jan Hubicka
2002-12-16 14:29 ` David Edelsohn
2002-12-16 14:35 ` Jan Hubicka
2002-12-17 0:55 ` Gabriel Dos Reis
2002-12-17 0:58 ` Jan Hubicka
2002-12-17 1:53 ` Gabriel Dos Reis
2002-12-17 4:16 ` Jan Hubicka
2002-12-17 4:29 ` Fergus Henderson
2002-12-17 8:39 ` Gabriel Dos Reis
2002-12-17 13:58 ` Jan Hubicka
2002-12-16 14:44 ` David Edelsohn
2002-12-16 14:45 ` Jan Hubicka
2002-12-16 14:52 ` David Edelsohn
2002-12-16 14:54 ` Jan Hubicka
2002-12-16 17:05 ` Mark Mitchell
2002-12-17 0:44 ` Jan Hubicka
2002-12-17 0:46 ` Mark Mitchell
2002-12-17 0:51 ` Jan Hubicka
2002-12-17 4:10 ` Joseph S. Myers
2002-12-17 7:06 ` Gabriel Dos Reis
2002-12-17 11:42 ` Joseph S. Myers
2002-12-17 9:43 ` Mark Mitchell
2002-12-17 14:06 ` Jan Hubicka
2002-12-17 14:18 ` Gabriel Dos Reis
2002-12-17 14:36 ` Implicit generation of runtime calls Jan Hubicka
2002-12-17 14:51 ` Jan Hubicka
2002-12-17 0:54 ` basic-improvements merge status Jan Hubicka
2002-12-17 3:24 ` Gabriel Dos Reis
2002-12-17 4:28 ` Hot to configure sinf? Jan Hubicka
2002-12-17 8:24 ` Gabriel Dos Reis
2002-12-17 1:51 ` basic-improvements merge status Gabriel Dos Reis
2002-12-17 21:31 ` Alexandre Oliva
2002-12-17 21:21 ` Alexandre Oliva
2002-12-18 5:44 ` Jan Hubicka
2002-12-17 1:16 ` Gabriel Dos Reis
2002-12-16 15:05 ` [libstdc++] " Jan Hubicka
2002-12-16 15:40 ` Dale Johannesen
2002-12-16 16:16 ` Jan Hubicka
2002-12-16 17:12 ` Dale Johannesen
2002-12-16 19:16 ` Fergus Henderson
2002-12-17 1:14 ` Gabriel Dos Reis
2002-12-17 3:48 ` Joseph S. Myers
2002-12-16 15:55 ` Benjamin Kosnik
2002-12-16 16:10 ` Jan Hubicka
2002-12-16 15:56 ` Andrew Pinski
2002-12-17 0:53 ` Gabriel Dos Reis
2002-12-17 0:56 ` Jan Hubicka
2002-12-17 1:22 ` Gabriel Dos Reis
2002-12-17 3:20 ` Gabriel Dos Reis
2002-12-17 2:12 ` Gabriel Dos Reis
[not found] <B1F15313-1157-11D7-96C8-00039375D8A0@apple.com>
2002-12-16 17:44 ` Geoff Keating
2002-12-16 18:28 ` Zack Weinberg
2002-12-16 18:47 ` Geoff Keating
-- strict thread matches above, loose matches on Subject: below --
2002-12-16 10:26 David Edelsohn
2002-12-15 15:46 Zack Weinberg
2002-12-15 20:57 ` Mark Mitchell
2002-12-16 1:02 ` Zack Weinberg
2002-12-16 1:05 ` Mark Mitchell
2002-12-16 2:19 ` Tom Lord
2002-12-16 11:52 ` DJ Delorie
2002-12-16 8:46 ` Jason R Thorpe
2002-12-16 1:46 ` Jan Hubicka
2002-12-16 12:55 ` Geoff Keating
2002-12-16 13:11 ` Robert McNulty Junior
2002-12-16 14:39 ` Mark Mitchell
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=m3bs3lggk5.fsf@uniton.integrable-solutions.net \
--to=gdr@integrable-solutions.net \
--cc=dje@watson.ibm.com \
--cc=gcc@gcc.gnu.org \
--cc=jh@suse.cz \
--cc=libstdc++@gcc.gnu.org \
--cc=zack@codesourcery.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).