[PATCH] D44559: [Sema] Wrong width of result of mul operation

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In https://reviews.llvm.org/D44559#1048399, @lebedev.ri wrote:

> I'm having a very hard time following this thread. In fact, i can't follow the logic at all.
>
> In https://reviews.llvm.org/D44559#1041007, @rjmccall wrote:
>
> > ...
> >  This patch, however, is contrary to the design of -Wconversion, which does attempt to avoid warning in cases where the user might reasonably see an operation as "really" being performed in its operand type.  If you want to argue that we should change the design of -Wconversion, that is a broader conversation that you should take to cfe-dev.
>
>
> Can you at least point out where the current design goals are documented?


They probably aren't, other than in mailing-list discussions like this.

I remember basing the design off the vision of a white paper that someone working on GCC wrote up.  Maybe it was just this wiki page:

  https://gcc.gnu.org/wiki/NewWconversion

But our design was always more sophisticated than GCC's.  Note the comment at the bottom of that page about how you should write INT_MIN as (-INT_MAX - 1), because otherwise GCC was warning about it!  I don't know how that was ever considered acceptable.

Looking for that paper, I did find this GCC bug:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752

where they had a very similar debate to the one we just had.

The basic tenet of Clang's -Wconversion design, as far as this problem goes, is that users generally ought to be able to ignore most of the technical details of what C calls for with integer promotions and the types of literals; instead, they should generally be able to think of arithmetic as taking place in the narrowest promoted type of the opaque operands used in the expression.  If the actual computation type doesn't include the full range of that theoretical promoted type, that's worth a warning; this can happen when mixing the signedness of operands.  But otherwise they can generally think of the operation as computing a value of that promoted type.  If that operation overflows, so be it — we're not going to warn about the potential for overflow every time the user adds two ints, and by the same token, it doesn't make any sense to warn about every time the user adds two shorts just because the language made this otherwise-unimportant technical decision to do the arithmetic in a wider type.


https://reviews.llvm.org/D44559