commit c5fd96ebb vs. gcc15 vs. ppcle64 in Fedora

[gsomlo]

Version

commit c5fd96e

On which OS did this happen?

Linux

Reproduction Steps

I maintain yosys in Fedora. With each new release, the source RPM is built for a set of different architectures, including x86_64, aarch64, etc., including ppc64le.

While working on version 51, I noticed that make test fails, only on ppcle64, and only on fedora versions >= 42
(the latter most likely correlated with gcc version 15).

After a bisect, I found the first commit where this happens to be c5fd96e ("macc_v2: Start new cell"), authored by @povik

Attached is the full ppcle64 fedora mock build log illustrating that problem. c5fd96ebb0c9067927bd4df381af92783bb4b547.build.log.txt

Expected Behavior

make test succeeds on all architectures, including ppcle64

Actual Behavior

make test fails on ppcle64, gcc15 (fedora 42 and later)

[KrystalDelusion]

(the latter most likely correlated with gcc version 15).

Ah, looks like we only have CI for gcc-13 or older. And gcc-14 was failing when it was set to gcc-13 as the newest supported. Should probably look into why that was failing.

[gsomlo]

On Wed, Mar 26, 2025 at 03:15:53PM -0700, KrystalDelusion wrote: (the latter most likely correlated with gcc version 15). Ah, looks like we only have CI for gcc-13 or older. And gcc-14 was failing when it was set to gcc-13 as the newest supported. Should probably look into why that was failing.

The weird thing is that (for now) it only fails on (gcc15 AND arch==ppcle64). I.e., it passes all tests (even with gcc15) on x86_64. On one hand, ppcle64 is the "tail wagging the dog" in that I don't know anyone who might really care about the intersection of yosys and that arch... :) OTOH, just because it fails to fail on x86_64, doesn't mean there isn't something subtly wrong and ppcle64 is just an "early warning"...

[KrystalDelusion]

Are you able to retrieve the tests/arch/nanoxplore/meminit.log file? According to the log file you shared that should contain the failure

ERROR: Assertion top.did_read_$check_EN (meminit.v:47.9-47.39) failed.
make[1]: *** [run-test.mk:41: nanoxplore-meminit.ys] Error 1

[KrystalDelusion]

Are you able to test with latest main? We've had a few issues come through from the Debian folks that we've fixed for them, and I wonder if something in there might solve this too.

[gsomlo]

Are you able to retrieve the tests/arch/nanoxplore/meminit.log file?

meminit.log

I'm also going to try building the latest main, but that's going to take a few hours of ppcle64-on-x86 emulation...

[KrystalDelusion]

Oh, nanoxplore-meminit.ys is failing on c5fd96e because the $macc_v2 cell didn't have a model when it was initially added. I would be very surprised if that was the same failure as the v0.51 release. When bisecting try to stick to commits on main, since commits in PRs may be in work in progress and aren't expected to pass CI, whereas main is (although there are still rare cases where main failed on a non-release commits, so may be worth double checking the CI report anyway).

[gsomlo]

When bisecting try to stick to commits on main

I had grabbed main at the time I got the "v0.51 was observed in the wild" notification from the fedora monitoring scripts, and tried to build it. I found c5fd96e to be the first commit failing on ppcle64 between the v051 tag and current main, via bisect.

So yeah, breakage started happening some short time after the v051 release.

I also tried latest main as of 13 hours ago (which had commit ID b913185).

As before, it builds fine on x86_64, but fails a (different this time) test on ppcle64. Here's the build log: b9131853f.build.log and also the log of the failing test: t_mem1.log

EDIT: it's not quite failing the test, as much as the test leads it to coredump on ppcle64...

[KrystalDelusion]

So yeah, breakage started happening some short time after the v051 release.

Gotcha, thanks.

EDIT: it's not quite failing the test, as much as the test leads it to coredump on ppcle64...

That's... odd. Having written it out both before and after the memory_libmap call that is getting the segfault on ppcle64, with both 0.51 and 0.51+85 (b913185). The only difference in the outputs are the names of the auto generated wires/cells because they take the line number of the file they come from (all of the differences here being a few lines later in rtlil.cc). memory_libmap (the command where the fault is thrown) hasn't changed in that time either.

If there was anything between 0.51 and 0.51+85 that could've broken support on an obscure platform, I would've guessed it was #4834 which refactored io handling, rather than #4818 which you originally picked out. Are you able to test e44d1d4? That

EDIT: As I was saying, that should include the complete macc_v2 PR and we can see if it's the same thing failing or not. Alternatively, if you still have access to the compiled b913185 in ppcle64 can you try run tests/various/stat.ys, if that fails then I think there's a good chance that the problem is the io changes.

