Tcl Source Code

Hi,

Using the CVS head as of 6-dec-2006, tcltest fails for expr-47.12:

i = 28: isqrt( 72057594037927936-1) != 268435455
i = 28: isqrt( 72057594037927936+1) != 268435456
i = 29: isqrt( 288230376151711744-1) != 536870911
i = 29: isqrt( 288230376151711744+1) != 536870912
i = 30: isqrt( 1152921504606846976-1) != 1073741823
i = 30: isqrt( 1152921504606846976+1) != 1073741824
i = 31: isqrt( 4611686018427387904-1) != 2147483647
i = 31: isqrt( 4611686018427387904+1) != 2147483648
i = 32: isqrt( 18446744073709551616-1) != 4294967295
...

Platform: Linux 2.4.20-8smp #1 SMP Thu Mar 13 17:45:54 EST 2003 i686 i686 i386 GNU/Linux

Kind regards,

Jos.

Logged In: YES 
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

Logged In: YES 
user_id=99768
Originator: NO

We have two separate problems here.

(1) The ldexp() function appears to be generating incorrect code on 'gcc -O2' on gcc 3.2.2. Generally speaking, we don't attempt to program around all compiler bugs; only when a compiler is extremely popular and a fix from the vendor is unavailable do we introduce the complexity that would cost us.  In this case, "upgrade to gcc 3.2.3 or better," appears to be an adequate answer.

(2) gcc 3.3.4 crashes when running this test on an x64 system.  This second bug is the issue where __attributes(mode(TI))__ doesn't appear to be working.  In this case, there is no gcc
fix -- all versions of gcc for x64 appear to exhibit the problem -- and there is an easy Core fix -- don't use 128-bit arithmetic.  It's this second bug I was trying to address with the HEAD changes.

Logged In: YES 
user_id=370749
Originator: YES

After rebuilding from the head, the tests still fails (but passes when compiling bn_mp_sqrt.c without -O2).

Logged In: YES 
user_id=99768
Originator: NO

We appear to be running afoul of a compiler or libc bug near the handling of variables of type 'unsigned long __attributes(TI)__.'  I've committed a change that eliminates the attempt to use that type in our local copy of tommath.h.  Can you rebuild a current HEAD from 'make distclean' and see if the problem goes away?

Note: If the change works, I think we need some additional fiddling to get the mp_digit and mp_word types exactly right, but that's a matter of controlling memory waste rather than anything that will crash us.

Logged In: YES 
user_id=72656
Originator: NO

This test crashes using gcc 3.3.4 on x64 SuSE 9.2 on head.

File Added - 206667: bn_mp_sqrt.c

Logged In: YES 
user_id=370749
Originator: YES

Hi,

This problem is only triggered with gcc 3.2.2, other versions work fine (even 3.2.3). The attached file fixes the problem by calling a dummy function when using gcc 3.2.2. How would such a case be treated in the Tcl core?

Jos.
File Added: bn_mp_sqrt.c

Logged In: YES 
user_id=370749
Originator: YES

Compiling bn_mp_sqrt.c without -O2 indeed solves the problem.

Jos.

Logged In: YES 
user_id=79902
Originator: NO

Ugh, you mean it might be an optimizer bug? :-(

At least upgrading to 3.4.* seems to fix the problem.

Logged In: YES 
user_id=370749
Originator: YES

This seems to be a platform or compiler issue. On Redhat 9 (Linux 2.4.20-8smp + gcc 3.2.2) it fails, on Redhat enterprise  edition ( Linux 2.6.9-5.ELsmp + gcc 3.4.3) is passes. I added some printf statements to bn_mp_sqrt.c to compare both platforms and suddenly it worked! This fails:

  d = sqrt(d);
  dig = (mp_digit) ldexp(d, -DIGIT_BIT);
  if (dig) {

This passes:

  d = sqrt(d);
  dig = (mp_digit) ldexp(d, -DIGIT_BIT);
  printf("");
  if (dig) {

Not clear to me what's going wrong here. 

Jos.

Logged In: YES 
user_id=80530
Originator: NO


looks to me like the issue
must be down in the mp_sqrt()
routine.

Logged In: YES 
user_id=370749
Originator: YES

After doing a new checkout, I still encounter this problem. libtommath/bn_mp_sqrt.c is at version 1.5. The result of the test is:

==== expr-47.12 isqrt of various sizes of integer FAILED
==== Contents of test case:

    set faults 0
    for {set i 0} {$faults < 10 && $i <= 1024} {incr i} {
        set root [expr {1 << $i}]
        set rm1 [expr {$root - 1}]
        set arg [expr {1 << (2 * $i)}]
        set tval [expr {isqrt($arg-1)}]
        if {$tval != $rm1} {
            append trouble "i = " $i ": isqrt(" $arg "-1) == " $tval  " != " $rm
1 "\n"
            incr faults
        }
        set tval [expr {isqrt($arg)}]
        if {$tval != $root} {
            append trouble "i = " $i ": isqrt(" $arg ") == " $tval  " != " $root
 "\n"
            incr faults
        }
        set tval [expr {isqrt($arg+1)}]
        if {$tval != $root} {
            append trouble "i = " $i ": isqrt(" $arg "+1) == " $tval  " != " $ro
ot "\n"
            incr faults
        }
    }
    set trouble

---- Result was:
i = 28: isqrt(72057594037927936-1) == 279620267 != 268435455
i = 28: isqrt(72057594037927936+1) == 279620267 != 268435456
i = 29: isqrt(288230376151711744-1) == 545818760 != 536870911
i = 29: isqrt(288230376151711744+1) == 545818760 != 536870912
i = 30: isqrt(1152921504606846976-1) == 1079707056 != 1073741823
i = 30: isqrt(1152921504606846976+1) == 1079707056 != 1073741824
i = 31: isqrt(4611686018427387904-1) == 2150992608 != 2147483647
i = 31: isqrt(4611686018427387904+1) == 2150992608 != 2147483648
i = 32: isqrt(18446744073709551616-1) == 4296881274 != 4294967295
i = 41: isqrt(4835703278458516698824704-1) == 2199023259647 != 2199023255551

---- Result should have been (exact matching):

==== expr-47.12 FAILED

Logged In: YES 
user_id=99768
Originator: NO

I've committed a change to expr-47.12 to improve the fault
reporting a bit, in hopes of narrowing down the symptoms of
this.  This one is awkward, because it works for both dgp
and me.

Logged In: YES 
user_id=99768
Originator: NO

In particular, verify that your sources include version 1.3 or later (HEAD is 1.5) of libtommath/bn_mp_sqrt.c - there was a bug there with these precise symptoms.

Logged In: YES 
user_id=80530
Originator: NO


Seems likely this failed test
came from testing a partial
implementation.

Do another `cvs update`,
and test a build from
a `make distclean` state.

Re-open if the failure is
still present.

Logged In: YES 
user_id=80530
Originator: NO


Works for me.