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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ecc38b3271b36b88 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews.google.com!f15g2000pro.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: What is the warning about builtin-function on gcc-4.6.0 ? Date: Wed, 30 Mar 2011 07:41:58 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <87aagiclte.fsf@mid.deneb.enyo.de> <475d10ca-5d4e-490c-9b88-e12cd3cd3faa@b13g2000prf.googlegroups.com> <87d3lejjyv.fsf@mid.deneb.enyo.de> <6c748f70-7e75-49b4-a467-d1d2d6b24323@w9g2000prg.googlegroups.com> <87k4flhoeg.fsf@mid.deneb.enyo.de> <8762r5hl2u.fsf@mid.deneb.enyo.de> <87vcz5ot5z.fsf@mid.deneb.enyo.de> <87sju8lcis.fsf@mid.deneb.enyo.de> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1301496118 21589 127.0.0.1 (30 Mar 2011 14:41:58 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 30 Mar 2011 14:41:58 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: f15g2000pro.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; .NET4.0C),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:18603 Date: 2011-03-30T07:41:58-07:00 List-Id: On Mar 30, 5:57=A0am, Robert A Duff wrote: > >...If the > > compiler's behavior is incorrect and doesn't raise C_E for > > abs(Integer'First) when it's supposed to, then presumably > > abs(Integer'First) will still be Integer'First (on a normal 2's > > complement machine), and EQUAL will return TRUE. > > Right, that would be a compiler bug. > > I was imagining a compiler that returns the right answer for > abs(Integer'First). =A0It's not entirely unreasonable. =A0Perhaps > Integer is 32 bits, and the arithmetic is done in a 64-bit > register, which can obviously represent 2**31 just fine. Offhand, I don't think that makes sense, though. The "abs" predefined function is predefined to return Integer'Base; if the mathematical answer doesn't fit in Integer'Base, I don't see how the right answer can be returned. Actually, 3.5.4(11) says that the predefined subtype Integer is constrained to the base range of its type, and 3.5.4(9) says that the base ranges of integer types are symmetric about zero except possibly for an extra negative number. So I don't think the scenario you envision can legally exist. If arithmetic is done in a 64-bit register, the program may temporarily have the correct mathematical answer for abs(Integer'First); but if that answer doesn't fit in 32 bits, nothing can be done with that value---the compiler would have to raise C_E right away. (*) So I don't know what you mean by "returns the right answer", but I don't think it's possible in any meaningful sense. Maybe I've lost track of what you were trying to say. (*) If the value were used as part of a larger expression involving predefined operators, there might be a Chapter 11 Implementation Permission that would allow computation to continue using the 64-bit value. Here, though, it's just passed as a parameter of type Integer to a user-defined function, so the constraint check would have to take place. Bottom line: there's really no way for Equal(abs(X),X) to return False if X=3DInteger'First. -- Adam