[PATCH v3 00/13] RISC-V: assorted fixes and (hopefully) improvements

[Nelson Chu]

Thanks for the information!  I would love to take a look at these cool
stuffs.  Sorry to keep you waiting so long... I remember that 2.47 is
scheduled for release in August, so I will have it finished by then.

Thanks!
Nelson

On Thu, Jul 9, 2026 at 1:57 PM Jan Beulich <jbeulich@suse.com> wrote:

> Nelson,
>
> On 19.06.2026 13:45, Jan Beulich wrote:
> > There may not be many dependencies among the patches, but the issues
> > were all noticed more or less together (i.e. while addressing one,
> > the next one popped up). I've not made an attempt at sorting the V vs
> > Z?inx issue, as per Andrew's request.
> >
> > Quite a few further points are made in remarks in individual patches.
> > Input there is very welcome.
> >
> > Jiawei kindly reviewed v1 and v2, and I meanwhile committed a few more
> > patches from there, which I assumed were pretty sure to be reasonably
> > uncontroversial. For the others I'd prefer RISC-V maintainer approval,
> > yet I'm not going to wait indefinitely.
> >
> > There aren't many changes in v3. See individual changes for what
> > changed, if anything.
> >
> > 01: RISC-V: add dedicated vector arithmetic .insn forms
> > 02: RISC-V: EEW64 checking
> > 03: bfd/RISC-V: Zvfbfwma implies Zvfbfmin
> > 04: RISC-V: Zv{b,k}* imply Zve32x
> > 05: RISC-V: drop FCVT.Q.L{,U} forms with rounding mode operand
> > 06: RISC-V: make FP rounding mode an optional argument
> > 07: RISC-V: check operands for Zdinx in RV32
> > 08: RISC-V: check operands for Zqinx
> > 09: RISC-V/gas: .attribute vs .insn
> > 10: RISC-V/gas: warn about non-boolean unaligned-access attribute
> > 11: RISC-V/gas: warn about non-power-of-2 stack-align attribute
> > 12: RISC-V/bfd: warn about non-boolean unaligned-access attribute
> > 13: RISC-V/bfd: warn about non-power-of-2 stack-align attribute
>
> now that you're back, would you mind looking over this series. After
> branching for 2.47 I'd like to get this in, as I think I have already
> waited for rather too long.
>
> Thanks, Jan
>
> > I'd also like to point out that [1] continues to be pending. I'm
> > far from insisting that that patch be taken, but something needs
> > doing about the issue.
> >
> > Jan
> >
> > [1] https://sourceware.org/pipermail/binutils/2023-March/126601.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20260710/895530b5/attachment.htm>