- User Since
- Feb 7 2018, 7:04 PM (112 w, 5 d)
Wed, Mar 11
Adding Nate who is going to own the Windows MLIR Buildbot during my maternity :).
Mar 5 2020
Mar 4 2020
Make check-mlir be the only checks that run
Add AMDGPU and NVPTX to the targets
Mar 3 2020
I'm seeing an error on Windows with this:
Thanks! This works.
Mar 2 2020
@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.
Feb 27 2020
Feb 24 2020
It looks like this broke the Windows LLDB Buildbot:
Feb 21 2020
Looks like this broke the Windows LLDB bot:
It looks like this broke the Windows LLDB Buildbot:
Feb 19 2020
Feb 18 2020
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:
Feb 14 2020
Feb 13 2020
This broke the Windows LLDB Buildbot:
Feb 6 2020
Thanks for doing this!
Feb 5 2020
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.
Jan 31 2020
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:
Jan 29 2020
These two tests are failing on Windows like so:
Jan 21 2020
This change is causing a build break on Windows (which was hidden by the Hexagon build break you just fixed :().
Jan 17 2020
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):
Jan 14 2020
Jan 13 2020
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):
Jan 8 2020
Dec 20 2019
This broke the Windows LLDB bot:
It looks like this also caused a failure on the Windows LLDB bot:
Dec 17 2019
This broke the windows LLDB bot:
Dec 9 2019
Sorry, I was out on vacation until today :).
Oct 30 2019
Sadly, I think this broke the windows bot now (assuming it got applied to staging, otherwise I have to figure out what did):
Oct 29 2019
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:
Oct 18 2019
Oh, and TestCallOverridenMethod still has some failures on Windows:
Oct 17 2019
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:
Oct 16 2019
Oct 15 2019
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.
Oct 14 2019
This is still failing on the Windows bot. Please fix it ASAP or revert it.
Oct 11 2019
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:
Oct 8 2019
It looks like this broke one of the tests on the Windows LLDB bot:
Oct 7 2019
The windows LLDB bot also has the same failure: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/9600
Oct 2 2019
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.
Sep 30 2019
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:
Sep 23 2019
Sep 11 2019
This broke the windows bot:
LGTM as long as all the tests still pass
Aug 30 2019
Is there a way to reduce some of the code duplication? The more duplication there is, the harder it is to maintain.
Aug 22 2019
It looks like this broke the windows build bot:
Aug 20 2019
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.
Aug 15 2019
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:
Aug 12 2019
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