From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!reality.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Profiling Ada binaries
Date: Fri, 5 Aug 2016 15:27:25 -0500
Organization: JSA Research & Innovation
Message-ID: <no2sr5$krm$1@franka.jacob-sparre.dk>
References: <nmt6qe$3d6$1@gioia.aioe.org> <nmtcbq$6fh$1@dont-email.me>
 <nmtcns$81a$1@dont-email.me> <nn4dfh$1cog$1@gioia.aioe.org>
 <a9f6bc88-81e3-480f-9e2d-91060e1dbdb5@googlegroups.com>
 <04e12bd0-2c9d-f90d-2497-bf58593addfd@spam.spam>
 <845e12db-9e2c-4d0f-a3b0-19ac50f14d24@googlegroups.com>
 <nnome9$iac$1@dont-email.me>
 <588a93bb-b39a-4196-b6ca-5e673fd256dd@googlegroups.com>
NNTP-Posting-Host: rrsoftware.com
X-Trace: franka.jacob-sparre.dk 1470428837 21366 24.196.82.226 (5 Aug 2016
 20:27:17 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Fri, 5 Aug 2016 20:27:17 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-RFC2646: Format=Flowed; Original
Xref: news.eternal-september.org comp.lang.ada:31303
Date: 2016-08-05T15:27:25-05:00
List-Id: <comp.lang.ada>

<rieachus@comcast.net> wrote in message 
news:588a93bb-b39a-4196-b6ca-5e673fd256dd@googlegroups.com...
On Monday, August 1, 2016 at 7:36:45 PM UTC-4, Jeffrey R. Carter wrote:

>> If you look at the requirements for the Cos function in Annex A and Annex 
>> G (if
>> implemented, which it is for GNAT), you'll find a number of requirements 
>> for
>> accuracy and special cases. If you look at the definition of the built-in
>> function, you'll likely find that it doesn't meet all of those 
>> requirements. Any
>> call to Cos has to involve wrapping a call to the built-in function in 
>> code to
>> ensure those requirements are met, so you won't find a call to the 
>> built-in
>> function in the generated code.
>
>Yes, any "strict" LRM matching implementation probably won't use the 
>built-in functions.

Can't really, at least for the Intel implementations of Sin, Cos, etc. Those 
don't do argument reduction, which is required to get the appropriate 
accuracy. (I recall reading the Intel processor manual for those 
instructions, and they recommended reducing the arguments before using 
them.) I suppose one could try to do all of that inline, but I can't see the 
reason to bother with special code for that -- the usual inlining mechanisms 
will do that if it makes sense.

                                     Randy.