[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: HAVE_FAST_UNALIGNED_ACCESS
From: |
Po Lu |
Subject: |
Re: HAVE_FAST_UNALIGNED_ACCESS |
Date: |
Sun, 02 Apr 2023 08:48:02 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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.
- Re: HAVE_FAST_UNALIGNED_ACCESS, (continued)
- Re: HAVE_FAST_UNALIGNED_ACCESS, Eli Zaretskii, 2023/04/01
- Re: HAVE_FAST_UNALIGNED_ACCESS, Mattias Engdegård, 2023/04/01
- Re: HAVE_FAST_UNALIGNED_ACCESS, Eli Zaretskii, 2023/04/01
- Re: HAVE_FAST_UNALIGNED_ACCESS, Po Lu, 2023/04/01
- Re: HAVE_FAST_UNALIGNED_ACCESS, Eli Zaretskii, 2023/04/01
- Re: HAVE_FAST_UNALIGNED_ACCESS, Arsen Arsenović, 2023/04/01
- Re: HAVE_FAST_UNALIGNED_ACCESS, Eli Zaretskii, 2023/04/01
- Re: HAVE_FAST_UNALIGNED_ACCESS, Arsen Arsenović, 2023/04/01
- Re: HAVE_FAST_UNALIGNED_ACCESS, Eli Zaretskii, 2023/04/01
- Re: HAVE_FAST_UNALIGNED_ACCESS, Po Lu, 2023/04/01
- Re: HAVE_FAST_UNALIGNED_ACCESS,
Po Lu <=