[REVIEW ONLY 4/4] RISC-V: Tentative ".bfloat16" assembly support

[Jan Beulich]

On 03.08.2023 09:51, Tsukasa OI wrote:
> On 2023/08/03 16:17, Tsukasa OI via Binutils wrote:
>>
>>
>> On 2023/08/03 15:47, Jan Beulich wrote:
>>> On 03.08.2023 02:04, Tsukasa OI via Binutils wrote:> --- a/gas/config/tc-riscv.c
>>>> +++ b/gas/config/tc-riscv.c
>>>> @@ -437,7 +437,7 @@ const char EXP_CHARS[] = "eE";
>>>>  
>>>>  /* Chars that mean this number is a floating point constant.
>>>>     As in 0f12.456 or 0d1.2345e12.  */
>>>> -const char FLT_CHARS[] = "rRsSfFdDxXpPhH";
>>>> +const char FLT_CHARS[] = "rRsSfFdDxXpPhHb";
>>>
>>> I realize Arm64 also has it this way (x86 doesn't), but are you sure
>>> about only adding 'b' and not also 'B'? Aiui this introduces a needless
>>> special case of case sensitivity.
>>
>> I'm not sure (the only reason I did so is because what I saw is AArch64
>> code).  So, I'll investigate whether introducing additional character
>> will benefit (I think there's not so many cases but there might be at
>> least one).
> 
> I checked the code and actually, no code is affected by lacking 'B'.  I
> first thought something like 0B:1234 (raw hexadecimal representation as
> float) is affected but in a floating number literal, any 0[a-zA-Z]:1234
> turns to a 16-bit word 0x1234, reinterpreted as a floating point number
> (and the second character is just ignored and the length is checked
> against another parameter).

I'm actually questioning that overly lax check; IOW I wonder whether it
shouldn't consult FLT_CHARS[].

Jan