Re: [Gcl-devel] some GCL bugs revealed by ansi test suite

[Camm Maguire]

Greetings!

"Vadim V. Zhytnikov" <address@hidden> writes:

> Hi!
> 
> I'd like to report some GCL bugs revealed during
> clocc ansi compatibility tests.  The list is
> very far from being complete and problem ranges
> from very simple bugs to some quite general
> problems which require modification in many many
> places.
> 
> First, a couple of very simple bugs:
> 
> 1)  (make-array 5 :fill-pointer -1)
> must signal an error for any negative value
> of :fill-pointer.
> 

Done.  Please verify.

> 2)  The built-in constant
> 
>      array-total-size-limit
> 
> returns symbol (another constant)
> 
>      array-dimension-limit
> 
> as its value but should return
> numerical value (probably the same as
> value of array-dimension-limit).
> 

Done.  Please verify.

> 3) The path designator #P"aaa" (capital P)
> result in error but should not be different
> from #p"aaa".
> 

Done.  Please verify.

> 
> Now some more serious problems. ANSI tests
> clocc suite report really huge number of
> errors with floating point operations.
> Here is some short extract from error log:
> 

Umm -- clearly the AKCL numbers below are right, and the 'should be'
are wrong, no?  I can even see this in my head :-).  Are the tests
using 'legacy' broken values as the expected return?

> Bugid: :NUMBER-LEGACY-2938 interpreted Form: (+ 0.52019S0 0.98203S0)
> Should be: 1.50223S0
> AKCL: 1.50222S0
> 
> Bugid: :NUMBER-LEGACY-2942 interpreted Form: (+ 0.026268S0 0.6137S0)
> Should be: 0.63997S0
> AKCL: 0.639968S0
> 
> Bugid: :NUMBER-LEGACY-2946 interpreted Form: (+ -0.338943S0 0.450523S0)
> Should be: 0.11158S0
> AKCL: 0.11158S0
> 
> Bugid: :NUMBER-LEGACY-2950 interpreted Form: (+ -0.032799S0 0.995186S0)
> Should be: 0.96239S0
> AKCL: 0.962387S0
> 
> Frankly I don't quite understand how to treat these
> results. Are they really bugs? Clisp and cmucl
> seems to be OK...
> 

Could you please give me some lisp showing this?

> Another similar result which is reported as bug:
> 1e-37     ->  1.0000000000000001E-37
> 10.0e-38  ->  9.9999999999999986E-38
> 
> 

Grepping through the sources, internal-simple-error doesn't appear
anywhere.  How are the tests detecting this?  Errors aren't returned
values in lisp, right?  Aren't they just caught in trapping routines
showing the user the stack and giving an option to proceed?  If you
can explain how the tests discover a return of internal-simple-error,
we can make it detect the others instead in the right places :-).

> Next quite general GCL problem which provides large number of
> non-ansi reports is the error handling system.
> Presently many GCL functions signals INTERNAL-SIMPLE-ERROR
> if some error occurs while ANSI requires something more
> sophisticated.  Functions must signal TYPE-ERROR if operand
> of wrong type is received, PROGRAM-ERROR is wrong program
> structure is encountered etc.  These non-ansi-ines is already
> not so easy to fix.  First CONDITIONS (clcs) package should
> be modified or replaced to define all required ANSI
> error conditions.  Next all relevant functions must be
> modified to signal proper error types.  It seems also
> that such modification to GCL can't be done with current
> build system when we first build saved_gcl and next add PCL and
> CONDITIONS and save new image.  With new error system PCL and
> CONDITIONS must be present in core GCL from very beginning.
> 
> Finally the following code
> 
> (defvar *counters* (make-hash-table))
> 
> (defmacro how-many (obj) `(values (gethash ,obj *counters* 0)))
> 
> (defun count-it (obj) (incf (how-many obj)))
> 
> (dolist (x '(bar foo foo bar bar baz)) (count-it x))
> 
> produces error in setf.
> 

This seems to be a lisp code issue.  setf has various methods to store
values in various types of objects.  And the code cannot recognize
your hash macro as one of the known types.  Here is the function:

=============================================================================
(defun get-setf-method-multiple-value (form &optional env &aux tem)
  (cond ((symbolp form)
         (let ((store (gensym)))
           (values nil nil (list store) `(setq ,form ,store) form)))
        ((or (not (consp form)) (not (symbolp (car form))))
         (error "Cannot get the setf-method of ~S." form))
        ((and env (setq tem (assoc (car form) (second env))))
         (setq tem (macroexpand form env))
         (if (eq form tem) (error "Cannot get setf-method for ~a" form))
         (return-from get-setf-method-multiple-value
                      (get-setf-method-multiple-value tem  env)))
        ((get (car form) 'setf-method)
         (apply (get (car form) 'setf-method) env (cdr form)))
        ((or (get (car form) 'setf-update-fn)
             (setq tem (get (car form) 'si::structure-access)))
         (let ((vars (mapcar #'(lambda (x)
                                 (declare (ignore x))
                                 (gensym))
                             (cdr form)))
               (store (gensym)))
           (values vars (cdr form) (list store)
                   (cond (tem
                           (setf-structure-access (car vars) (car tem)
                                                  (cdr tem) store))
                         (t
                           `(,(get (car form) 'setf-update-fn)
                             ,@vars ,store)))
                   (cons (car form) vars))))
        ((get (car form) 'setf-lambda)
         (let* ((vars (mapcar #'(lambda (x)
                                  (declare (ignore x))
                                  (gensym))
                              (cdr form)))
                (store (gensym))
                (l (get (car form) 'setf-lambda))
                ;; this looks bogus to me.  What if l is compiled?--wfs
                (f `(lambda ,(car l) #'(lambda ,(cadr l) ,@(cddr l)))))
           (values vars (cdr form) (list store)
                   (funcall (apply f vars) store)
                   (cons (car form) vars))))
        ((macro-function (car form))
         (get-setf-method-multiple-value (macroexpand form)))
        (t
         (error "Cannot expand the SETF form ~S." form))))
=============================================================================

My question for you and others as our resident lisp experts is to
explain to me what should happen here.  Should this form trigger one
of the tests preceding the default?  Or do we need to write a new
method?  What should that method be conceptually?

Take care,



> Best wishes,
> 
> Vadim
> 
> 
> 
> 
> 
> 
> -- 
>        Vadim V. Zhytnikov
> 
>         <address@hidden>
>        <address@hidden>
>        <address@hidden>
>       <address@hidden>
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah