public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
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

  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).