Skip to content

Conversation

@gkirchou
Copy link

@gkirchou gkirchou commented Dec 2, 2025

To stop the warning.

Reproduce steps:

./configure --enable-optimizations --with-lto
make -s -j $(nproc);

@gkirchou gkirchou requested a review from markshannon as a code owner December 2, 2025 15:00
@bedevere-app

This comment was marked as resolved.

@StanFromIreland
Copy link
Member

StanFromIreland commented Dec 2, 2025

We already have #132376 open for this (we also had #134207, but that's closed now).

@chris-eibl
Copy link
Member

See my comment on the issue. There is prior art and initializing in this hot path to silence a false positive warning is not (my) preferred solution.

@picnixz
Copy link
Member

picnixz commented Dec 2, 2025

Initialization in a hot path is not desired and it's also a false positive. I'm going to close this PR, sorry.

@picnixz picnixz closed this Dec 2, 2025
@vstinner
Copy link
Member

vstinner commented Dec 2, 2025

IMO this change is a reasonable fix for the warnings.

@picnixz
Copy link
Member

picnixz commented Dec 2, 2025

I think we should have checked the produced assembly to see whether this introduces a true overhead in an optimized build. Personally, I think the pragmas are fine (we do this elsewhere) but we could disable them in DEBUG mode so that we correctly catch a possible issue when it's not optimized.

@chris-eibl
Copy link
Member

chris-eibl commented Dec 2, 2025

Well, we can check and then we know for this compiler and version we've checked. And are at the mercy of all compilers and versions that they hopefully behave the same - i.e. do not produce needless initialization code we've put in to silence a false positive warning.

@chris-eibl
Copy link
Member

I think the pragmas are fine

I think so, too. It is good to have less warnings. It is even better to have less false positive warnings :)

@chris-eibl
Copy link
Member

OTOH, _PyEvalFramePushAndInit_Ex is not very hot and compared to what the function is doing, the initialization most probably will be lost in noise.
It just bugs me to let the compiler emit unneeded code 1 and to have to think about whether it is impactful or not when I know it definitely isn't needed ...
So I'll leave it up to others to decide how to get rid of the warning and am just happy when the warning is gone :)

Footnotes

  1. maybe I should use "potentially unneeded code": some compilers might be smart enough to omit it, most probably those that don't emit the warning :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants