In D93951#2523886, @wallace wrote:

@stella.stamenova , is that build a Debug or Release build? I think that will help me determine why it's failing

I am seeing this consistently fail on our internal Ubuntu bot:

It looks like this broke the windows lldb bot:

It looks like this broke the windows LLDB buildbot: http://lab.llvm.org:8011/#/builders/83/builds/2795

This broke the windows mlir bot. Please fix it or revert it:

In D92425#2428952, @teemperor wrote:

In D92425#2428844, @stella.stamenova wrote:

This caused failures on the Windows lldb buildbot:

http://lab.llvm.org:8011/#/builders/83/builds/1294

Tests have to have unique names, so the two new added tests that use TestCase as the class name are both trying to write to the same log file and failing to do so.

Thanks, fixed.

FWIW, this (frankly silly) requirement is actually supposed to be fixed by D83767.

This caused failures on the Windows lldb buildbot:

In D90589#2393110, @csigg wrote:

In D90589#2391801, @stella.stamenova wrote:

onnx-mlir (https://github.com/onnx/onnx-mlir) is currently using parseDimAndSymbolList. Is the intention for this function to not be available outside of mlir any more? I notice it no longer has any uses inside mlir either.

It's now private to AffineOps.cpp. Maybe the easiest would be to export it again from there. Would that work for onnx?

onnx-mlir (https://github.com/onnx/onnx-mlir) is currently using parseDimAndSymbolList. Is the intention for this function to not be available outside of mlir any more? I notice it no longer has any uses inside mlir either.

It looks like this broke the windows lldb buildbot:

This test is failing on the Windows bot:

This change broke the windows lldb bot:

@frgossen , Thanks! Let me know if you need any help investigating.

In D89354#2366718, @rriddle wrote:

In D89354#2366600, @stella.stamenova wrote:

I haven't had a chance to debug this yet, but we are seeing failures in the mlir tests on Windows Debug that appear to be caused by this change. The failures are:

Sorry about that. Should be fixed by 235dfcf70abca65dba5d80f1a42d1485bab8980c.

In D90379#2367830, @frgossen wrote:

Unfortunately, I could not reproduce this failure,
I tried with gcc/g++ (Debian 10.2.0-9) 10.2.0.

I haven't had a chance to debug this yet, but we are seeing failures in the mlir tests on Windows Debug that appear to be caused by this change. The failures are:

We are seeing a failure in the mlir build on Ubuntu with gcc/g++ since these two changes went in:

In D88977#2356948, @sammccall wrote:

Oh wow, I think those are different pointers to the same string, and MSVC+Debug is the only configuration that doesn't fold them together.

So this is just a dumb bug in the test. I just pushed 1a1aad9156407bc891e2738e9877c03bd594e67f which should fix it, please let me know if it doesn't!

In D88977#2355654, @sammccall wrote:

No, not expected... can you provide more details?
Is this on a public LLVM buildbot I missed somehow?

It looks like this broke the windows lldb bot:

load-pdb is still failing on the Windows bot. Can you please commit a fix soon or revert the change?

The new test fails on Windows when we compile Debug (instead of Release). Is that expected?

I ask because I'm still trying to figure out why 899 LLDB tests started failing for me on Friday. (Actually, it was 936 tests, but I fixed 37 of them with a fix to a line that was introduced almost a year ago. I have not idea why the problems just started appearing on the 9th.)

It looks like this changed caused a failure on the windows bot and your follow up change to fix the test left it still broken. Can you have a look?

In D88850#2315053, @aganea wrote:

In D88850#2314943, @stella.stamenova wrote:

In D88850#2312893, @aganea wrote:

@stella.stamenova Strangely, your initial bug description sounds like a deadlock initiated by tar_version.communicate() in https://github.com/llvm/llvm-project/blob/f7941d98091827b8d0b6fdabb731e38c99f44b13/lld/test/lit.cfg.py#L110
Are the lit tests using python 3.6 and not the 2.7 that you seem to have installed as well? In any case, I wonder if setting stderr=open(os.devnull) at lld/test/lit.cfg.py#L108, would fix the issue? Or perhaps just check the 'Threads' tab in Process Explorer on tar.exe, see why it is blocked.

It does, doesn't it! But it's not. If I manually kill tar.exe, then any of the tests that use the git tools time out and fail as well, because all of the tools hang similarly. I attached a debugger to tar.exe after it hung and it is getting an access violation when trying to call GetCommandLineA, so I ran the tests as a different user and they passed. It looks like the tools that come with git can't run successfully under an account that has restricted permissions while the tools that come with GnuWin32 can (also, any other tools we are using in the tests run just fine under the same restricted account, the git tools are the exception). This makes me question whether using the git tools by default is the right choice - the failure was not obvious and not easy to track down. Granted, it is not one that will likely happen on a developer machine, but anyone who is trying to set up automated testing on Windows might (and likely should) be using a restricted account. If we do decide to proceed with using the git tools by default, this should at least be documented and gnuwin32 should be an alternative. Thoughts?

Thanks for investigating! Isn't that related to access rights to the binaries, rather than an issue with the Git tools?

In D84380#2314645, @hans wrote:

It seems confusing to me to automagically use tools that are not on PATH (or passed in explicitly as cmake flags or similar).

Can't folks who want to use the git tools put them on their PATH?

After this patch I think it's surprising to users why the git tools are used when e.g. the gnuwin tools are the only ones available on PATH.

In D88850#2312893, @aganea wrote:

@stella.stamenova Strangely, your initial bug description sounds like a deadlock initiated by tar_version.communicate() in https://github.com/llvm/llvm-project/blob/f7941d98091827b8d0b6fdabb731e38c99f44b13/lld/test/lit.cfg.py#L110
Are the lit tests using python 3.6 and not the 2.7 that you seem to have installed as well? In any case, I wonder if setting stderr=open(os.devnull) at lld/test/lit.cfg.py#L108, would fix the issue? Or perhaps just check the 'Threads' tab in Process Explorer on tar.exe, see why it is blocked.

In D88850#2312985, @amccarth wrote:

I don't know whether Python and our config tools use the terms consistent, but Win32 is the name of the Windows API used on both 32- and 64-bit processors, Win16 was the API used on 16-bit machines, and Win64 is a made-up term that confuses the issues.

In D84380#2310895, @zturner wrote:

In D84380#2310504, @stella.stamenova wrote:

In D84380#2309885, @stella.stamenova wrote:

In D84380#2309853, @aganea wrote: Maybe if L28 wasn't there, things would work correctly if you already had the required tools in %PATH%? Would you possibly try that please?

I will try it. I'll let you know if it makes a difference.

Yes, that works. We don't end up prepending the lit path and the tests work as before.

For some context, L28 was added because the previous code made the underlying assumption that this variable was defined. Specifically, this:

path = self.lit_config.getToolsPath(lit_tools_dir, config.environment['PATH'], required_tools)

will raise an exception in the case that lit_tools_dir==None. It sounds like you're saying lit_tools_dir = [] in your case. If so, instead of removing this line, can it be changed to if lit_tools_dir != None:?

In D84380#2309885, @stella.stamenova wrote:

In D84380#2309853, @aganea wrote: Maybe if L28 wasn't there, things would work correctly if you already had the required tools in %PATH%? Would you possibly try that please?

I will try it. I'll let you know if it makes a difference.

In D84380#2309853, @aganea wrote: Maybe if L28 wasn't there, things would work correctly if you already had the required tools in %PATH%? Would you possibly try that please?

I will try it. I'll let you know if it makes a difference.

Since this was committed, all of our internal bots (but not the external windows bot!) are hanging when the tests run. I've looked into it some and I noticed a couple of things:

LGTM

This broke some bots:

It looks like this broke the windows lldb buildbot:

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: