Re: HAVE_FAST_UNALIGNED_ACCESS

[Po Lu <luangruo@yahoo.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arsen Arsenović <arsen@aarsen.me>
>> Cc: Po Lu <luangruo@yahoo.com>, mattias.engdegard@gmail.com,
>>  vibhavp@gmail.com, rpluim@gmail.com, emacs-devel@gnu.org
>> Date: Sat, 01 Apr 2023 14:59:53 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > I'm still unconvinced, and I said already what will have a chance of
>> > convincing me: a specific report about a problem this particular code
>> > causes on a specific existing platform we support in Emacs 29 and with
>> > a specific compiler.
>> 
>> Similar (but not exactly the same) loops as this one have been shown to
>> generate incorrect code in this thread.  It's not a large leap for it to
>> happen to this one, introducing subtle errors for a bit of code that is
>> completely unnecessary (as demonstrated by it being optional),
>> especially at higher optimization levels, where the compiler could
>> easily produce better code than the assumption of a 'mov' would.
>> 
>> Is the following trivial enough for 29?
>
> You are again trying to push for a change without showing any actual
> bug with the existing code.  Please humor me, and please show me an
> actual bug due to the existing code before suggesting a solution.  See
> above for the description of the details I'd like to know about such
> actual bug.

> Sorry, I don't want to risk any errors, and I would like to avoid any
> experiments with the release branch.  Which is why I'm asking for hard
> evidence.  It isn't that I don't understand what you and others are
> saying, or don't believe you.  It's just that we need to see the
> problems before we can judge the solutions that must be safe on this
> branch.

The nature of this bug is that there is no ``hard evidence'' of its
presence, until it strikes.  Just like writing outside malloc'ed memory,
or freeing a pointer twice, or signed integer overflow (which falls
apart entirely on the R4000.)

This code has a very high risk for errors.
Removing it entirely will reduce the risk, since it was only installed
late in Emacs 29's development.