Longstanding failing tests - clang-tidy, MachO, Polly

Project Infrastructure LLVM Dev List Archives
1

Hi,

A few tests seem broken for a long time, some for more than a month. Would it possible for respective owners to take a look please?

I’m at checkout 133a7e631cee97965e310f0d110739217427fd3d, compiling on Windows 10.

These tests fail with Visual Studio 2019:

Failing Tests (7):

Clang Tools :: clang-tidy/checkers/cert-mem57-cpp-cpp17.cpp

Clang Tools :: clang-tidy/checkers/performance-noexcept-move-constructor-fix.cpp

LLVM :: MC/MachO/gen-dwarf-cpp.s

LLVM :: MC/MachO/gen-dwarf-macro-cpp.s

LLVM :: MC/MachO/gen-dwarf-producer.s

LLVM :: MC/MachO/gen-dwarf.s

Polly :: ScopInfo/memset_null.ll

Expected Passes : 57692

Expected Failures : 283

Unsupported Tests : 1941

Unexpected Failures: 7

The clang-tidy tests fail since end of November-December.

The MachO tests fail since about the beginning of December.

The Polly test fails since a few days ago.

(see below for more info)

I’m using the following cmake cmd-line:

cmake -GNinja %ROOT%/llvm -DCMAKE_BUILD_TYPE=Release -DLLVM_OPTIMIZED_TABLEGEN=ON -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_LIBXML2=OFF -DCMAKE_C_COMPILER=“%VS2019%/bin/HostX64/x64/cl.EXE” -DCMAKE_CXX_COMPILER=“%VS2019%/bin/HostX64/x64/cl.EXE” -DCMAKE_LINKER=“%VS2019%/bin/HostX64/x64/link.EXE” -DLLVM_ENABLE_PROJECTS=“llvm;clang;lld;clang-tools-extra;compiler-rt;mlir;polly” -DLLVM_ENABLE_PDB=ON -DLLVM_POLLY_LINK_INTO_TOOLS=ON

These tests fail with Clang 9.0.1:

Failing Tests (3):

Clang Tools :: clang-tidy/checkers/cert-mem57-cpp-cpp17.cpp

Clang Tools :: clang-tidy/checkers/performance-noexcept-move-constructor-fix.cpp

Polly :: ScopInfo/memset_null.ll

Expected Passes : 57727

Expected Failures : 283

Unsupported Tests : 1911

Unexpected Failures: 3

1 warning(s) in tests

I’m using the following cmake cmd-line:

cmake -GNinja %ROOT%/llvm -DCMAKE_BUILD_TYPE=Release -DLLVM_OPTIMIZED_TABLEGEN=ON -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_LIBXML2=OFF -DCMAKE_C_COMPILER=“%LLVM%/bin/clang-cl.EXE” -DCMAKE_CXX_COMPILER=“%LLVM%/bin/clang-cl.EXE” -DCMAKE_LINKER=“%LLVM%/bin/lld-link.EXE” -DLLVM_ENABLE_PROJECTS=“llvm;clang;lld;clang-tools-extra;compiler-rt;mlir;polly” -DLLVM_ENABLE_PDB=ON -DLLVM_POLLY_LINK_INTO_TOOLS=ON -DLLVM_ENABLE_LLD=ON

Thanks in advance!

Alex.

2

I just XFAIL’ed the polly test; it was also failing on the polly bots.

The other tests you mentioned are not failing on any of the bots on lab.llvm.org, as far as I can tell, including http://lab.llvm.org:8011/builders/clang-x64-windows-msvc , which runs a similar configuration to yours. So it’s going to be hard for anyone without your exact environment to reproduce the issues.

-Eli

3

I’m seeing this on two different machines, with completely different hardware. The git checkout is clean.

I’ve tried again, with the exact cmake cmd-line used on the MSVC bot, it fails on the same tests.

The only difference I see is that the bot uses MSVC 16.3.7, whereas I use the latest 16.4.3. The first 16.4 was released at the beginning of December, and it’s about the time where I started seeing the issues. The tests might fail because of the new MSVC optimizer, this doesn’t happen on Debug builds.

I’m also occasionally seeing crashes in opt, in LLVM :: Transforms/InstCombine/strcpy-2.ll, but this is not 100% repro (using the exact cmd-line as on the bot):

FAIL: LLVM :: Transforms/InstCombine/strcpy-2.ll (35388 of 35388)

******************** TEST ‘LLVM :: Transforms/InstCombine/strcpy-2.ll’ FAILED ********************

Script:

4

error: command failed with exit status: 3221225477

3221225477= 0xC0000005 = access violation. opt crashed with a bad pointer deref. Hopefully you can repro with a debug build and get a stack dump.

–paulr

5

The gen-dwarf* test failures actually seem like an MSVC compiler bug. This variable somehow gets folded to true with MSVC, and extra unexpected relocations are produced:
https://github.com/llvm/llvm-project/blob/master/llvm/lib/MC/MCDwarf.cpp#L1141
I will try to reduce it. I suspect it requires this specific MSVC release to reproduce, and our buildbots must not have it.

6

So, for this test case:

extern “C” void shouldBeUnconditional();
extern “C” void shouldBeConditional();
extern “C” void otherCall();
void testFn(bool Bool1, bool Bool2) {
Bool1 |= Bool2;
shouldBeUnconditional();
if (Bool1)
shouldBeConditional();
if (Bool2) {
otherCall();
if (Bool1)
otherCall();
}
}

MSVC generates this buggy asm:

$ cl -c -Fat.asm msvc-bool-bug.cpp -O2
Microsoft (R) C/C++ Optimizing Compiler Version 19.24.28315 for x64
Copyright (C) Microsoft Corporation. All rights reserved.

msvc-bool-bug.cpp

$ cat t.asm
…
; Line 6
call shouldBeUnconditional
; Line 8
call shouldBeConditional

…

There is no conditional branch between these two calls, but if both Bool1 and Bool2 are false, the second call should not execute.

I went to file the issue, but I suspect that this report is a duplicate:
https://developercommunity.visualstudio.com/content/problem/845933/miscompile-boolean-condition-deduced-to-be-always.html

I posted my repro there.

It’s not clear if we should do anything in LLVM to work around the problem, or if we should just wait for the next release.

7

It's not clear if we should do anything in LLVM to work around
the problem, or if we should just wait for the next release.

Wherever we talk about supported versions, we should say that
this specific MSVC is known to have a problem.
--paulr

8

Would about just disabling optimizations for that function, for the known versions that fail?

#if defined(_MSC_VER) && (_MSC_VER >= 1923) && (_MSC_VER < 1925)
#pragma optimize("", off)
#endif

Supposedly this will be fixed in VS2019 16.5 (which corresponds to 1925 above)

-----Message d'origine-----