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

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

[ytomino]

Hello.
gcc-4.6.0 was released!
I'm trying to compile my code with gcc-4.6.0,
and I found a strange warning at using built-in functions of gcc.

The minimal code is here:

with Ada.Text_IO;
procedure test1 is
   function isfinite (X : Long_Float) return Integer;
   pragma Import (Intrinsic, isfinite, "__builtin_isfinite");
begin
   -- 10 is finite value, it puts 1
   Ada.Text_IO.Put_Line (Integer'Image (
      isfinite (Long_Float'Value ("10"))));
   -- 10 / 0 is infinite, it puts 0
   Ada.Text_IO.Put_Line (Integer'Image (
      isfinite (Long_Float'Value ("10") / Long_Float'Value ("0"))));
end test1;

$ /usr/local/bin/gcc-4.5.2/gnatmake test1
gcc -c test1.adb
gnatbind -x test1.ali
gnatlink test1.ali
~/projects/exam/ada/compiler/builtin
$ /usr/local/bin/gcc-4.6.0/gnatmake test1
gcc -c test1.adb
test1.adb:3:13: warning: profile of "isfinite" doesn't match the
builtin it binds <- this warning
gnatbind -x test1.ali
gnatlink test1.ali

I tried changing the prototype again and again,

   function isfinite (X : Long_Float) return Integer;
   function isfinite (X : Long_Float) return Boolean;
   function isfinite (X : Float) return Integer;
   function isfinite (X : Long_Long_Float) return Integer;
   ...etc...

but I could not erase this warning... Can anyone erase this warning ?

Thank you.

--
Yuta Tomino

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

[Florian Weimer]

* ytomino:

>    function isfinite (X : Long_Float) return Integer;
>    pragma Import (Intrinsic, isfinite, "__builtin_isfinite");

isfinite and the corresponding GCC builtin are overloaded C99
functions and cannot be called from Ada.

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

[ytomino]

On Mar 26, 5:45 pm, Florian Weimer <f...@deneb.enyo.de> wrote:
> * ytomino:
>
> >    function isfinite (X : Long_Float) return Integer;
> >    pragma Import (Intrinsic, isfinite, "__builtin_isfinite");
>
> isfinite and the corresponding GCC builtin are overloaded C99
> functions and cannot be called from Ada.

I've used isfinite (and other builtins) with gcc-4.5.x、and it works
fine.
And, with gcc-4.6.0, it reports warning, but it works fine exactly.
So I think these builtins *can* called from Ada.

Is it disallowed in the specification ?

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

[Florian Weimer]

* ytomino:

> I've used isfinite (and other builtins) with gcc-4.5.x、and it works
> fine.

Yes, the check was added in r161257, which was after the release of
GCC 4.5.

> And, with gcc-4.6.0, it reports warning, but it works fine exactly.
> So I think these builtins *can* called from Ada.
>
> Is it disallowed in the specification ?

I'm not aware of any specification, unfortunately.

Perhaps the warning should only check if the argument is a
floating-point type.  It might it work in this case.  But the
underlying problem is that the import mechanism only targets C-like
functions, and those overloaded C99 functions are not really C-like at
all.

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

[ytomino]

On Mar 26, 6:43 pm, Florian Weimer <f...@deneb.enyo.de> wrote:
> Perhaps the warning should only check if the argument is a
> floating-point type.  It might it work in this case.  But the
> underlying problem is that the import mechanism only targets C-like
> functions, and those overloaded C99 functions are not really C-like at
> all.

OK, I understand.
Thank you, Florian.

nn...then, there are no function to take infinity and NaN...

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

[Florian Weimer]

* ytomino:

> nn...then, there are no function to take infinity and NaN...

There has to be something in the language, somewhere, but I can't find
it.  A.5.3 in Ada 2005 would be an obvious location (attributes on
floating point types), but it's not there.

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

[Dmitry A. Kazakov]

On Sat, 26 Mar 2011 11:24:37 +0100, Florian Weimer wrote:

> * ytomino:
> 
>> nn...then, there are no function to take infinity and NaN...
> 
> There has to be something in the language, somewhere, but I can't find
> it.  A.5.3 in Ada 2005 would be an obvious location (attributes on
> floating point types), but it's not there.

Ada floating point types are not necessarily IEEE.

Luckily you can kill the IEEE stuff even if the machine is IEEE:

   subtype No_Mess is Float range Float'Range; -- No surprises any more

When interfacing C, one IMO should always add a range or validity check
when taking floating-point values from C, to prevent non-numbers leaking
out. Unfortunately it is a lot of work, so no Ada bindings actually follows
this rule.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[ytomino]

On Mar 27, 12:14 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> Ada floating point types are not necessarily IEEE.

I knew and so used builtin-functions.

> Luckily you can kill the IEEE stuff even if the machine is IEEE:
>
>    subtype No_Mess is Float range Float'Range; -- No surprises any more
>
> When interfacing C, one IMO should always add a range or validity check
> when taking floating-point values from C, to prevent non-numbers leaking
> out. Unfortunately it is a lot of work, so no Ada bindings actually follows
> this rule.

uh, there are functions (from C) that return infinity/NaN
intentionally, too.

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

[Dmitry A. Kazakov]

On Sat, 26 Mar 2011 14:36:04 -0700 (PDT), ytomino wrote:

> On Mar 27, 12:14�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:

>> When interfacing C, one IMO should always add a range or validity check
>> when taking floating-point values from C, to prevent non-numbers leaking
>> out. Unfortunately it is a lot of work, so no Ada bindings actually follows
>> this rule.
> 
> uh, there are functions (from C) that return infinity/NaN
> intentionally, too.

When a numeric function returns garbage it is useless. When non-numbers are
supposed to serve error indication, they must be converted to an exception,
e.g. Constraint_Error. Which is the whole point. In my view a C binding
should check the result for mess and raise an exception if necessary.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Simon Wright]

