I happened to a difficult problem at the newest version of XEmacs taken from CVS. (My environment is Debian GNU/Linux (potato), the latest version.) -- (gdb) run Starting program: /home/himi/OpenCVS/xemacs/xemacs/src/xemacs Fatal error: assertion failed, file mule-charset.h, line 569, lb >= 0x80 && lb <= 0xFF (gdb) bt #0 0x402be931 in kill () from /lib/libc.so.6 #1 0x402be618 in raise () from /lib/libc.so.6 #2 0x402bfc71 in abort () from /lib/libc.so.6 #3 0x80bf72b in assert_failed (file=0x828d1c9 "mule-charset.h", line=569, expr=0x828d1d8 "lb >= 0x80 && lb <= 0xFF") at emacs.c:3189 #4 0x81f187e in x_keysym_to_character (keysym=1244) at mule-charset.h:569 #5 0x81f1b51 in x_has_keysym (keysym=1244, hash_table=140042288, with_modifiers=1) at event-Xt.c:306 #6 0x81f1d7a in x_reset_key_mapping (d=0x8598df0) at event-Xt.c:406 #7 0x81f1e58 in x_reset_modifier_mapping (d=0x8598df0) at event-Xt.c:461 #8 0x81f789e in x_init_modifier_mapping (d=0x8598df0) at event-Xt.c:625 #9 0x81eef6e in x_init_device (d=0x8598df0, props=137214908) at device-x.c:803 #10 0x80adf1e in Fmake_device (type=137351036, connection=137214908, props=137214908) at device.c:588 #11 0x80c5c6d in Ffuncall (nargs=3, args=0xbffff2f8) at eval.c:3528 ...(snip)... -- This assertion failure is caused by CHARSET_BY_LEADING_BYTE(a)mule-charset.h. -- INLINE_HEADER Lisp_Object CHARSET_BY_LEADING_BYTE (Bufbyte lb); INLINE_HEADER Lisp_Object CHARSET_BY_LEADING_BYTE (Bufbyte lb) { extern struct charset_lookup *chlook; type_checking_assert (lb >= 0x80 && lb <= 0xFF); return chlook->charset_by_leading_byte[lb - 128]; } -- This function is embedded into x_keysym_to_character()(a)event-Xt.c And this part in x_keysym_to_character calls CHARSET_BY_LEADING_BYTE(), and fails because my X server have KATAKANA_JISX0201 keysyms. -- #define USE_CHARSET(var,cs) \ ((var) = CHARSET_BY_LEADING_BYTE (LEADING_BYTE_##cs)) ...(snip) case 4: /* Katakana */ USE_CHARSET (charset, KATAKANA_JISX0201); if ((keysym & 0xff) > 0xa0) code = keysym & 0x7f; break; -- Expanding the macro of USE_CHARSET, we obtain an expression, CHARSET_BY_LEADING_BYTE(LEADING_BYTE_KATAKANA_JISX0201). As you know, LEADING_BYTE_KATAKANA_JISX0201 is constant, its value is 0x89. Therefore, the following assertion in CHARSET_BY_LEADING_BYTE must be passed. -- type_checking_assert (lb >= 0x80 && lb <= 0xFF); -- 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. -- (gdb) i reg eip eip 0x81f187e 136255614 (gdb) disas Dump of assembler code for function x_keysym_to_character: 0x81f1790 <x_keysym_to_character>: push %ebp 0x81f1791 <x_keysym_to_character+1>: mov %esp,%ebp 0x81f1793 <x_keysym_to_character+3>: sub $0xc,%esp 0x81f1796 <x_keysym_to_character+6>: push %edi 0x81f1797 <x_keysym_to_character+7>: push %esi 0x81f1798 <x_keysym_to_character+8>: push %ebx 0x81f1799 <x_keysym_to_character+9>: mov 0x8(%ebp),%ebx 0x81f179c <x_keysym_to_character+12>: mov $0x1,%esi 0x81f17a1 <x_keysym_to_character+17>: xor %edi,%edi 0x81f17a3 <x_keysym_to_character+19>: cmp $0x9f,%bl 0x81f17a6 <x_keysym_to_character+22>: ja 0x81f17b2 <x_keysym_to_character+34> 0x81f17a8 <x_keysym_to_character+24>: mov 0x82b50d4,%eax 0x81f17ad <x_keysym_to_character+29>: jmp 0x81f1a8a <x_keysym_to_character+762> 0x81f17b2 <x_keysym_to_character+34>: mov %ebx,%eax 0x81f17b4 <x_keysym_to_character+36>: shr $0x8,%eax 0x81f17b7 <x_keysym_to_character+39>: cmp $0x20,%eax 0x81f17ba <x_keysym_to_character+42>: ja 0x81f196b <x_keysym_to_character+475> 0x81f17c0 <x_keysym_to_character+48>: jmp *0x828ebe0(,%eax,4) 0x81f17c7 <x_keysym_to_character+55>: add $0xfffffffc,%esp 0x81f17ca <x_keysym_to_character+58>: push $0x828d1d8 0x81f17cf <x_keysym_to_character+63>: push $0x239 0x81f17d4 <x_keysym_to_character+68>: push $0x828d1c9 0x81f17d9 <x_keysym_to_character+73>: call 0x80bf654 <assert_failed> 0x81f17de <x_keysym_to_character+78>: add $0x10,%esp 0x81f17e1 <x_keysym_to_character+81>: mov 0x82b55e0,%eax 0x81f17e6 <x_keysym_to_character+86>: mov 0x4(%eax),%esi 0x81f17e9 <x_keysym_to_character+89>: jmp 0x81f1966 <x_keysym_to_character+470> .... (omitted, this part deals with other case than KATAKANA_JISX0201) .... 0x81f1867 <x_keysym_to_character+215>: add $0xfffffffc,%esp 0x81f186a <x_keysym_to_character+218>: push $0x828d1d8 0x81f186f <x_keysym_to_character+223>: push $0x239 0x81f1874 <x_keysym_to_character+228>: push $0x828d1c9 0x81f1879 <x_keysym_to_character+233>: call 0x80bf654 <assert_failed> 0x81f187e <x_keysym_to_character+238>: add $0x10,%esp <===== return address points here!!!!!!!!!!!! 0x81f1881 <x_keysym_to_character+241>: mov 0x82b55e0,%eax 0x81f1886 <x_keysym_to_character+246>: mov 0x24(%eax),%esi 0x81f1889 <x_keysym_to_character+249>: cmp $0xa0,%bl 0x81f188c <x_keysym_to_character+252>: jbe 0x81f196b <x_keysym_to_character+475> -- 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. -- INLINE_HEADER Lisp_Object CHARSET_BY_LEADING_BYTE (Bufbyte lb); INLINE_HEADER Lisp_Object CHARSET_BY_LEADING_BYTE (Bufbyte lb) { extern struct charset_lookup *chlook; int test = lb; type_checking_assert (test >= 0x80 && test <= 0xFF); return chlook->charset_by_leading_byte[lb - 128]; } -- And I dissassembled this part, -- 0x81f17fa <x_keysym_to_character+106>: lea 0x0(%esi),%esi 0x81f1800 <x_keysym_to_character+112>: mov 0x82b54c0,%eax 0x81f1805 <x_keysym_to_character+117>: mov 0x24(%eax),%esi 0x81f1808 <x_keysym_to_character+120>: cmp $0xa0,%dl 0x81f180b <x_keysym_to_character+123>: jbe 0x81f185f <x_keysym_to_character+207> 0x81f180d <x_keysym_to_character+125>: jmp 0x81f185a <x_keysym_to_character+202> -- 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. by GCC's bug. Do you reproduce this problem also in your environment? from himi