[KrystalDelusion]

Dang misclick...

[KrystalDelusion]

The

terminate called after throwing an instance of 'std::runtime_error'
  what():  pool<> assert failed.

suggests a failure in hash lib, but that also hasn't changed since before 0.51.

[gsomlo]

attempting to build e44d1d4 on ppcle64 fails with the same error as main, earlier:

...
Passed qlf_k6n10f-t_mem0.ys
Warning: delay target has not been set via SDC or scratchpad; assuming 12 MHz clock.
Warning: Complex async reset for dff `\Q'.
Warning: Resizing cell port TB.uut.data_out from 8 bits to 32 bits.
Warning: Resizing cell port TB.uut.address_in_r from 10 bits to 8 bits.
Warning: Wire TB.\rq_b [7] is used but has no driver.
Warning: Wire TB.\rq_b [6] is used but has no driver.
Warning: Wire TB.\rq_b [5] is used but has no driver.
Warning: Wire TB.\rq_b [4] is used but has no driver.
Warning: Wire TB.\rq_b [3] is used but has no driver.
Warning: Wire TB.\rq_b [2] is used but has no driver.
Warning: Wire TB.\rq_b [1] is used but has no driver.
Warning: Wire TB.\rq_b [0] is used but has no driver.
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
make[1]: *** [run-test.mk:71: qlf_k6n10f-t_mem1.ys] Segmentation fault (core dumped)
make[1]: Leaving directory '/builddir/build/BUILD/yosys-0.51-build/yosys/tests/arch/quicklogic/qlf_k6n10f'
...

Here's a(nother?) copy of t_mem1.log

[KrystalDelusion]

That actually appears to be a different error, signal 11/segfault instead of signal6/abort... But both in the same place. Something is going very wrong there. Rather than running the full test suite, are you able to build Yosys (or reuse a previous build you still have it) and run this script:
script.ys

read_verilog << EOF
module double_sync_ram_sdp #(parameter DATA_WIDTH_A=10, ADDRESS_WIDTH_A=16, DATA_WIDTH_B=10, ADDRESS_WIDTH_B=16)
(
    input  wire                        write_enable_a, clk_a,
    input  wire  [DATA_WIDTH_A-1:0]    data_in_a,
    input  wire  [ADDRESS_WIDTH_A-1:0] address_in_r_a, address_in_w_a,
    output wire  [DATA_WIDTH_A-1:0]    data_out_a,

    input  wire                        write_enable_b, clk_b,
    input  wire  [DATA_WIDTH_B-1:0]    data_in_b,
    input  wire  [ADDRESS_WIDTH_B-1:0] address_in_r_b, address_in_w_b,
    output wire  [DATA_WIDTH_B-1:0]    data_out_b
);

    sync_ram_sdp #(
        .DATA_WIDTH(DATA_WIDTH_A),
        .ADDRESS_WIDTH(ADDRESS_WIDTH_A)
    ) a_ram (
    .write_enable(write_enable_a),
    .clk(clk_a),
    .data_in(data_in_a),
    .address_in_r(address_in_r_a),
    .address_in_w(address_in_w_a),
    .data_out(data_out_a)
    );

    sync_ram_sdp #(
        .DATA_WIDTH(DATA_WIDTH_B),
        .ADDRESS_WIDTH(ADDRESS_WIDTH_B)
    ) b_ram (
    .write_enable(write_enable_b),
    .clk(clk_b),
    .data_in(data_in_b),
    .address_in_r(address_in_r_b),
    .address_in_w(address_in_w_b),
    .data_out(data_out_b)
    );

endmodule // double_sync_ram_sdp

module sync_ram_sdp #(parameter DATA_WIDTH=8, ADDRESS_WIDTH=10)
   (input  wire                      clk, write_enable,
    input  wire  [DATA_WIDTH-1:0]    data_in,
    input  wire  [ADDRESS_WIDTH-1:0] address_in_r, address_in_w,
    output wire  [DATA_WIDTH-1:0]    data_out);

  localparam WORD  = (DATA_WIDTH-1);
  localparam DEPTH = (2**ADDRESS_WIDTH-1);

  reg [WORD:0] data_out_r;
  reg [WORD:0] memory [0:DEPTH];

  always @(posedge clk) begin
    if (write_enable)
      memory[address_in_w] <= data_in;
    data_out_r <= memory[address_in_r];
  end

  assign data_out = data_out_r;

endmodule // sync_ram_sdp

EOF
debug synth_quicklogic -family qlf_k6n10f -top double_sync_ram_sdp

I'm not sure if it will work, but could you also try to call it with yosys --trace script.ys