Custom Query (1030 matches)
Results (394 - 396 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #562 | fixed | ESC-anything breaks the IDE | ||
| Description |
To reproduce:
Result:
1 > After exiting from the breakloop, the IDE remains confused, expecting a keydown and breaking on any it receives. |
|||
| #861 | invalid | overzealous and flaky warning about SETQ'd unused lexical variable/ | ||
| Description |
Sometimes the compiler warns
where FOO is some variable I've SETQ'd but then not referred to. That's annoying enough. I don't think that should be done at all. It's a pain to have to throw away documentary (multiple-value-setq (x y z) ...) variables or go through other hoops just to get rid of this warning. Also, it's "used" by reasonable definition: it's set, just not "read" or "eval'd". Whatever. It's a pain to encounter and to work around. But that's not the main point. Sometimes -- not always!! -- I cannot even still the compiler by simply placing the variable inline to be evaluated. The compiler first of all is so clever as to optimize out the reference, then turns on me and tells me it's not referenced. That is quite frustrating to put it mildly. Seems to happen in big functions. Small functions work fine, so I cannot give you an example. But it's like this:
(defun foo (a b)
(let (c d)
(multiple-value-setq (c d) (round a b))
c))
always warns about D "unused" (annoying to me, but I can deal with it) (defun foo (a b)
(let (c d)
(multiple-value-setq (c d) (round a b))
d
c))
not in this case, but in some larger functions, warns about D -- unacceptable, bug, etc.! Note: let me know if this is a known problem: that is, the flakyness (dependency on function size, or whatever), or -- if not -- if you need an example. I'll put cycles on it, but would rather not if it's already known. Version info:
CCL::*OPENMCL-MAJOR-VERSION*, Value: 1
CCL::*OPENMCL-MINOR-VERSION*, Value: 6
|
|||
| #1270 | fixed | compiler error referring to "comples", maybe typo for "complex" | ||
| Description |
Do not have a minimal way to reproduce this, but when I did an unusual (for our team) compiler optimization, namely (proclaim '(optimize (speed 3) (safety 0))) I got this error when compiling: Error:
Unknown vinsn: CCL::GET-COMPLES-SINGLE-FLOAT
[Condition of type SIMPLE-ERROR]
In:
Backtrace:
0: (CCL::NEED-VINSN-TEMPLATE CCL::GET-COMPLES-SINGLE-FLOAT #<HASH-TABLE :TEST EQ size 580/687 #x3020001CB97D>)
Robert Smith grepped for "comples" and found these hits in the sources: compiler/reg.lisp:(defconstant hard-reg-class-fpr-type-comples-double-float 2) compiler/X86/x862.lisp: (! get-comples-single-float reg result-reg) compiler/X86/x862.lisp: (! get-comples-double-float reg result-reg) Perhaps this shows a simple typo (comples for complex) and would be enough to at least fix something or figure out the error we're seeing. |
|||
