<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/58724>58724</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            Infinite self-recursion for functions renamed with __asm__, combined with inline specialization of it
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            clang,
            c
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          mstorsjo
      </td>
    </tr>
</table>

<pre>
    (This relates to similar code patterns as in https://reviews.llvm.org/D137073.)

One may want to redirect a well known public function name to a specific implementation name with `__asm__`.

One may also want to specialize that function with an inline version of it, which may (or may not) do special extra checks on the inputs, and fall back on the base implementation for the heavy lifting. This pattern with extra inline specializations is used e.g. for `_FORTIFY_SOURCE` macros.

This may look something like this:
```c
#ifdef _WIN64
typedef unsigned long long size_t;
#elif defined(_WIN32)
typedef unsigned int size_t;
#else
typedef unsigned long size_t;
#endif

//#define public_func_name strlen

size_t func_impl(const char *);

// Redirect use of public_func_name to func_impl. The declaration above
// is only necessary to allow calling it directly.
size_t public_func_name(const char *) __asm__("func_impl");

// Provide an inline version of public_func_name, which might or might not
// do some extra checks, and finally falls back on calling func_impl.
extern __inline__ __attribute__((__always_inline__, __gnu_inline__))
size_t public_func_name(const char *a) { 
  return func_impl(a);
}

void call(void) {
  public_func_name("foo");
}
```

If this is compiled with current Clang (e.g. 2390bb2347703bf500333fcd4d8c1b513a6e1740, Nov 1 2022), it produces an infinite loop:
```
$ clang -target x86_64-linux-gnu -S -o - -O2 clang-rename-inline.c
call:
.LBB0_1:
        jmp     .LBB0_1
```

If the function `public_func_name` is renamed to a function which Clang knows as a builtin, e.g. by uncommenting `#define public_func_name strlen`, then Clang successfully compiles this as one would have hoped:
```
$ clang -target x86_64-linux-gnu -S -o - -O2 clang-rename-inline.c
call:
        leaq    .L.str(%rip), %rdi
        jmp     func_impl@PLT
```

This can be tested online at https://gcc.godbolt.org/z/b814Y9Tjb too.

Note that this seems to have changed recently. With `#define public_func_name strlen`; Clang 13 produces the same infinite recursion still. Clang 14 and 15 produce a bogus call to `jmp strlen.inline`, while current Clang 16 seems to do the right thing.

(Also, doing such things for `strlen` is a bit unexpected - `strlen` was picked just for simplicity for the code example. Actual uses of such patterns do arise for e.g. printf style functions together with `_FORTIFY_SOURCE`.)

CC @lhmouse


</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJy9V0lv2zgU_jX2hbCgzdvBhywTIEDRFG0GRU8CRVEWE0rUkJQd99fPe6QWO_G0PU3gyJJIvu373uJcFafdLN48V8IQzSW13BCriBG1kFQTpgpOWmot140h1BDRkMra1sySm1n8AB_ND4IfTSDloQ6U3sOr-yhZh-skmMXbWXg_C2_89anhpKYncqSNRR2aF0JzZgklRy4leW3UsSFtl0vBSNk1zArVkIbWHHdTYlrORAlrom4lr3lj6bTjKGxFZqswy6ipswzugmu6qTRqNMAJpFL8BAUVtZNOJ4w24KwUcPDAtcHXqiTCzuI7cqwEq5w8CJ3S7q5RsLQlxSiW8DerKWEVZ6-GwHFbcZDYdtagDNoUpKTgdk7Z67CcU8Pfu1eCAlyrOD2ciBSlFc0-IA6xHhlvsNfX2zz65oQAboZ0hheEB3AWRWKsHp6-Pj8-_Mi-Pf399e4veAOeMK3MReicIvRQKvVKjKq5rcACsOQV4yYcFfz-Veg_rH-OE1EWvCTZ98fPq9S_tKeW47uuMWLfgEVSoTC8GEAis7PkdjzOwV0Cu8GjAkKNcpJ4pNUHUQJwvSbE8F_pvnKiKUR5HgNPdVjxtvQkzZAwmaOfsVry5vyIl-o4lSGiYD4DICwQAvJqFt-gG6POMy3k65AXABhy7oMyoO4oFonAIUQMstXzhebqwC8ECqSfBIpyxo2h-uTySUp1JAy-EExhiVcqT8GF_e-VX3ODDEkXb2ZxfOZx_J8-ftHqIKC0XE2yjzrHlBP7yhLMOHeDOXcuFZMP-HmReWOuiQZ8PbmcM2PSDf5P8fQCQQLmVZZ567IMfbRWi7yzvPd0A6_kkZ7MuAl1Zdm-6c7ebEe6_mlEKYZ0tr4l_hiBQmk7MOacSvQisuv78xAflCicY7AP73txg7Qr-hE1pd7jNUod0vpcyWPpch-5xVTdCgnZ5KoQ67SG2kXuJIW4gnBXceJkG-Z5nKTrdZjk5TIMkyQpWZEWGxblyyihKx6t0xAj-FkdSETi0JsDL4CcrVZFB-z1hAEsheVYkNqPxWdgREqYM2Fhqd5zS942q2yVLgCX7m0BGJHFN7JQZEEWT7HfugDDISALD17QVzEXyUFL8On2Nsyi8Zn0fy91676H9d8Ejk-9BpY_IAKF2LVjfCh885t6k0sEH13smK4rU5J3QkJjwHC5gOcnqHKADPYRJDha8dvytXLxB_OaXoHpGJaMssPM6XE2HniKRQX6rupkQSp6gAaloLr-z3gM8Zec_uPjH4AvjtJLLdqeQPhQiOuITVmVhl8-Pf8COdcIGRAwhxLMjQVolK9dMDtcDkV7xoK9KnIlbT8T_YT_fBOlP7bPLzlAqi567Gdl-xnExdZwXrsxzMUV6kKzB2VQngFMKNDkez_s_BGiyW0PZpRMaYQUNLhvTCaQ3vkKbKyQ0Ff6Q6mrntFyOItcU_vOuAqDNoIOjKVXGHiseiYBVyV_VxGi1eQe1Gs0RLti7qaK4LJXbG5gXkNJhRKejpXfZ4YZZvQTMwZMg1rRNfwNph_EZ3G55QikbQV7hZWXDiouyjCIvWDCnsZJyw29_I3iHBaQG2Y7mOagGRtsTs6GcSIGD6gW0KfxrEu8VsMUAtvsSU5Zjt4C5yuup0H1w_D1fl6-A-Kmoaxq1Q0DjL_O-S5ardbxdr1aL-fFLim2yZbOrbCS7x4HQA2X5WJCFQ2czBlqi7NmbN93mOM5Dlt-4eos6cfgeafl7h3p4UiXByACHvDnQP-1AOa8AB7wKIzpOLTkh-VmHafzasf4ktKoyNdxAd0g3NK0SPOcLottnEfRdjOXNIf5bTdb3kJ7clXBtSnM6Zjh7fJ-LnbYLKIoxE-aLIN4veRpWLKo2GxpwXMII6-pkOOPlLneOcvybm8wxsLY6RfMnBo3HnKnFeTTzlZK72pjlTYvau682DkX_gWrpkIN">