[llvm-dev] Builder lld-x86_64-win7​ is back

[Rui Ueyama via llvm-dev]

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...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160209/46d651a6/attachment.html>