Clang doesn't define the typeinfo for _Float16

[ldionne]

When libc++ defines ~__fundamental_type_info(), Clang is supposed to emit the typeinfos for all fundamental types, which should include _Float16. But this doesn’t happen, as can be seen here: https://godbolt.org/z/EKTe8z3cf

Self-standing repro:

$ cat <<EOF | clang++ -xc++ - -c -o typeinfos.o && nm -omg typeinfos.o | c++filt | grep _Float16
namespace __cxxabiv1 {
    struct __fundamental_type_info {
        virtual ~__fundamental_type_info();
    };

    // This miraculously (compiler magic) emits the type_info's for:
    //   1. all of the fundamental types
    //   2. pointers to all of the fundamental types
    //   3. pointers to all of the const fundamental types
    __fundamental_type_info::~__fundamental_type_info()
    {
    }
}
EOF

Output is: nothing
Ouput should be: Something like

typeinfos.o: 0000000000000580 (__DATA,__const) external typeinfo for _Float16 const*
typeinfos.o: 0000000000000560 (__DATA,__const) external typeinfo for _Float16*
typeinfos.o: 0000000000000550 (__DATA,__const) external typeinfo for _Float16
typeinfos.o: 0000000000000927 (__TEXT,__const) external typeinfo name for _Float16 const*
typeinfos.o: 0000000000000924 (__TEXT,__const) external typeinfo name for _Float16*
typeinfos.o: 0000000000000922 (__TEXT,__const) external typeinfo name for _Float16

rdar://120819357

[DimitryAndric]

See the lists here: https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/ItaniumCXXABI.cpp#L4263 and https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/ItaniumCXXABI.cpp#L3313 .

The latter does contain BuiltinType::Float16 while the former doesn't, so maybe just an oversight?

[llvmbot]

@llvm/issue-subscribers-clang-codegen

Author: Louis Dionne (ldionne)

When libc++ defines `~__fundamental_type_info()`, Clang is supposed to emit the typeinfos for all fundamental types, which should include `_Float16`. But this doesn’t happen, as can be seen here: https://godbolt.org/z/EKTe8z3cf

Self-standing repro:

$ cat <<EOF | clang++ -xc++ - -c -o typeinfos.o && nm -omg typeinfos.o | c++filt | grep _Float16
namespace __cxxabiv1 {
    struct __fundamental_type_info {
        virtual ~__fundamental_type_info();
    };

    // This miraculously (compiler magic) emits the type_info's for:
    //   1. all of the fundamental types
    //   2. pointers to all of the fundamental types
    //   3. pointers to all of the const fundamental types
    __fundamental_type_info::~__fundamental_type_info()
    {
    }
}
EOF

Output is: nothing
Ouput should be: Something like

typeinfos.o: 0000000000000580 (__DATA,__const) external typeinfo for _Float16 const*
typeinfos.o: 0000000000000560 (__DATA,__const) external typeinfo for _Float16*
typeinfos.o: 0000000000000550 (__DATA,__const) external typeinfo for _Float16
typeinfos.o: 0000000000000927 (__TEXT,__const) external typeinfo name for _Float16 const*
typeinfos.o: 0000000000000924 (__TEXT,__const) external typeinfo name for _Float16*
typeinfos.o: 0000000000000922 (__TEXT,__const) external typeinfo name for _Float16

rdar://120819357

[jroelofs]

Should BFloat16 also be covered in those lists?

[DimitryAndric]

BFloat16 is listed in TypeInfoIsInStandardLibrary() with the category that returns false, instead of the standard types for which it returns true. That said, I have been looking at this a little bit, and it seems to me that EmitFundamentalRTTIDescriptors needs runtime checks to see if the target actually supports all those types.

I have got a preliminary patch but I need to update the relevant test cases, and those would then be target-dependent. Not sure what the best way is to exercise that.

[Snektron]

What's the status on this? I'm still hitting this problem in LLVM 20.0.0.

[jroelofs]

I agree that it needs to be target dependent. Consider deployments to macOS/iOS: we could add the new symbol to libSystem, but if we do then it needs both a version check, and a polyfill for back-deployment to systems where that symbol wasn’t present. In this case, it’s probably easier to always have the compiler emit the symbol on Darwin platforms, but I could imagine new platforms wanting to start with it always being present in libcxxabi.