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

[Rafael Espíndola via llvm-dev]

On 9 February 2016 at 18:53, Rui Ueyama via llvm-commits
<llvm-commits at lists.llvm.org> wrote:
> 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. :)

How about reporting a bug on clang asking for that warning? :-)

Cheers,
Rafael