Subject: Re: bug#76559: 31.0.50; [-O3 + PGTK] Crash when 'copying as kill'/'killing word'

From: Po Lu <[email-masked]>
Date: Mon, 03 Mar 2025 22:46:42 +0800

Po Lu <[email-masked]> writes:

> Paul Eggert <[email-masked]> writes:
>
>> On 2025-03-01 21:10, Po Lu wrote:
>>> It doesn't take control flow into account, but rather _every statement
>>> operand_ in the current procedure that addresses an aggregate declared
>>> in the same procedure.
>>
>> Although, as you mentioned, we could work around this wrong-code GCC
>> bug by using -fno-tree-sra (something we already do for GCC pre-SSE2
>> x86), we should avoid the tricky union locals that trigger the bug on
>> x86-64 with gcc -flto. After all, these union locals make the code
>> harder for humans to read, so removing them is a win regardless of the
>> GCC bug. And if removing the union locals happens to work around the
>> GCC bug then so much the better.
>
> [...]
>
>> +/* Store EVENT obtained at interrupt level into kbd_buffer, fifo.
>> +   This is like kbd_buffer_store_event_hold, but for struct
>> +   selection_input_event instead of struct input_event.
>> +
>> +   If HOLD_QUIT && HOLD_QUIT->kind != NO_EVENT, discard EVENT.
>> +
>> +   This is used to postpone the processing of the quit event until all
>> +   subsequent input events have been parsed (and discarded).  */
>> +
>> +void
>> +kbd_buffer_store_selection_event_hold
>> +  (struct selection_input_event const *event,
>> +   struct input_event const *hold_quit)
>
> The patch is fine by me, but the line wrapping hereabouts is gruesome.
> Please delete the const qualifiers and wrap the parameter list after
> `event', since they probably will not assist code generation.
>
> Also, come to think of it, I doubt it's appropriate for selection event
> delivery (which is meant purely to be a transparent process to users) to
> be influenced by hold_quit at all.

Which reminds me: what is to be done on the release branch, if any?
Beyond directing users not to enable "-flto", which goes without saying.