[committed] RISC-V: Make g imply zmmul extension.

[Jeff Law]

On 9/15/22 21:26, Nelson Chu wrote:
> On Fri, Sep 16, 2022 at 10:34 AM Jeff Law via Binutils
> <binutils@sourceware.org> wrote:
>>
>> On 9/15/22 19:39, Nelson Chu wrote:
>>> bfd/
>>>        * elfxx-riscv.c (riscv_implicit_subset): Moved entry of m after g,
>>>        so that g can imply zmmul.
>>> gas/
>>>        * testsuite/gas/riscv/attribute-01.d: Updated.
>>>        * testsuite/gas/riscv/attribute-02.d: Likewise.
>>>        * testsuite/gas/riscv/attribute-03.d: Likewise.
>>>        * testsuite/gas/riscv/attribute-04.d: Likewise.
>>>        * testsuite/gas/riscv/attribute-05.d: Likewise.
>>>        * testsuite/gas/riscv/attribute-10.d: Likewise.
>>>        * testsuite/gas/riscv/march-imply-g.d: Likewise.
>>>        * testsuite/gas/riscv/march-imply-unsupported.d: Likewise.
>> Does this happen to fix this kind of failure that started showing up a
>> week or two ago?
>>
>> /tmp/ccdAErP7.s:6522: Error: unrecognized opcode `mul a5,a4,a5',
>> extension `m' or `zmmul' required
> I get the same error message if I just assemble files with
> -march=rv32/64g, or just use the default rv64g arch setting.  I
> remember gcc should always pass the expanded imafd for g to assembler,
> so the errors won't happen.  This error should only happen when we set
> g for architecture string.  Hope the patch can fix the problem you
> mentioned, it seems like the same as what I meet.

In that case I'll just fire up the riscv64 bootstrap-in-chroot job and 
check on it in the morning.  If it's still failing, then I'll start 
debugging again now that I'm out of the covid brain-fog.


>
>> I started chasing it down and concluded it likely wasn't the compiler,
>> but couldn't take it further before covid knocked me out.  I'm just
>> starting to try and catch up on things today...
>>
> Glad to hear you recovered :)

Not fully, but I feel a hell of a lot better today than I did yesterday!


jeff