From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3E4703858298; Tue, 19 Dec 2023 08:28:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3E4703858298 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1702974512; bh=MB3+C0b8KtKT14P8vVsBrO0F6y6cnr/dyh5ZSW4jg0g=; h=From:To:Subject:Date:In-Reply-To:References:From; b=HjQwgilHbaqgjszlwQS+wIorC02DNbwRRBN+e1b5bmNM1z0tmt7GeV+4f5IflZYB8 jS7OIK9YfyOhYzjPhWzVzIjOi8r8aiUl7wVDAO2WVwfY2vQdRUzZwRfnUopbzLGEC/ RxaWHAq5eCESzDX/dsXYXrPvXRgLiK/z0rygip9A= From: "david at westcontrol dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/56888] memcpy implementation optimized as a call to memcpy Date: Tue, 19 Dec 2023 08:28:25 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 4.8.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: david at westcontrol dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D56888 --- Comment #51 from David Brown --- (In reply to M Welinder from comment #48) > It's your (1). gcc is changing a program that can rely on errno not being > changed to one where the C library can change it. (The current C library= or > any future library that the resulting binary may be dynamically linked > against.) >=20 > Is there any real-world situation that benefits from introducing these > calls? It has the feel of optimizing for a benchmark. There are several real-world benefits from transforming back and forth betw= een library calls for this kind of small standard library function. One is that turning explicit code into library calls can give smaller code - often of importance in small embedded targets. Sometimes it can also result in run-= time improvements, especially for larger data sizes - user-written code might ju= st copy byte by byte, while the library implementation uses more efficient lar= ger blocks. Another is that turning library calls into inlined code can speed up code by using additional knowledge of sizes, alignment, etc., to get faster results= .=20 This is most obvious for calls to memcpy() or memmove(), which can sometime= s be required to get the semantics correct for type manipulation, but may genera= te no actual code at all. A "C implementation" consists of a compiler and a standard library in tande= m.=20 The C library can make use of its knowledge of the C compiler, and any spec= ial features, in its implementation. (This is, in fact, required - some things= in the standard library cannot be implemented in "pure" C.) The C compiler can make use of its knowledge of the library implementation in its code generat= ion or analysis. For the most part, compilers only make use of their knowledge= of the specifications of standard library functions, but they might also use implementation details. This means it is quite legitimate for the GCC team to say that gcc requires= a C library that does not set errno except for functions that explicitly say so= in their specifications. Users don't get to mix and match random compilers and random standard libraries and assume they form a conforming C implementatio= n - the pair must always be checked for compatibility. The question then is if this would be an onerous requirement for standard library implementations - do common existing libraries set errno in functio= ns that don't require it? I cannot say, but I would be very surprised if they did. Modern thought, AFAIUI, considers errno to be a bad idea which should= be avoided whenever possible - it is a hinder to optimisation, analysis, and parallelisation of code, as well as severely limiting C++ constexpr and oth= er compile-time calculations. My thoughts here are that GCC should make this library requirement explicit= and public, after first confirming with some "big name" libraries like glibc, newlib and muslc. They could also add a flag "-funknown-stdlib" to disable= any transforms back or forth between standard library calls, and assume nothing about the calls (not even what is given in the standards specifications). (As a note - the paragraph 7.5p3 allowing standard library functions to set errno is still in the current draft of C23.)=