[llvm-bugs] [Bug 41834] New: asm labels and overloading

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=41834

            Bug ID: 41834
           Summary: asm labels and overloading
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: aaron at aaronballman.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org,
                    neeilans at live.com, richard-llvm at metafoo.co.uk

It seems that asm labels do not play well with __attribute__((overloadable)) in
that only a single function definition is emit when there are two functions
with the same asm label. e.g.,

#define _TG_ATTRS __attribute__((__overloadable__))

static short _TG_ATTRS __tg_acos(short __x) asm("foo");
static short _TG_ATTRS __tg_acos(short __x) {
  // overflow
  short ret = 3;
  return ret / __x;
}

static int _TG_ATTRS __tg_acos(int __x) asm("foo");
static int _TG_ATTRS __tg_acos(int __x) {
  // no overflow
  int ret = 1999;
  return ret + __x;
}

void call_short() {
  short k = 0;
  __tg_acos(k);
}

In this code, only one function named "foo" is emitted, so the overloading is
silently ignored. Instead, the last definition with the label name is what gets
emitted. See https://godbolt.org/z/U8CyMw for details.

I'm not certain what should happen here. The user specified an assembly name
which we should try to honor, but then we cannot honor the overloadable
attribute because there is no way to get the proper name mangling for the
function. We should either ignore the overloadable attribute or the asm label
and then diagnose what we're ignoring so the user has a better chance of
understanding what's going on.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190510/e4aac81a/attachment.html>