From: Jim N. <jim...@gm...> - 2017-02-27 15:20:39
Attachments:
test-typep.lisp
|
I recently upgraded sbcl to 1.3.14. And I see something strange with inlining of typep. I've attached a file test-typep.lisp. When I compile the function, test123, the compiler tells me lots of code is unreachable. and when I test the function, I see that it gives the wrong result. But when I change the declare to ---> (declare (notinline subsetp typep)) and recompile, it no longer warns me about any unreachable code, and when I test the code it works correctly. Sorry, but when I say "works correctly" I mean, that in a larger context of my program I have cases where the behavior is different whether typep is inlined or not. If you need such a test case, I could try to come up with one. But my suspicion is that if someone can figure out why it thinks code is unreachable, that'll probably tell you what inlining is wrong. When I innocently look at the compiler messages, it loos like it has seen the (and (typep T1 '(cons (eql not))) (not (void-type-p (cadr T1))) ...) and falsely concluded that CADR can't be called on T1, or rather than CADR will return nil. But that's not the case. TEST> (typep '(not xyzzy) '(cons (eql not))) T TEST> (cadr '(not xyzz)) XYZZ TEST> It it perhaps confusing the type specifier (cons (eql not) with (cons (eql not) nil) or (cons (eql not) null) ? Here are the compiler warnings? I've copy-pasted the compiler output below. Kind regards Jim cd /Users/jnewton/ 8 compiler notes: sw/regular-type-expression/lisp-types/test-typep.lisp:32:29: note: deleting unreachable code sw/regular-type-expression/lisp-types/test-typep.lisp:32:42: note: deleting unreachable code --> CAR CDR ==> LISP-TYPES::T1 sw/regular-type-expression/lisp-types/test-typep.lisp:33:29: note: deleting unreachable code ==> LISP-TYPES::T2 sw/regular-type-expression/lisp-types/test-typep.lisp:34:42: note: deleting unreachable code --> CAR CDR ==> LISP-TYPES::T1 sw/regular-type-expression/lisp-types/test-typep.lisp:35:19: note: deleting unreachable code sw/regular-type-expression/lisp-types/test-typep.lisp:46:53: note: deleting unreachable code ==> LISP-TYPES::T2 sw/regular-type-expression/lisp-types/test-typep.lisp:46:63: note: deleting unreachable code --> CAR CDR ==> LISP-TYPES::T1 sw/regular-type-expression/lisp-types/test-typep.lisp:49:25: note: deleting unreachable code ==> LISP-TYPES::X |
From: Jim N. <jim...@gm...> - 2017-02-27 15:30:27
|
Smaller code to exhibit the problem. it looks like since T1 is being passed to find-class, the compiler is assuming T1 must be an atom. However, sbcl allows me to call find-class with a non-symbol as long as the 2nd argument is nil. Perhaps the real problem is that find-class fails to signal an error on a case such as the following: (find-class '(a) nil) Any thoughts? (defun test456 (T1 T2) (cond ((and (find-class T1 nil) (find-class T2 nil)) (list t t)) ((and (typep T1 '(cons (eql not))) (cadr T1)) (list nil t)))) On Mon, Feb 27, 2017 at 4:20 PM, Jim Newton <jim...@gm...> wrote: > I recently upgraded sbcl to 1.3.14. And I see something strange with > inlining of typep. > > I've attached a file test-typep.lisp. > > When I compile the function, test123, the compiler tells me lots of code > is unreachable. > and when I test the function, I see that it gives the wrong result. > But when I change the declare to > ---> (declare (notinline subsetp typep)) > and recompile, it no longer warns me about any unreachable code, and when > I test > the code it works correctly. > > Sorry, but when I say "works correctly" I mean, that in a larger context > of my program > I have cases where the behavior is different whether typep is inlined or > not. > > If you need such a test case, I could try to come up with one. But my > suspicion is that if someone can figure out why it thinks code is > unreachable, > that'll probably tell you what inlining is wrong. > > > When I innocently look at the compiler messages, it loos like > it has seen the (and (typep T1 '(cons (eql not))) (not (void-type-p (cadr > T1))) ...) > and falsely concluded that CADR can't be called on T1, > or rather than CADR will return nil. But that's not the case. > > TEST> (typep '(not xyzzy) '(cons (eql not))) > T > TEST> (cadr '(not xyzz)) > XYZZ > TEST> > > It it perhaps confusing the type specifier (cons (eql not) with (cons (eql > not) nil) > or (cons (eql not) null) ? > > Here are the compiler warnings? > > I've copy-pasted the compiler output below. > Kind regards > Jim > > > cd /Users/jnewton/ > 8 compiler notes: > > sw/regular-type-expression/lisp-types/test-typep.lisp:32:29: > note: deleting unreachable code > > sw/regular-type-expression/lisp-types/test-typep.lisp:32:42: > note: > deleting unreachable code > --> CAR CDR > ==> > LISP-TYPES::T1 > > > sw/regular-type-expression/lisp-types/test-typep.lisp:33:29: > note: > deleting unreachable code > ==> > LISP-TYPES::T2 > > > sw/regular-type-expression/lisp-types/test-typep.lisp:34:42: > note: > deleting unreachable code > --> CAR CDR > ==> > LISP-TYPES::T1 > > > sw/regular-type-expression/lisp-types/test-typep.lisp:35:19: > note: deleting unreachable code > > sw/regular-type-expression/lisp-types/test-typep.lisp:46:53: > note: > deleting unreachable code > ==> > LISP-TYPES::T2 > > > sw/regular-type-expression/lisp-types/test-typep.lisp:46:63: > note: > deleting unreachable code > --> CAR CDR > ==> > LISP-TYPES::T1 > > > sw/regular-type-expression/lisp-types/test-typep.lisp:49:25: > note: > deleting unreachable code > ==> > LISP-TYPES::X > > > |
From: Elias M. <lo...@gm...> - 2017-02-28 08:12:33
|
On 27 February 2017 at 23:30, Jim Newton <jim...@gm...> wrote: > Smaller code to exhibit the problem. > it looks like since T1 is being passed to find-class, the compiler is > assuming T1 must be an atom. > However, sbcl allows me to call find-class with a non-symbol as long as > the 2nd argument is nil. > This is wrong. The CLHS states that the first argument to FIND-CLASS must be a symbol. The behaviour of ERRORP only dictates whether or not an error is raised if the class does not exist. Therefore your code is not compliant and SBCL has the right to return nonsensical results. Regards, Elias |