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

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

Florian Weimer <fw@deneb.enyo.de> writes:

> * Robert A. Duff:
>
>> Florian Weimer <fw@deneb.enyo.de> writes:
>>
>>> I'm bothered by this reasoning because it means that Ada compilers
>>> don't have to implement any overflow checks on integer arithmetic.
>>
>> Randy was talking about floating point.  I'm not sure why the
>> above follows from what Randy said, but anyway, the rules for
>> integer arithmetic are:
>
> Okay, back one step.  I can't find the language rule which allows
> floating point arithmetic to produce invalid values (or objects with
> invalid representation, if you will).
>
> Is this about 3.5.6(7/2)?
>
> | For the execution of a predefined operation of a real type, the
> | implementation need not raise Constraint_Error if the result is
> | outside the base range of the type, so long as the correct result is
> | produced, or the Machine_Overflows attribute of the type is False
> | (see*note G.2).
>
> In the typical i386 case, this simplifies to:
>
> | For the execution of a predefined operation of a real type, the
> | implementation need not raise Constraint_Error if the result is
> | outside the base range of the type.
>
> This means that my initial assessment that a false value for 'Valid
> indicates a compiler bug was wrong.

I think what you say above is correct, but I'm not an expert in floating
point.  I'm pretty sure the intent of Ada 95 was to allow infinities to be
returned on overflow.  I don't know about division by zero.

>>>...(You cannot detect values which are
>>> conceptually invalid by inspecting the 'Valid attribute at run time
>>> because it produces false negatives, but this is a different matter.)
>>
>> I'm not sure what you mean.  How can 'Valid produce false negatives?
>
> The language rules define that a certain point of execution, an object
> has an invalid representation (and a compiler may assume it has).  But
> this might not be visible on the hardware during actual execution
> because the invalid representation is, by sheer luck, valid for the
> type of the object.

Sorry, I still don't understand what you mean.  Maybe you could
give an example (preferably using integers, not floats).

- Bob