clang-cl "cannot mangle this built-in __float128 type" due to promotions

[zmodem]

Bugzilla Link	35174
Resolution	FIXED
Resolved on	Nov 15, 2017 09:12
Version	trunk
OS	Linux
CC	@DougGregor,@dpxf,@zygoloid,@rnk

Extended Description

$ cat /tmp/a.cc
template struct B;
template constexpr bool is_floating_point_v = false;

struct StrictNumeric {
StrictNumeric(int);
template <typename Dst, B<is_floating_point_v> = nullptr> operator Dst();
};

static_assert(StrictNumeric(1) > 0);

$ bin/clang -cc1 -triple i686-pc-win32 /tmp/a.cc -std=c++17 -emit-obj

error: cannot mangle this built-in __float128 type yet
/tmp/a.cc:9:32: error: invalid operands to binary expression ('StrictNumeric' and 'int')
static_assert(StrictNumeric(1) > 0);
~~~~~~~~~~~~~~~~ ^ ~
2 errors generated.

Note that the source never mentions __float128, but Clang tries to use it when it tries to find a conversion of the StrictNumeric that works with the > expression. In the process, it instantiates is_floating_point_v<__float128>, causing the mangling error.

Should BuiltinOperatorOverloadBuilder::addGenericBinaryArithmeticOverloads() only consider types that are valid for the target?

(We hit this in Chromium with the latest MS SDK; see http://crbug.com/780311)

[zygoloid]

Should BuiltinOperatorOverloadBuilder::addGenericBinaryArithmeticOverloads()
only consider types that are valid for the target?

Yes, that would make sense. If a target has no meaningful __float128, we shouldn't consider it there. But why are we even mangling a weak symbol that we're never going to actually emit?

[rnk]

We appear to emit the variable template instantiation:

anonymous namespace'::MicrosoftCXXNameMangler::mangleType() Line 1875 anonymous namespace'::MicrosoftCXXNameMangler::mangleType() Line 62
anonymous namespace'::MicrosoftCXXNameMangler::mangleTemplateArgs() Line 1332 anonymous namespace'::MicrosoftCXXNameMangler::mangleTemplateInstantiationName() Line 1241
anonymous namespace'::MicrosoftCXXNameMangler::mangleUnqualifiedName() Line 765 anonymous namespace'::MicrosoftCXXNameMangler::mangleName() Line 664
anonymous namespace'::MicrosoftCXXNameMangler::mangle() Line 437 anonymous namespace'::MicrosoftMangleContextImpl::mangleCXXName() Line 2604
clang::CodeGen::CodeGenModule::getMangledName() Line 743
clang::CodeGen::CodeGenModule::EmitGlobal() Line 1828
clang::CodeGen::CodeGenModule::EmitTopLevelDecl() Line 4017
clang::Sema::InstantiateVariableDefinition() Line 4468
DoMarkVarDeclReferenced() Line 14892
clang::Sema::MarkDeclRefReferenced() Line 15000
clang::Sema::BuildDeclRefExpr() Line 1674
clang::Sema::BuildDeclarationNameExpr() Line 2990
clang::Sema::CheckVarTemplateId() Line 3885
clang::Sema::BuildTemplateIdExpr() Line 3928
clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformUnresolvedLookupExpr() Line 10472
clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformExpr() Line 721
clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateArgument() Line 3925
clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateArguments<clang::TemplateArgumentLocContainerIteratorclang::TemplateSpecializationTypeLoc >() Line 4105
clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateSpecializationType() Line 5856
clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateSpecializationType() Line 5733
clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType() Line 99
clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType() Line 4150
clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType() Line 4131
clang::Sema::SubstType() Line 1620
clang::Sema::CheckTemplateArgument() Line 4527
ConvertDeducedTemplateArgumentsclang::FunctionTemplateDecl() Line 2504
clang::Sema::FinishTemplateArgumentDeduction() Line 3151
clang::Sema::DeduceTemplateArguments() Line 4156
clang::Sema::AddTemplateConversionCandidate() Line 6993
IsUserDefinedConversion() Line 3365
TryUserDefinedConversion() Line 1227
TryImplicitConversion() Line 1359
TryCopyInitialization() Line 4992
clang::Sema::AddBuiltinCandidate() Line 7225
`anonymous namespace'::BuiltinOperatorOverloadBuilder::addGenericBinaryArithmeticOverloads() Line 8100

[zygoloid]

If I make the example compile:

template struct B; template<> struct B { using type = void*; };
template constexpr bool is_floating_point_v = __is_floating_point(T);

struct StrictNumeric {
constexpr StrictNumeric(int) {}
template <typename Dst, typename B<is_floating_point_v>::type = nullptr> operator Dst();
friend constexpr bool operator>(StrictNumeric, int) { return true; };
};

static_assert(StrictNumeric(1) > 0);

... it emits no IR when targeting an Itanium ABI platform, but errors when targeting MSABI.

A bit more tweaking...

template <typename Dst, typename B<(float*)0 == (Dst*)0>::type = nullptr, typename B<is_floating_point_v>::type = nullptr> operator Dst();

... and it compiles with MSABI as well, and does not emit is_floating_point_v. So it looks like we are mangling that symbol even though we aren't going to emit it. Here's the relevant code from EmitGlobal:

StringRef MangledName = getMangledName(GD);
if (GetGlobalValue(MangledName) != nullptr) {
// The value has already been used and should therefore be emitted.
addDeferredDeclToEmit(GD);
} else if (MustBeEmitted(Global)) {
// The value must be emitted, but cannot be emitted eagerly.
assert(!MayBeEmittedEagerly(Global));
addDeferredDeclToEmit(GD);
} else {
// Otherwise, remember that we saw a deferred decl with this name. The
// first use of the mangled name will cause it to move into
// DeferredDeclsToEmit.
DeferredDecls[MangledName] = GD;
}

So, CodeGen is assuming that it can form a mangled name for all defined entities, even ones it won't actually happen to emit. That seems a little wasteful, but not really wrong, and at least explains how we got to this diagnostic.

[zmodem]

Patch attempt: https://reviews.llvm.org/D39579

[zmodem]

r318309