This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Promoting floats to doubles?

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

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

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:
  else if (TREE_CODE (type) = REAL_TYPE)
    parmval = convert (double_type_node, parmval);

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)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]