The function pcharp_to_svalue_inumber(), used by the compiler to parse integer literals, clamps literals to [MIN_INT_TYPE..MAX_INT_TYPE] when AUTO_BIGNUM is not defined, i.e. a literal such as e.g. 12345678912345 will typically become the literal 2147483647. Is this intentional? The testsuite does not like it:
test_any([[int a=0xffffffff; return a+17]], 0x100000010); test_any([[int a=0xffffffff; return a-17]], 0xffffffee); test_any([[int a=0xffffffff; return a*17]], 0x10ffffffef); [...] test_any([[int a=0xffffffff; return a<<17]], 0x1fffffffe0000);
test_any([[ int a=0xffffffff; return a/17 ]], [[ (0xffffffff == -1)?-1:0x0f0f0f0f ]]); test_any([[ int a=0xffffffff; return a%17 ]], [[ (0xffffffff == -1)?16:0 ]]); test_any([[ int a=0xffffffff; return a>>17 ]], [[ (0xffffffff == -1)?-1:0x7fff ]]);
All these fail due to the clamping. In order to perform the intended tests, all the literals greater than 17 have to be written as 0xffff|(0xffff<<16), 0x10000001<<4, etc. The question is, should this clamping be performed in the first place?
I think it should do clamping. I think the failing tests should be designated bignum-only-tests and not called when bignums are not available.
pcharp_to_svalue_inumber is a re-implementation of the strtod function, which also does clamping.
/ Fredrik (Naranek) Hubinette (Real Build Master)
Previous text:
2003-12-20 21:30: Subject: Arithmetic tests and --without-bignums
The function pcharp_to_svalue_inumber(), used by the compiler to parse integer literals, clamps literals to [MIN_INT_TYPE..MAX_INT_TYPE] when AUTO_BIGNUM is not defined, i.e. a literal such as e.g. 12345678912345 will typically become the literal 2147483647. Is this intentional? The testsuite does not like it:
test_any([[int a=0xffffffff; return a+17]], 0x100000010); test_any([[int a=0xffffffff; return a-17]], 0xffffffee); test_any([[int a=0xffffffff; return a*17]], 0x10ffffffef); [...] test_any([[int a=0xffffffff; return a<<17]], 0x1fffffffe0000);
test_any([[ int a=0xffffffff; return a/17 ]], [[ (0xffffffff == -1)?-1:0x0f0f0f0f ]]); test_any([[ int a=0xffffffff; return a%17 ]], [[ (0xffffffff == -1)?16:0 ]]); test_any([[ int a=0xffffffff; return a>>17 ]], [[ (0xffffffff == -1)?-1:0x7fff ]]);
All these fail due to the clamping. In order to perform the intended tests, all the literals greater than 17 have to be written as 0xffff|(0xffff<<16), 0x10000001<<4, etc. The question is, should this clamping be performed in the first place?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Personally I think that a literal that can't be represented should be an error. Silently replacing it with a different literal is a very dubious feature.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-12-20 22:42: Subject: Arithmetic tests and --without-bignums
I think it should do clamping. I think the failing tests should be designated bignum-only-tests and not called when bignums are not available.
pcharp_to_svalue_inumber is a re-implementation of the strtod function, which also does clamping.
/ Fredrik (Naranek) Hubinette (Real Build Master)
Sounds like a good idea. I wasn't thinking very clearly before and was only considering clamping and not clamping as available options.
/ Fredrik (Naranek) Hubinette (Real Build Master)
Previous text:
2003-12-20 22:44: Subject: Arithmetic tests and --without-bignums
Personally I think that a literal that can't be represented should be an error. Silently replacing it with a different literal is a very dubious feature.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
If you give Pike a number it can't represent, I think a compile error is what you want...
Note that these tests will still work with 64 bit integers in Pike.
/ Mirar
Previous text:
2003-12-20 21:30: Subject: Arithmetic tests and --without-bignums
The function pcharp_to_svalue_inumber(), used by the compiler to parse integer literals, clamps literals to [MIN_INT_TYPE..MAX_INT_TYPE] when AUTO_BIGNUM is not defined, i.e. a literal such as e.g. 12345678912345 will typically become the literal 2147483647. Is this intentional? The testsuite does not like it:
test_any([[int a=0xffffffff; return a+17]], 0x100000010); test_any([[int a=0xffffffff; return a-17]], 0xffffffee); test_any([[int a=0xffffffff; return a*17]], 0x10ffffffef); [...] test_any([[int a=0xffffffff; return a<<17]], 0x1fffffffe0000);
test_any([[ int a=0xffffffff; return a/17 ]], [[ (0xffffffff == -1)?-1:0x0f0f0f0f ]]); test_any([[ int a=0xffffffff; return a%17 ]], [[ (0xffffffff == -1)?16:0 ]]); test_any([[ int a=0xffffffff; return a>>17 ]], [[ (0xffffffff == -1)?-1:0x7fff ]]);
All these fail due to the clamping. In order to perform the intended tests, all the literals greater than 17 have to be written as 0xffff|(0xffff<<16), 0x10000001<<4, etc. The question is, should this clamping be performed in the first place?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
pike-devel@lists.lysator.liu.se
-
Fredrik (Naranek) Hubinette (Real Build Master) ＠ Pike (-) developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Mirar ＠ Pike developers forum