Adding Nate who is going to own the Windows MLIR Buildbot during my maternity :).

Make check-mlir be the only checks that run

Add AMDGPU and NVPTX to the targets

In D75459#1903822, @nicolasvasilache wrote:

@stella.stamenova this seems related: https://developercommunityapi.westus.cloudapp.azure.com/content/problem/110435/not-compile-time-constant-expression.html
This is marked as "fixed in: visual studio 2019 version 16.2"

I'm seeing an error on Windows with this:

Thanks! This works.

@gkistanova: We have the machine setup to connect to silent master (buildmaster_host = 'lab.llvm.org', port = 9994) as we expect some failures. Let me know if we need to do anything else other than commit the patch and wait for a reboot. Thanks!

This change broke the MLIR build on Windows.

It looks like this broke the Windows LLDB Buildbot:

In D73999#1887784, @MaskRay wrote:

In D73999#1887767, @stella.stamenova wrote:

Looks like this broke the Windows LLDB bot:

http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/14056

The tests used wrong sh_flags caught by this assembler change.

Hopefully fixed by ebee131259719fa9c06cd346e21ace3fa8ac0888. I made a typo in my description. sh_flags was incorrect, not sh_type.

Looks like this broke the Windows LLDB bot:

It looks like this broke the Windows LLDB Buildbot:

In D73534#1880790, @stella.stamenova wrote:

I am not sure this was the cause of the failure, but other than your patches, there was only one other change in the first failing build. I have not had time to fully investigate yet.

I am not sure this was the cause of the failure, but other than your patches, there was only one other change in the first failing build. I have not had time to fully investigate yet.

It looks like this broke the windows lldb bot:

In D74475#1875674, @JDevlieghere wrote:

Yup, looks like that was it, the bot is green again: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/13740

This broke the Windows LLDB Buildbot:

Either this change or D74243 broke the windows bot and I do suspect D74243 but have not confirmed it yet:

Either this change or D74475 broke the windows bot and I suspect it's not D74475:

Thanks for doing this!

If this is going to take more than a day or two to fix at this point, I think you should at least XFAIL the tests that are failing on Windows because any runs that include MLIR right now are red and will stay so until your fix lands. You can un-XFAIL them once you verify that they pass with the fix.

LGTM and I verified that the test now passes.

CHECK-DAG makes no difference. The output simply does not contain the expected values as written. The test expects to find @_ocml_tanh_f32 (e.g. llvm.func @_ocml_tanh_f32(!llvm.float) -> !llvm.float), but the output is:

These two tests are failing on Windows like so:

