`openroad` binary in official `openroad/orfs` Docker images crashes with SIGILL (illegal instruction) in CTS on any CPU without AVX-512

[mguthaus]

Subject

[Build] / Docker images (also affects the prebuilt binaries — see #4105)

Describe the bug

The openroad binary shipped in the official openroad/orfs Docker images
executes an AVX-512 instruction somewhere in the CTS stage. On any CPU without
AVX-512 the flow runs normally through synthesis, floorplan, placement, and
post-placement resizing, then dies deterministically at the start of CTS:

Error: cts.tcl, 83 child killed: illegal instruction
Elapsed time: 0:02.26[h:]min:sec. CPU time: user 1.89 sys 0.28 (96%). Peak memory: 140276KB.
make[1]: *** [Makefile:511: do-4_1_cts] Error 1
make: *** [Makefile:511: results/nangate45/gcd/base/4_1_cts.odb] Error 2

This is not an "old hardware" problem: it reproduces on AMD EPYC 7542 (Zen 2,
2019 datacenter part) and EPYC Milan-class Kubernetes nodes. No AMD CPU before
Zen 4 (late 2022) has AVX-512, and Intel removed it from consumer parts from
Alder Lake on — so the images are unusable on a large fraction of modern
machines, failing with a message that (per #4105) gets read as user error.

Evidence that it is specifically the image build, and specifically AVX-512:

• Every design fails identically at CTS in the image on non-AVX-512 hosts
  (tested nangate45/gcd, nangate45/black_parrot, nangate45/mempool_group,
  asap7/swerv_wrapper — tiny gcd traps ~2 s into clock_tree_synthesis).
• The same image runs the same designs through CTS and detailed routing
  without issue on Intel Xeon nodes that have AVX-512 (verified on 2 different
  AVX-512 nodes vs 4 different non-AVX-512 nodes, both AMD and older hardware,
  on the NRP Nautilus Kubernetes cluster).
• A native build of the same ORFS commit (a5ff7ef7d, OpenROAD submodule
  6b9d7fb806) on the same AVX-512-less EPYC 7542 host runs all of these
  designs through the full flow with no issue (several hundred completed runs).
• All flow stages before CTS run for hours in-image on the affected CPUs, so
  the binary is not globally miscompiled — a specific code path reached first
  in CTS (TritonCTS itself or a dependency kernel compiled with AVX-512,
  e.g. an -march=native / build-host-autodetected object in the image build)
  contains the offending instructions.

Issue #4105 reports the same signature (cts.tcl ... child killed: illegal instruction, 26Q1 prebuilt binaries) and went stale without a root cause —
this is very likely the same defect.

Expected Behavior

Official images/binaries should run on the x86-64-v3 baseline (AVX2) that the
rest of the binary already targets — either by compiling the whole image at a
portable -march, or using runtime dispatch for any AVX-512 kernels.

Environment

• Images tested, both failing identically on the same host:
  • docker.io/openroad/orfs:26Q3-54-ga5ff7ef7d
    (digest sha256:a6140cf4dc568e10238356f67b9fd73b9074955eeda6f2ee126bc60f5d7fc3ac)
  • docker.io/openroad/orfs:latest as of 2026-07-25 (26Q3-209; its openroad
    reports 26Q2-209-g0d9d73ffba) — fails at cts.tcl, 82 with the same
    SIGILL, so current images are still affected.
  • bug: tutorial flow fails on CTS #4105 shows the same signature on 26Q1 prebuilt binaries.
• Failing hosts: AMD EPYC 7542 (Zen 2) / Ubuntu 24.04 / docker 27.x; AMD EPYC
  Milan-class and pre-AVX2 Kubernetes nodes (NRP Nautilus).
• Working hosts (same image, same commands): Intel Xeon nodes with AVX-512.

To Reproduce

On any machine whose /proc/cpuinfo has no avx512 flags (any AMD before
Zen 4, any Intel consumer CPU from 12th gen on):

docker run --rm docker.io/openroad/orfs:26Q3-54-ga5ff7ef7d bash -c \
  'source ./env.sh; cd flow && make DESIGN_CONFIG=./designs/nangate45/gcd/config.mk cts'

Fails in ~3 minutes total (~2 s into the CTS stage) with
Error: cts.tcl, 83 child killed: illegal instruction. The same command on an
AVX-512 machine completes.