GNU bug report logs - #50230
Endian problem with native compilation

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: akrl <at> sdf.org
Cc: schwab <at> linux-m68k.org, 50230 <at> debbugs.gnu.org
Subject: bug#50230: Endian problem with native compilation
Date: Sat, 04 Sep 2021 12:15:24 +0300

> Date: Wed, 01 Sep 2021 19:05:56 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: schwab <at> linux-m68k.org, 50230 <at> debbugs.gnu.org
> 
> > From: Andrea Corallo <akrl <at> sdf.org>
> > Cc: schwab <at> linux-m68k.org, 50230 <at> debbugs.gnu.org
> > Date: Wed, 01 Sep 2021 15:13:54 +0000
> > 
> > This is changing the cast functions we synthesize and use in all the
> > code we generate, so yes it is potentially destabilizing.
> > 
> > That said the generated code looks correct to me (and considerably
> > cleaner).  Also, given these functions are really the foundation of a
> > lot of other code we generate I guess would be unlikely to have these
> > wrong but still have the testsuite passing clean and Emacs booting up
> > correctly.  Call me optimistic but I'd be pretty confident with this
> > change...
> 
> OK, thanks.  We'll see how it goes (after you find the problem with
> endianness and fix it).

I've noticed that building Emacs --with-native-compilation after this
change still uses the same subdirectory of native-lisp/ for the
preloaded files, and doesn't recompile *.eln files that were
native-compiled before the change (unless the corresponding *.el files
were updated in the meantime).  Shouldn't we recompile all the *.eln
files after this change?

I don't know if Andreas did recompile all of them, but if not, perhaps
that's one reason why the change didn't fix Emacs on big-endian
systems?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.