[flang] Check there's no dependency on C++ libs

[rovka]

Summary

Add a test to make sure the flang runtime doesn't pull in the C++
runtime libraries.

This is achieved by adding a C file that calls some functions from the
runtime (currently only CpuTime, but we should probably add anything
complicated enough, e.g. IO-related things). We force the C compiler to
use -std=c90 to make sure it's really in C mode (we don't really care
which version of the standard, this one is probably more widely
available). We only enable this test if CMAKE_C_COMPILER is set to
something (which is probably always true in practice).

[jeanPerier]

Looks like a good idea to me to have this test, thanks !

flang/test/lit.cfg.py

85

I wonder if you should also add libFortranDecimal.a to this, libFortranRuntime.a depends upon it. The dependency is not required for your test, so maybe this could also be done when adding an I/O runtime call use that actually depends on it.

[klausler]

I would like to have some automated check in the build that would catch an inadvertent binary dependency, but this scheme seems to admit false negative results when the linkage is static.

I have an extra step in my build that scrapes the runtime libraries' binaries' unsatisfied external symbols in search of mangled C++ names, but that's obviously not portable.

When the llvm tree can build an end-to-end Fortran compiler, if we're allowed to have end-to-end Fortran compilation tests, they'll be better checks for C++-free linking.

[rovka]

In D104290#2819654, @klausler wrote:

I would like to have some automated check in the build that would catch an inadvertent binary dependency, but this scheme seems to admit false negative results when the linkage is static.

This just tests that CpuTime doesn't bring in any C++ symbols. If we added calls to all the runtime functions here, we could be reasonably confident that nothing in the runtime lib brings in C++ symbols, right? So there shouldn't be any false negatives unless the C compiler does something funny. I suppose we could avoid that if we called the linker directly? I'm not sure off the top of my head how complicated it would be to do that in a portable way.

I have an extra step in my build that scrapes the runtime libraries' binaries' unsatisfied external symbols in search of mangled C++ names, but that's obviously not portable.

When the llvm tree can build an end-to-end Fortran compiler, if we're allowed to have end-to-end Fortran compilation tests, they'll be better checks for C++-free linking.

We can definitely have end-to-end fortran tests. In the worst case, they'll have to live in the test-suite :) But I'm thinking when flang can handle linking we could just replace this file with the fortran equivalent and call flang instead of cc.

flang/test/lit.cfg.py

85

Yeah, I think it's better to add it when there's a need for it. It will be easy to know because the test will fail then :)

[awarzynski]

Hi @rovka , could you take a look: https://lab.llvm.org/buildbot/#/builders/160/builds/2726? Looks like it should just be a matter of replacing // with /* in the test file. Thank you!

EDIT:
Ive just noticed https://reviews.llvm.org/rG0ad051b5fc22b4e7334635b2bdc54eca8ee7c4c4, thanks for the fix and apologies for the noise!

[rovka]

Hi Andrzej,

I already fixed that and another issue as of 0ad051b5fc22 (It hasn't been
picked up by that builder yet).

Cheers,
Diana

flang/test/Runtime/no-cpp-dep.c

+// This test makes sure that flang's runtime does not depend on the C++ runtime
+// library. It tries to link this simple file against libFortranRuntime.a with
+// a C compiler.
+//
+// REQUIRES: c-compiler
+//
+// RUN: %cc -std=c90 %s -I%runtimeincludes %libruntime -o /dev/null
+
+#include "entry-names.h"
+
+// Manually add declarations for the runtime functions that we want to make sure
+// we're testing. We can't include any headers directly since they likely
+// contain C++ code that would explode here.
+double RTNAME(CpuTime)();
+
+int main() {
+  double x = RTNAME(CpuTime)();
+  return x;
+}

flang/test/lit.cfg.py

if config.include_flang_new_driver_test:
    tools.append(ToolSubst('%flang_fc1', command=FindTool('flang-new'),
     extra_args=['-fc1'], unresolved='fatal'))
 else:
    tools.append(ToolSubst('%flang', command=FindTool('f18'),
     unresolved='fatal'))
    tools.append(ToolSubst('%flang_fc1', command=FindTool('f18'),
     unresolved='fatal'))
 
+# Define some variables to help us test that the flang runtime doesn't depend on
+# the C++ runtime libraries. For this we need a C compiler. If for some reason
+# we don't have one, we can just disable the test.
+if config.cc:
+    config.available_features.add('c-compiler')
+    tools.append(ToolSubst('%cc', command=config.cc, unresolved='ignore'))
+    tools.append(ToolSubst('%libruntime',
+        command=os.path.join(config.flang_lib_dir, 'libFortranRuntime.a'),
+        unresolved='warn'))
+    tools.append(ToolSubst('%runtimeincludes',
+        command=os.path.join(config.flang_src_dir, 'runtime'),
+        unresolved='warn'))
+
 if config.flang_standalone_build:
     llvm_config.add_tool_substitutions(tools, [config.flang_llvm_tools_dir])
 else:
     llvm_config.add_tool_substitutions(tools, config.llvm_tools_dir)
 
 # Enable libpgmath testing
 result = lit_config.params.get("LIBPGMATH")
 if result:
     config.environment["LIBPGMATH"] = True

flang/test/lit.site.cfg.py.in

 @LIT_SITE_CFG_IN_HEADER@
 
 import sys
 
 config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
 config.lit_tools_dir = "@LLVM_LIT_TOOLS_DIR@"
 config.flang_obj_root = "@FLANG_BINARY_DIR@"
 config.flang_src_dir = "@FLANG_SOURCE_DIR@"
 config.flang_tools_dir = "@FLANG_TOOLS_DIR@"
 config.flang_intrinsic_modules_dir = "@FLANG_INTRINSIC_MODULES_DIR@"
 config.flang_llvm_tools_dir = "@CMAKE_BINARY_DIR@/bin"
+config.flang_lib_dir = "@CMAKE_BINARY_DIR@/lib"
 config.python_executable = "@PYTHON_EXECUTABLE@"
 config.flang_standalone_build = @FLANG_STANDALONE_BUILD@
+config.cc = "@CMAKE_C_COMPILER@"
 
 # Control the regression test for flang-new driver
 import lit.util
 config.include_flang_new_driver_test = \
     lit.util.pythonize_bool("@FLANG_BUILD_NEW_DRIVER@")
 
 # Support substitution of the tools_dir with user parameters. This is
 # used when we can't determine the tool dir at configuration time.