Runtime Cling Errors (VS2013 / Windows) / Test Failures

Hello,
Thank you for accepting my account registration! :slight_smile:


Edit:

… I wish I’d read that more carefully the first few times.
Any estimate time frame for working windows support?
Or: Any known work around? If I use LLVM/Clang or GCC (mingw) to compile through VS will it work?

After getting the llvm, clang, and cling projects to successfully build and link in Visual Studio 2013, I ran into this same problem. ValuePrinter errors on Windows

Below is first a reiteration of the problem at this post, and below that is an extended report on the failure of many llvm/clang tests, as well as the inability to run the cling test.

C:\Development\build2\Debug\bin>cling

****************** CLING ******************
* Type C++ code and press enter to run it *
*             Type .q to exit             *
*******************************************
[cling]$ int number = 123;
IncrementalExecutor::executeFunction: symbol '☺?local_cxa_atexit@internal@runtime@cling@@YAHP6AXPAX@Z00@Z' unresolved while linking function '☺?__cling_Un1Qu30@
@YAXPAX@Z'!
[cling]$ int number = 123;
input_line_5:2:6: error: redefinition of 'number'
 int number = 123;
     ^
input_line_4:2:6: note: previous definition is here
 int number = 123;
     ^
[cling]$[/code]
[code]C:\Development\build2\Debug\bin>cling -v -x c

****************** CLING ******************
* Type C++ code and press enter to run it *
*             Type .q to exit             *
*******************************************
[cling]$ #include <stdio.h>
[cling]$ int a = 5;
[cling]$ int b = 8;
[cling]$ printf("%i", a + b);
13
[cling]$

Similarly:
test.c

int test() { int a = 10; int b = 12; return a + b; }

[code]****************** CLING ******************

  • Type C++ code and press enter to run it *
  •         Type .q to exit             *
    

[cling] .x test.c IncrementalExecutor::executeFunction: symbol '☺?local_cxa_atexit@internal@runtime@cling@@YAHP6AXPAX@Z00@Z' unresolved while linking function '☺?__cling_Un1Qu30@ @YAXPAX@Z'! IncrementalExecutor::executeFunction: symbol '☺?setValueNoAlloc@internal@runtime@cling@@YAXPAX000_K@Z' unresolved while linking function '☺?__cling_Un1Qu30@@YAX PAX@Z'! [cling] .L test.c
[cling] test(); [cling][/code]

But what is worse?

[code]C:\Development\build2\Debug\bin>cling -v -x c

****************** CLING ******************

  • Type C++ code and press enter to run it *
  •         Type .q to exit             *
    

[cling]$ .x test.c
Assertion failed: !R.empty() && “Cannot find cling::runtime::internal::setValueNoAlloc”, file C:\Development\llvm2\tools\cling\lib\Interpreter\ValueExtractionSy
nthesizer.cpp, line 384

C:\Development\build2\Debug\bin>cling -v -x c

****************** CLING ******************

  • Type C++ code and press enter to run it *
  •         Type .q to exit             *
    

[cling] .x "test.c" input_line_3:1:10: error: empty filename #include ""test.c"" ^ input_line_4:2:2: warning: missing terminating '"' character [-Winvalid-pp-token] "test() ^ input_line_4:2:2: error: expected expression [cling] .L test.c
[cling]$[/code]

x fails, L works?

When attempting to interpret internally in my program using:
“test.c(10,12)”, “test.cpp(10,12)”, OR -v -x c “test.cpp(10,12)” as arguments.
Note: I have the ui metaprocessor running .I first, before processing the command line arguments.

Regardless of this last step, it should work using the stand alone executable.

Perhaps more interesting and informative.
This is what a fair number of the test results looked like in check-all.

