[clang][alias|ifunc]: Add a diagnostic for mangled names

[0xdc03]

Summary

When an alias or ifunc attribute refers to a function name that is
mangled, a diagnostic is emitted to suggest the mangled name as a
replacement for the given function name for every matching name in the
current TU.

Fixes #59164

[0xdc03]

Note that as it stands currently, this patch cannot be committed because the test clang/test/SemaCXX/externc-ifunc-resolver.cpp fails to run. The contents of the test are as follows:

// RUN: %clang_cc1 -emit-llvm-only -triple x86_64-linux-gnu -verify %s

extern "C" {
__attribute__((used)) static void *resolve_foo() { return 0; }
namespace NS {
__attribute__((used)) static void *resolve_foo() { return 0; }
} // namespace NS

// FIXME: This diagnostic is pretty confusing, the issue is that the existence
// of the two functions suppresses the 'alias' creation, and thus the ifunc
// resolution via the alias as well. In the future we should probably find
// some way to improve this diagnostic (likely by diagnosing when we decide
// this case suppresses alias creation).
__attribute__((ifunc("resolve_foo"))) void foo(); // expected-error{{ifunc must point to a defined function}}
}

The error that I get is as follows:

Command Output (stderr):
--
+ : 'RUN: at line 1'
+ /mnt/entschuldigung/LLVM/llvm-main/build-release/bin/clang -cc1 -internal-isystem /mnt/entschuldigung/LLVM/llvm-main/build-release/lib/clang/17/include -nostdsysteminc -emit-llvm-only -triple x86_64-linux-gnu -verify /mnt/entschuldigung/LLVM/llvm-main/clang/test/SemaCXX/externc-ifunc-resolver.cpp
error: 'note' diagnostics seen but not expected:
  File /mnt/entschuldigung/LLVM/llvm-main/clang/test/SemaCXX/externc-ifunc-resolver.cpp Line 14: 'resolve_foo' exists as a mangled name, did you mean to use '_ZL11resolve_foov'?
  File /mnt/entschuldigung/LLVM/llvm-main/clang/test/SemaCXX/externc-ifunc-resolver.cpp Line 14: 'resolve_foo' exists as a mangled name, did you mean to use '_ZN2NSL11resolve_fooEv'?
2 errors generated.

--

which confuses me because an extern "C" block is not supposed to mangle any names, right? Appreciate any inputs on this.

[dblaikie]

In D143803#4120000, @0xdc03 wrote:

Note that as it stands currently, this patch cannot be committed because the test clang/test/SemaCXX/externc-ifunc-resolver.cpp fails to run. The contents of the test are as follows:

// RUN: %clang_cc1 -emit-llvm-only -triple x86_64-linux-gnu -verify %s

extern "C" {
__attribute__((used)) static void *resolve_foo() { return 0; }
namespace NS {
__attribute__((used)) static void *resolve_foo() { return 0; }
} // namespace NS

// FIXME: This diagnostic is pretty confusing, the issue is that the existence
// of the two functions suppresses the 'alias' creation, and thus the ifunc
// resolution via the alias as well. In the future we should probably find
// some way to improve this diagnostic (likely by diagnosing when we decide
// this case suppresses alias creation).
__attribute__((ifunc("resolve_foo"))) void foo(); // expected-error{{ifunc must point to a defined function}}
}

The error that I get is as follows:

Command Output (stderr):
--
+ : 'RUN: at line 1'
+ /mnt/entschuldigung/LLVM/llvm-main/build-release/bin/clang -cc1 -internal-isystem /mnt/entschuldigung/LLVM/llvm-main/build-release/lib/clang/17/include -nostdsysteminc -emit-llvm-only -triple x86_64-linux-gnu -verify /mnt/entschuldigung/LLVM/llvm-main/clang/test/SemaCXX/externc-ifunc-resolver.cpp
error: 'note' diagnostics seen but not expected:
  File /mnt/entschuldigung/LLVM/llvm-main/clang/test/SemaCXX/externc-ifunc-resolver.cpp Line 14: 'resolve_foo' exists as a mangled name, did you mean to use '_ZL11resolve_foov'?
  File /mnt/entschuldigung/LLVM/llvm-main/clang/test/SemaCXX/externc-ifunc-resolver.cpp Line 14: 'resolve_foo' exists as a mangled name, did you mean to use '_ZN2NSL11resolve_fooEv'?