This change is causing a build break on Windows (which was hidden by the Hexagon build break you just fixed :().

With the latest VS 2019, the error is still the same (MSVC 19.24).

No difference (I would have been surprised, really, as the issue doesn't appear to be with the way the constructor is declared, but with how it is used):

In D72310#1820632, @nicolasvasilache wrote:

my apologies, I lost track of this and do not have an easy repro atm, Aart is taking a shot at it.

This also broke a number of the tests on the Windows LLDB bot, so when you get around to resubmitting the change with a fix, please make sure the bot doesn't get broken again: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/12551

This introduced a failure on the Windows LLDB bot (there were already other failing tests though, so maybe you missed it):

This broke the Windows LLDB bot:

It looks like this also caused a failure on the Windows LLDB bot:

This broke the windows LLDB bot:

Sorry, I was out on vacation until today :).

Sadly, I think this broke the windows bot now (assuming it got applied to staging, otherwise I have to figure out what did):

This is broken on Windows. I moved the Buildbot to staging to resolve some of the issues with the move to the monorepo, so you can see the failures here:

Thanks @labath

Oh, and TestCallOverridenMethod still has some failures on Windows:

In D68130#1713620, @teemperor wrote:

Yeah, seems like constructing objects in expressions isn't implemented on Windows. I'm not sure if there is a reliable way to test that constructors aren't shadowed by these global functions if constructors themselves don't work on Windows, but I filed llvm.org/pr43707 for the underlying bug and x-failed the tests. Will push in a few minutes.

Unfortunately, this is failing on the windows bot:

Please also file a bug and reference it in the skip statement.

The tests passed in my setup. After you commit this, please monitor the windows Buildbot (it currently has a couple of failures, so you will have to check it and not rely on an email).

This is causing a failure on the Windows Bot:

In D68980#1709967, @mstorsjo wrote:

In D68980#1709931, @labath wrote:

In D68980#1709884, @stella.stamenova wrote:

The two things that come to mind are the path to clang-cl (which is sometimes a clang build and sometimes installed on the system as part of a VS installation or an LLVM installation) as well as the path to the linker when it is needed. This is most often an issue in the case of a VS install - I don't remember all the details any more, but I believe that before Zach added the script, we were often picking up the wrong clang-cl and ending up not being able to compile the tests at all.

Thanks.

Was this during a standalone lldb build? In a non-standalone build, lit should definitely prefer the just-built clang/lld (and if it doesn't, it should be fixed to do that). The situation is more complicated for a standalone build because the clang binary is sort of out of our control. But, in this case, I don't see how having build.py around can help, because the information about which clang to use has to come externally anyway...

How do tests like test/Shell/Register/x86*.test work in such standalone builds then? They use lines like these:

# XFAIL: system-windows
# REQUIRES: native && target-x86_64
# RUN: %clangxx -fomit-frame-pointer %p/Inputs/x86-64-gp-read.cpp -o %t
# RUN: %lldb -b -s %s %t | FileCheck %s

(The XFAIL for system-windows, at least in this test, when I tried it out, seemed to relate to the fact that register read --all on windows didn't include all the 32 bit subregisters.)

If tests already can use such constrcuts, I don't see why we couldn't use # RUN: %clang_cl .., as lit sets up %clang_cl in the same way as %clangxx.

In D68980#1709968, @mstorsjo wrote:

In D68980#1709954, @stella.stamenova wrote:

Both. Again, it's been a long time, but when we use VS for building, the environment already contains a path to clang-cl so regardless of whether the build is standalone or not, the build gets confused about which clang-cl to use. @mstorsjo might want to update the tests to use clang-cl but then make sure that the update works on the Windows Buildbot (or similar environment) before committing.

Is there any way of checking whether it works on this buildbot, other than committing (after doing best effort testing of it in whatever comparable windows environments I have available)?

In D68980#1709931, @labath wrote:

In D68980#1709884, @stella.stamenova wrote:

The two things that come to mind are the path to clang-cl (which is sometimes a clang build and sometimes installed on the system as part of a VS installation or an LLVM installation) as well as the path to the linker when it is needed. This is most often an issue in the case of a VS install - I don't remember all the details any more, but I believe that before Zach added the script, we were often picking up the wrong clang-cl and ending up not being able to compile the tests at all.

Thanks.

Was this during a standalone lldb build? In a non-standalone build, lit should definitely prefer the just-built clang/lld (and if it doesn't, it should be fixed to do that). The situation is more complicated for a standalone build because the clang binary is sort of out of our control. But, in this case, I don't see how having build.py around can help, because the information about which clang to use has to come externally anyway...

In D68980#1709866, @labath wrote:

In D68980#1709830, @stella.stamenova wrote:

I suspect that using clang-cl directly will not work though - the script does a lot of the setup needed to run clang-cl correctly today (previously the environment for clang-cl was not setup correctly and the tests either didn't pass or passed for the wrong reasons, so using build.py has been a huge improvement).

Can you elaborate on what kind of setup do you have in mind here? Bear in mind that here we are only talking about tests that do not use any system libraries or headers, and which already run fine on a linux system which does not have any windows-specific stuff installed. With those restrictions, I don't see what can be possibly gained from using build.py. The only thing I can see it possibly doing is to clear some environment variables which might otherwise be present and confuse clang-cl. However, that's something that can be easily done in lit.

I haven't fully debugged this, but it looks like this change caused a failure on the Windows LLDB bot. There was already another failure, so you probably didn't get an email:

This change looks fine assuming all the tests continue to pass.

This is still failing on the Windows bot. Please fix it ASAP or revert it.

In D67347#1706405, @stella.stamenova wrote:

It looks like this changed fixed at least one of the XFAILed tests on Windows:

http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/9751

So now the test results would be red because of the unexpectedly passing test (if there wasn't another failure). Could you have a look at whether any of the other tests that were XFAILed for the same bug are also now passing and remove the expected failure tags as appropriate?

It looks like this changed fixed at least one of the XFAILed tests on Windows:

This is failing on the windows bot. There was already another failure, so you probably didn't get an email:

It looks like this broke one of the tests on the Windows LLDB bot:

The windows LLDB bot also has the same failure: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/9600

Thanks for taking care of this!

This broke the windows build: http://lab.llvm.org:8011/buildslaves/win-py3-buildbot. There was already a test broken from earlier today, so you might not have gotten an email.

This broke the windows bot. A couple of other issues have shown up and been fixed since, but this change is still causing a break:

This broke the windows bot:

LGTM as long as all the tests still pass

Is there a way to reduce some of the code duplication? The more duplication there is, the harder it is to maintain.

It looks like this broke the windows build bot:

LGTM. Please monitor the windows Buildbot to make sure it still passes after your commit though.

I think this is actually fine. The change that was needed for multi-configuration generators is how the two default paths for the compilers are set. The USE variables were to make it explicit when we will or we won't override the user-set compiler. As long as we are OK overriding it if they set it to an empty string (which is probably an error, anyway), this change is good.

LGTM

It looks like this changed caused 30 or so of the tests to fail on the Windows bot. It was already broken, so you wouldn't have gotten an email:

This change caused failures on the Windows bot: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/7681 compounding on the existing failures from [lldb] Refactor guard variable checks in IRForTarget