On Fri, Jan 9, 2026 at 3:45 PM Daniel Henrique Barboza <[email protected]> wrote: > > > > On 1/9/2026 10:44 AM, Jeffrey Law wrote: > > > > > > On 1/9/2026 12:24 AM, Richard Biener wrote: > >> Please don't any new fold_overflow_warning things, those are borderly > >> useless (IMO all of them should be wiped). > >> > >> No comments on the rest, I didn't review the discussion. > > Blame me for that. I saw a note somewhere in our docs that made me > > believe it was a requirement for these kinds of cases. It's certainly > > simpler if we don't have to do that! > > The note is on the docs of the macro in gcc/tree.h: > > /* True if overflow is undefined for the given integral or pointer type. > We may optimize on the assumption that values in the type never > overflow. > > IMPORTANT NOTE: Any optimization based on TYPE_OVERFLOW_UNDEFINED > must issue a warning based on warn_strict_overflow. In some cases > it will be appropriate to issue the warning immediately, and in > other cases it will be appropriate to simply set a flag and let the > caller decide whether a warning is appropriate or not. */ > #define TYPE_OVERFLOW_UNDEFINED(TYPE) \
Ah, we should remove that note. -Wstrict-overflow proved useless IMO, it's way too noisy as it diagnoses when the compiler relies on overflow not happening, not diagnosing when it possibly happens. That's not a very useful diagnostic to have - it does not point to a possible problem in the code (we could as well diagnose _all_ signed arithmetic operations for the same argument that we might eventually rely on overflow not happening). The documentation about -Wstrict-overflow actually says this. UBSAN is a _much_ more useful tool given it diagnoses signed overflow that actually happens! Richard. > > Daniel > > > > > > jeff >
