Running Flang tests on Windows

[kaadam]

The goal is to add a basic Windows support to Flang tests. My approach is to adopting the current test environment to Windows, try to preserve the current test process [lit->sh->make->FileCheck] how they are launched as much as possible by using gnuwin32 tools. As far as I see this is the simplest way to find a general solution in a short time.

I managed to determine some issues which need to be fixed in order to run Flang tests on Windows:

1. Defining temporary "environment" variable for forked process:
   The following logic how these variables are defined and pass them to the forked bash process doesn't work in PowerShell or Command Promt.
   RUN: KEEP_FILES=%keep FLAGS=%flags TEST_SRC=%s MAKE_FILE_DIR=%S/.. bash %S/runmake | tee %t
   Instead we should use this format:
   RUN: bash -c "KEEP_FILES=%keep FLAGS=%flags TEST_SRC=%:s MAKE_FILE_DIR=%:S/.. %:S/runmake | tee %:t"
   It would be good, if we could use a common sh file for Linux and Windows. But maybe it is more clear if we create a separate bat/ps1 file for each tests.

2. Using proper path separator for gnuwin32 bash.
   We should use Linux style path '/c/path/to//test/dir' instead of Windows path. Maybe we should override %:S behaviour which removes : from the path (this is good for us) , but also removes / single leading by default.

3. Detecting Clang-cl and Flang compiler.
   On Linux by default classic flang llvm tools are installed into /usr/local and the make easily finds them.
   On Windows it needs to tell explicitly to the make where the Flang compiler is.
   It could be done if we pass the path to llvm tools dir through the script chain, or generating a 'config.mk' file with cmake which will be included in main Makefile. Or add the 'llvm_tools_dir' to the PATH before the tests execution.

4. Linking issue
   It seems it needs to fix the how Flang pass the flang runtime libraries to MS Linker.

InstalledDir: C:\flang_work_dir\classic-flang-llvm-project\build_15\.\bin "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.34.31933\\bin\\Hostx64\\x64\\link.exe" -out:ab10.exe "-libpath:C:\\flang_work_dir\\classic-flang-llvm-project\\build_15\\lib" -lflang -lflangrti -lpgmath -lpthread -lrt /subsystem:console -nologo ab10.o check.o
Microsoft (R) Incremental Linker Version 14.34.31937.0
Copyright (C) Microsoft Corporation.  All rights reserved.
LINK : warning LNK4044: unrecognized option '/lflang'; ignored
LINK : warning LNK4044: unrecognized option '/lflangrti'; ignored
LINK : warning LNK4044: unrecognized option '/lpgmath'; ignored
LINK : warning LNK4044: unrecognized option '/lpthread'; ignored
LINK : warning LNK4044: unrecognized option '/lrt'; ignored
ab10.o : error LNK2019: unresolved external symbol fort_init referenced in function MAIN_
libcmt.lib(exe_main.obj) : error LNK2019: unresolved external symbol main referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)

5. Direct test output to pipe and stdout
   The output of tests direct to a file and stdout by 'tee' ( "bash %S/runmake | tee %t " ). In this case the output is empty, so the result of the test is not represented in stdout nor the tmp file.
   It seems it is a buffering issue due to different line endings [cr+lf vs lf], if I add an extra 'fflush' call in the 'check.c' file, it solves this issue.

[bryanpkc]

Thanks for creating and investigating the issue and volunteering for this effort!

Some quick responses to your points:

1. Please find a way to eliminate f90_correct/lit/*.sh. Most of them are identical and maintaining them add unnecessary overhead. Also, instead of:

   RUN: bash -c "KEEP_FILES=%keep FLAGS=%flags TEST_SRC=%:s MAKE_FILE_DIR=%:S/.. %:S/runmake | tee %:t"
   

   I suggest (if env is provided by gnuwin32 tools):

   RUN: env KEEP_FILES=%keep FLAGS=%flags TEST_SRC=%:s MAKE_FILE_DIR=%:S/.. %:S/runmake | tee %:t
   

2. test/lit.cfg contains code to add the Flang and LLVM tools directories to $PATH. Does that not work for some reason?
3. Regarding the buffering issue, check.c terminates every line of output with "\n", and I am surprised that the C runtime doesn't automatically convert that into a CRLF sequence on Windows. I suspect that the I/O subsystem in the Classic Flang runtime is not shutting down properly on Windows.