Vin Shelton <acs(a)xemacs.org> writes:
> I recompiled ralloc.c with -fno-strict-aliasing, and voila! I can
> build and run an XEmacs. Perhaps someone who understands the aliasing
> issues better than I do can track this down, he or she cares to.
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.