Crash under clang14 in release mode on windows

[levinli303]

After updating Visual Studio to 17.3 (which updated clang to clang 14), I'm noticing a crash in some methods when built with clang 14 in release mode on Windows. This only happens with clang 14 + Release. Does not happen with clang 13, or in debug mode. Using example project in https://github.com/gnustep/tools-windows-msvc

One example is to use this method [NSProgress progressWithTotalUnitCount:10];

This crash does not happen if I write [[NSProgress alloc] initWithParent:nil userInfo:nil];

[triplef]

This is probably related to this bug: https://github.com/llvm/llvm-project/issues/56952

For the time being I’d recommend sticking with Clang 13. You can use one of the official downloads from the LLVM website instead of using the Visual Studio one.

[levinli303]

looks like it. it is possible to use a custom LLVM toolchain in Visual Studio too. might be good to mention it in the msvc-tools repo about this bug.

[weliveindetail]

@levinli303 Can you run the test suite for libobjc2 and check if you see these failing:

7 - ARCTest_arc (Exit code 0xc0000409)
8 - ARCTest_arc_optimised (Exit code 0xc0000409)
41 - PropertyIntrospectionTest2_arc (SEGFAULT)
42 - PropertyIntrospectionTest2_arc_optimised (SEGFAULT)

I am looking into these failures right now. Might be good to know if this is one and the same issue.

[levinli303]

@weliveindetail do you still need me to run these tests? I'm not sure how to do so, if you can provide some commands to allow me to run the tests I can do it in the coming few days.

[weliveindetail]

Yes that might be a good test. Assuming you use CMake and Ninja to build libobjc2 and that you installed Clang from one of the releases you should be able to build a release version like this:

> git clone https://github.com/gnustep/libobjc2
> cd libobjc2
> mkdir build-release
> cd build-release
> cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER="C:/LLVM14/bin/clang-cl.exe" -DCMAKE_CXX_COMPILER="C:/LLVM14/bin/clang-cl.exe" ..
> ninja

Then copy the objc.dll into the Test subdirectory and run ctest:

> cp objc.dll Test\objc.dll
> ctest

Up until Clang 15.x the above mentioned tests should fail. I landed a fix in mainline yesterday. If you build Clang from the latest sources yourself (or wait for release 16.x) they should pass now.

[triplef]

might be good to mention it in the msvc-tools repo about this bug.

I’ve added a section about known compiler issues in the readme: https://github.com/gnustep/tools-windows-msvc#status-and-known-issues

[levinli303]

@weliveindetail I'm seeing

    lld-link: error: could not open 'kernel32.lib': no such file or directory
    lld-link: error: could not open 'user32.lib': no such file or directory
    lld-link: error: could not open 'gdi32.lib': no such file or directory
    lld-link: error: could not open 'winspool.lib': no such file or directory
    lld-link: error: could not open 'shell32.lib': no such file or directory
    lld-link: error: could not open 'ole32.lib': no such file or directory
    lld-link: error: could not open 'oleaut32.lib': no such file or directory
    lld-link: error: could not open 'uuid.lib': no such file or directory
    lld-link: error: could not open 'comdlg32.lib': no such file or directory
    lld-link: error: could not open 'advapi32.lib': no such file or directory
    lld-link: error: could not open 'msvcrtd.lib': no such file or directory
    lld-link: error: could not open 'oldnames.lib': no such file or directory
    ninja: build stopped: subcommand failed.

with the cmake -GNinja ... command

[weliveindetail]

@levinli303 Did you run this from your Visual Studio command line?

[levinli303]

@weliveindetail the test suite are all passing for this clang version (I need to set CMAKE_C_COMPILER to clang instead of clang-cl, otherwise it will complain import is not a MSVC feature)

clang version 14.0.5
Target: i686-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\Llvm\bin

[davidchisnall]

Is this now fixed?

[levinli303]

based on https://github.com/gnustep/tools-windows-msvc#status-and-known-issues, it is fixed in clang 16.

[triplef]

Yes this was fixed in Clang 16. You can get the RC build here if you want to give it a try to confirm: https://github.com/llvm/llvm-project/releases

In the discussions around this fix there were some open questions around whether the GNUstep runtime needs/uses markers for ObjC ARC autorelease optimization. @davidchisnall could you still chime in on that?

From https://github.com/llvm/llvm-project/issues/56952#issuecomment-1256136782:

@davidchisnall Is GNUstep checking for optimized callers like the callerAcceptsOptimizedReturn() in Apple's ObjC runtime here? https://opensource.apple.com/source/objc4/objc4-818.2/runtime/objc-object.h.auto.html

From https://reviews.llvm.org/D134441#3810388:

It's possible the GNU runtime generally uses a different approach and doesn't need these markers at all; David Chisnall might know.