darwin bootstrap failure

Is anyone else seeing this bootstrap failure on current svn trunk?

[ 6%] Linking CXX executable …/…/bin/llvm-tblgen
cd /sw/src/fink.build/llvm60-6.0.0-1/build/stage1/utils/TableGen && /sw/bin/cmake -E cmake_link_script CMakeFiles/llvm-tblgen.dir/link.txt --verbose=1
/sw/src/fink.build/llvm60-6.0.0-1/opt-bin/ccclang++ -fno-common -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -O3 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/sw/lib -Wl,-dead_strip CMakeFiles/obj.llvm-tblgen.dir/AsmMatcherEmitter.cpp.o CMakeFiles/obj.llvm-tblgen.dir/AsmWriterEmitter.cpp.o CMakeFiles/obj.llvm-tblgen.dir/AsmWriterInst.cpp.o CMakeFiles/obj.llvm-tblgen.dir/Attributes.cpp.o CMakeFiles/obj.llvm-tblgen.dir/CallingConvEmitter.cpp.o CMakeFiles/obj.llvm-tblgen.dir/CodeEmitterGen.cpp.o CMakeFiles/obj.llvm-tblgen.dir/CodeGenDAGPatterns.cpp.o CMakeFiles/obj.llvm-tblgen.dir/CodeGenHwModes.cpp.o CMakeFiles/obj.llvm-tblgen.dir/CodeGenInstruction.cpp.o CMakeFiles/obj.llvm-tblgen.dir/CodeGenMapTable.cpp.o CMakeFiles/obj.llvm-tblgen.dir/CodeGenRegisters.cpp.o CMakeFiles/obj.llvm-tblgen.dir/CodeGenSchedule.cpp.o CMakeFiles/obj.llvm-tblgen.dir/CodeGenTarget.cpp.o CMakeFiles/obj.llvm-tblgen.dir/DAGISelEmitter.cpp.o CMakeFiles/obj.llvm-tblgen.dir/DAGISelMatcherEmitter.cpp.o CMakeFiles/obj.llvm-tblgen.dir/DAGISelMatcherGen.cpp.o CMakeFiles/obj.llvm-tblgen.dir/DAGISelMatcherOpt.cpp.o CMakeFiles/obj.llvm-tblgen.dir/DAGISelMatcher.cpp.o CMakeFiles/obj.llvm-tblgen.dir/DFAPacketizerEmitter.cpp.o CMakeFiles/obj.llvm-tblgen.dir/DisassemblerEmitter.cpp.o CMakeFiles/obj.llvm-tblgen.dir/FastISelEmitter.cpp.o CMakeFiles/obj.llvm-tblgen.dir/FixedLenDecoderEmitter.cpp.o CMakeFiles/obj.llvm-tblgen.dir/GlobalISelEmitter.cpp.o CMakeFiles/obj.llvm-tblgen.dir/InfoByHwMode.cpp.o CMakeFiles/obj.llvm-tblgen.dir/InstrInfoEmitter.cpp.o CMakeFiles/obj.llvm-tblgen.dir/IntrinsicEmitter.cpp.o CMakeFiles/obj.llvm-tblgen.dir/OptParserEmitter.cpp.o CMakeFiles/obj.llvm-tblgen.dir/PseudoLoweringEmitter.cpp.o CMakeFiles/obj.llvm-tblgen.dir/RegisterBankEmitter.cpp.o CMakeFiles/obj.llvm-tblgen.dir/RegisterInfoEmitter.cpp.o CMakeFiles/obj.llvm-tblgen.dir/SearchableTableEmitter.cpp.o CMakeFiles/obj.llvm-tblgen.dir/SubtargetEmitter.cpp.o CMakeFiles/obj.llvm-tblgen.dir/SubtargetFeatureInfo.cpp.o CMakeFiles/obj.llvm-tblgen.dir/TableGen.cpp.o CMakeFiles/obj.llvm-tblgen.dir/Types.cpp.o CMakeFiles/obj.llvm-tblgen.dir/X86DisassemblerTables.cpp.o CMakeFiles/obj.llvm-tblgen.dir/X86EVEX2VEXTablesEmitter.cpp.o CMakeFiles/obj.llvm-tblgen.dir/X86FoldTablesEmitter.cpp.o CMakeFiles/obj.llvm-tblgen.dir/X86ModRMFilters.cpp.o CMakeFiles/obj.llvm-tblgen.dir/X86RecognizableInstr.cpp.o CMakeFiles/obj.llvm-tblgen.dir/CTagsEmitter.cpp.o -o …/…/bin/llvm-tblgen -Wl,-rpath,@loader_path/…/lib …/…/lib/libLLVMSupport.a …/…/lib/libLLVMTableGen.a …/…/lib/libLLVMSupport.a -lcurses -lz -lm …/…/lib/libLLVMDemangle.a
Undefined symbols for architecture x86_64:
“llvm::Record::dump() const”, referenced from:
llvm::getValueTypeByHwMode(llvm::Record*, llvm::CodeGenHwModes const&) in InfoByHwMode.cpp.o
“llvm::SubtargetFeatureInfo::dump() const”, referenced from:
(anonymous namespace)::AsmMatcherInfo::buildInfo() in AsmMatcherEmitter.cpp.o
“(anonymous namespace)::MatchableInfo::dump() const”, referenced from:
(anonymous namespace)::AsmMatcherEmitter::run(llvm::raw_ostream&) in AsmMatcherEmitter.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [bin/llvm-tblgen] Error 1
make[1]: *** [utils/TableGen/CMakeFiles/llvm-tblgen.dir/all] Error 2
make: *** [all] Error 2

