Optimizing hypot()

Zack Weinberg zack@codesourcery.com
Thu Jul 24 19:32:00 GMT 2003


Roger Sayle <roger@eyesopen.com> writes:

> On Thu, 24 Jul 2003, Zack Weinberg wrote:
>> Roger Sayle <roger@eyesopen.com> writes:
>> > No problem, I'd be happy to.  I've added these three to my list of
>> > builtins to add to GCC.  I've one or two more builtins clean-up
>> > patches to submit first, including a realphabetization of
>> > builtins.def, after which I was planning to add several more math
>> > builtins anyway.
>>
>> Any hope of completing the removal of builtins defined in
>> builtin-attr.h?
>
> Hi Zack,
>
> Exactly! :>
>
> The game plan is that strftime can't yet be removed from builtin-attrs.def
> bacause it's third argument is "const struct tm *tm", and we don't yet
> support fuzzy matching beyond the first argument, except for when we use
> an additional hack of declaring the prototype without any arguments [which
> works for fputs but defeats the whole point of ATTR_FORMAT_STRFTIME_3_0].

Have you considered adding the capability to have a built-in forward
declaration of struct tm?

> Fortunately a patch to fix this is already waiting for review:
> http://gcc.gnu.org/ml/gcc-patches/2003-07/msg02031.html
> which will then allow the removal of FALLBACK builtins and the removal
> of DEF_FN_ATTR_IDENT from builtin-attrs.def (and the resulting dead code
> to process it).

This patch is OK.

> Along similar lines, another builtin clean-up patch waiting review is:
> http://gcc.gnu.org/ml/gcc-patches/2003-07/msg02011.html
> which allows the removal of FRONT_END builtins (and the resulting dead
> code to process them).  However, I've just finished bootstrapping and
> am currently regression testing a revised version of this patch that
> incorporates Kaveh's suggestion of changing "int unlocked" to bool.

And this one, with Kaveh's suggested changes.  I would add that a next
logical step would be to teach build_string to get the type of the
string constant right in the first place, thus obviating the need for
build_string_literal, fix_string_type in the C front end, and some
gunk in cp_lexer_read_token in the C++ front end.  The type as
established by each varies a bit, but I suspect this is accidental
rather than intentional.

zw



More information about the Gcc mailing list