Re: xemacs coredump in M-x eval-print-last-sexp
Valdis.Kletnieks(a)vt.edu wrote:
The fact that the optimizer triggers it does not automatically mean
it's
a compiler *bug*. I've seen instances where it *looked* like a compiler bug,
but in reality it was a program error with an aliasing issue - when running
without optimization, an otherwise dead store was concealing the bug. When
the optimizer was turned on, the dead store was removed, and the bug was
manifested.
Okay, but we know that the same version of the compiler when used on
another platform (x86 Linux) does *not* cause the same program behavior.
This argues strongly for the problem being in the compiler back end (for
the Sparc, in this case). Now, if we just knew that -O2 invoked the
same set of optimizations on both platforms, I would say that with more
certainty...:-)
Just in case, here's the preprocessed version of the line that is
crashing, reformatted to see it more easily. The crash is inside the if
test somewhere.
if (((((enum Lisp_Type)
(((unsigned long)(var)) & ~(((1UL << ((4 * 8) - 2)) - 1UL) << 2)))
== Lisp_Type_Record) &&
(((unsigned int)(((struct lrecord_header *)
((void *) (var)))->type))
== ((unsigned int)(lrecord_type_symbol)))))
*value = Qnil;
The crash happens when the CPU tries to read the contents of memory
pointed to by a register that just happens to be holding the value 1.
No matter what the value of var is here, that shouldn't happen. When
it's a number, the first test should fail and shortcut the second one
... shouldn't it?
--
Jerry James
http://www.ittc.ku.edu/~james/