[PATCH] opcodes/aarch64: make aarch64_ext_ldst_reglist()'s data[] static const

[Jan Beulich]

On 29.07.2025 11:11, Richard Earnshaw (lists) wrote:
> On 29/07/2025 10:03, Jan Beulich wrote:
>> On 29.07.2025 10:57, Richard Earnshaw (lists) wrote:
>>> On 29/07/2025 07:53, Jan Beulich wrote:
>>>> On 28.07.2025 18:10, Richard Earnshaw (lists) wrote:
>>>>> On 28/07/2025 16:58, Jan Beulich wrote:
>>>>>> ---
>>>>>> I further wonder whether the struct fields being unsigned int isn't
>>>>>> wasteful - unsigned char (or bool for "is_reserved") would appear to
>>>>>> suffice, without negatively affecting generated code (except on
>>>>>> architectures where byte loads are more expensive).
>>>>>
>>>>> uint8_t would be fine and preferable to (unsigned) char since it's a value not a character.
>>>>
>>>> I can use uint8_t, but personally I recommend to avoid fixed-width types
>>>> where they can be avoided. They will only cause problems on architectures
>>>> which have no way to express those types. (E.g. on TI C4x and C54x I
>>>> wonder how uint8_t would be expressable, with them having 32 / 16 bits
>>>> per byte respectively.) The "not a character" argument imo only applies
>>>> to uses of plain char; signed or unsigned forms thereof are normal (just
>>>> narrow) integer types according to my understanding).
>>>
>>> If space is a concern then I'd just use a bitfield.  Performance isn't critical here, so
>>
>> Okay, if bitfields are okay to use here, I'd indeed prefer going that route.
>>
>>>  struct
>>>     {
>>>       bool is_reserved      : 8;
>>
>> I don't think a bool bitfield can be other than 1 bit wide, though. I'd put
>> the field ...
> 
> I don't see why they couldn't be.  Other bitfields can be wider than they're type: eg
> 
> uint16_t x: 24;
> 
> is legal, it just adds padding.

Except that e.g. gcc14 then says

"error: width of '...' exceeds its type"

My understanding of that restriction is that it's there to avoid the need
to deal with values other than (numeric) 0 and 1 in bitfields.

Jan