User Details
- User Since
- Feb 25 2020, 10:20 AM (116 w, 4 d)
Apr 15 2022
I posted this on the commit, sorry! Meant to do it here.
This appears to have broken a number of tests on the Windows buildbot: https://lab.llvm.org/buildbot/#/builders/13/builds/19731
LLVM ERROR: TypeID::get<`anonymous-namespace'::ClonePass>(): Using TypeID on a class with an anonymous namespace requires an explicit TypeID definition. The implicit fallback uses string name, which does not guarantee uniqueness in anonymous contexts. Define an explicit TypeID instantiation for this type using `MLIR_DECLARE_EXPLICIT_TYPE_ID`/`MLIR_DEFINE_EXPLICIT_TYPE_ID` or `DEFINE_EXPLICIT_PRIVATE_INLINE_TYPE_ID`.
This appears to have broken a number of tests on the Windows buildbot: https://lab.llvm.org/buildbot/#/builders/13/builds/19731
LLVM ERROR: TypeID::get<`anonymous-namespace'::ClonePass>(): Using TypeID on a class with an anonymous namespace requires an explicit TypeID definition. The implicit fallback uses string name, which does not guarantee uniqueness in anonymous contexts. Define an explicit TypeID instantiation for this type using `MLIR_DECLARE_EXPLICIT_TYPE_ID`/`MLIR_DEFINE_EXPLICIT_TYPE_ID` or `DEFINE_EXPLICIT_PRIVATE_INLINE_TYPE_ID`.
Apr 13 2022
This is causing failures on the Windows builbot: https://lab.llvm.org/buildbot/#/builders/13/builds/19626/steps/6/logs/stdio
I believe you simply need #include <string> to make MSVC happy.
Mar 23 2022
Mar 22 2022
I believe this change produces a comparison warning with clang:
May 20 2021
May 19 2021
I believe this change causes the assert on the attribute SmallVector (for size >256) to hit when the size isn't specified on Windows debug builds.
May 16 2021
Yes, the fix works! Thanks again.
May 15 2021
Hi Lang,
May 14 2021
I believe this change, or one of the subsequent ones (I can't find them on Differential, sorry), broke a test on the Windows Debug build.
Apr 16 2021
This broke the Windows MLIR buildbot, because algorithm is required for std::min in MSVC.
https://lab.llvm.org/buildbot/#/builders/13/builds/6985/steps/6/logs/stdio
Mar 1 2021
It doesn't look like MSVC likes this use of type. Break in the buildbot here: https://lab.llvm.org/buildbot/#/builders/13/builds/5148. Thanks!
Feb 9 2021
Could you please add #include<algorithm> for RunnerUtils.h? MSVC requires it for std::max/min, resulting in this http://lab.llvm.org:8011/#/builders/13/builds/4283/steps/6/logs/stdio failure. Thanks!
Dec 1 2020
This appears to still be failing on VS2017 after the latest GCC5 fix (although builder is having some trouble, so I'll confirm). http://lab.llvm.org:8011/#/builders/13/builds/2128
Oct 7 2020
I think there may be a small remaining issue on the llvmir-intrinsics.mlir test on Windows, as seen here: http://lab.llvm.org:8011/#/builders/82/builds/40/steps/7/logs/stdio
Jul 9 2020
Jul 8 2020
Unfortunately, this still produces a cryptic error on VS2017:
Jun 12 2020
Jun 11 2020
Jun 10 2020
I believe this change may have broken the Windows buildbot, here: http://lab.llvm.org:8011/builders/mlir-windows/builds/3068
May 29 2020
I believe this change broke the windows buildbot as well, just as an additional data point. http://lab.llvm.org:8011/builders/mlir-windows/builds/2485
1025.187 [461/64/2346] Building CXX object tools\mlir\lib\Dialect\Linalg\Transforms\CMakeFiles\obj.MLIRLinalgTransforms.dir\Loops.cpp.obj
FAILED: tools/mlir/lib/Dialect/Linalg/Transforms/CMakeFiles/obj.MLIRLinalgTransforms.dir/Loops.cpp.obj
C:\PROGRA~2\MICROS~1\2017\COMMUN~1\VC\Tools\MSVC\1416~1.270\bin\Hostx64\x64\cl.exe /nologo /TP -DBUILD_EXAMPLES -DGTEST_HAS_RTTI=0 -DMLIR_CUDA_CONVERSIONS_ENABLED=1 -DMLIR_ROCM_CONVERSIONS_ENABLED=1 -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools\mlir\lib\Dialect\Linalg\Transforms -IE:\build_slave\mlir-x64-windows-ninja\llvm-project\mlir\lib\Dialect\Linalg\Transforms -Iinclude -IE:\build_slave\mlir-x64-windows-ninja\llvm-project\llvm\include -IE:\build_slave\mlir-x64-windows-ninja\llvm-project\mlir\include -Itools\mlir\include /DWIN32 /D_WINDOWS /Zc:inline /Zc:strictStrings /Oi /Zc:rvalueCast /W4 -wd4141 -wd4146 -wd4244 -wd4267 -wd4291 -wd4351 -wd4456 -wd4457 -wd4458 -wd4459 -wd4503 -wd4624 -wd4722 -wd4100 -wd4127 -wd4512 -wd4505 -wd4610 -wd4510 -wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703 -wd4389 -wd4611 -wd4805 -wd4204 -wd4577 -wd4091 -wd4592 -wd4319 -wd4709 -wd4324 -w14062 -we4238 /Gw /MD /O2 /Ob2 /EHs-c- /GR- -UNDEBUG -std:c++14 /showIncludes /Fotools\mlir\lib\Dialect\Linalg\Transforms\CMakeFiles\obj.MLIRLinalgTransforms.dir\Loops.cpp.obj /Fdtools\mlir\lib\Dialect\Linalg\Transforms\CMakeFiles\obj.MLIRLinalgTransforms.dir\ /FS -c E:\build_slave\mlir-x64-windows-ninja\llvm-project\mlir\lib\Dialect\Linalg\Transforms\Loops.cpp
E:\build_slave\mlir-x64-windows-ninja\llvm-project\mlir\include\mlir/IR/PatternMatch.h(192): error C2664: 'mlir::LogicalResult mlir::OpRewritePattern<mlir::vector::TransferWriteOp>::match(SourceOp) const': cannot convert argument 1 from 'SourceOp' to 'mlir::Operation *'
with
[
SourceOp=mlir::vector::TransferWriteOp
]
E:\build_slave\mlir-x64-windows-ninja\llvm-project\mlir\include\mlir/IR/PatternMatch.h(192): note: use of undefined type 'mlir::vector::TransferWriteOp'
E:\build_slave\mlir-x64-windows-ninja\llvm-project\mlir\include\mlir/Dialect/Linalg/Transforms/Transforms.h(20): note: see declaration of 'mlir::vector::TransferWriteOp'May 19 2020
I believe this change broke the build on the Windows VS2017 buildbot, http://lab.llvm.org:8011/builders/mlir-windows/builds/2042. It's not obvious to me why it would generate deeply nested code. Any thoughts? Thanks!
Apr 17 2020
I believe this change pushes clang\lib\Sema\SemaTemplateDeduction.cpp over the 16-bit COFF section limit for Windows Debug builds. Could you please resolve it or add /bigobj to the CMakeFile file for MSVC (see clang\lib\CodeGen\CMakeLists.txt). ERROR C1128 Thanks!
Mar 27 2020
Hey Brooks, do you have a public buildbot so I can try to fix it? What generator are you using?
Mar 26 2020
This patch resolved the issue for our VS build. Thanks! Unfortunately, I don't have any way to test it for Xcode. Should I still accept the revision?
Mar 16 2020
Should be fixed in 2d723d4ad51c1e369810b543e1ac9ac1dfe0bfc8
That changed the error to following. In cases like this is better to move the discussion to the latest update, or keep it here? Thanks!
I think part of this change may have broken the Windows build. Sorry for not being able to be more specific or catching it sooner. I'll be more on top of this once the buildbot moves over to the loud master.
Mar 11 2020
The mlir-check target passes with MS C++ 19.24.28319 (except for the known failure). If there is another test that would be helpful on Windows let me know.
Mar 6 2020
This appears to break the VisualStudio build for MSVC++ 14.16