2 errors generated.

--

which confuses me because an extern "C" block is not supposed to mangle any names, right? Appreciate any inputs on this.

Looks like maybe a Clang feature, that since they're "static"/internal linkage, Clang decides it can still mangle them: https://godbolt.org/z/6oMfjced1 - GCC doesn't do this, and fails if you try to overload them, whereas clang doesn't.

That does surprise me - if only for GCC/Clang compatibility, regardless of what the spec says, exactly...

[0xdc03]

nudge! at anyone who knows what to do here

[aaron.ballman]

Adding Erich as he's more familiar with ifunc and friends.

clang/lib/CodeGen/CodeGenModule.cpp

342

Does clang-format do this? It looks far beyond the usual 80 col limit we use.

355

359–360

Should this come with a fix-it to switch the attribute to using the mangled name instead?

[aaron.ballman]

Btw, these changes should come with a release note as well.

[erichkeane]

which confuses me because an extern "C" block is not supposed to mangle any names, right? Appreciate any inputs on this.

That IS strange, that has internal linkage, but so the 'extern "C"' doesn't do anything to it, so we choose to just mangle it. I guess there is some sense in that. GCC doesn't mangle EITHER of those (so leaving them both causes a multiple definition error!), but there is apparently a runtime error even trying to use an ifunc to those functions.

We COULD just prohibit ifuncs to functions without external linkage, but that is a bigger change than I'm sure I would want to commit to just yet.

As far as this patch, I think there is value with improving this diagnostic, but I'm not sure this is the one. I don't have a great idea of an alternate, BUT:

error: ifunc must point to a defined function
note: the name specified in an ifunc must refer to the <linkage name> (needs better words here for what we mean by the name it needs to call)
note: function by that name is mangled as %0
<and notes for each similar name>

[0xdc03]

I will try to come up with a better diagnostic for this issue and will try and update the patch as soon as I can.

In D143803#4150423, @aaron.ballman wrote:

Btw, these changes should come with a release note as well.

Are all functional changes logged in the release notes? I am not really aware of how they work.

clang/lib/CodeGen/CodeGenModule.cpp

342

It is beyond the 80 column limit because I formatted it by hand. The linting part of arc diff did not complain so it seemed fine to me. I suppose I was supposed to use git clang-format, I was not aware of it. I will use that command from now on.

359–360

I did consider it, however I have no idea how to implement that 😅

[aaron.ballman]

In D143803#4150624, @0xdc03 wrote:

In D143803#4150423, @aaron.ballman wrote:

Btw, these changes should come with a release note as well.

Are all functional changes logged in the release notes? I am not really aware of how they work.

Not quite all, but somewhat close to it -- if the changes are "user facing", we usually try to write a release note for it: https://llvm.org/docs/DeveloperPolicy.html#release-notes

clang/lib/CodeGen/CodeGenModule.cpp

342

I'd recommend using the patch formatting script: https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting

359–360

We have some documentation on that: https://clang.llvm.org/docs/InternalsManual.html#fix-it-hints

The basic idea here is that you'd create a replacement range so you can replace the old name with the new one.

[erichkeane]

clang/lib/CodeGen/CodeGenModule.cpp

359–360

Do we have to do some work to make sure we dont suggest multiple fixits? Or is that OK?

[aaron.ballman]

clang/lib/CodeGen/CodeGenModule.cpp

359–360