ytomino <aghia05@gmail.com> writes:

> nn...then, there are no function to take infinity and NaN...

'Valid should do the trick.

   FP_Value := 1.0 / 0.0;
   if FP_Value'Valid then
      --  it won't be

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

[Florian Weimer]

* Simon Wright:

> ytomino <aghia05@gmail.com> writes:
>
>> nn...then, there are no function to take infinity and NaN...
>
> 'Valid should do the trick.
>
>    FP_Value := 1.0 / 0.0;
>    if FP_Value'Valid then
>       --  it won't be

This is a compiler bug.

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

[Simon Wright]

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

> * Simon Wright:
>
>> ytomino <aghia05@gmail.com> writes:
>>
>>> nn...then, there are no function to take infinity and NaN...
>>
>> 'Valid should do the trick.
>>
>>    FP_Value := 1.0 / 0.0;
>>    if FP_Value'Valid then
>>       --  it won't be
>
> This is a compiler bug.

I don't understand what you mean.

If the compiler doesn't raise an exception on division by zero (it's
allowed not to, and GNAT doesn't) it will (in this case) set the result
to +Inf, and 'Valid will return False.

That's for plain [Long_[Long_]]Float. If you've said

   subtype Real is Float range Float'Range;

you'll get a Constraint_Error on assignment of Inf or NaN to a Real. 

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

[Florian Weimer]

* Simon Wright:

> Florian Weimer <fw@deneb.enyo.de> writes:
>
>> * Simon Wright:
>>
>>> ytomino <aghia05@gmail.com> writes:
>>>
>>>> nn...then, there are no function to take infinity and NaN...
>>>
>>> 'Valid should do the trick.
>>>
>>>    FP_Value := 1.0 / 0.0;
>>>    if FP_Value'Valid then
>>>       --  it won't be
>>
>> This is a compiler bug.
>
> I don't understand what you mean.

The standard requires that FP_Value'Valid is true.

> If the compiler doesn't raise an exception on division by zero (it's
> allowed not to, and GNAT doesn't) it will (in this case) set the result
> to +Inf, and 'Valid will return False.

My understanding is that an implementation must either raise
Constraint_Error, or the evaluation of an expression must result in a
valid value.

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

[Simon Wright]

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

> * Simon Wright:
>
>> Florian Weimer <fw@deneb.enyo.de> writes:
>>
>>> * Simon Wright:
>>>
>>>> ytomino <aghia05@gmail.com> writes:
>>>>
>>>>> nn...then, there are no function to take infinity and NaN...
>>>>
>>>> 'Valid should do the trick.
>>>>
>>>>    FP_Value := 1.0 / 0.0;
>>>>    if FP_Value'Valid then
>>>>       --  it won't be
>>>
>>> This is a compiler bug.
>>
>> I don't understand what you mean.
>
> The standard requires that FP_Value'Valid is true.
>
>> If the compiler doesn't raise an exception on division by zero (it's
>> allowed not to, and GNAT doesn't) it will (in this case) set the result
>> to +Inf, and 'Valid will return False.
>
> My understanding is that an implementation must either raise
> Constraint_Error, or the evaluation of an expression must result in a
> valid value.

