Re: What is the warning about builtin-function on gcc-4.6.0 ?

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Adam Beneschan <adam@irvine.com> writes:

> On Mar 29, 11:35�am, Robert A Duff <bobd...@shell01.TheWorld.com>
> wrote:
>
>> > And if it didn't do that, the implementor could change the function to
>> > include 'Valid on the operands to ensure that they're not invalid.
>>
>> Sure, EQUAL can raise C_E on invalid values.
>> But I don't think it can return True for invalid values
>> that are not mathematically equal. �(If it can, I think it's
>> a mistake in the REPORT package.) �I'm too lazy to inspect it
>> right now.
>
> The version of Report's body I'm looking at is from 3/29/01, but the
> comments don't indicate any changes to EQUAL since the first version.
> EQUAL can't propagate C_E because it has an exception handler for it:
> it just reverts to "return X = Y" if any exception is raised.

I see.  But as Randy pointed out, passing an invalid value to
EQUAL can raise C_E, even if abs(Integer'First) doesn not.

>...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).  It's not entirely unreasonable.  Perhaps
Integer is 32 bits, and the arithmetic is done in a 64-bit
register, which can obviously represent 2**31 just fine.

>...[If the compiler did
> something interesting like reserving a bit pattern like 16#8000# or
> 16#80000000# to be an invalid integer, then Integer'Last would be -
> Integer'First and the interesting part of C45632A would never be
> executed due to the first IF.]

I've used compilers that did that.  Not Ada compilers, though.

- Bob