[llvm-dev] Builder lld-x86_64-win7 is back
Rui Ueyama via llvm-dev
llvm-dev at lists.llvm.org
Tue Feb 9 15:53:20 PST 2016
On Tue, Feb 9, 2016 at 3:47 PM, Joerg Sonnenberger via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Tue, Feb 09, 2016 at 03:09:01PM -0800, Rui Ueyama wrote:
> > On Tue, Feb 9, 2016 at 3:03 PM, Joerg Sonnenberger via llvm-commits <
> > llvm-commits at lists.llvm.org> wrote:
> > > On Tue, Feb 09, 2016 at 02:40:06PM -0800, Rui Ueyama via llvm-commits
> > > wrote:
> > > > Tried to fix the warning, and I'm not now sure if the warning makes
> > > sense.
> > > > These "'~': zero extending '<smaller integer type>' to 'int64_t' of
> > > greater
> > > > size" warning may be annoying as it is issued for code like "int64_t
> x =
> > > > ~<some-int32_t-var>".
> > >
> > > This sounds like something were the semantic of the code is not
> > > obviously what was originally intended.
> > >
> > So you thought that was useful? Then why doesn't clang/gcc warn on that?
> Good question :) I mean consider:
> int64_t x;
> x &= ~7;
> was the intention here really to clear the upper half of x as well? Same
> question for a variable instead of 7.
I understand the point. It also warned a case such that you have a function
f(uint64_t) and a variable x uint32_t and call f(~x). It may be hard to
identify that the upper 32 bits are filled with zeros from local context.
However, my question still stands. :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev