Then you can configure with:

CC=clang CXX=clang++ cmake -G Ninja ../llvm/llvm \
  -DCMAKE_BUILD_TYPE=Release \
  -DLLVM_ENABLE_ASSERTIONS=OFF \
  -DLLVM_ENABLE_PROJECTS="mlir" \
  -DLLVM_EXTERNAL_PROJECTS="circt" \
  -DLLVM_EXTERNAL_CIRCT_SOURCE_DIR=.. \
  -DLLVM_TARGETS_TO_BUILD="host" \
  -DLLVM_STATIC_LINK_CXX_STDLIB=ON \
  -DLLVM_ENABLE_TERMINFO=OFF \
  -DCIRCT_RELEASE_TAG=firtool \
  -DCIRCT_RELEASE_TAG_ENABLED=On \
  -DLLVM_FORCE_ENABLE_STATS=ON \
  -DCIRCT_LLHD_SIM_ENABLED=OFF \
  -DLLVM_ENABLE_PIC=OFF \
  -DLLVM_BUILD_STATIC=ON \
  -DLLVM_LINK_LLVM_DYLIB=off \
  -DLLVM_ENABLE_LIBXML2=OFF

So this worked for me (I did tweak the build target to X86, and I used FROM --platform=linux/amd64 alpine:3.19.1 since I built on an M1.

But I'm trying to understand why this build works without the version error for GLIBC_2.18 not found is it because we are using clang in your cmake command?

Firtool takes advantage the "automatic logic" feature of SystemVerilog to create intermediate combinatorial signals inside of clocked blocks, for example:

  always @(posedge clock) begin
    automatic logic            _GEN_11 = _GEN_7 | ~_GEN_10 | _GEN_2;
    automatic logic [3:0][7:0] _GEN_12 =
      {{tailq_0_0},
       {_GEN_11 ? tailq_0_0 : io_in_bits_data_0},
       {tailq_0_0},
       {_GEN_1 ? tailq_0_0 : io_in_bits_data_0}};

While perfectly legal and synthesizable, it appears to drive the Mentor lint/formal tool nuts because it thinks _GEN_11 and _GEN_12 are registers. Is there a way to turn this off so that it explictly creates wires as intermediates? I tried "disallowLocalVariables" and it had no effect on these.

In reply to @jackkoenig-57e1805540f3a6eec0665030:gitter.im
Chisel does not represent tri-state buffers so unless your synthesis tool is going to generate them from standard muxing (doubtful but I'm not sure) then that might be a problem for you.

In reply to @jackkoenig-57e1805540f3a6eec0665030:gitter.im
FixedPoint is a Data-type for representing fixed point numbers. There's not much in the docs because it was removed in Chisel 5.0. I'm not aware of any reason why Mux1H wouldn't work for FixedPoint since the optimizations that Mux1H enables are agnostic to how the bits being muxed are interpreted.

In reply to @jackkoenig-57e1805540f3a6eec0665030:gitter.im
You can represent the bus with Analog in Chisel, but for driving it you'll have to use Verilog BlackBoxes

Yeah, I'm not that worried about actually implementing it. It's all academic anyway and I can probably hand-wave it away by saying that Mux1H conveys the semantic meaning that I want.