[Bug/Win11] Street Fighter Zero 3 (Japan) temporary yellow tint on startup and menu with GCC LTO builds

[Immersion95]

Street Fighter Zero 3 (Japan) has a temporary yellow tint with Beetle Saturn.

During startup, the first logo/loading screen appears yellowish. The main menu also gets a yellow/brown tint for a few seconds before returning to normal.

This seems to have been introduced by recent commits, since the issue does not happen in standalone Mednafen.

I attached a video showing the issue (at 12s and 20s).

Street_Fighter_Zero_3_Japan_yellow_tint_issue_with_audio.mp4

Tested on 8f0d69a

The issue isn't present on Mednafen 1.32.1

Edit - June, 14th : Additional finding

The issue appears to be build-configuration dependent.

I tested the same commit with different Windows x64 builds:

• Windows x64, MSYS2, non-LTO, correct rendering --> no yellow tint.
• Windows x64, MSYS2, LTO --> yellow tint appears.
• Windows x64, MSYS2, LTO without -fipa-pta --> yellow tint still appears.

So the issue does not seem to be caused by -fipa-pta specifically. It looks triggered by GCC LTO itself, or by undefined behavior exposed by LTO.

A non-LTO build from the same commit renders Street Fighter Zero 3 correctly, while an LTO-enabled build shows the yellow tint.

[Immersion95]

I built the core myself with Github workflow on top of 8f0d69a and the problem is gone.

https://github.com/Immersion95/beetle-saturn-libretro/actions/runs/27494305600

It seems the problem comes from the gitlab workflow.

[Immersion95]

The issue appears to be LTO-dependent.

On Windows x64, the same commit was tested with:

• LTO=: correct rendering
• default LTO=1: yellow tint
• LTO=1 without -fipa-pta: yellow tint

So this does not seem to be caused by -fipa-pta; the problem is triggered by GCC LTO itself or by undefined behavior exposed by LTO.

A non-LTO build from the same commit renders Street Fighter Zero 3 correctly.

[Immersion95]

#80 disables LTO in the official build

[pstef]

If it is UB then what #80 does is paper over it, not solve.

[i30817]

Debugging link time optimization ub bugs is hard, lto is a switch for a collective of optimization techniques all at once. It would be nice if there was a bisect technique that operated on the compilation unit level so you could "divide" code until you track down first the file, then the functions affected.

[i30817]

Google ai (yes I know, the link goes to the actual llvm docs) tells me clang does have such a feature.

https://llvm.org/docs/OptBisect.html

This is ofc assuming the bug still exists in llvm as opposed to gcc, which is kind of unlikely.

It also told me of a way to use python and gcc but that goes only to the file level apparently. Ask it yourself.

Edit: actually that llvm only appears to bisect which particular optimization is causing the effect, not where. I suppose it has other ways after.

Gcc, according to google ai supposedly has

__attribute__((optimize("no-lto"), noinline))

To disable it at the function level but I wouldn't trust google ai without verification (as this very post showed for llvm)