ARM 13.9.2 doesn't include division by zero as a means of producing an
invalid float.

However, A.5.3(12) ('Machine_Overflows) implies that Constraint_Error
doesn't _have_ to be raised. It doesn't say what happens - that's
implementation-defined, M.2(123) and G.2.1(13).

The GNAT RM
(http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gnat_rm/Strict-Conformance-to-the-Ada-Reference-Manual.html#Strict-Conformance-to-the-Ada-Reference-Manual)
says

   "Note that the result of a floating point arithmetic operation in
   overflow and invalid situations, when the Machine_Overflows attribute
   of the result type is False, is to generate IEEE NaN and infinite
   values. This is the case for machines compliant with the IEEE
   floating-point standard, but on machines that are not fully compliant
   with this standard, such as Alpha, the -mieee compiler flag must be
   used for achieving IEEE confirming behavior (although at the cost of
   a significant performance penalty), so infinite and and NaN values
   are properly generated."


I don't see anything in the above that says that 'Valid should produce
False for Inf/NaN, but GNAT - on Intel & PowerPC hardware - certainly
does.

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

[Florian Weimer]

* Simon Wright:

>> My understanding is that an implementation must either raise
>> Constraint_Error, or the evaluation of an expression must result in a
>> valid value.
>
> ARM 13.9.2 doesn't include division by zero as a means of producing an
> invalid float.

Floating point arithmetic is not mentioned in in 13.9.1, either (which
seems an exhaustive list to me).

I'm concerned that any interpretation which makes 'Valid false here
would also allow to produce arbitrary values from any form of
arithmetic, floating point or not.  (If 'Valid is false, the object is
abnormal, so all bets are off.)

> I don't see anything in the above that says that 'Valid should produce
> False for Inf/NaN, but GNAT - on Intel & PowerPC hardware - certainly
> does.

And it's not an accident as the result of failing range checks or
something like that.  There is a deliberate check for Infs and Nans in
s-fatgen.adb.

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

[Randy Brukardt]

"Florian Weimer" <fw@deneb.enyo.de> wrote in message 
news:8762r5hl2u.fsf@mid.deneb.enyo.de...
...
>> If the compiler doesn't raise an exception on division by zero (it's
>> allowed not to, and GNAT doesn't) it will (in this case) set the result
>> to +Inf, and 'Valid will return False.
>
> My understanding is that an implementation must either raise
> Constraint_Error, or the evaluation of an expression must result in a
> valid value.

Your understanding is wrong.

The only real requirement on Ada math is that the resulting values are not 
used in a way that causes erroneous execution (and there is even an explicit 
hole allowing that for Unchecked_Conversion). Otherwise, using/producing an 
"invalid value" is allowed in almost all contexts -- but it is a bounded 
error so a compiler can raise an exception if it wants.

Also note that "abnormal" is something different from "invalid" (only scalar 
objects can be invalid).

Data validity is a very complex subject; you can read 13.9.1 10 times and 
get different impressions each time. Reading the e-mail on the various AIs 
on the topic (AI05-0195-1 is the most recent) and the AARM *might* help --  
or might confuse further. On top of that, different implementations use 
different models to ensure validity without inserting more checks than 
necessary.

                                            Randy.

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

[Florian Weimer]

* Randy Brukardt:

> "Florian Weimer" <fw@deneb.enyo.de> wrote in message 
> news:8762r5hl2u.fsf@mid.deneb.enyo.de...
> ...
>>> If the compiler doesn't raise an exception on division by zero (it's
>>> allowed not to, and GNAT doesn't) it will (in this case) set the result
>>> to +Inf, and 'Valid will return False.
>>
>> My understanding is that an implementation must either raise
>> Constraint_Error, or the evaluation of an expression must result in a
>> valid value.
>
> Your understanding is wrong.
>
> The only real requirement on Ada math is that the resulting values are not 
> used in a way that causes erroneous execution (and there is even an explicit 
> hole allowing that for Unchecked_Conversion). Otherwise, using/producing an 
> "invalid value" is allowed in almost all contexts -- but it is a bounded 
> error so a compiler can raise an exception if it wants.

I'm bothered by this reasoning because it means that Ada compilers
don't have to implement any overflow checks on integer arithmetic.
This is at odds with the existing Ada literature, and existing ACATS
tests (C45632A, for example).

A concrete example: Suppose that A, B are of type Integer, and
Integer'Base has the same range as Integer, and A + B gives a
mathematical result outside this range.  The implementation chooses to
produce an "invalid value" for the result.  During actual execution on
real hardware, it is represented as the lower Integer'Size bits of the
result.  This representation will not cause erroneous execution on its
own, so it passes the test in 13.9.1.

> Also note that "abnormal" is something different from "invalid" (only scalar 
> objects can be invalid).

It's also not clear whether "abnormal" and "not normal" and "invalid"
and "not valid" are equivalent.  (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.)

> Data validity is a very complex subject; you can read 13.9.1 10
> times and get different impressions each time.

I don't think 13.9.1 comes into play at all.  It says what happens
with invalid representations, but doesn't say how they are produced.
(The standard doesn't say much at all about the behavior of Ada
programs if you can invoke 13.9.1 whenever it's convenient.)

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

[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:

If the expression is static, you get the right answer.

If the expression is dynamic, and is within the base range,
you get the right answer.

If the expression is dynamic, and is outside the base range,
either you get the right answer, or it raises Constraint_Error.
It is never required to raise C_E.

> A concrete example: Suppose that A, B are of type Integer, and
> Integer'Base has the same range as Integer, and A + B gives a
> mathematical result outside this range.  The implementation chooses to
> produce an "invalid value" for the result.

OK so far.

>...During actual execution on
> real hardware, it is represented as the lower Integer'Size bits of the
> result.

No, that's not allowed.  If integer is 32 bits, it can store the
result of A+B in a 64-bit register, and not raise C_E.  But it
can't just throw away the high-order bits.

Suppose A+B >= 2**31.  If you say, "if A+B > Integer'Last then...",
then it must either raise C_E or be True.  It can't be False,
because that's a wrong answer.

> It's also not clear whether "abnormal" and "not normal" and "invalid"
> and "not valid" are equivalent.

It's clear to me.  ;-)

I mean, surely the RM doesn't twist the normal meaning of English
THAT badly!

>...(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?

>> Data validity is a very complex subject; you can read 13.9.1 10
>> times and get different impressions each time.
>
> I don't think 13.9.1 comes into play at all.  It says what happens
> with invalid representations, but doesn't say how they are produced.

The main way, which is mentioned in 13.9.1, is to use an uninitialized
variable.

> (The standard doesn't say much at all about the behavior of Ada
> programs if you can invoke 13.9.1 whenever it's convenient.)

- Bob

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

[Florian Weimer]

* 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.

>>...(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.

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

[Robert A Duff]

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

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

[Robert A Duff]

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

> This is at odds with the existing Ada literature, and existing ACATS
> tests (C45632A, for example).

Hmm, I got curious, and looked at C45632A.  It looks wrong, to me.
"EQUAL (ABS I, I)" should return False, or else raise C_E.
The test requires it to return True, or raise C_E.
Maybe they meant "EQUAL (ABS I, - I)".

Or am I misreading this test?

WITH REPORT; USE REPORT;

PROCEDURE C45632A IS

     I : INTEGER := IDENT_INT (INTEGER'FIRST);

BEGIN

     TEST ( "C45632A", "CHECK THAT FOR PREDEFINED TYPE INTEGER " &
                       "CONSTRAINT_ERROR IS RAISED " &
                       "FOR ABS (INTEGER'FIRST) IF -INTEGER'LAST > " &
                       "INTEGER'FIRST" );

     BEGIN
          IF - INTEGER'LAST > INTEGER'FIRST THEN
               BEGIN
                    IF EQUAL (ABS I, I) THEN
                         NULL;
                    ELSE
                         FAILED ( "WRONG RESULT FOR ABS" );
                    END IF;
                    FAILED ( "EXCEPTION NOT RAISED" );
               EXCEPTION
                    WHEN CONSTRAINT_ERROR =>
                         COMMENT ( "CONSTRAINT_ERROR RAISED" );
                    WHEN OTHERS =>
                         FAILED ( "WRONG EXCEPTION RAISED" );
               END;
          ELSE
               COMMENT ( "-INTEGER'LAST <= INTEGER'FIRST" );
          END IF;
     END;

     RESULT;

END C45632A;

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

[Florian Weimer]

* Robert A. Duff:

> Florian Weimer <fw@deneb.enyo.de> writes:
>
>> This is at odds with the existing Ada literature, and existing ACATS
>> tests (C45632A, for example).
>
> Hmm, I got curious, and looked at C45632A.  It looks wrong, to me.
> "EQUAL (ABS I, I)" should return False, or else raise C_E.
> The test requires it to return True, or raise C_E.
> Maybe they meant "EQUAL (ABS I, - I)".

I think the equality test is just there to provide a better failure
message.  With wrap-around semantics, both abs I = I and abs I = -I
are true.  There's still a call to Failed further down, so this
doesn't affect the correctness of the test.

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

[Robert A Duff]

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

> * Robert A. Duff:
>
>> Florian Weimer <fw@deneb.enyo.de> writes:
>>
>>> This is at odds with the existing Ada literature, and existing ACATS
>>> tests (C45632A, for example).
>>
>> Hmm, I got curious, and looked at C45632A.  It looks wrong, to me.
>> "EQUAL (ABS I, I)" should return False, or else raise C_E.
>> The test requires it to return True, or raise C_E.
>> Maybe they meant "EQUAL (ABS I, - I)".
>
> I think the equality test is just there to provide a better failure
> message.  With wrap-around semantics, both abs I = I and abs I = -I
> are true.  

But "EQUAL (ABS I, I)" can return False.  The test calls FAILED
(twice) if it does, so the test is wrong.

>...There's still a call to Failed further down, so this
> doesn't affect the correctness of the test.

Ah, I missed that.  But I still think the test is wrong.

I'm not surprised nobody noticed -- I think most compilers will raise C_E.

- Bob

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

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccsju8fptr.fsf@shell01.TheWorld.com...
> Florian Weimer <fw@deneb.enyo.de> writes:
>
>> * Robert A. Duff:
>>
>>> Florian Weimer <fw@deneb.enyo.de> writes:
>>>
>>>> This is at odds with the existing Ada literature, and existing ACATS
>>>> tests (C45632A, for example).
>>>
>>> Hmm, I got curious, and looked at C45632A.  It looks wrong, to me.
>>> "EQUAL (ABS I, I)" should return False, or else raise C_E.
>>> The test requires it to return True, or raise C_E.
>>> Maybe they meant "EQUAL (ABS I, - I)".
>>
>> I think the equality test is just there to provide a better failure
>> message.  With wrap-around semantics, both abs I = I and abs I = -I
>> are true.
>
> But "EQUAL (ABS I, I)" can return False.  The test calls FAILED
> (twice) if it does, so the test is wrong.

Doesn't that depend on the implementation of EQUAL? It's just a function 
call, it doesn't necessarily have the same semantics as "=". (I think the 
intent is that the result is the same as "=" for valid values, but I doubt 
anything is guaranteed about invalid values.)

The actual implementation of EQUAL is full of recursion (it's intended to be 
an optimization blocker), and it's hard to tell whether or not one of the 
inner calls would cause some other results for invalid values (such as 
raising Constraint_Error).

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.

>>...There's still a call to Failed further down, so this
>> doesn't affect the correctness of the test.
>
> Ah, I missed that.  But I still think the test is wrong.
>
> I'm not surprised nobody noticed -- I think most compilers will raise C_E.

I agree that it doesn't make any sense, because the Failed message is in the 
wrong branch. But since it fails either way it doesn't matter in a 
significant way.

I suspect that there are lot of tests that might fail if the rules for valid 
values are taken to the limit -- any test that intentionally raises an 
exception is always at risk for optimization problems (and that is what 
13.9.1 is ultimately about).

                                    Randy.

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

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> news:wccsju8fptr.fsf@shell01.TheWorld.com...
>> But "EQUAL (ABS I, I)" can return False.  The test calls FAILED
>> (twice) if it does, so the test is wrong.
>
> Doesn't that depend on the implementation of EQUAL? It's just a function 
> call, it doesn't necessarily have the same semantics as "=". (I think the 
> intent is that the result is the same as "=" for valid values, but I doubt 
> anything is guaranteed about invalid values.)
>
> The actual implementation of EQUAL is full of recursion (it's intended to be 
> an optimization blocker), and it's hard to tell whether or not one of the 
> inner calls would cause some other results for invalid values (such as 
> raising Constraint_Error).
>
> 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.

Has EQUAL changed since Ada 83 days?  Just curious.

> I suspect that there are lot of tests that might fail if the rules for valid 
> values are taken to the limit -- any test that intentionally raises an 
> exception is always at risk for optimization problems (and that is what 
> 13.9.1 is ultimately about).

Yes, and I'll bet an agressive implementation of 11.6 would find some
wrong ACATS tests.

- Bob

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

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcc39m5u64w.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
...
> 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.

I did inspect it, and proved to myself that I had no idea what it actually 
does. :-)

I do think the intent was that it returns the equal result, but that isn't 
documented anywhere (although it might be in the super-secret manual --  
nobody reads that, including me. :-)

> Has EQUAL changed since Ada 83 days?  Just curious.

I don't think so. The change log consists of lots of entries "Updated ACATS 
version string to "3.0"". The last substantive change is some functions 
added in June 1995; no changelog entry mentions Equal.

>> I suspect that there are lot of tests that might fail if the rules for 
>> valid
>> values are taken to the limit -- any test that intentionally raises an
>> exception is always at risk for optimization problems (and that is what
>> 13.9.1 is ultimately about).
>
> Yes, and I'll bet an agressive implementation of 11.6 would find some
> wrong ACATS tests.

That of course has happened a lot in the past. Fewer implementors are 
reporting anything these days, which probably only means that there is less 
active implementation.

                                 Randy.

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

[Adam Beneschan]

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.  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.  [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.]

                                     -- Adam

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

[Robert A Duff]

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

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

[Adam Beneschan]

On Mar 30, 5:57 am, Robert A Duff <bobd...@shell01.TheWorld.com>
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).  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.

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=Integer'First.

                             -- Adam

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

[Robert A Duff]

Adam Beneschan <adam@irvine.com> writes:

> 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.

3.5.4(24) says you can always get the right answer.
But now that I think about it, I'm not entirely sure how this relates
to invalid values.  And I'm too busy to reread the chap 13 stuff
right now -- as Randy said, it's complicated.

- Bob

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

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcc62r022b4.fsf@shell01.TheWorld.com...
...
> 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.

You don't need to imagine it. Janus/Ada does that (presuming you replace 32 
by 16 and 64 by 32 in the above writeup). But I believe that we always 
ensure parameters are valid, so that implies a check when the parameter is 
passed to EQUAL, in the absence of any earlier check.

                                            Randy.

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

[ytomino]

In definition of builtin-functions:

http://gcc.gnu.org/viewcvs/trunk/gcc/builtins.def?view=markup
> DEF_C99_C90RES_BUILTIN (BUILT_IN_ISINF, "isinf", BT_FN_INT_VAR, ATTR_CONST_NOTHROW_TYPEGENERIC)
> DEF_EXT_LIB_BUILTIN    (BUILT_IN_ISINFF, "isinff", BT_FN_INT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
> DEF_EXT_LIB_BUILTIN    (BUILT_IN_ISINFL, "isinfl", BT_FN_INT_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)

isinf has a "VAR" argument, it means overload,
and isinff has an argument that is just float.

This means,  we can call isinff and isinfl, but can not call isinf
(for double as Long_Float) from Ada. Is it right?

It seems to me that the compiler shall accept isinf(double only).

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

[Florian Weimer]

* ytomino:

> In definition of builtin-functions:
>
> http://gcc.gnu.org/viewcvs/trunk/gcc/builtins.def?view=markup
>> DEF_C99_C90RES_BUILTIN (BUILT_IN_ISINF, "isinf", BT_FN_INT_VAR, ATTR_CONST_NOTHROW_TYPEGENERIC)
>> DEF_EXT_LIB_BUILTIN    (BUILT_IN_ISINFF, "isinff", BT_FN_INT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
>> DEF_EXT_LIB_BUILTIN    (BUILT_IN_ISINFL, "isinfl", BT_FN_INT_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
>
> isinf has a "VAR" argument, it means overload,
> and isinff has an argument that is just float.
>
> This means,  we can call isinff and isinfl, but can not call isinf
> (for double as Long_Float) from Ada. Is it right?

I believe the compiler will resolve the overload internally, but I'm
not sure.

> It seems to me that the compiler shall accept isinf(double only).

I think you mean "isinfl", but that should be accepted.

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

[anon]

In <b7736fb9-8593-47cc-9ac5-58a95ff6be5f@34g2000pru.googlegroups.com>, ytomino <aghia05@gmail.com> writes:
>Hello.
>gcc-4.6.0 was released!
>I'm trying to compile my code with gcc-4.6.0,
>and I found a strange warning at using built-in functions of gcc.
>
>The minimal code is here:
>
>with Ada.Text_IO;
>procedure test1 is
>   function isfinite (X : Long_Float) return Integer;
>   pragma Import (Intrinsic, isfinite, "__builtin_isfinite");
>begin
>   -- 10 is finite value, it puts 1
>   Ada.Text_IO.Put_Line (Integer'Image (
>      isfinite (Long_Float'Value ("10"))));
>   -- 10 / 0 is infinite, it puts 0
>   Ada.Text_IO.Put_Line (Integer'Image (
>      isfinite (Long_Float'Value ("10") / Long_Float'Value ("0"))));
>end test1;
>
>$ /usr/local/bin/gcc-4.5.2/gnatmake test1
>gcc -c test1.adb
>gnatbind -x test1.ali
>gnatlink test1.ali
>~/projects/exam/ada/compiler/builtin
>$ /usr/local/bin/gcc-4.6.0/gnatmake test1
>gcc -c test1.adb
>test1.adb:3:13: warning: profile of "isfinite" doesn't match the
>builtin it binds <- this warning
>gnatbind -x test1.ali
>gnatlink test1.ali
>
>I tried changing the prototype again and again,
>
>   function isfinite (X : Long_Float) return Integer;
>   function isfinite (X : Long_Float) return Boolean;
>   function isfinite (X : Float) return Integer;
>   function isfinite (X : Long_Long_Float) return Integer;
>   ...etc...
>
>but I could not erase this warning... Can anyone erase this warning ?
>
>Thank you.
>
>--
>Yuta Tomino

Try replacing with 
   pragma Import (Intrinsic, isfinite, "__builtin_isfinite");
with
   pragma Import (C, isfinite, "__builtin_isfinite");

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

[ytomino]

On Mar 27, 7:22 am, a...@att.net wrote:
> Try replacing with
>    pragma Import (Intrinsic, isfinite, "__builtin_isfinite");
> with
>    pragma Import (C, isfinite, "__builtin_isfinite");

$ /usr/local/bin/gcc-4.6.0/gnatmake test1
gcc -c test1.adb
gnatbind -x test1.ali
gnatlink test1.ali
Undefined symbols:
  "___builtin_isfinite", referenced from:
      __ada_test1 in test1.o
      __ada_test1 in test1.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
gnatlink: error when calling /usr/local/bin/gcc-4.6.0/gcc
gnatmake: *** link failed.

__builtin_* is magic function of gcc, not library function.

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

[anon]

In <380fc033-6f6f-4e69-9371-89610c9c5d77@r19g2000prm.googlegroups.com>, ytomino <aghia05@gmail.com> writes:
>On Mar 27, 7:22=A0am, a...@att.net wrote:
>> Try replacing with
>> =A0 =A0pragma Import (Intrinsic, isfinite, "__builtin_isfinite");
>> with
>> =A0 =A0pragma Import (C, isfinite, "__builtin_isfinite");
>
>$ /usr/local/bin/gcc-4.6.0/gnatmake test1
>gcc -c test1.adb
>gnatbind -x test1.ali
>gnatlink test1.ali
>Undefined symbols:
>  "___builtin_isfinite", referenced from:
>      __ada_test1 in test1.o
>      __ada_test1 in test1.o
>ld: symbol(s) not found
>collect2: ld returned 1 exit status
>gnatlink: error when calling /usr/local/bin/gcc-4.6.0/gcc
>gnatmake: *** link failed.
>
>__builtin_* is magic function of gcc, not library function.

Using C you may need to also change the first underscore or remove both
such as 

  pragma Import (C, isfinite, "_builtin_isfinite");
or
  pragma Import (C, isfinite, "builtin_isfinite");

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

[ytomino]

On Mar 27, 9:00 pm, a...@att.net wrote:
> Using C you may need to also change the first underscore or remove both
> such as
>
>   pragma Import (C, isfinite, "_builtin_isfinite");

$ /usr/local/bin/gcc-4.6.0/gnatmake test1
gcc -c test1.adb
gnatbind -x test1.ali
gnatlink test1.ali
Undefined symbols:
  "__builtin_isfinite", referenced from:
      __ada_test1 in test1.o
      __ada_test1 in test1.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
gnatlink: error when calling /usr/local/bin/gcc-4.6.0/gcc
gnatmake: *** link failed.

> or
>   pragma Import (C, isfinite, "builtin_isfinite");

$ /usr/local/bin/gcc-4.6.0/gnatmake test1
gcc -c test1.adb
gnatbind -x test1.ali
gnatlink test1.ali
Undefined symbols:
  "_builtin_isfinite", referenced from:
      __ada_test1 in test1.o
      __ada_test1 in test1.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
gnatlink: error when calling /usr/local/bin/gcc-4.6.0/gcc
gnatmake: *** link failed.

In the first, libc.a (or libm.a) does not have the body of "isfinite"
function.
gcc expands builtin-functions to inline-assembly code.
To tell the truth, libm.a has "_isfinite", but that is unused to call
"__builtin_isfinite".
Please make sure with nm.

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

[anon]

In <0ea88302-a755-4a61-bf5b-728469c9d5d2@34g2000pru.googlegroups.com>, ytomino <aghia05@gmail.com> writes:
>On Mar 27, 9:00=A0pm, a...@att.net wrote:
>> Using C you may need to also change the first underscore or remove both
>> such as
>>
>> =A0 pragma Import (C, isfinite, "_builtin_isfinite");
>
>$ /usr/local/bin/gcc-4.6.0/gnatmake test1
>gcc -c test1.adb
>gnatbind -x test1.ali
>gnatlink test1.ali
>Undefined symbols:
>  "__builtin_isfinite", referenced from:
>      __ada_test1 in test1.o
>      __ada_test1 in test1.o
>ld: symbol(s) not found
>collect2: ld returned 1 exit status
>gnatlink: error when calling /usr/local/bin/gcc-4.6.0/gcc
>gnatmake: *** link failed.
>
>> or
>> =A0 pragma Import (C, isfinite, "builtin_isfinite");
>
>$ /usr/local/bin/gcc-4.6.0/gnatmake test1
>gcc -c test1.adb
>gnatbind -x test1.ali
>gnatlink test1.ali
>Undefined symbols:
>  "_builtin_isfinite", referenced from:
>      __ada_test1 in test1.o
>      __ada_test1 in test1.o
>ld: symbol(s) not found
>collect2: ld returned 1 exit status
>gnatlink: error when calling /usr/local/bin/gcc-4.6.0/gcc
>gnatmake: *** link failed.
>
>In the first, libc.a (or libm.a) does not have the body of "isfinite"
>function.
>gcc expands builtin-functions to inline-assembly code.
>To tell the truth, libm.a has "_isfinite", but that is unused to call
>"__builtin_isfinite".
>Please make sure with nm.
The problem with builtin routines is that you need to write a C interface 
routine that is called by Ada and then that routine calls the 
"__builtin_isfinite" macro. Such as:

   function isfinite ( X : Long_Float ) return Integer;
   pragma Import ( C, isfinite, "_gnat_builtin_isfinite" ) ;


/* 
 * File: builtin.c
 * the C code 
 */
void _gnat_builtin_isfinite ( x )
     long x ;
  {
    __builtin_isfinite ( x ) ;
  }


to compile 
  gcc -c builtin.c
  gnat make <program>.adb   -largs builtin.o
or
  gnat link <program>.ali builtin.o


But the easiest way is just use Ada:

   function isfinite ( S : Long_Float ) return Boolean ;


   function isfinite ( S : Long_Float ) return Boolean ;
      
     begin
  
       -- IEEE 754 standards
      
       If S'Exponent = -1 and S'Fraction = 0 Then
         return True ;
       end if ;            
       return False ;

     end isfinite ;

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

[anon]

In <0ea88302-a755-4a61-bf5b-728469c9d5d2@34g2000pru.googlegroups.com>, ytomino <aghia05@gmail.com> writes:
>On Mar 27, 9:00=A0pm, a...@att.net wrote:
>> Using C you may need to also change the first underscore or remove both
>> such as
>>
>> =A0 pragma Import (C, isfinite, "_builtin_isfinite");
>
>$ /usr/local/bin/gcc-4.6.0/gnatmake test1
>gcc -c test1.adb
>gnatbind -x test1.ali
>gnatlink test1.ali
>Undefined symbols:
>  "__builtin_isfinite", referenced from:
>      __ada_test1 in test1.o
>      __ada_test1 in test1.o
>ld: symbol(s) not found
>collect2: ld returned 1 exit status
>gnatlink: error when calling /usr/local/bin/gcc-4.6.0/gcc
>gnatmake: *** link failed.
>
>> or
>> =A0 pragma Import (C, isfinite, "builtin_isfinite");
>
>$ /usr/local/bin/gcc-4.6.0/gnatmake test1
>gcc -c test1.adb
>gnatbind -x test1.ali
>gnatlink test1.ali
>Undefined symbols:
>  "_builtin_isfinite", referenced from:
>      __ada_test1 in test1.o
>      __ada_test1 in test1.o
>ld: symbol(s) not found
>collect2: ld returned 1 exit status
>gnatlink: error when calling /usr/local/bin/gcc-4.6.0/gcc
>gnatmake: *** link failed.
>
>In the first, libc.a (or libm.a) does not have the body of "isfinite"
>function.
>gcc expands builtin-functions to inline-assembly code.
>To tell the truth, libm.a has "_isfinite", but that is unused to call
>"__builtin_isfinite".
>Please make sure with nm.

forgot tyo make the c code a function:

int _gnat_builtin_isfinite ( x )
    long x ;
 {
  return __builtin_isfinite ( x ) ;
 }