Vin Shelton <acs(a)xemacs.org&gt; writes: I am not sure, but I think this is suspect: #define SET_FUN_PTR(fun_ptr, fun_val) \ (*((void **) (&fun_ptr)) = ((void *) (fun_val))) void init_ralloc (void) { if (r_alloc_initialized) return; r_alloc_initialized = 1; SET_FUN_PTR (real_morecore, __morecore); SET_FUN_PTR (__morecore, r_alloc_sbrk); FSF Emacs simply has real_morecore == __morecore I would look at the output of make ralloc.s in both cases. Jan P.S. IMHO this whole -fstrict-aliasing issue (for C) is a unfortunate mistake by the GCC people. In particular the "portable code won't break because other compilers have been doing this for ages" argument seems invalid. Of the 4 large C programs I use at home (linux kernel, glibc, XEmacs, X) 3 have (had) aliasing problems known to me. I am just waiting for the aliasing bugs in X to show up.