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

[Tsukasa OI]

On 2023/08/03 17:00, Jan Beulich via Binutils wrote:
> 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
> 

Hmm, I'm tempted to say "don't ask me".  I mean, that overly lax check
is in the portable portion of GAS and not RISC-V-specific.  I will start
digging if I'm interested... but currently... I'm not quite sure.

Regards,
Tsukasa