This is on x86_64-apple-darwin16 with Xcode 9.0.
Jack

Hi Jack:

Looks like I missed this one in my recent change.

Please let me know if this solves your problem:

$ git diff
diff --git a/utils/TableGen/InfoByHwMode.cpp b/utils/TableGen/InfoByHwMode.cpp
index 7e1e1864356…8d3636432aa 100644
— a/utils/TableGen/InfoByHwMode.cpp
+++ b/utils/TableGen/InfoByHwMode.cpp
@@ -98,14 +98,16 @@ void ValueTypeByHwMode::writeToStream(raw_ostream &OS) const {
OS << ‘}’;
}

+#ifdef LLVM_ENABLE_DUMP
LLVM_DUMP_METHOD
void ValueTypeByHwMode::dump() const {
dbgs() << *this << ‘\n’;
}
+#endif

ValueTypeByHwMode llvm::getValueTypeByHwMode(Record *Rec,
const CodeGenHwModes &CGH) {
-#ifndef NDEBUG
+#ifdef LLVM_ENABLE_DUMP
if (!Rec->isSubClassOf(“ValueType”))
Rec->dump();
#endif

thanks…
don

Hi Jack:

Looks like I missed this one in my recent change.

Please let me know if this solves your problem:

$ git diff
diff --git a/utils/TableGen/InfoByHwMode.cpp
b/utils/TableGen/InfoByHwMode.cpp
index 7e1e1864356..8d3636432aa 100644
--- a/utils/TableGen/InfoByHwMode.cpp
+++ b/utils/TableGen/InfoByHwMode.cpp
@@ -98,14 +98,16 @@ void ValueTypeByHwMode::writeToStream(raw_ostream
&OS) const {
   OS << '}';
}

+#ifdef LLVM_ENABLE_DUMP
LLVM_DUMP_METHOD
void ValueTypeByHwMode::dump() const {
   dbgs() << *this << '\n';
}
+#endif

ValueTypeByHwMode llvm::getValueTypeByHwMode(Record *Rec,
                                              const CodeGenHwModes &CGH) {
-#ifndef NDEBUG
+#ifdef LLVM_ENABLE_DUMP
   if (!Rec->isSubClassOf("ValueType"))
     Rec->dump();
#endif

thanks...
don

The patch seems to be incomplete as it moves the failure to...

[ 6%] Linking CXX executable ../../bin/llvm-tblgen
cd /sw/src/fink.build/llvm60-6.0.0-1/build/stage1/utils/TableGen &&
/sw/bin/cmake -E cmake_link_script CMakeFiles/llvm-tblgen.dir/link.txt
--verbose=1
/sw/src/fink.build/llvm60-6.0.0-1/opt-bin/ccclang++ -fno-common -fPIC
-fvisibility-inlines-hidden -Werror=date-time
-Werror=unguarded-availability-new -std=c++11 -Wall -W
-Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wmissing-field-initializers -pedantic -Wno-long-long
-Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
-Wstring-conversion -O3 -Wl,-search_paths_first
-Wl,-headerpad_max_install_names -L/sw/lib -Wl,-dead_strip
CMakeFiles/obj.llvm-tblgen.dir/AsmMatcherEmitter.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/AsmWriterEmitter.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/AsmWriterInst.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/Attributes.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/CallingConvEmitter.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/CodeEmitterGen.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/CodeGenDAGPatterns.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/CodeGenHwModes.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/CodeGenInstruction.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/CodeGenMapTable.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/CodeGenRegisters.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/CodeGenSchedule.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/CodeGenTarget.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/DAGISelEmitter.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/DAGISelMatcherEmitter.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/DAGISelMatcherGen.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/DAGISelMatcherOpt.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/DAGISelMatcher.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/DFAPacketizerEmitter.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/DisassemblerEmitter.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/FastISelEmitter.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/FixedLenDecoderEmitter.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/GlobalISelEmitter.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/InfoByHwMode.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/InstrInfoEmitter.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/IntrinsicEmitter.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/OptParserEmitter.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/PseudoLoweringEmitter.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/RegisterBankEmitter.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/RegisterInfoEmitter.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/SearchableTableEmitter.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/SubtargetEmitter.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/SubtargetFeatureInfo.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/TableGen.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/Types.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/X86DisassemblerTables.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/X86EVEX2VEXTablesEmitter.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/X86FoldTablesEmitter.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/X86ModRMFilters.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/X86RecognizableInstr.cpp.o
CMakeFiles/obj.llvm-tblgen.dir/CTagsEmitter.cpp.o -o ../../bin/llvm-tblgen
-Wl,-rpath,@loader_path/../lib ../../lib/libLLVMSupport.a
../../lib/libLLVMTableGen.a ../../lib/libLLVMSupport.a -lcurses -lz -lm
../../lib/libLLVMDemangle.a
Undefined symbols for architecture x86_64:
  "llvm::SubtargetFeatureInfo::dump() const", referenced from:
      (anonymous namespace)::AsmMatcherInfo::buildInfo() in
AsmMatcherEmitter.cpp.o
  "(anonymous namespace)::MatchableInfo::dump() const", referenced from:
      (anonymous namespace)::AsmMatcherEmitter::run(llvm::raw_ostream&) in
AsmMatcherEmitter.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make[2]: *** [bin/llvm-tblgen] Error 1
make[1]: *** [utils/TableGen/CMakeFiles/llvm-tblgen.dir/all] Error 2
make: *** [all] Error 2

        Jack

Hi Jack:

Yes, I was just looking at that. Seems like TableGen wasn’t done along with the rest of llvm. I’ll work up a complete patch shortly.

Btw, I’m curious how this happened. Do you have a stale CMakeCache.txt by any chance? You might check the value for LLVM_ENABLE_DUMP and see if it’s consistent.

Again, I’ll gen up a complete patch shortly – sorry for delay, had to walk my dog first…

thanks…
don

Hi Jack:

Yes, I was just looking at that. Seems like TableGen wasn't done along
with the rest of llvm. I'll work up a complete patch shortly.

Btw, I'm curious how this happened. Do you have a stale CMakeCache.txt by
any chance? You might check the value for LLVM_ENABLE_DUMP and see if it's
consistent.

Again, I'll gen up a complete patch shortly -- sorry for delay, had to
walk my dog first...

thanks...
don

There are no instances of LLVM_ENABLE_DUMP being emitted during the stage1
build (which is where the failure occurs). Greping for LLVM_ENABLE_DUMP in the
stage1 build directory only shows...

% grep -R LLVM_ENABLE_DUMP *

include/llvm/Config/llvm-config.h:/* #undef LLVM_ENABLE_DUMP */

Binary file
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/SubtargetEmitter.cpp.o matches

   Jack
ps A more general grep for DUMP in CMakeCacne.txt shows...

% grep DUMP CMakeCache.txt
CMAKE_OBJDUMP:FILEPATH=/usr/bin/objdump
LLVM_FORCE_ENABLE_DUMP:BOOL=OFF
LLVM_TOOL_LLVM_CXXDUMP_BUILD:BOOL=ON
LLVM_TOOL_LLVM_DWARFDUMP_BUILD:BOOL=ON
LLVM_TOOL_LLVM_OBJDUMP_BUILD:BOOL=ON
//ADVANCED property for variable: CMAKE_OBJDUMP
CMAKE_OBJDUMP-ADVANCED:INTERNAL=1
//ADVANCED property for variable: LLVM_TOOL_LLVM_CXXDUMP_BUILD
LLVM_TOOL_LLVM_CXXDUMP_BUILD-ADVANCED:INTERNAL=1
//ADVANCED property for variable: LLVM_TOOL_LLVM_DWARFDUMP_BUILD
LLVM_TOOL_LLVM_DWARFDUMP_BUILD-ADVANCED:INTERNAL=1
//ADVANCED property for variable: LLVM_TOOL_LLVM_OBJDUMP_BUILD
LLVM_TOOL_LLVM_OBJDUMP_BUILD-ADVANCED:INTERNAL=1

Sorry, LLVM_FORCE_ENABLE_DUMP is the variable, which is used along with LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP.

Again, I’m working on a fix, but could you also provide your cmake command? Looks like we aren’t handling your use case correctly.

thanks…
don

Sorry, LLVM_FORCE_ENABLE_DUMP is the variable, which is used along with
LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP.

Again, I'm working on a fix, but could you also provide your cmake
command? Looks like we aren't handling your use case correctly.

thanks..
don

% grep -R LLVM_FORCE_ENABLE_DUMP *
CMakeCache.txt:LLVM_FORCE_ENABLE_DUMP:BOOL=OFF
CMakeCache.txt.orig:LLVM_FORCE_ENABLE_DUMP:BOOL=OFF
include/llvm/Config/llvm-config.h:/* Defined in debug builds and release
builds if LLVM_FORCE_ENABLE_DUMP

is what I see from a cmake options of...

-DLLVM_LINK_LLVM_DYLIB:BOOL=ON -DCOMPILER_RT_ENABLE_IOS:BOOL=OFF
-DLLVM_ENABLE_FFI=ON -DFFI_INCLUDE_DIR=/sw/include
-DFFI_LIBRARY_DIR=/sw/lib -DLLVM_LIT_ARGS:STRING=-v
-DPYTHON_EXECUTABLE:FILEPATH=/sw/bin/python2.7
-DLIBOMP_OSX_ARCHITECTURES=x86_64;i386 -DLLVM_ENABLE_ASSERTIONS:BOOL=OFF
-DCMAKE_OSX_SYSROOT:STRING=/ -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING=
-DLLVM_TARGETS_TO_BUILD=X86;PowerPC;ARM
-DCMAKE_INSTALL_PREFIX:PATH=/sw/opt/llvm-6.0
-DCMAKE_BUILD_TYPE:STRING=Release -DCMAKE_C_FLAGS=-fno-common
-DLLVM_BUILD_EXTERNAL_COMPILER_RT:BOOL=ON -DCMAKE_CXX_FLAGS=-fno-common
-DCMAKE_SHARED_LINKER_FLAGS= -L/sw/lib -DCMAKE_MODULE_LINKER_FLAGS=
-L/sw/lib -DCMAKE_EXE_LINKER_FLAGS= -L/sw/lib

Hi Jack:

The only way I could reproduce the problem you are seeing was to rerun cmake with -DCMAKE_BUILD_TYPE=Debug in a build directory previously configured with -DCMAKE_BUILD_TYPE=Release. I can fix that, but not sure if it’s what you are seeing.

If this isn’t your case, could you send me the actual commands you ran?

In the meantime, you can add -DLLVM_FOURCE_ENABLE_DUMP=ON to your cmake invocation which should guarantee LLVM_ENABLE_DUMP is defined.

hth…
don

Hi Jack:

The only way I could reproduce the problem you are seeing was to rerun
cmake with -DCMAKE_BUILD_TYPE=Debug in a build directory previously
configured with -DCMAKE_BUILD_TYPE=Release. I can fix that, but not sure
if it's what you are seeing.

If this isn't your case, could you send me the actual commands you ran?

In the meantime, you can add -DLLVM_FOURCE_ENABLE_DUMP=ON to your cmake
invocation which should guarantee LLVM_ENABLE_DUMP is defined.

hth...
don

Don,
    Did you try a build with
-DLLVM_ENABLE_ASSERTIONS:BOOL=OFF -DCMAKE_BUILD_TYPE:STRING=Release?
        Jack

Yes, you tried your exact options (except for python etc…), but LLVM_ENABLE_ASSERTIONS defaults to OFF for Release builds anyway.

In fact I tried every combinations I could think of. For some reason, it looks like you have a release build that doesn’t pass -DNDEBUG to clang++, which I cannot explain.

Yes, you tried your exact options (except for python etc...), but
LLVM_ENABLE_ASSERTIONS defaults to OFF for Release builds anyway.

In fact I tried every combinations I could think of. For some reason, it
looks like you have a release build that doesn't pass -DNDEBUG to clang++,
which I cannot explain.

Don,
     My mistake. The llvm fink packaging files we are using had a build
script with...

         # Do not want -DNDEBUG, cause linker errors (undef symbols)
        # LLVM_ENABLE_ASSERTIONS:ON should have removed -DNDEBUG
        # but it doesn't, so hack it out of cmake file
        test "$enable_assertions" = OFF ||
                sed -i.orig -e '/-DNDEBUG/s|.*|#&|'
cmake/modules/HandleLLVMOptions.cmake

which isn't problematic but later in stage1 the script used...

        # kill -DNDEBUG with fire
        sed -i.orig -e 's| -DNDEBUG||g' CMakeCache.txt

Changing that to...

        # kill -DNDEBUG with fire
        test "$enable_assertions" = OFF || sed -i.orig -e 's| -DNDEBUG||g'
CMakeCache.txt

eliminated that particular build failure in llvm trunk.
         Jack

Great, glad you got it sorted out.

But it did highlight a few related issues, which I’ll try to address this week.

thanks…
don

Hi Jack:

Yes, I was just looking at that. Seems like TableGen wasn't done along with
the rest of llvm. I'll work up a complete patch shortly.

This also broke the build for MSVC when doing a debug build (though no
builder seems to be picking up the failure!). After working around a
handful of link errors, I came to one that's going to require more
understanding of LLVM's tablegen than I have.

Error LNK2019 unresolved external symbol "public: void __cdecl
`anonymous namespace'::MatchableInfo::dump(void)const "
(?dump@MatchableInfo@?A0xf4f1c304@@QEBAXXZ) referenced in function
"public: void __cdecl `anonymous
namespace'::AsmMatcherEmitter::run(class llvm::raw_ostream &)"
(?run@AsmMatcherEmitter@?A0xf4f1c304@@QEAAXAEAVraw_ostream@llvm@@@Z)
llvm-tblgen D:\llvm\2017\utils\TableGen\AsmMatcherEmitter.obj 1

Since this has been broken for over a day and the fixes are
nontrivial, I've reverted your commit (r315590) in r315854. Hopefully
this doesn't cause you too many problems!

~Aaron

Thanks Aaron.

I don’t have a Windows system, and haven’t seen any buildbot failures, so I it’s difficult to come up with a patch for something I can’t reproduce locally or see any actual failures. Could you send me the commands you used that uncovered the failure?

thanks again…
don

Thanks Aaron.

I don't have a Windows system, and haven't seen any buildbot failures, so I
it's difficult to come up with a patch for something I can't reproduce
locally or see any actual failures. Could you send me the commands you used
that uncovered the failure?

This was from building Clang + LLVM on Windows 10 with MSVC 2017 x64
Debug. My cmake command to generate the VS solution is pretty
uninteresting: cmake -G "Visual Studio 15 Win64" ..\llvm

I fixed a few of the link errors that Jack pointed out before
stumbling on the problem in AsmMatcherEmitter::run(). I wasn't
comfortable attempting to work around it there because the
DEBUG_WITH_TYPE macro was conflicting with trying to guard calls to
MatchableInfo::dump() with LLVM_ENABLE_DUMP.

I think this is another instance of "TableGen wasn't done along with
the rest of llvm" -- nothing about it should be Visual Studio- or
Windows-specific.

~Aaron

> Thanks Aaron.
>
> I don't have a Windows system, and haven't seen any buildbot failures,
so I
> it's difficult to come up with a patch for something I can't reproduce
> locally or see any actual failures. Could you send me the commands you
used
> that uncovered the failure?

This was from building Clang + LLVM on Windows 10 with MSVC 2017 x64
Debug. My cmake command to generate the VS solution is pretty
uninteresting: cmake -G "Visual Studio 15 Win64" ..\llvm

I fixed a few of the link errors that Jack pointed out before
stumbling on the problem in AsmMatcherEmitter::run(). I wasn't
comfortable attempting to work around it there because the
DEBUG_WITH_TYPE macro was conflicting with trying to guard calls to
MatchableInfo::dump() with LLVM_ENABLE_DUMP.

I think this is another instance of "TableGen wasn't done along with
the rest of llvm" -- nothing about it should be Visual Studio- or
Windows-specific.

I think this is specific to cmake generators that create multiple
configuration types -- visual studio and xcode. Setting LLVM_ENABLE_DUMP
in a header just won't work in those situations, so it might make sense to
remove it altogether.

Thanks again...
don

> Thanks Aaron.
>
> I don't have a Windows system, and haven't seen any buildbot failures,
> so I
> it's difficult to come up with a patch for something I can't reproduce
> locally or see any actual failures. Could you send me the commands you
> used
> that uncovered the failure?

This was from building Clang + LLVM on Windows 10 with MSVC 2017 x64
Debug. My cmake command to generate the VS solution is pretty
uninteresting: cmake -G "Visual Studio 15 Win64" ..\llvm

I fixed a few of the link errors that Jack pointed out before
stumbling on the problem in AsmMatcherEmitter::run(). I wasn't
comfortable attempting to work around it there because the
DEBUG_WITH_TYPE macro was conflicting with trying to guard calls to
MatchableInfo::dump() with LLVM_ENABLE_DUMP.

I think this is another instance of "TableGen wasn't done along with
the rest of llvm" -- nothing about it should be Visual Studio- or
Windows-specific.

I think this is specific to cmake generators that create multiple
configuration types -- visual studio and xcode. Setting LLVM_ENABLE_DUMP in
a header just won't work in those situations, so it might make sense to
remove it altogether.

FWIW, most of the ones I was fixing up were guarded by NDEBUG instead
of LLVM_ENABLE_DUMP. Switching to LLVM_ENABLE_DUMP fixed the link
errors for me -- the only one I struggled with was
AsmMatcherEmitter::run(). But it sounds like you're saying switching
the configuration type in MSVC from Debug to Release would have
possibly caused issues as well?

~Aaron

FWIW, most of the ones I was fixing up were guarded by NDEBUG instead
of LLVM_ENABLE_DUMP. Switching to LLVM_ENABLE_DUMP fixed the link
errors for me -- the only one I struggled with was
AsmMatcherEmitter::run(). But it sounds like you're saying switching
the configuration type in MSVC from Debug to Release would have
possibly caused issues as well?

This is what I believe is going on -- hope this isn't too convoluted...

I don't know how you invoked cmake, but the generators for VS and Xcode
support multiple configurations, allowing you to delay choosing the build
type and implicitly setting CMAKE_BUILD_TYPE=None.

If CMAKE_BUILD_TYPE isn't passed or doesn't include "debug", CMakeLists.txt
assumes it's a release build, turns off both asserts and dump methods, and
generates llvm-config.h without defining LLVM_ENABLE_DUMP. Since my change
removed the NDEBUG test for most dump definitions, they were #ifdef'd
away. While it's possible to override this behavior by passing
-DLLVM_ENABLE_ASSERTIONS or -DLLMV_FORCE_ENABLE_DUMP, you don't seem to
have done that.

So, when a Debug build was later selected, llvm-config.h had already been
written without defining LLVM_ENABLE_DUMP, and since table-gen didn't have
the fix, it assumed the dump methods were available when it didn't see
-DNEBUG on the command line -- hence the linking errors.

So, setting LLVM_ENABLE_DUMP at configuration time won't work in this case,
and I'm leaning toward removing it completely.

Jack's issue involved removing -DNDEBUG in a script for Release builds.
While it caused the same linking issues you saw, it really didn't have
anything to do with the configuration issue you uncovered. Had I seen any
other errors, I would have rolled it back yesterday, but as you've said,
the bots were clean wrt this change.

So, thanks again for reverting it, and sorry for any inconvenience.

hth...
don

FWIW, most of the ones I was fixing up were guarded by NDEBUG instead
of LLVM_ENABLE_DUMP. Switching to LLVM_ENABLE_DUMP fixed the link
errors for me -- the only one I struggled with was
AsmMatcherEmitter::run(). But it sounds like you're saying switching
the configuration type in MSVC from Debug to Release would have
possibly caused issues as well?

This is what I believe is going on -- hope this isn't too convoluted...

I don't know how you invoked cmake, but the generators for VS and Xcode
support multiple configurations, allowing you to delay choosing the build
type and implicitly setting CMAKE_BUILD_TYPE=None.

If CMAKE_BUILD_TYPE isn't passed or doesn't include "debug", CMakeLists.txt
assumes it's a release build, turns off both asserts and dump methods, and
generates llvm-config.h without defining LLVM_ENABLE_DUMP. Since my change
removed the NDEBUG test for most dump definitions, they were #ifdef'd away.
While it's possible to override this behavior by passing
-DLLVM_ENABLE_ASSERTIONS or -DLLMV_FORCE_ENABLE_DUMP, you don't seem to have
done that.

So, when a Debug build was later selected, llvm-config.h had already been
written without defining LLVM_ENABLE_DUMP, and since table-gen didn't have
the fix, it assumed the dump methods were available when it didn't see
-DNEBUG on the command line -- hence the linking errors.

So, setting LLVM_ENABLE_DUMP at configuration time won't work in this case,
and I'm leaning toward removing it completely.

Ah, okay, I see what the issue is. Thank you for the explanation!

Jack's issue involved removing -DNDEBUG in a script for Release builds.
While it caused the same linking issues you saw, it really didn't have
anything to do with the configuration issue you uncovered. Had I seen any
other errors, I would have rolled it back yesterday, but as you've said, the
bots were clean wrt this change.

I was surprised that this didn't make any MSVC bots go red. The
default behavior I see is that I run cmake and I get a Debug build
without fiddling with anything in MSVC, unless I specify cmake options
to do a release build.

So, thanks again for reverting it, and sorry for any inconvenience.

No problem -- sorry that the patch may not work out!

~Aaron

>>
>> FWIW, most of the ones I was fixing up were guarded by NDEBUG instead
>> of LLVM_ENABLE_DUMP. Switching to LLVM_ENABLE_DUMP fixed the link
>> errors for me -- the only one I struggled with was
>> AsmMatcherEmitter::run(). But it sounds like you're saying switching
>> the configuration type in MSVC from Debug to Release would have
>> possibly caused issues as well?
>
>
> This is what I believe is going on -- hope this isn't too convoluted...
>
> I don't know how you invoked cmake, but the generators for VS and Xcode
> support multiple configurations, allowing you to delay choosing the build
> type and implicitly setting CMAKE_BUILD_TYPE=None.
>
> If CMAKE_BUILD_TYPE isn't passed or doesn't include "debug",
CMakeLists.txt
> assumes it's a release build, turns off both asserts and dump methods,
and
> generates llvm-config.h without defining LLVM_ENABLE_DUMP. Since my
change
> removed the NDEBUG test for most dump definitions, they were #ifdef'd
away.
> While it's possible to override this behavior by passing
> -DLLVM_ENABLE_ASSERTIONS or -DLLMV_FORCE_ENABLE_DUMP, you don't seem to
have
> done that.
>
> So, when a Debug build was later selected, llvm-config.h had already been
> written without defining LLVM_ENABLE_DUMP, and since table-gen didn't
have
> the fix, it assumed the dump methods were available when it didn't see
> -DNEBUG on the command line -- hence the linking errors.
>
> So, setting LLVM_ENABLE_DUMP at configuration time won't work in this
case,
> and I'm leaning toward removing it completely.

Ah, okay, I see what the issue is. Thank you for the explanation!

> Jack's issue involved removing -DNDEBUG in a script for Release builds.
> While it caused the same linking issues you saw, it really didn't have
> anything to do with the configuration issue you uncovered. Had I seen
any
> other errors, I would have rolled it back yesterday, but as you've said,
the
>bots were clean wrt this change.

I was surprised that this didn't make any MSVC bots go red. The
default behavior I see is that I run cmake and I get a Debug build
without fiddling with anything in MSVC, unless I specify cmake options
to do a release build.

Since it creates multiple ones, it must be selecting the Debug
configuration by default -- it has to pick something. But that has nothing
to do with the cmake variables we set in CMakeList.txt.