__builtin_object_size(p, 1) misbehaves when inlined

[kees]

Using __builtin_object_size(p, 1) in within an inline acts like mode 0 instead of mode 1.

#include <stdint.h>
#include <string.h>
#include <stdio.h>

#define show(expr) printf("%s: %zu\n", #expr, expr)

struct object {
        int a;
        char buf[7];
        int c;
};

static inline void func_inline(const char *ptr)
{
    puts("func_inline");
    show(__builtin_object_size(ptr, 0));
    show(__builtin_object_size(ptr, 1));
}

void __attribute__ ((noinline)) func(const char *ptr)
{
    puts("func");
    show(__builtin_object_size(ptr, 0));
    show(__builtin_object_size(ptr, 1));
}

int main(void)
{
    struct object instance;

    puts("main");
    show(__builtin_object_size(instance.buf, 0));
    show(__builtin_object_size(instance.buf, 1));

    func_inline(instance.buf);

    func(instance.buf);

    return 0;
}

GCC:

main
__builtin_object_size(instance.buf, 0): 12
__builtin_object_size(instance.buf, 1): 7
func_inline
__builtin_object_size(ptr, 0): 12
__builtin_object_size(ptr, 1): 7
func
__builtin_object_size(ptr, 0): 18446744073709551615
__builtin_object_size(ptr, 1): 18446744073709551615

Clang:

main
__builtin_object_size(instance.buf, 0): 12
__builtin_object_size(instance.buf, 1): 7
func_inline
__builtin_object_size(ptr, 0): 12
__builtin_object_size(ptr, 1): 12
func
__builtin_object_size(ptr, 0): 18446744073709551615
__builtin_object_size(ptr, 1): 18446744073709551615

[zygoloid]

There's not really anything we can feasibly do about this.

The current behaviour is not strictly wrong: we're required to produce an upper bound of the amount of memory accessible here, and we do, but it's not very precise. The reason for that is that LLVM has no idea about the front-end notions of struct members, and Clang doesn't itself do any inlining, so by the time inlining happens the information we'd need here is gone. We're able to get the right answer in main because the front-end can compute that itself. To match this behaviour we'd need significant heroics somewhere -- perhaps either speculatively emitting some metadata everywhere just in case some inlined call to objectsize inspects it, or a different lowering strategy for Clang that provides a front-end inliner, or maybe a special-case analysis in the front-end looking for exactly this pattern in the AST and customizing the code generation for it -- but these would all be expensive options in one way or another.

Fundamentally what you're seeing here is that the GCC implementation is exposing architectural details of the design of GCC that Clang and LLVM don't share.

We do provide a workaround for this architectural difference: Clang has a pass_object_size attribute for pointer parameters to functions that causes us to pass the object size as an implicit parameter. If you use that, you should be able to get the same behaviour as GCC. (That also would mean the behaviour doesn't depend on whether the function happens to be inlined or not.)

[kees]

Ah, I see. I hadn't realized that the structure layout itself could be modified on the way through IR fun. Yes, that does pose a problem. gbiv has helped me get pass_object_size working, though it still suffers from being blocked by inlining. I will ponder how the "end of C struct member" detail could be encoded somewhere in the IR...