Martin Buchholz <martin(a)xemacs.org> writes:
I tried to track this down on Steve's computer. Steve is using
amazingly aggressive optimization, ie.
pgcc-2.95.3 -O3 -fomit-frame-pointer -Wall -mathlon -mcpu=athlon
-march=athlon -malign-functions=4 -funroll-loops
-fexpensive-optimizations -malign-double -fschedule-insns2
With that degree of optimization, I expect optimizer bugs from the
gcc/pgcc guys. We've had them before. Of course, it *could* be a
stray pointer bug in XEmacs, but it smells like a compiler bug.
If you just use -O3 like configure wants you to, the world will be
happy, and your xemacs will be fast enough.
Yoshiki, are you also using pgcc or athlon-specific optimizations?
I'm using gcc 2.95.2 and compiler options is default one
from configure. Now I've done a little more test and I
found my modification to the byte optimizer is the culprit.
Failed tests are:
L172: (Assert (= (* iterations 4) (hash-table-count ht)))
L185: (Assert (= (+ 2 (* 2 iterations)) (hash-table-count ht)))
I copied following code from Emacs 20.7 but I became busy and
never got around to submit it.
(put 'concat 'byte-optimizer 'byte-optimize-concat)
(defun byte-optimize-concat (form)
(let ((args (cdr form))
(while (and args constant)
(or (byte-compile-constp (car args))
(setq constant nil))
(setq args (cdr args)))
With this optimze on, byte-compiled (concat "1" "2")
produces new object on only first evaluation. Now I have
some time to hack XEmacs again and going to submit above
optimization, I'd like to change (concat "1" "2") to
(concat "1" (number-to-string 2)). Martin, what do you