Xi Ruoyao via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > On Fri, 2022-03-04 at 15:17 +0800, xucheng...@loongson.cn wrote: > >> The binutils has been merged into trunk: >> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=560b3fe208255ae909b4b1c88ba9c28b09043307 >> >> Note: We split -mabi= into -mabi=lp64d/f/s, the new options not support by >> upstream binutils yet, >> this GCC port requires the following patch applied to binutils to build. >> https://github.com/loongson/binutils-gdb/commit/aacb0bf860f02aa5a7dcb76dd0e392bf871c7586 >> (will be submitted to upstream after gcc side comfirmed) > > I think you don't need a review for binutils change here. You should > get it reviewed and applied in binutils-gdb ASAP. Then in install.texi > you would add a note like "loongarch64-*-* requires binutils >= 2.39" in > "Target specific installation notes", as an unpatched 2.38 does not > work. > > And based on the history of RISC-V port > (https://gcc.gnu.org/pipermail/gcc/2017-January/222595.html) the process > for a new port seems: > > 1. Get a permission from the Steering Committee. > 2. Add one or two port maintainers into MAINTAINERS file. > 3. Now the technical reviewing of the patch series just begin. > > > I'm not an expert in software engineering (or social interaction :) and > I don't know if the process has been changed in these years.
I'm not sure either, but yeah, this is what I understood the process to be. On the technical side: I've gone through the series and sent comments about some of the patches. The ones I didn't reply to looked good as-is. Generally the series looks in very good shape to me FWIW. There are no target-independent changes, so I agree there's no reason to delay the patches until GCC 13. If for some reason they don't go in before GCC 12.1, they would be safe to backport to GCC 12.2. Thanks, Richard
