A core dump occurred during the `synth_coolrunner2` process.

[sdjasj]

Version

Yosys 0.51+107 (git sha1 f03b449, clang++ 14.0.0-1ubuntu1.1 -fPIC -O3)

On which OS did this happen?

Linux

Reproduction Steps

The following is the problematic Verilog code file bug.v, which I have minimized as much as possible out of responsibility:

module a (
    output b
);
    reg [2:1] c;
    
    always begin
        case (0)
            default: begin
                b = c;
                c = ^c;
            end
        endcase
    end
endmodule

The following is the minimized min.il file using Yosys's bugpoint.

# Generated by Yosys 0.51+107 (git sha1 f03b44959, clang++ 14.0.0-1ubuntu1.1 -fPIC -O3)
autoidx 13
attribute \src "bug.v:1.1-14.10"
attribute \cells_not_processed 1
module \a
  attribute \src "bug.v:6.5-13.8"
  wire $0\b[0:0]
  attribute \src "bug.v:6.5-13.8"
  wire width 2 $0\c[1:0]
  attribute \src "bug.v:6.5-13.8"
  wire $1\b[0:0]
  attribute \src "bug.v:6.5-13.8"
  wire width 2 $1\c[1:0]
  attribute \src "bug.v:10.21-10.23"
  wire width 2 $reduce_xor$bug.v:10$2_Y
  attribute \src "bug.v:2.12-2.13"
  wire output 1 \b
  attribute \src "bug.v:4.15-4.16"
  wire width 2 offset 1 \c
  attribute \src "bug.v:10.21-10.23"
  cell $reduce_xor $reduce_xor$bug.v:10$2
    parameter \A_SIGNED 0
    parameter \A_WIDTH 2
    parameter \Y_WIDTH 2
    connect \A \c
    connect \Y $reduce_xor$bug.v:10$2_Y
  end
  attribute \src "bug.v:6.5-13.8"
  process $proc$bug.v:6$1
    assign $0\b[0:0] $1\b[0:0]
    assign $0\c[1:0] $1\c[1:0]
    attribute \src "bug.v:7.9-12.16"
    switch 0
      case 
        assign $1\b[0:0] \c [0]
        assign $1\c[1:0] $reduce_xor$bug.v:10$2_Y
    end
    sync always
      update \b $0\b[0:0]
      update \c $0\c[1:0]
  end
end

The bug can be reproduced with the following commands:

yosys -p "read_verilog bug.v; synth_coolrunner2"

or

yosys -p "read_rtlil min.il; synth_coolrunner2"

Expected Behavior

A core dump should not occur during the Yosys synthesis process.

Actual Behavior

Yosys produced the following log during execution:

2.25. Executing ATTRMVCP pass (move or copy attributes).
Moving attribute src="bug.v:2.12-2.13" from a.b to a.$iopadmap$a.b[0].

2.26. Executing ATTRMVCP pass (move or copy attributes).
Moving attribute src="bug.v:4.15-4.16" from a.c to a.$iopadmap$a.b[0].

2.27. Executing COOLRUNNER2_FIXUP pass (insert necessary buffer cells for CoolRunner-II architecture).
Buffering input to "$iopadmap$a.b[0]"
Warning: While buffering, changing x to 0 into cell $iopadmap$a.b[0]
Buffering output enable to "$iopadmap$a.b[0]"
Segmentation fault (core dumped)

With ASan and UBSan instrumentation enabled, the following runtime error was reported:

techlibs/coolrunner2/coolrunner2_fixup.cc:96:34: runtime error: member access within null pointer of type 'RTLIL::Wire'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior techlibs/coolrunner2/coolrunner2_fixup.cc:96:34 in 
...
==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000058==
...
#0 in Yosys::RTLIL::IdString::c_str() const
#1 in makeptermbuffer
...

So the issue is likely caused by the following line in techlibs/coolrunner2/coolrunner2_fixup.cc:

auto inwire_name = inwire.wire->name.c_str();

Here is the full snippet of the makeptermbuffer function:

RTLIL::Wire *makeptermbuffer(RTLIL::Module *module, SigBit inwire)
{
	auto inwire_name = inwire.wire->name.c_str(); // <-- techlibs/coolrunner2/coolrunner2_fixup.cc:96, likely nullptr access here

	auto outwire = module->addWire(
		module->uniquify(stringf("$xc2fix$%s_BUF_AND_OUT", inwire_name)));

	auto and_cell = module->addCell(
		module->uniquify(stringf("$xc2fix$%s_BUF_AND", inwire_name)),
		ID(ANDTERM));
	and_cell->setParam(ID(TRUE_INP), 1);
	and_cell->setParam(ID(COMP_INP), 0);
	and_cell->setPort(ID(OUT), outwire);
	and_cell->setPort(ID(IN), inwire);
	and_cell->setPort(ID(IN_B), SigSpec());

	return outwire;
}

This suggests that inwire.wire is a null pointer, causing the segmentation fault when trying to access its name. A null check may be needed before this access.

[sdjasj]

The following is the minimized intermediate representation (via bugpoint + manual inspection):

# Generated by Yosys 0.51+107 (git sha1 f03b44959, clang++ 14.0.0-1ubuntu1.1 -fPIC -O3)

autoidx 87

module \a

  cell \IOBUFE \x
    connect \E 1'x
    connect \I 1'x
    connect \IO 1'x
  end

end

The minimization script used:

read_verilog bug.v
synth_coolrunner2 -run :map_cells
dfflibmap -liberty +/coolrunner2/xc2_dff.lib
dffinit -ff FDCP Q INIT
dffinit -ff FDCP_N Q INIT
dffinit -ff FTCP Q INIT
dffinit -ff FTCP_N Q INIT
dffinit -ff LDCP Q INIT
dffinit -ff LDCP_N Q INIT
coolrunner2_sop
clean
iopadmap -bits -inpad IBUF O:I -outpad IOBUFE I:IO -inoutpad IOBUFE O:IO -toutpad IOBUFE E:I:IO -tinoutpad IOBUFE E:O:I:IO
attrmvcp -attr src -attr LOC t:IOBUFE n:*
attrmvcp -attr src -attr LOC -driven t:IBUF n:*
bugpoint -command coolrunner2_fixup

select *
write_rtlil -selected min.il

In the minimized RTLIL code, all ports \E, \I, and \IO are connected to 1'x, which are constants—not wires.

Then, in coolrunner2_fixup.cc, within the makeptermbuffer() function, there's the following line:

auto inwire_name = inwire.wire->name.c_str();  // ⚠️ here: inwire.wire == nullptr

This line does not check whether inwire.wire == nullptr. It assumes inwire (e.g., from the IOBUFE.IO port) is always a wire. However, during the earlier processing, a 1’x constant might be assigned here, which leads to a null pointer dereference.

[sdjasj]

Based on the suggestion in #4987 (comment), I checked the synth_coolrunner2 script and found that the opt commands before the bug is triggered already have the -fast option enabled (e.g., opt -fast -full and opt -fast). Therefore, I tried removing the -fast option, but the issue can still be reproduced.

[KrystalDelusion]

Logic loop this time, but still potentially closed by #5058