[llvm-dev] invalid code generated on Windows x86_64 using skylake-specific features

Andrew Kelley via llvm-dev llvm-dev at lists.llvm.org
Sat Sep 30 12:33:59 PDT 2017

I have this code, which works fine on MacOS and Linux hosts:

    const char *target_specific_cpu_args;
    const char *target_specific_features;
    if (g->is_native_target) {
        target_specific_cpu_args = ZigLLVMGetHostCPUName();
        target_specific_features = ZigLLVMGetNativeFeatures();
    } else {
        target_specific_cpu_args = "";
        target_specific_features = "";

    g->target_machine = LLVMCreateTargetMachine(target_ref,
            target_specific_cpu_args, target_specific_features, opt_level,
reloc_mode, LLVMCodeModelDefault);

char *ZigLLVMGetHostCPUName(void) {
    std::string str = sys::getHostCPUName();
    return strdup(str.c_str());

char *ZigLLVMGetNativeFeatures(void) {
    SubtargetFeatures features;

    StringMap<bool> host_features;
    if (sys::getHostCPUFeatures(host_features)) {
        for (auto &F : host_features)
            features.AddFeature(F.first(), F.second);

    return strdup(features.getString().c_str());

On this windows laptop that I am testing on, I get these values:

target_specific_cpu_args: skylake


It successfully creates a binary, but the binary when run crashes with:

Unhandled exception at 0x00007FF7C9913BA7 in test.exe: 0xC0000005: Access
violation reading location 0xFFFFFFFFFFFFFFFF.

The disassembly of the crashed instruction is:

00007FF7C9913BA7  vmovdqa     xmmword ptr [rbp-20h],xmm0

There is no callstack or source in the MSVC debugger. The .pdb produced is
64KB exactly. The file was linked with:

lld -NOLOGO -DEBUG -MACHINE:X64 /SUBSYSTEM:console -OUT:.\test.exe
-NODEFAULTLIB -ENTRY:_start ./zig-cache/test.obj ./zig-cache/builtin.obj
./zig-cache/compiler_rt.obj ./zig-cache/kernel32.lib

When I change the call to LLVMCreateTargetMachine so that both
target_specific_cpu_args  and target_specific_features  are the empty
string, the produced binary is valid and runs successfully.

Is this an LLVM bug? Am I using the API incorrectly? Is there more
information I can provide to LLVM-dev mailing list that would make it
easier to help me?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170930/9b7b6ba8/attachment.html>

More information about the llvm-dev mailing list