Hi, When building 4.6.1 on armv5tel platform, `make check` finishes with the following: ------------ TEST 5 (compiler generating C code) rm -f mix.c LD_LIBRARY_PATH=../lib:../gsi:../gsc: ../gsc/gsc -:d-,~~bin=../bin,~~lib=../lib,~~include=../include -f -c mix.scm diff test5.ok mix.c 1781c1781 < ___DEF_SUB_FLO(___X17,-0x1L,-0x1L) ---
___DEF_SUB_FLO(___X17,0x7fffffffL,-0x1L) make: *** [test5] Error 1
Is it critical? Regards, Paul.
Afficher les réponses par date
On 2011-10-19, at 9:52 AM, Paul Wolneykien wrote:
Hi,
When building 4.6.1 on armv5tel platform, `make check` finishes with the following:
------------ TEST 5 (compiler generating C code) rm -f mix.c LD_LIBRARY_PATH=../lib:../gsi:../gsc: ../gsc/gsc -:d-,~~bin=../bin,~~lib=../lib,~~include=../include -f -c mix.scm diff test5.ok mix.c 1781c1781 < ___DEF_SUB_FLO(___X17,-0x1L,-0x1L) ---
___DEF_SUB_FLO(___X17,0x7fffffffL,-0x1L) make: *** [test5] Error 1
Is it critical?
It is not critical, but I will look into it. My guess is that this is a difference in the representation of the constant +NaN.0 (it seems the sign is different on ARM). Marc
As far as I can tell it is a problem with the sign of NaN. On my system, an x86 Mac, it seems that NaN has a negative sign: % gsc Gambit v4.6.1
(c#targ-float->exact-exponential-format (/ 0.0 0.0) #f) #(16777215 105 -1) (c#targ-float->exact-exponential-format (/ 0.0 0.0) #t) #(9007199254740991 972 -1)
Can you try to evaluate those two expressions with gsc and report the values you get? I think the solution would be to normalize the representation so that on all systems the binary representation of NaN in the generated C code is the same. Marc On 2011-10-19, at 9:52 AM, Paul Wolneykien wrote:
Hi,
When building 4.6.1 on armv5tel platform, `make check` finishes with the following:
------------ TEST 5 (compiler generating C code) rm -f mix.c LD_LIBRARY_PATH=../lib:../gsi:../gsc: ../gsc/gsc -:d-,~~bin=../bin,~~lib=../lib,~~include=../include -f -c mix.scm diff test5.ok mix.c 1781c1781 < ___DEF_SUB_FLO(___X17,-0x1L,-0x1L) ---
___DEF_SUB_FLO(___X17,0x7fffffffL,-0x1L) make: *** [test5] Error 1
Is it critical?
Regards,
Paul.
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
On Thu, 2011-10-20 at 14:55 -0400, Marc Feeley wrote:
I think the solution would be to normalize the representation so that on all systems the binary representation of NaN in the generated C code is the same.
Marc: It's not good to encourage people to think that there's only one NaN per system. Apple's runtime library used to return different NaNs to indicate what function was the initial cause of the NaN, etc. Some runtime libraries still may do so. The failing Test 5 comes up periodically (I'm sure we discussed this sign of NaN issue years ago); perhaps it would be best to just add some documentation to explain the failure, or make the diff ignore that one line. Brad
On 2011-10-20, at 3:02 PM, Bradley Lucier wrote:
On Thu, 2011-10-20 at 14:55 -0400, Marc Feeley wrote:
I think the solution would be to normalize the representation so that on all systems the binary representation of NaN in the generated C code is the same.
Marc:
It's not good to encourage people to think that there's only one NaN per system. Apple's runtime library used to return different NaNs to indicate what function was the initial cause of the NaN, etc. Some runtime libraries still may do so.
The failing Test 5 comes up periodically (I'm sure we discussed this sign of NaN issue years ago); perhaps it would be best to just add some documentation to explain the failure, or make the diff ignore that one line.
Brad
My point is that the compilation of Scheme to C by gsc should not expose machine dependencies. When the user writes +nan.0 in the Scheme code and compiles it to C, the C code should use the same IEEE NaN bit pattern regardless of the platform used to compile the Scheme program. That way the C code will be completely portable. When code is executed, perhaps different bit patterns will be generated for the various NaNs computed, and this might depend on the platform the code runs on. I have no problem with that. Marc
On Oct 20, 2011, at 3:27 PM, Marc Feeley wrote:
My point is that the compilation of Scheme to C by gsc should not expose machine dependencies. When the user writes +nan.0 in the Scheme code and compiles it to C, the C code should use the same IEEE NaN bit pattern regardless of the platform used to compile the Scheme program. That way the C code will be completely portable.
Perhaps +nan.0 (and perhaps other system-dependent constants) should always be computed at load time for the module.
On 2011-10-20, at 3:39 PM, Bradley Lucier wrote:
On Oct 20, 2011, at 3:27 PM, Marc Feeley wrote:
My point is that the compilation of Scheme to C by gsc should not expose machine dependencies. When the user writes +nan.0 in the Scheme code and compiles it to C, the C code should use the same IEEE NaN bit pattern regardless of the platform used to compile the Scheme program. That way the C code will be completely portable.
Perhaps +nan.0 (and perhaps other system-dependent constants) should always be computed at load time for the module.
Perhaps, but how do you recreate the NaN that was compiled? It is much simpler to normalize NaNs to a unique bit pattern. Marc
On Oct 20, 2011, at 3:42 PM, Marc Feeley wrote:
On 2011-10-20, at 3:39 PM, Bradley Lucier wrote:
Perhaps +nan.0 (and perhaps other system-dependent constants) should always be computed at load time for the module.
Perhaps, but how do you recreate the NaN that was compiled?
But why would you want to? On one machine, it might be a signaling NaN, on another, it might be silent. It's like the difference between the host and target machine with gcc. Brad
On 2011-10-20, at 5:54 PM, Bradley Lucier wrote:
On Oct 20, 2011, at 3:42 PM, Marc Feeley wrote:
On 2011-10-20, at 3:39 PM, Bradley Lucier wrote:
Perhaps +nan.0 (and perhaps other system-dependent constants) should always be computed at load time for the module.
Perhaps, but how do you recreate the NaN that was compiled?
But why would you want to?
So that gsc is a function of one argument: from Scheme source code to C source code, i.e. Scheme_source -> C_source instead of Scheme_source * platform -> C_source
On one machine, it might be a signaling NaN, on another, it might be silent.
But there is just one +nan.0 available in Scheme source code. We are talking about the representation of this NaN, not all possible NaNs. Portability is one of the primary objectives of Gambit. If the platform becomes an implicit parameter of gsc, then Scheme code compiled to C on one platform, will not work in all cases on another. For example, gsc could have been designed to require the compilation platform and the target platform to have the same word width, but that would limit its use. Moreover, it wouldn't be possible to distribute Gambit as a set of C generated files, and expect it to work on all platforms. Same goes for endianness. Having a normalized representation for +nan.0 is consistent with portability. Perhaps I'm missing something... can you explain a use case where it would be interesting for gsc to preserve a particular bit pattern for NaNs? Marc
On Thu, 2011-10-20 at 19:40 -0400, Marc Feeley wrote:
On 2011-10-20, at 5:54 PM, Bradley Lucier wrote:
On Oct 20, 2011, at 3:42 PM, Marc Feeley wrote:
On 2011-10-20, at 3:39 PM, Bradley Lucier wrote:
Perhaps +nan.0 (and perhaps other system-dependent constants) should always be computed at load time for the module.
Perhaps, but how do you recreate the NaN that was compiled?
But why would you want to?
So that gsc is a function of one argument: from Scheme source code to C source code, i.e.
Scheme_source -> C_source
instead of
Scheme_source * platform -> C_source
On one machine, it might be a signaling NaN, on another, it might be silent.
But there is just one +nan.0 available in Scheme source code.
There is only one lexical symbol "+nan.0" in (Gambit) scheme code. In my opinion it should represent a generic NaN on the machine where the code is running. At load time a NaN can be boxed up and bound to +nan.0.
We are talking about the representation of this NaN, not all possible NaNs.
I don't know what you mean "this NaN". On output, this symbol is used for any NaN that is given to display. There is no "this NaN". Some on the R7RS committee have said explicitly that they think that there is "one NaN", and then this leads to problems. As you say, gsc shouldn't use the bit representation of a specific NaN on the machine where gsc is running. But if you fix a bit pattern for the NaN generated by gsc, then that NaN may be interpreted differently when the code is running on different machines. (It may be signalling on one machine, and non-signalling on another.) Anyway, it's not that important. Your solution has the great benefit of not having people worry about test failures that are not that important. I've argued before (to little avail) that the notation for NaNs in scheme should allow the programmer to specify the sign and the (nonzero) mantissa of a NaN, and that those quantities should be displayed by "display". Brad
20.10.2011 22:55, Marc Feeley пишет:
As far as I can tell it is a problem with the sign of NaN.
It seems so. On my system, an x86 Mac, it seems that NaN has a negative sign:
% gsc Gambit v4.6.1
(c#targ-float->exact-exponential-format (/ 0.0 0.0) #f) #(16777215 105 -1) (c#targ-float->exact-exponential-format (/ 0.0 0.0) #t) #(9007199254740991 972 -1)
Can you try to evaluate those two expressions with gsc and report the values you get?
(c#targ-float->exact-exponential-format (/ 0.0 0.0) #f) #(16777215 105 1) (c#targ-float->exact-exponential-format (/ 0.0 0.0) #t) #(9007199254740991 972 1)
I think the solution would be to normalize the representation so that on all systems the binary representation of NaN in the generated C code is the same.
Should the generated C code necessary be portable? IMHO, if it is not the goal, it isn't critical to have the same things on all platforms in C. However, the C test for a NaN value should give correct results on the platform it was compiled.
Marc
On 2011-10-19, at 9:52 AM, Paul Wolneykien wrote:
Hi,
When building 4.6.1 on armv5tel platform, `make check` finishes with the following:
------------ TEST 5 (compiler generating C code) rm -f mix.c LD_LIBRARY_PATH=../lib:../gsi:../gsc: ../gsc/gsc -:d-,~~bin=../bin,~~lib=../lib,~~include=../include -f -c mix.scm diff test5.ok mix.c 1781c1781 < ___DEF_SUB_FLO(___X17,-0x1L,-0x1L) ---
___DEF_SUB_FLO(___X17,0x7fffffffL,-0x1L) make: *** [test5] Error 1
Is it critical?
Regards,
Paul.
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
On 2011-10-20, at 3:28 PM, Paul Wolneykien wrote:
20.10.2011 22:55, Marc Feeley пишет:
As far as I can tell it is a problem with the sign of NaN.
It seems so.
Very well. I have now added code in the compiler to normalize the bit pattern of +nan.0 . Note that in the C code generated the non-sign bits are all equal to 1 regardless of the machine bit pattern for the NaN being "dumped" to C. So forcing the sign bit to 1 is consistent with this. The new code is on the repo. Please give it a try to see if test5 passes. Marc
20.10.2011 23:48, Marc Feeley пишет:
On 2011-10-20, at 3:28 PM, Paul Wolneykien wrote:
20.10.2011 22:55, Marc Feeley пишет:
As far as I can tell it is a problem with the sign of NaN.
It seems so.
Very well. I have now added code in the compiler to normalize the bit pattern of +nan.0 . Note that in the C code generated the non-sign bits are all equal to 1 regardless of the machine bit pattern for the NaN being "dumped" to C. So forcing the sign bit to 1 is consistent with this.
The new code is on the repo. Please give it a try to see if test5 passes.
Thanks, Marc. I applied the patch to the v4.6.1 (having 4.6.0 I have to build that version first). It compiles fine and all of the tests are passed now.
Marc
participants (3)
-
Bradley Lucier -
Marc Feeley -
Paul Wolneykien