http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59219
--- Comment #2 from Martin Sebor <msebor at gmail dot com> --- I'm suggesting that when -fno-builtin is used, __builtin___memcpy_chk (and other __bultin_xxx_chk) invocations that are determined not to exceed the size of the buffer boundaries expand to a call to memcpy instead of being expanded inline. Invocations that aren't guaranteed to be safe will continue to expand to calls to __memcpy_chk as they do now (i.e., I'm not suggesting a change there because freestanding implementations can and provide their own implementation of __memcpy_chk). I understand the convention of expanding __builtin_xxx invocations inline regardless of -fno-builtin but this convention makes the __builtin_xxx_chk intrinsics unusable in freestanding environments where the xxx functions have different semantics than those required of hosted implementations (and those assumed by GCC). A simple example where the inline expansion of __builtin___memcpy_chk is undesirable is a freestanding environment with a null-safe memcpy. This example can be dealt with by modifying the extern inline definiton of memcpy to avoid invoking __builtin___memcpy_chk when either of the pointers is null, so that can be easily solved with no compiler change. An example that can't be as easily solved without the proposed change is one involving __builtin___sprintf_chk where the freestanding implementation of sprintf behaves differently than the standard specifies for hosted implementations (and GCC's inline expansion assumes). For instance, the implementation could treat the $ character as the beginning of a formatting directive.
