Give a few more thought behind my first LGTM: I am OK *IF* binutils bits accepted since it's just kind of bypassing the -march to bintuils to enable those instructions for assembly code. However the situation seems is little more complicated than my expect at beginning...:P
Anyway, I still think it's fine to accept that to me *IF* bintuils part has landed, but only limited to -march support, no further things for GCC 14 like intrinsic and auto vectorizer stuff for t-head vector (or vector 0.7). On Fri, Nov 10, 2023 at 12:05 AM Jeff Law <jeffreya...@gmail.com> wrote: > > > > On 11/9/23 01:38, Yixuan Chen wrote: > > Hi Kito and Christoph, > > > > XYenChi (oriachi...@gmail.com <mailto:oriachi...@gmail.com>) is my > > e-mail address too. I didn't notice the git email config have changed, > > very sorry about that. > > > > We want to support other operate system project from our team, so port > > the XTheadV. If T-Head and VRULL have made great progress, it's pleasure > > to follow your work. By the way, I have sent the opcode patch to > > binutils, if you have any concern, please check the patch: > > https://sourceware.org/pipermail/binutils/2023-November/130431.html > > <https://sourceware.org/pipermail/binutils/2023-November/130431.html> > > > > If our team could provide any help, please let us know. > Given we see multiple organizations with an interest in this work, but > that the bulk of the work can't be integrated in the short term, y'all > might consider a shared development branch for coordination. > > That gives the two organizations a place to coordinate their work while > things like the ISA spec and such get solidified. Presumably the goal > for the main body of work is not gcc-14, but gcc-15. > > I don't want to dictate how coordination happens. Ultimately it's > something the relevant developers can decide. > > jeff
