Custom Query (1030 matches)

Running the code in attached file, in which 10 threads cons hysterically, will pretty reliably elicit heap corruption.

From Matt Lamari, see ​http://clozure.com/pipermail/openmcl-devel/2011-May/012827.html.

Sometimes the compiler warns

style-warning: Unused lexical variable FOO

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

r11754 is workaround for a bug in how the lisp assembler encodes memory operands that are just a displacement.

To elaborate on that commit message, there are two ways on 32-bit x86 to encode a memory operand that's just a displacement.

For example, take the instruction:

0x806e6db:	mov    %fs:0x84,%ecx

The lisp assembler encodes this as:

0x806e6db:	0x64	0x8b	0x0c	0x25	0x84	0x00	0x00	0x00

Note that the modrm byte of 0x0c (00 001 100) means that a sib byte follows.

This could also be encoded as this shorter sequence (and the Unix assembler does so):

0x806e6db:	0x64	0x8b	0x0d	0x84	0x00	0x00	0x00

The modrm byte of 0x0d (00 001 101) here means that the displacement follows.

The reason that the lisp assembler selects the longer encoding is because it targeted x86-64 first. On x86-64, the modrm byte in the shorter sequence is redefined to mean that the displacement is RIP-relative. Therefore, the longer sib byte encoding is used to specify just a displacement.

The lisp assembler needs to be persuaded to emit the shorter encoding for 32-bit x86. When it does, we can recompile and bump fasl versions, etc., and remove the workaround in pc_luser_xp().