https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127503
Bug ID: 127503
Summary: RISC-V bootstrap bug found using --with-cpu
Product: gcc
Version: 17.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
This may ultimately turn into a meta-bug as I expect we'll find more cases like
this if we exercise the thead extensions further.
I've had a TODO for a while to converting the c920 build to use
--with-cpu=xt-c920. It's the fastest bootstrap & regression test platform I've
got, even though it doesn't test many of the newer extensions like B, V,
Zicond, etc (though there may be rough equivalents in the thead extension
space).
Naturally bootstrap failed. In particular we get an assembler error building
libgcc that was ultimately tracked down to the atomic patterns.
Essentially the thead design exposes more addressing modes and when those modes
are used we should be using instructions like th.lrd rather than ld. So loads
which accept "memory_operand" and which emit assembly directly are likely
broken -- they need to route through output_move which in turn will use
th_output_move to get the assembly syntax right for the thead extensions.
As an example, look at atomic_load_rvwmo<mmode>:
(define_insn "atomic_load_rvwmo<mode>"
[(set (match_operand:ANYI 0 "register_operand" "=r,r")
(unspec_volatile:ANYI
[(match_operand:ANYI 1 "memory_operand" "m,A")
(match_operand:SI 2 "const_int_operand" "B2,B1")]
UNSPECV_ATOMIC_LOAD))]
"!TARGET_ZTSO"
{
enum memmodel model = (enum memmodel) INTVAL (operands[2]);
model = memmodel_base (model);
if (model == MEMMODEL_SEQ_CST)
return "fence\trw,rw\;"
"<load>\t%0,%1\;"
"fence\tr,rw";
if (TARGET_ZALASR && model == MEMMODEL_ACQUIRE)
return "<load>.aq\t%0,%1";
if (model == MEMMODEL_ACQUIRE)
return "<load>\t%0,%1\;"
"fence\tr,rw";
return "<load>\t%0,%1";
}
So note the predicate on operand1. It accepts any memory operand. But it uses
the <load> iterator for assembly output. So if we have one of the thead memory
address extensions, we'll generate invalid assembly.
Not at the top of my TODO, but I don't want this to get lost...
