public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Kean Johnston <jkj@sco.com>
To: Jim Wilson <wilson@specifixinc.com>
Cc: gcc@gcc.gnu.org
Subject: Re: Promoting floats to doubles?
Date: Tue, 04 May 2004 17:45:00 -0000	[thread overview]
Message-ID: <4097D44D.5090105@sco.com> (raw)
In-Reply-To: <1083643245.1258.151.camel@leaf.tuliptree.org>

> You could look at the current PROMOTE_FUNCTION_ARG/PROMOTE_PROTOTYPES
> stuff and extend it so that it works for float->double conversions.
I took a look at this, and I think extending it to support
float-doubles will be ... tricky. It may not even be appropriate,
considering that the docs talk about them being specifically for
integrals that are less than the native width.

Now I was able to achive what I needed to by hacking in two functions:
c-typeck.c:default_conversion(), where I added:
  if (TYPE_MAIN_INVARIANT (type) == float_type_node)
    return convert (double_type_node, exp);
and in c-typeck.c:convert_arguments(), where I extended the check
after the call to targetm.calls.promoto_prototypes to check for
a TREE_TYPE(type) == REAL_TYPE.

The first case I think should be protected by something like
#if TARGET_PROMOTES_FLOAT_TO_DOUBLE. My only concern is that I dont
know if thats the right function to put the conversion in, as I dont
know all of the circumstances under which default_conversion() is
called. Perhaps the right thing to do is isolate any changes to
convert_arguments().

For convert_arguments() itself, I think this type of check needs
to happen pretty early on. If the target requires this sort of
promotion to satisfy some ABI brain-damage, and this conversion
will always happen, then there is no point in warning about it.
So, the conversion should happen before the warning checks that
start close to the top of the fn. That implies that type can
change before the call to convert_for_assignment(). I am again
unsure of the consequences of this, so I would appreciate a little
guidance. Alternately, the conversion can happen later and the
warnings about float to fouble promotion can be silenced by
something like #ifndef TARGET_ALWAYS_PROMOTES_FLOATS. If this is
acceptable, then I can perhaps extend the code after the check
for targetm.calls.promote_prototypes(), which will always fail
becuase a float wont pass the INTEGRAL_TYPE_P() check. Thus I
could extend the if (targetm.calls...) at the end to say:
#ifdef TARGET_ALWAYS_PROMOTES_FLOATS
   else if (TREE_CODE (type) = REAL_TYPE)
     parmval = convert (double_type_node, parmval);
#endif

> The fixinc solution has the flaw that code with prototypes that use
> float won't be portable between the SCO compiler and GCC.  You can fix
> the system header prototypes, but you can't fix the prototypes in all
> applications and libraries.
True. I've abandoned the fixinc notion (after having come up with
a suitably gnarly sed script to do the conversion of course :P)

Kean

  reply	other threads:[~2004-05-04 17:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-02  6:32 Kean Johnston
2004-05-03 20:39 ` Jim Wilson
2004-05-04  1:25   ` Kean Johnston
2004-05-04  4:00     ` Jim Wilson
2004-05-04 17:45       ` Kean Johnston [this message]
2004-05-04 18:52         ` Joseph S. Myers
2004-05-04 20:44           ` Jim Wilson
2004-05-05  0:06             ` Kean Johnston
2004-05-05  2:18               ` Jim Wilson
2004-05-05  7:10               ` Jim Wilson
2004-05-05  9:10                 ` Kean Johnston
2004-05-05 22:47                   ` Jim Wilson
2004-05-05 23:48                     ` Kean Johnston
2004-05-04 20:52         ` Jim Wilson
2004-05-05  0:14           ` Kean Johnston

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=4097D44D.5090105@sco.com \
    --to=jkj@sco.com \
    --cc=gcc@gcc.gnu.org \
    --cc=wilson@specifixinc.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).