#12323: delete ctor of AllGatherFusedOpSignaler

[marty1885]

Ticket

Link to Github Issue

Problem description

Due to the ctor of AllGatherFusedOpSignaler is essentially the default constructor. The expression std::optional<AllGatherFusedOpSignaler> all_gather_fused_op_signaler = AllGatherFusedOpSignaler(); triggers GCC14's uninitialized variable detection.

What's changed

Delete the default constructor.

Checklist

• Post commit CI passes
• Blackhole Post commit (if applicable)
• Model regression CI testing passes (if applicable)
• New/Existing tests provide coverage for changes

[ayerofieiev-tt]

Or this constructor has to be removed

    MatmulFusedOpSignaler() {}

[marty1885]

Oops.. forced pushed the wrong commit and GH auto closed the PR. Fixed now.

@ayerofieiev-tt Still compiling on my machine but I think your solution is better.

[marty1885]

@ayerofieiev-tt This patch works well on my side. Can you help merge it into main?

[tt-rkim]

@TT-billteng @ttmchiou Looks like gcc 14 was released literally this year. We're still quite limited on runners. Should we keep it to gcc-12 that's tested on CI? Nightlies etc?

[marty1885]

@tt-rkim I understand TT's difficulties keeping up with new compilers. I also have no problem keep upstreaming these patches when breaks do happen. The last thing I want is maintaining a branch with piles of patches just so I can get tt-metal working on my machine but TT still gotta reinvent the wheel when the next version of Ubuntu released. It also complicates the process of me upstreaming bug fixes as things have to be backported instead of a clean branch.

Can TT accept these patches as-is and we keep an eye on gcc-12 compatibility?

[tt-rkim]

Just running this to be sure: https://github.com/tenstorrent/tt-metal/actions/runs/10775571014

[tt-rkim]

And we are okay with that workflow, if you are okay with it

[marty1885]

I would prefer if TT can have newer GCC in CI. But open source is where downstream developers will do anything and everything to get their code working. And expect upstream to accept the patches unless there's a good reason not to. Mutual help.

So yes, I'm happy keep upstreaming these fixes if TT doesn't have the resource.

[tt-rkim]

Once we get more compute resources, we should be able to support more GCC releases. I'm wondering given the stage we are currently in, if it's worth just upgrading our gcc across the board and requiring 14 or higher.

[TT-billteng]

which OS natively supports GCC 14 currently?

[marty1885]

Ubuntu 24.04 (package: gcc-14), Fedora 40, Arch Linux