Hi! On Tue, May 27, 2025 at 09:52:38AM +0100, Jonathan Wakely via Gcc-help wrote: > On Tue, 27 May 2025 at 09:38, Basile Starynkevitch wrote: > > > > On Tue, 2025-05-27 at 09:33 +0100, Jonathan Wakely wrote: > > > GCC assumes certain functions are always present, e.g. memcpy is needed for > > > copying large structs on the stack. The question is which functions does it > > > need. Your answer isn't really relevant to the question. > > > > > > memcpy is actually a builtin inside GCC. and has to be one because many > > processors (including x86-64 and ARM) has specific machine instructions to > > implement it efficiently. > > It *is* a built-in, but that doesn't mean it's implemented inside GCC. Yup. Many (or most?) builtin functions can actually expand to something calling the actual function with the same name. But they can also expand to more optimal code, and in all cases the compiler can see the actual semantics of what the code is doing, perhaps changing what code the compiler will generate for it. GCC always can use memcpy, the C standard requires memcpy to be usable. The externally callable version of the memcpy function is provided by some C library, on most configurations (just like many other functions, on systems that implement the POSIX requirements). There are four or five functions not provided by GCC itself (in libgcc or such) that the compiler needs to be available. The manual lists them: Most of the compiler support routines used by GCC are present in 'libgcc', but there are a few exceptions. GCC requires the freestanding environment provide 'memcpy', 'memmove', 'memset' and 'memcmp'. Contrary to the standards covering 'memcpy' GCC expects the case of an exact overlap of source and destination to work and not invoke undefined behavior. Finally, if '__builtin_trap' is used, and the target does not implement the 'trap' pattern, then GCC emits a call to 'abort'. (https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/Standards.html#C-Language, the one but last paragraph) Segher