61> ******************** 61> UNRESOLVED: LLVM :: Object/obj2yaml.test (13782 of 16842) 61> ******************** TEST 'LLVM :: Object/obj2yaml.test' FAILED ******************** 61> Exception during script execution: 61> Traceback (most recent call last): 61> File "C:\Development\llvm2\utils\lit\lit\run.py", line 166, in execute_test 61> result = test.config.test_format.execute(test, self.lit_config) 61> File "C:\Development\llvm2\utils\lit\lit\formats\shtest.py", line 12, in execute 61> self.execute_external) 61> File "C:\Development\llvm2\utils\lit\lit\TestRunner.py", line 488, in executeShTest 61> res = executeScriptInternal(test, litConfig, tmpBase, script, execdir) 61> File "C:\Development\llvm2\utils\lit\lit\TestRunner.py", line 251, in executeScriptInternal 61> exitCode = executeShCmd(cmd, test.config, cwd, results) 61> File "C:\Development\llvm2\utils\lit\lit\TestRunner.py", line 40, in executeShCmd 61> res = executeShCmd(cmd.lhs, cfg, cwd, results) 61> File "C:\Development\llvm2\utils\lit\lit\TestRunner.py", line 153, in executeShCmd 61> close_fds = kUseCloseFDs)) 61> File "c:\Development\Python34\lib\subprocess.py", line 754, in __init__ 61> _cleanup() 61> File "c:\Development\Python34\lib\subprocess.py", line 474, in _cleanup 61> res = inst._internal_poll(_deadstate=sys.maxsize) 61> File "c:\Development\Python34\lib\subprocess.py", line 1146, in _internal_poll 61> if _WaitForSingleObject(self._handle, 0) == _WAIT_OBJECT_0: 61> OSError: [WinError 6] The handle is invalid

61> Expected Passes : 1061
61> Expected Failures : 23
61> Unsupported Tests : 107
61> Unresolved Tests : 15321
61> Unexpected Failures: 330

As shown, I am using python34. Should I be using a different version?
The error which was shown when attempting to run cling-test:

44>------ Build started: Project: cling-test, Configuration: Debug Win32 ------ 44> Building Custom Rule C:/Development/llvm2/tools/cling/test/CMakeLists.txt 44> CMake does not need to re-run because C:\Development\build2\tools\cling\test\CMakeFiles\generate.stamp is up-to-date. 44> Running Cling regression tests 44> lit.py: LitConfig.py:94: note: Unable to find 'bash.exe'. 44> lit.py: lit.cfg:226: fatal: couldn't find 'cling' program, try setting CLING in your environment 44>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(170,5): error MSB6006: "cmd.exe" exited with code 2.

cling’s directory is set up inside the windows PATH, but this is a python complaint?


I hope someone is able to help, more than just “Still no Windows support.” That would be unfortunate.
I love the prospects of cling, and it seems like there is so much to learn!

Thank you for the help!

Hi,
Cling in C mode on Windows:
The limitation of cling on Windows comes from the fact that clang doesn’t support fully windows mangling scheme, i.e it is not binary compatible. For example, one cannot call a function compiled with other than clang/gcc compiler.

  • There is a lot of progress in that direction recently on the clang side. We should investigate why cling chalks up. I.e is everything set up correctly in the CIFactory in the case where the OS is windows.
  • Since C doesn’t have mangling cling in C mode must be working on Windows (i.e cling -x c). However there are a few missing things when running in C mode. We have a facility called Value Printing, where we would stream the execution results on the prompt:
    cling

[cling]$ int i
(int) 0

whereas:

cling -x c

[cling]$ int i
cling: /home/vvassilev/workspace/root/interpreter/cling/lib/Interpreter/ValueExtractionSynthesizer.cpp:353: void cling::ValueExtractionSynthesizer::FindAndCacheRuntimeDecls(): Assertion `!R.empty() && “Cannot find cling::runtime::internal::setValueNoAlloc”’ failed.
Aborted (core dumped)

Most of the changes need to be done in: ValueExtractionSynthesizer. The ValuePrinterSynthesizer probably will disappear, but have a look how things were done for c mode.

The idea behind the ValueExtractionSynthesizer is that, we need to get the execution result out of any expression and store it in ‘some’ place. The complexity comes from c++, where it may create a references to temporary objects. Eg.
class MyClass{};
MyClass f() { return MyClass(); }
f()
The lifetime of the MyClass object will be the scope of the stmt of f(). However we couldn’t store it anywhere, so we do extra mechanics to get the value out.

Fortunately for C it will be easier. Please have a look at setValueNoAlloc routines. Also have a look at the test suite, mostly, test/Interfaces/evaluate.C.
One of the problems is that setValueNoAlloc has multiple overloads (and is in a namespace) and C doesn’t support overloads, so we have to come up with a nice solution.

This is an issue which we intend to work on soon and patches are very welcome.
Vassil