>>>I fixed various nits in the ChangeLog to make the pre-commit hooks happy and pushed this to the trunk. Thanks a lot Jeff for fixing the Changelog and .md misinformatted (we use VS Code or VI with tab 4 spaces).
and also use git-fix-changelog.py and check_GNU_style.py formatting ,which still looks like it needs modification to adhere to the latest GNU code style standrad . Thank you again, ~U On Tue, Jul 15, 2025 at 10:08 PM Jeff Law <jeffreya...@gmail.com> wrote: > > > On 7/14/25 11:34 PM, Umesh Kalappa wrote: > > Updated the test for rv32 accordingly and no regress found for runs like > > "runtest --tool gcc > --target_board='riscv-sim/-march=rv32gc_zba_zbb_zbc_zbs/-mabi=ilp32d/-mcmodel=medlow' > riscv.exp" and > > "runtest --tool gcc > --target_board='riscv-sim/-march=rv64gc_zba_zbb_zbc_zbs/-mabi=lp64d/-mcmodel=medlow' > riscv.exp" > > > > lint warnings can be ignored for riscv-cores.def and riscv-ext-mips.def > > > > gcc/ChangeLog: > > > > *config/riscv/riscv-cores.def(RISCV_CORE): Updated the > supported march. > > *config/riscv/riscv-ext-mips.def(DEFINE_RISCV_EXT): > > New file added for mips conditional mov extension. > > *config/riscv/riscv-ext.def: Likewise. > > *config/riscv/t-riscv: Generates riscv-ext.opt > > *config/riscv/riscv-ext.opt: Generated file. > > *config/riscv/riscv.cc(riscv_expand_conditional_move): Updated > for mips cmov > > and outlined some code that handle arch cond move. > > *config/riscv/riscv.md(mov<mode>cc): updated expand for MIPS > CCMOV. > > *config/riscv/mips-insn.md: New file for mips-p8700 ccmov insn. > > *gcc/doc/riscv-ext.texi: Updated for mips cmov. > > > > gcc/testsuite/ChangeLog: > > > > *testsuite/gcc.target/riscv/mipscondmov.c: Test file for > mips.ccmov insn. > > --- > > > > > diff --git a/gcc/config/riscv/mips-insn.md > b/gcc/config/riscv/mips-insn.md > > new file mode 100644 > > index 00000000000..de53638d587 > > --- /dev/null > > +++ b/gcc/config/riscv/mips-insn.md > > @@ -0,0 +1,36 @@ > > +;; Machine description for MIPS custom instructions. > > +;; Copyright (C) 2025 Free Software Foundation, Inc. > > + > > +;; This file is part of GCC. > > + > > +;; GCC is free software; you can redistribute it and/or modify > > +;; it under the terms of the GNU General Public License as published by > > +;; the Free Software Foundation; either version 3, or (at your option) > > +;; any later version. > > + > > +;; GCC is distributed in the hope that it will be useful, > > +;; but WITHOUT ANY WARRANTY; without even the implied warranty of > > +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > +;; GNU General Public License for more details. > > + > > +;; You should have received a copy of the GNU General Public License > > +;; along with GCC; see the file COPYING3. If not see > > +;; <http://www.gnu.org/licenses/>. > > + > > +(define_insn "*mov<GPR:mode><X:mode>cc_bitmanip" > > + [(set (match_operand:GPR 0 "register_operand" "=r") > > + (if_then_else:GPR > > + (any_eq:X (match_operand:X 1 "register_operand" "r") > > + (match_operand:X 2 "const_0_operand" "J")) > > + (match_operand:GPR 3 "reg_or_0_operand" "rJ") > > + (match_operand:GPR 4 "reg_or_0_operand" "rJ")))] > This was misformatted. The "any_eq" should either be on the same line > as the if_then_else or indented relative to the if_then_else. The final > selection of the location of the any_eq expression will influence how > operands 2, 3 and 4 get formatted. Essentially oeprand 2 would line up > with operand 1 (since they're both operands of the any_eq. operands 3 > and 4 would line up with the any_eq since like the any_eq, they are > operands of the if_then_else. I've fixed this too. > > > > > > > @@ -4897,3 +4897,4 @@ > > (include "sifive-p600.md") > > (include "generic-vector-ooo.md") > > (include "generic-ooo.md") > > +(include "mips-insn.md") > Minor adjustment needed here. Kito recently clarified that we have > groups of includes. Some are ratified RVI extensions, there's another > group for vector extensions and a final group for scheduling modules. > > Your patch bits the mips-insn.md into the group for scheduling models. > It needs to move into the vector extension group. I've taken care of that. > > > I fixed various nits in the ChangeLog to make the pre-commit hooks happy > and pushed this to the trunk. > > jeff >
