MIYASHITA Hisashi <himi(a)m17n.org> writes:
At this time, I doubted soundness of the C-compiler gcc-2.95.2
20000220.
Then, I changed the optimization option from -O3 to -O0,
and remade xemacs. This xemacs works well.
Next, I restore the optimization option to -O3,
then, disassemble the corresponding part to x_keysym_to_character()
as follows.
[...]
If you can read this asssembler code, you know that this part
obviously
calls assert_failed unconditionally. That means that GCC judged
the expression of the assertion is always false.
I suspected this problem is caused by type conversion, because
if GCC always fails to evaluate such simple expressions
as (lb >= 0x80 && lb <= 0xFF), GCC 2.95 should be useless.
Therefore, I modified this part as follows.
[...]
The assertion is cleaned because the expression can be
statically evaluated, and it is always true. That's correct.
Of course, this xemacs works well.
From these situations, I conludeded that this problem is caused
by GCC's bug.
Do you reproduce this problem also in your environment?
I cannot reprodue it but my XEmacs crashes when I evaluate
(decode-buffer 1). I use Debian woody and this gcc
% gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs
gcc version 2.95.2 20000220 (Debian GNU/Linux)
My crash goes away if I turn off gcse optimization. Gcc has
several optimization bugs and some known issues are checked
by configure script. Perhaps the best way would be to use
-O2 always...
--
Yoshiki Hayashi