So long as each fix-it is associated with its own note, that's fine. We don't allow fix-its attached to notes to be automatically applied (specifically because we're either not certain the fix is correct or because there may be multiple fixes for the user to pick from).

[0xdc03]

• Update to address reviewer comments
• Add release note
• Redo notes to match reviewer comments
• Make the fix-it highlight the whole attribute
• Update tests to check new diagnostics

[0xdc03]

Okay, I have now modified the diagnostic to look something like (as per the discussion at https://discord.com/channels/636084430946959380/636732781086638081/1079356357024694363):

../../bug/ifunc-#59164.cpp:17:16: error: ifunc must point to a defined function
__attribute__((ifunc("resolver")))
               ^
../../bug/ifunc-#59164.cpp:17:16: note: the name specified in an ifunc must refer to the mangled name
../../bug/ifunc-#59164.cpp:17:16: note: function by that name is mangled as "_ZL8resolverv"
__attribute__((ifunc("resolver")))
               ^~~~~~~~~~~~~~~~~
               ifunc("_ZL8resolverv")
../../bug/ifunc-#59164.cpp:20:16: error: alias must point to a defined variable or function
__attribute__((alias("resolver")))
               ^
../../bug/ifunc-#59164.cpp:20:16: note: the name specified in an alias must refer to the mangled name
../../bug/ifunc-#59164.cpp:20:16: note: function by that name is mangled as "_ZL8resolverv"
__attribute__((alias("resolver")))
               ^~~~~~~~~~~~~~~~~
               alias("_ZL8resolverv")
../../bug/ifunc-#59164.cpp:23:24: error: ifunc must point to a defined function
__attribute__((unused, ifunc("resolver"), deprecated("hahahaha, isn't C great?"))) void func();
                       ^
../../bug/ifunc-#59164.cpp:23:24: note: the name specified in an ifunc must refer to the mangled name
../../bug/ifunc-#59164.cpp:23:24: note: function by that name is mangled as "_ZL8resolverv"
__attribute__((unused, ifunc("resolver"), deprecated("hahahaha, isn't C great?"))) void func();
                       ^~~~~~~~~~~~~~~~~
                       ifunc("_ZL8resolverv")
3 errors generated.

However, clang/test/SemaCXX/externc-ifunc-resolver.cpp still fails, and I am not entirely sure what to do with it. Should I update it to check the diagnostic? Also, it seems that the code I wrote prints "must refer to the mangled name" everywhere, even when the resolver or aliasee is not a function. Should I try to fix this? Or is it OK as it is?

[erichkeane]

In D143803#4154736, @0xdc03 wrote:

Okay, I have now modified the diagnostic to look something like (as per the discussion at https://discord.com/channels/636084430946959380/636732781086638081/1079356357024694363):

../../bug/ifunc-#59164.cpp:17:16: error: ifunc must point to a defined function
__attribute__((ifunc("resolver")))
               ^
../../bug/ifunc-#59164.cpp:17:16: note: the name specified in an ifunc must refer to the mangled name
../../bug/ifunc-#59164.cpp:17:16: note: function by that name is mangled as "_ZL8resolverv"
__attribute__((ifunc("resolver")))
               ^~~~~~~~~~~~~~~~~
               ifunc("_ZL8resolverv")
../../bug/ifunc-#59164.cpp:20:16: error: alias must point to a defined variable or function
__attribute__((alias("resolver")))
               ^
../../bug/ifunc-#59164.cpp:20:16: note: the name specified in an alias must refer to the mangled name
../../bug/ifunc-#59164.cpp:20:16: note: function by that name is mangled as "_ZL8resolverv"
__attribute__((alias("resolver")))
               ^~~~~~~~~~~~~~~~~
               alias("_ZL8resolverv")
../../bug/ifunc-#59164.cpp:23:24: error: ifunc must point to a defined function
__attribute__((unused, ifunc("resolver"), deprecated("hahahaha, isn't C great?"))) void func();
                       ^
../../bug/ifunc-#59164.cpp:23:24: note: the name specified in an ifunc must refer to the mangled name
../../bug/ifunc-#59164.cpp:23:24: note: function by that name is mangled as "_ZL8resolverv"
__attribute__((unused, ifunc("resolver"), deprecated("hahahaha, isn't C great?"))) void func();
                       ^~~~~~~~~~~~~~~~~
                       ifunc("_ZL8resolverv")
3 errors generated.

However, clang/test/SemaCXX/externc-ifunc-resolver.cpp still fails, and I am not entirely sure what to do with it. Should I update it to check the diagnostic? Also, it seems that the code I wrote prints "must refer to the mangled name" everywhere, even when the resolver or aliasee is not a function. Should I try to fix this? Or is it OK as it is?

I think updating that test with this additional note is the right thing to do. As far as that note, saying 'mangled name' is perhaps not correct there, since what we really care is that it is the name-as-emitted to the linker. I don't have an idea on exactly what to call it. If we could come up with a better phrase, it probably makes the diagnostic on the thing not being a function.

ALSO, it would be worth updating the error here to mention that it must point to a defined function, <x, y, Z> (where x,y,z are the things that it is allowed to target).

[0xdc03]

In D143803#4155266, @erichkeane wrote:

I think updating that test with this additional note is the right thing to do.

Will do, will also add checks for the fix-its.

As far as that note, saying 'mangled name' is perhaps not correct there, since what we really care is that it is the name-as-emitted to the linker. I don't have an idea on exactly what to call it. If we could come up with a better phrase, it probably makes the diagnostic on the thing not being a function.

First few that come to mind:

• ABI-mangled symbol
• Linked symbol
• Externally-visible name

It may also be worth splitting the diagnostic for ifuncs and aliases to be something like:

• ifunc: the function specified in an ifunc must refer to its <mangled name>
• alias: the function or variable specified in an alias must refer to its <mangled name>

I feel externally-visible name fits the best, though it doesn't really make sense with internal linkage.

ALSO, it would be worth updating the error here to mention that it must point to a defined function, <x, y, Z> (where x,y,z are the things that it is allowed to target).

Hmm, I do not really understand this point, could you please clarify it?

[erichkeane]

In D143803#4155345, @0xdc03 wrote:

In D143803#4155266, @erichkeane wrote:

I think updating that test with this additional note is the right thing to do.

Will do, will also add checks for the fix-its.

As far as that note, saying 'mangled name' is perhaps not correct there, since what we really care is that it is the name-as-emitted to the linker. I don't have an idea on exactly what to call it. If we could come up with a better phrase, it probably makes the diagnostic on the thing not being a function.

First few that come to mind:

• ABI-mangled symbol
• Linked symbol
• Externally-visible name

I don't think any of those are accurate with internal names. ABI-mangled is incorrect as the ABI says nothing about these. "Linked Symbol" isnt really accurate, as these aren't really 'linked'. AND, they aren't externally-visible. I wish I was better at this part :D Perhaps @shafik might have a better ability to bikeshed here?

It may also be worth splitting the diagnostic for ifuncs and aliases to be something like:

• ifunc: the function specified in an ifunc must refer to its <mangled name>
• alias: the function or variable specified in an alias must refer to its <mangled name>

I feel externally-visible name fits the best, though it doesn't really make sense with internal linkage.

ALSO, it would be worth updating the error here to mention that it must point to a defined function, <x, y, Z> (where x,y,z are the things that it is allowed to target).

Hmm, I do not really understand this point, could you please clarify it?

Exactly what you were saying above with the 'splitting the diagnostic', I was saying in less accurate words, that I'd prefer that.

[dblaikie]

I think "mangled name" is probably the closest without being overly verbose for the average user.

We do use "mangled name" in a few places already, some which look not too unrelated to this one:

clang/include/clang/Basic/DiagnosticSemaKinds.td:  "mangled name of %0 will change in C++17 due to non-throwing exception "
clang/include/clang/Basic/DiagnosticSemaKinds.td-  "specification in function signature">, InGroup<CXX17CompatMangling>;
clang/include/clang/Basic/DiagnosticSemaKinds.td-
--
clang/include/clang/Basic/DiagnosticSemaKinds.td:def err_hip_invalid_args_builtin_mangled_name : Error<
clang/include/clang/Basic/DiagnosticSemaKinds.td-    "invalid argument: symbol must be a device-side function or global variable">;
--
clang/include/clang/Basic/DiagnosticFrontendKinds.td:def err_duplicate_mangled_name : Error<
clang/include/clang/Basic/DiagnosticFrontendKinds.td:  "definition with same mangled name '%0' as another definition">;

[0xdc03]

• Reword the diagnostic messages
• Refactor tests to match updated diagnostic

[erichkeane]

Not thrilled about 'mangled name' still, but I can't think of anything better after all this time, so LGTM.

[0xdc03]

Okay, I have now modified the diagnostic to look like this:

../bug/ifunc-#59164.cpp:17:16: error: ifunc must point to a defined function
__attribute__((ifunc("resolver")))
               ^
../bug/ifunc-#59164.cpp:17:16: note: the function specified in an ifunc must refer to its mangled name
../bug/ifunc-#59164.cpp:17:16: note: function by that name is mangled as "_ZL8resolverv"
__attribute__((ifunc("resolver")))
               ^~~~~~~~~~~~~~~~~
               ifunc("_ZL8resolverv")
../bug/ifunc-#59164.cpp:20:16: error: alias must point to a defined variable or function
__attribute__((alias("resolver")))
               ^
../bug/ifunc-#59164.cpp:20:16: note: the function or variable specified in an alias must refer to its mangled name
../bug/ifunc-#59164.cpp:20:16: note: function by that name is mangled as "_ZL8resolverv"
__attribute__((alias("resolver")))
               ^~~~~~~~~~~~~~~~~
               alias("_ZL8resolverv")
../bug/ifunc-#59164.cpp:23:24: error: ifunc must point to a defined function
__attribute__((unused, ifunc("resolver"), deprecated("hahahaha, isn't C great?"))) void func();
                       ^
../bug/ifunc-#59164.cpp:23:24: note: the function specified in an ifunc must refer to its mangled name
../bug/ifunc-#59164.cpp:23:24: note: function by that name is mangled as "_ZL8resolverv"
__attribute__((unused, ifunc("resolver"), deprecated("hahahaha, isn't C great?"))) void func();
                       ^~~~~~~~~~~~~~~~~
                       ifunc("_ZL8resolverv")
3 errors generated.

Honestly I think this is good enough, I don't really think its worth bikeshedding over <mangled name>. I would anyways expect a user of these features to know how mangling works, so :shrug: from me.

I have also added checks for the fix-its.

[0xdc03]

In D143803#4171728, @erichkeane wrote:

Not thrilled about 'mangled name' still, but I can't think of anything better after all this time, so LGTM.

Oh wow your reply was much faster than I expected 😅. If you can, please land this patch on my behalf as I do not have commit access, using "Dhruv Chawla <[e-mail]>"

clang/docs/ReleaseNotes.rst

 - We now generate a diagnostic for signed integer overflow due to unary minus
   in a non-constant expression context.
   (`#31643 <https://github.com/llvm/llvm-project/issues/31643>`)
 - Clang now warns by default for C++20 and later about deprecated capture of
   ``this`` with a capture default of ``=``. This warning can be disabled with
   ``-Wno-deprecated-this-capture``.
 - Clang had failed to emit some ``-Wundefined-internal`` for members of a local
   class if that class was first introduced with a forward declaration.
+- Diagnostic notes and fix-its are now generated for ``ifunc``/``alias`` attributes
+  which point to functions whose names are mangled.
 
 Bug Fixes in This Version
 -------------------------
 
 - Fix crash when diagnosing incorrect usage of ``_Nullable`` involving alias
   templates.
   (`#60344 <https://github.com/llvm/llvm-project/issues/60344>`_)
 - Fix confusing warning message when ``/clang:-x`` is passed in ``clang-cl``

clang/include/clang/Basic/DiagnosticFrontendKinds.td

def warn_avx_calling_convention
     : Warning<"AVX vector %select{return|argument}0 of type %1 without '%2' "
               "enabled changes the ABI">,
       InGroup<DiagGroup<"psabi">>;
 def err_avx_calling_convention : Error<warn_avx_calling_convention.Summary>;
 
 def err_alias_to_undefined : Error<
   "%select{alias|ifunc}0 must point to a defined "
   "%select{variable or |}1function">;
+def note_alias_requires_mangled_name : Note<
+  "the %select{function or variable|function}0 specified in an %select{alias|ifunc}1 must refer to its mangled name">;
+def note_alias_mangled_name_alternative: Note<
+  "function by that name is mangled as \"%0\"">;
 def warn_alias_to_weak_alias : Warning<
   "%select{alias|ifunc}2 will always resolve to %0 even if weak definition of "
   "%1 is overridden">,
   InGroup<IgnoredAttributes>;
 def err_duplicate_mangled_name : Error<
   "definition with same mangled name '%0' as another definition">;
 def err_cyclic_alias : Error<
   "%select{alias|ifunc}0 definition is part of a cycle">;

clang/lib/CodeGen/CodeGenModule.cpp

static const llvm::GlobalValue *getAliasedGlobal(const llvm::GlobalValue *GV) {
 
   const llvm::GlobalValue *FinalGV = AliaseeGV->getAliaseeObject();
   if (FinalGV == GV)
     return nullptr;
 
   return FinalGV;
 }
 
-static bool checkAliasedGlobal(DiagnosticsEngine &Diags,
-                               SourceLocation Location, bool IsIFunc,
-                               const llvm::GlobalValue *Alias,
-                               const llvm::GlobalValue *&GV) {
+static bool checkAliasedGlobal(
+    DiagnosticsEngine &Diags, SourceLocation Location, bool IsIFunc,
+    const llvm::GlobalValue *Alias, const llvm::GlobalValue *&GV,
+    const llvm::MapVector<GlobalDecl, StringRef> &MangledDeclNames,
+    SourceRange AliasRange) {
   GV = getAliasedGlobal(Alias);
   if (!GV) {
     Diags.Report(Location, diag::err_cyclic_alias) << IsIFunc;
     return false;
   }
 
   if (GV->isDeclaration()) {
     Diags.Report(Location, diag::err_alias_to_undefined) << IsIFunc << IsIFunc;
+    Diags.Report(Location, diag::note_alias_requires_mangled_name)
+        << IsIFunc << IsIFunc;
+    // Provide a note if the given function is not found and exists as a
+    // mangled name.
+    for (const auto &[Decl, Name] : MangledDeclNames) {
+      if (const auto *ND = dyn_cast<NamedDecl>(Decl.getDecl())) {
+        if (ND->getName() == GV->getName()) {
+          Diags.Report(Location, diag::note_alias_mangled_name_alternative)
+              << Name
+              << FixItHint::CreateReplacement(
+                     AliasRange,
+                     (Twine(IsIFunc ? "ifunc" : "alias") + "(\"" + Name + "\")")
+                         .str());
+        }
+      }
+    }
     return false;
   }
 
   if (IsIFunc) {
     // Check resolver function type.
     const auto *F = dyn_cast<llvm::Function>(GV);
     if (!F) {
       Diags.Report(Location, diag::err_alias_to_undefined)
void CodeGenModule::checkAliases() {
   // Check if the constructed aliases are well formed. It is really unfortunate
   // that we have to do this in CodeGen, but we only construct mangled names
   // and aliases during codegen.
   bool Error = false;
   DiagnosticsEngine &Diags = getDiags();
   for (const GlobalDecl &GD : Aliases) {
     const auto *D = cast<ValueDecl>(GD.getDecl());
     SourceLocation Location;
+    SourceRange Range;
     bool IsIFunc = D->hasAttr<IFuncAttr>();
-    if (const Attr *A = D->getDefiningAttr())
+    if (const Attr *A = D->getDefiningAttr()) {
       Location = A->getLocation();
-    else
+      Range = A->getRange();
+    } else
       llvm_unreachable("Not an alias or ifunc?");
 
     StringRef MangledName = getMangledName(GD);
     llvm::GlobalValue *Alias = GetGlobalValue(MangledName);
     const llvm::GlobalValue *GV = nullptr;
-    if (!checkAliasedGlobal(Diags, Location, IsIFunc, Alias, GV)) {
+    if (!checkAliasedGlobal(Diags, Location, IsIFunc, Alias, GV,
+                            MangledDeclNames, Range)) {
       Error = true;
       continue;
     }
 
     llvm::Constant *Aliasee =
         IsIFunc ? cast<llvm::GlobalIFunc>(Alias)->getResolver()
                 : cast<llvm::GlobalAlias>(Alias)->getAliasee();
 

clang/test/CodeGen/alias.cpp

+// RUN: %clang_cc1 -triple x86_64-linux -verify -emit-llvm-only %s
+// RUN: not %clang_cc1 -triple x86_64-linux -emit-llvm-only -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s
+
+void *f1_ifunc(void) { return nullptr; }
+void f1(void) __attribute__((alias("f1_ifunc")));
+// expected-error@-1 {{alias must point to a defined variable or function}}
+// expected-note@-2 {{must refer to its mangled name}}
+// expected-note@-3 {{function by that name is mangled as}}
+// CHECK: fix-it:"{{.*}}":{[[@LINE-4]]:30-[[@LINE-4]]:47}:"alias(\"_Z8f1_ifuncv\")"
+
+void *f6_resolver_resolver(void) { return 0; }
+void *f6_resolver(void) __attribute__((alias("f6_resolver_resolver")));
+// expected-error@-1 {{alias must point to a defined variable or function}}
+// expected-note@-2 {{must refer to its mangled name}}
+// expected-note@-3 {{function by that name is mangled as}}
+// CHECK: fix-it:"{{.*}}":{[[@LINE-4]]:40-[[@LINE-4]]:69}:"alias(\"_Z20f6_resolver_resolverv\")"
+void f6(void) __attribute__((alias("f6_resolver")));
+// expected-error@-1 {{alias must point to a defined variable or function}}
+// expected-note@-2 {{must refer to its mangled name}}
+// expected-note@-3 {{function by that name is mangled as}}
+// CHECK: fix-it:"{{.*}}":{[[@LINE-4]]:30-[[@LINE-4]]:50}:"alias(\"_Z11f6_resolverv\")"
+
+__attribute__((unused, alias("resolver"), deprecated("hahahaha, isn't C great?")))
+void func();
+// expected-error@-2 {{alias must point to a defined variable or function}}
+// expected-note@-3 {{must refer to its mangled name}}
+

clang/test/CodeGen/attr-ifunc.c

 // RUN: %clang_cc1 -triple x86_64-windows -fsyntax-only -verify %s
 // RUN: %clang_cc1 -triple x86_64-linux -fsyntax-only -verify -emit-llvm-only -DCHECK_ALIASES %s
 // RUN: %clang_cc1 -triple x86_64-linux -fsyntax-only -verify -emit-llvm-only %s
 
 #if defined(_WIN32)
 void foo(void) {}
 void bar(void) __attribute__((ifunc("foo")));
 // expected-warning@-1 {{unknown attribute 'ifunc' ignored}}
 
 #else
 #if defined(CHECK_ALIASES)
 void *f1_ifunc(void);
 void f1(void) __attribute__((ifunc("f1_ifunc")));
 // expected-error@-1 {{ifunc must point to a defined function}}
+// expected-note@-2 {{must refer to its mangled name}}
 
 void *f2_a(void) __attribute__((alias("f2_b")));
 void *f2_b(void) __attribute__((ifunc("f2_a")));
 // expected-error@-1 {{ifunc definition is part of a cycle}}
 
 void *f3_a(void) __attribute__((ifunc("f3_b")));
 // expected-warning@-1 {{ifunc will always resolve to f3_c even if weak definition of f3_b is overridden}}
 void *f3_b(void) __attribute__((weak, alias("f3_c")));

clang/test/CodeGen/attr-ifunc.cpp

+// RUN: %clang_cc1 -triple x86_64-linux -fsyntax-only -verify -emit-llvm-only %s
+// RUN: not %clang_cc1 -triple x86_64-linux -emit-llvm-only -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s
+
+void *f1_ifunc(void) { return nullptr; }
+void f1(void) __attribute__((ifunc("f1_ifunc")));
+// expected-error@-1 {{ifunc must point to a defined function}}
+// expected-note@-2 {{must refer to its mangled name}}
+// expected-note@-3 {{function by that name is mangled as}}
+// CHECK: fix-it:"{{.*}}":{[[@LINE-4]]:30-[[@LINE-4]]:47}:"ifunc(\"_Z8f1_ifuncv\")"
+
+void *f6_resolver_resolver(void) { return 0; }
+void *f6_resolver(void) __attribute__((ifunc("f6_resolver_resolver")));
+// expected-error@-1 {{ifunc must point to a defined function}}
+// expected-note@-2 {{must refer to its mangled name}}
+// expected-note@-3 {{function by that name is mangled as}}
+// CHECK: fix-it:"{{.*}}":{[[@LINE-4]]:40-[[@LINE-4]]:69}:"ifunc(\"_Z20f6_resolver_resolverv\")"
+void f6(void) __attribute__((ifunc("f6_resolver")));
+// expected-error@-1 {{ifunc must point to a defined function}}
+// expected-note@-2 {{must refer to its mangled name}}
+// expected-note@-3 {{function by that name is mangled as}}
+// CHECK: fix-it:"{{.*}}":{[[@LINE-4]]:30-[[@LINE-4]]:50}:"ifunc(\"_Z11f6_resolverv\")"
+
+__attribute__((unused, ifunc("resolver"), deprecated("hahahaha, isn't C great?")))
+void func();
+// expected-error@-2 {{ifunc must point to a defined function}}
+// expected-note@-3 {{must refer to its mangled name}}
+

clang/test/Sema/attr-alias-elf.c

 // RUN: %clang_cc1 -triple x86_64-pc-linux -Wno-strict-prototypes -fsyntax-only -verify -emit-llvm-only %s
 
 void f1(void) __attribute__((alias("g1")));
 void g1(void) {
 }
 
 void f2(void) __attribute__((alias("g2"))); // expected-error {{alias must point to a defined variable or function}}
-
+// expected-note@-1 {{must refer to its mangled name}}
 
 void f3(void) __attribute__((alias("g3"))); // expected-error {{alias must point to a defined variable or function}}
+// expected-note@-1 {{must refer to its mangled name}}
 void g3(void);
 
 
 void f4() __attribute__((alias("g4")));
 void g4() {}
 void h4() __attribute__((alias("f4")));
 
 void f5() __attribute__((alias("g5")));

 // FIXME: This could be a bit better, h10 is not part of the cycle, it points
 // to it.
 void h10() __attribute__((alias("g10"))); // expected-error {{alias definition is part of a cycle}}
 
 extern int a1 __attribute__((alias("b1")));
 int b1 = 42;
 
 extern int a2 __attribute__((alias("b2"))); // expected-error {{alias must point to a defined variable or function}}
+// expected-note@-1 {{must refer to its mangled name}}
 
 extern int a3 __attribute__((alias("b3"))); // expected-error {{alias must point to a defined variable or function}}
+// expected-note@-1 {{must refer to its mangled name}}
 extern int b3;
 
 extern int a4 __attribute__((alias("b4"))); // expected-error {{alias must point to a defined variable or function}}
+// expected-note@-1 {{must refer to its mangled name}}
 typedef int b4;
 
 void test2_bar() {}
 void test2_foo() __attribute__((weak, alias("test2_bar")));
 void test2_zed() __attribute__((alias("test2_foo"))); // expected-warning {{alias will always resolve to test2_bar even if weak definition of test2_foo is overridden}}
 
 void test3_bar() { }
 void test3_foo() __attribute__((section("test"))); // expected-warning {{alias will not be in section 'test' but in the same section as the aliasee}}
 void test3_foo() __attribute__((alias("test3_bar")));
 
 __attribute__((section("test"))) void test4_bar() { }
 void test4_foo() __attribute__((section("test")));
 void test4_foo() __attribute__((alias("test4_bar")));
 
 int test5_bar = 0;
 extern struct incomplete_type test5_foo __attribute__((alias("test5_bar")));

clang/test/SemaCXX/externc-ifunc-resolver.cpp

 // RUN: %clang_cc1 -emit-llvm-only -triple x86_64-linux-gnu -verify %s
+// RUN: not %clang_cc1 -triple x86_64-linux -emit-llvm-only -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s
 
 extern "C" {
 __attribute__((used)) static void *resolve_foo() { return 0; }
 namespace NS {
 __attribute__((used)) static void *resolve_foo() { return 0; }
 } // namespace NS
 
 // FIXME: This diagnostic is pretty confusing, the issue is that the existence
 // of the two functions suppresses the 'alias' creation, and thus the ifunc
 // resolution via the alias as well. In the future we should probably find
 // some way to improve this diagnostic (likely by diagnosing when we decide
 // this case suppresses alias creation).
 __attribute__((ifunc("resolve_foo"))) void foo(); // expected-error{{ifunc must point to a defined function}}
+// expected-note@-1 {{must refer to its mangled name}}
+// expected-note@-2 {{function by that name is mangled as}}
+// expected-note@-3 {{function by that name is mangled as}}
+// CHECK: fix-it:"{{.*}}":{[[@LINE-4]]:16-[[@LINE-4]]:36}:"ifunc(\"_ZL11resolve_foov\")"
+// CHECK: fix-it:"{{.*}}":{[[@LINE-5]]:16-[[@LINE-5]]:36}:"ifunc(\"_ZN2NSL11resolve_fooEv\")"
 }