* What is the warning about builtin-function on gcc-4.6.0 ? @ 2011-03-26 6:32 ytomino 2011-03-26 8:45 ` Florian Weimer 2011-03-26 22:22 ` anon 0 siblings, 2 replies; 39+ messages in thread From: ytomino @ 2011-03-26 6:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-26 6:32 What is the warning about builtin-function on gcc-4.6.0 ? ytomino @ 2011-03-26 8:45 ` Florian Weimer 2011-03-26 9:13 ` ytomino 2011-03-26 22:22 ` anon 1 sibling, 1 reply; 39+ messages in thread From: Florian Weimer @ 2011-03-26 8:45 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-26 8:45 ` Florian Weimer @ 2011-03-26 9:13 ` ytomino 2011-03-26 9:43 ` Florian Weimer 0 siblings, 1 reply; 39+ messages in thread From: ytomino @ 2011-03-26 9:13 UTC (permalink / raw) 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 ? ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-26 9:13 ` ytomino @ 2011-03-26 9:43 ` Florian Weimer 2011-03-26 10:07 ` ytomino 2011-03-26 21:58 ` ytomino 0 siblings, 2 replies; 39+ messages in thread From: Florian Weimer @ 2011-03-26 9:43 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-26 9:43 ` Florian Weimer @ 2011-03-26 10:07 ` ytomino 2011-03-26 10:24 ` Florian Weimer 2011-03-26 14:50 ` Simon Wright 2011-03-26 21:58 ` ytomino 1 sibling, 2 replies; 39+ messages in thread From: ytomino @ 2011-03-26 10:07 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-26 10:07 ` ytomino @ 2011-03-26 10:24 ` Florian Weimer 2011-03-26 15:14 ` Dmitry A. Kazakov 2011-03-26 14:50 ` Simon Wright 1 sibling, 1 reply; 39+ messages in thread From: Florian Weimer @ 2011-03-26 10:24 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-26 10:24 ` Florian Weimer @ 2011-03-26 15:14 ` Dmitry A. Kazakov 2011-03-26 21:36 ` ytomino 0 siblings, 1 reply; 39+ messages in thread From: Dmitry A. Kazakov @ 2011-03-26 15:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-26 15:14 ` Dmitry A. Kazakov @ 2011-03-26 21:36 ` ytomino 2011-03-27 9:50 ` Dmitry A. Kazakov 0 siblings, 1 reply; 39+ messages in thread From: ytomino @ 2011-03-26 21:36 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-26 21:36 ` ytomino @ 2011-03-27 9:50 ` Dmitry A. Kazakov 0 siblings, 0 replies; 39+ messages in thread From: Dmitry A. Kazakov @ 2011-03-27 9:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-26 10:07 ` ytomino 2011-03-26 10:24 ` Florian Weimer @ 2011-03-26 14:50 ` Simon Wright 2011-03-26 15:50 ` Florian Weimer 1 sibling, 1 reply; 39+ messages in thread From: Simon Wright @ 2011-03-26 14:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-26 14:50 ` Simon Wright @ 2011-03-26 15:50 ` Florian Weimer 2011-03-26 16:32 ` Simon Wright 0 siblings, 1 reply; 39+ messages in thread From: Florian Weimer @ 2011-03-26 15:50 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-26 15:50 ` Florian Weimer @ 2011-03-26 16:32 ` Simon Wright 2011-03-26 17:02 ` Florian Weimer 0 siblings, 1 reply; 39+ messages in thread From: Simon Wright @ 2011-03-26 16:32 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-26 16:32 ` Simon Wright @ 2011-03-26 17:02 ` Florian Weimer 2011-03-26 17:48 ` Simon Wright 2011-03-27 2:08 ` Randy Brukardt 0 siblings, 2 replies; 39+ messages in thread From: Florian Weimer @ 2011-03-26 17:02 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-26 17:02 ` Florian Weimer @ 2011-03-26 17:48 ` Simon Wright 2011-03-26 18:48 ` Florian Weimer 2011-03-27 2:08 ` Randy Brukardt 1 sibling, 1 reply; 39+ messages in thread From: Simon Wright @ 2011-03-26 17:48 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-26 17:48 ` Simon Wright @ 2011-03-26 18:48 ` Florian Weimer 0 siblings, 0 replies; 39+ messages in thread From: Florian Weimer @ 2011-03-26 18:48 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-26 17:02 ` Florian Weimer 2011-03-26 17:48 ` Simon Wright @ 2011-03-27 2:08 ` Randy Brukardt 2011-03-27 8:37 ` Florian Weimer 1 sibling, 1 reply; 39+ messages in thread From: Randy Brukardt @ 2011-03-27 2:08 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-27 2:08 ` Randy Brukardt @ 2011-03-27 8:37 ` Florian Weimer 2011-03-27 16:41 ` Robert A Duff 2011-03-27 16:51 ` Robert A Duff 0 siblings, 2 replies; 39+ messages in thread From: Florian Weimer @ 2011-03-27 8:37 UTC (permalink / raw) * 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.) ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-27 8:37 ` Florian Weimer @ 2011-03-27 16:41 ` Robert A Duff 2011-03-27 17:21 ` Florian Weimer 2011-03-27 16:51 ` Robert A Duff 1 sibling, 1 reply; 39+ messages in thread From: Robert A Duff @ 2011-03-27 16:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-27 16:41 ` Robert A Duff @ 2011-03-27 17:21 ` Florian Weimer 2011-03-27 17:56 ` Robert A Duff 0 siblings, 1 reply; 39+ messages in thread From: Florian Weimer @ 2011-03-27 17:21 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-27 17:21 ` Florian Weimer @ 2011-03-27 17:56 ` Robert A Duff 0 siblings, 0 replies; 39+ messages in thread From: Robert A Duff @ 2011-03-27 17:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-27 8:37 ` Florian Weimer 2011-03-27 16:41 ` Robert A Duff @ 2011-03-27 16:51 ` Robert A Duff 2011-03-27 17:05 ` Florian Weimer 1 sibling, 1 reply; 39+ messages in thread From: Robert A Duff @ 2011-03-27 16:51 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-27 16:51 ` Robert A Duff @ 2011-03-27 17:05 ` Florian Weimer 2011-03-27 17:14 ` Robert A Duff 0 siblings, 1 reply; 39+ messages in thread From: Florian Weimer @ 2011-03-27 17:05 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-27 17:05 ` Florian Weimer @ 2011-03-27 17:14 ` Robert A Duff 2011-03-29 2:20 ` Randy Brukardt 0 siblings, 1 reply; 39+ messages in thread From: Robert A Duff @ 2011-03-27 17:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-27 17:14 ` Robert A Duff @ 2011-03-29 2:20 ` Randy Brukardt 2011-03-29 18:35 ` Robert A Duff 0 siblings, 1 reply; 39+ messages in thread From: Randy Brukardt @ 2011-03-29 2:20 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-29 2:20 ` Randy Brukardt @ 2011-03-29 18:35 ` Robert A Duff 2011-03-29 23:35 ` Randy Brukardt 2011-03-30 1:02 ` Adam Beneschan 0 siblings, 2 replies; 39+ messages in thread From: Robert A Duff @ 2011-03-29 18:35 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-29 18:35 ` Robert A Duff @ 2011-03-29 23:35 ` Randy Brukardt 2011-03-30 1:02 ` Adam Beneschan 1 sibling, 0 replies; 39+ messages in thread From: Randy Brukardt @ 2011-03-29 23:35 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-29 18:35 ` Robert A Duff 2011-03-29 23:35 ` Randy Brukardt @ 2011-03-30 1:02 ` Adam Beneschan 2011-03-30 12:57 ` Robert A Duff 1 sibling, 1 reply; 39+ messages in thread From: Adam Beneschan @ 2011-03-30 1:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-30 1:02 ` Adam Beneschan @ 2011-03-30 12:57 ` Robert A Duff 2011-03-30 14:41 ` Adam Beneschan 2011-03-30 19:28 ` Randy Brukardt 0 siblings, 2 replies; 39+ messages in thread From: Robert A Duff @ 2011-03-30 12:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-30 12:57 ` Robert A Duff @ 2011-03-30 14:41 ` Adam Beneschan 2011-03-30 18:39 ` Robert A Duff 2011-03-30 19:28 ` Randy Brukardt 1 sibling, 1 reply; 39+ messages in thread From: Adam Beneschan @ 2011-03-30 14:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-30 14:41 ` Adam Beneschan @ 2011-03-30 18:39 ` Robert A Duff 0 siblings, 0 replies; 39+ messages in thread From: Robert A Duff @ 2011-03-30 18:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-30 12:57 ` Robert A Duff 2011-03-30 14:41 ` Adam Beneschan @ 2011-03-30 19:28 ` Randy Brukardt 1 sibling, 0 replies; 39+ messages in thread From: Randy Brukardt @ 2011-03-30 19:28 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-26 9:43 ` Florian Weimer 2011-03-26 10:07 ` ytomino @ 2011-03-26 21:58 ` ytomino 2011-03-26 22:00 ` Florian Weimer 1 sibling, 1 reply; 39+ messages in thread From: ytomino @ 2011-03-26 21:58 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-26 21:58 ` ytomino @ 2011-03-26 22:00 ` Florian Weimer 0 siblings, 0 replies; 39+ messages in thread From: Florian Weimer @ 2011-03-26 22:00 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-26 6:32 What is the warning about builtin-function on gcc-4.6.0 ? ytomino 2011-03-26 8:45 ` Florian Weimer @ 2011-03-26 22:22 ` anon 2011-03-26 22:36 ` ytomino 1 sibling, 1 reply; 39+ messages in thread From: anon @ 2011-03-26 22:22 UTC (permalink / raw) 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"); ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-26 22:22 ` anon @ 2011-03-26 22:36 ` ytomino 2011-03-27 12:00 ` anon 0 siblings, 1 reply; 39+ messages in thread From: ytomino @ 2011-03-26 22:36 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-26 22:36 ` ytomino @ 2011-03-27 12:00 ` anon 2011-03-27 18:50 ` ytomino 0 siblings, 1 reply; 39+ messages in thread From: anon @ 2011-03-27 12:00 UTC (permalink / raw) 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"); ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-27 12:00 ` anon @ 2011-03-27 18:50 ` ytomino 2011-03-27 23:35 ` anon 2011-03-27 23:42 ` anon 0 siblings, 2 replies; 39+ messages in thread From: ytomino @ 2011-03-27 18:50 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-27 18:50 ` ytomino @ 2011-03-27 23:35 ` anon 2011-03-27 23:42 ` anon 1 sibling, 0 replies; 39+ messages in thread From: anon @ 2011-03-27 23:35 UTC (permalink / raw) 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 ; ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: What is the warning about builtin-function on gcc-4.6.0 ? 2011-03-27 18:50 ` ytomino 2011-03-27 23:35 ` anon @ 2011-03-27 23:42 ` anon 1 sibling, 0 replies; 39+ messages in thread From: anon @ 2011-03-27 23:42 UTC (permalink / raw) 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 ) ; } ^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2011-03-30 19:28 UTC | newest] Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-03-26 6:32 What is the warning about builtin-function on gcc-4.6.0 ? ytomino 2011-03-26 8:45 ` Florian Weimer 2011-03-26 9:13 ` ytomino 2011-03-26 9:43 ` Florian Weimer 2011-03-26 10:07 ` ytomino 2011-03-26 10:24 ` Florian Weimer 2011-03-26 15:14 ` Dmitry A. Kazakov 2011-03-26 21:36 ` ytomino 2011-03-27 9:50 ` Dmitry A. Kazakov 2011-03-26 14:50 ` Simon Wright 2011-03-26 15:50 ` Florian Weimer 2011-03-26 16:32 ` Simon Wright 2011-03-26 17:02 ` Florian Weimer 2011-03-26 17:48 ` Simon Wright 2011-03-26 18:48 ` Florian Weimer 2011-03-27 2:08 ` Randy Brukardt 2011-03-27 8:37 ` Florian Weimer 2011-03-27 16:41 ` Robert A Duff 2011-03-27 17:21 ` Florian Weimer 2011-03-27 17:56 ` Robert A Duff 2011-03-27 16:51 ` Robert A Duff 2011-03-27 17:05 ` Florian Weimer 2011-03-27 17:14 ` Robert A Duff 2011-03-29 2:20 ` Randy Brukardt 2011-03-29 18:35 ` Robert A Duff 2011-03-29 23:35 ` Randy Brukardt 2011-03-30 1:02 ` Adam Beneschan 2011-03-30 12:57 ` Robert A Duff 2011-03-30 14:41 ` Adam Beneschan 2011-03-30 18:39 ` Robert A Duff 2011-03-30 19:28 ` Randy Brukardt 2011-03-26 21:58 ` ytomino 2011-03-26 22:00 ` Florian Weimer 2011-03-26 22:22 ` anon 2011-03-26 22:36 ` ytomino 2011-03-27 12:00 ` anon 2011-03-27 18:50 ` ytomino 2011-03-27 23:35 ` anon 2011-03-27 23:42 ` anon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox