Builder lld-x86_64-win7​ is back

Hello everyone,

The builder http://lab.llvm.org:8011/builders/lld-x86_64-win7​ is up and running. It builds lld and runs lld tests for each commit.
The build shows 11 warnings, everything else is green.

Do you think it is feasible to treat warnings as errors, or better keep it this way for now?

Thanks

Galina

Hello everyone,

http://lab.llvm.org:8011/builders/lld-x86_64-win7 is a new fast lld builder to host windows.
It is fast and build every commit, so blame lists are accurate.
Please keep an eye and let me know if you would see any issue.

Thanks

Galina

Most of the warnings are actually in LLVM code. Any reason we don't
see it in other bots?

Cheers,
Rafael

Most of the warnings are actually in LLVM code. Any reason we don't
see it in other bots?

Cheers,
Rafael

Reid said that he has disabled non-x86-64 backends for the clang/win64 buildbot, so maybe this is the first time for us to see these warnings. But all of them seem to be easily fixable, so why don’t we do that.

Sounds good to me :slight_smile:

Cheers,
Rafael

Tried to fix the warning, and I’m not now sure if the warning makes sense. These “’~’: zero extending ‘’ to ‘int64_t’ of greater size” warning may be annoying as it is issued for code like “int64_t x = ~<some-int32_t-var>”.

Probably we should disable the warning instead?

This sounds like something were the semantic of the code is not
obviously what was originally intended.

Joerg

> 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 :slight_smile: 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.

Joerg

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. :slight_smile:

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

Cheers,
Rafael