https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113852
--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 12 Feb 2024, admin at computerquip dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113852 > > --- Comment #7 from Zachary L <admin at computerquip dot com> --- > (In reply to Richard Biener from comment #6) > > Well, given athat a1 * a2 is carried out in 'int' you are invoking undefined > > behavior if it overflows. GCC assumes that doesn't happen so it's correct > > to elide the diagnostic. Unless you make overflow well-defined with > > -fwrapv. > > > > I think that errors on the right side for the purpose of -Wsign-compare. > > Removing a diagnostic because the program could be ill-formed seems backwards > to me, especially since it seems like there's already logic in performing this > diagnostic. Perhaps I've misunderstood the situation? Well, we could, for each int * int diagnose a "may invoke undefined behavior if overflow happens at runtime" but that's hardly useful. So we want to diagnose cases where it's _likely_ that there's an issue. For the case at hand it's not likely that ushort * ushort invokes undefined behavior (because invoking undefined should be unlikely, very much so). So we choose to not diagnose it as "maybe". Yes, with constexpr evaluation we actually _see_ we invoke undefined behavior and diagnose that. The subsequent diagnostic of -Wsign-compare is then spurious though and IMO should be not given. The error is the integer overflow invoking undefined behavior even - if that didn't happen there would be no issue with comparing signed/unsigned values.
