From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by server2.sourceware.org (Postfix, from userid 48) id A91173943546; Sun, 8 Mar 2020 13:25:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 server2.sourceware.org A91173943546 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1583674313; bh=pJJyoOHt/o37y/MsTw2yFvV3NU0CR2Bdqix5P428x14=; h=From:To:Subject:Date:In-Reply-To:References:From; b=hBUZQl977/4eWbqjvnS3i8/Wiav3Xynq14OGydPZTBmQzHLSy0r26dnS2r0YigRHT 8WCkP3SY53/7UggioDJQeq2zoJ7jQszPurrvjaUJFwoleeV9gWa/11TGmJ8i6N2osz +8QcA7KUZSkQI9E2lPvIkExhMbYH1ivo0Bp6mz6k= From: "D.Bahadir at GMX dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/94082] __builtin_memcpy in constexpr context should compile Date: Sun, 08 Mar 2020 13:25:07 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: D.Bahadir at GMX dot de X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned 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 X-Spam-Status: No, score=-7.9 required=5.0 tests=ALL_TRUSTED, BAYES_00, GIT_PATCH_2 autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 13:31:53 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94082 --- Comment #1 from Deniz Bahadir --- Not: As due to the sourceware/gcc move it seems my original bug-report comm= ent got lost, I am here re-posting it. Reading P0202 (wg21.link/p0202) (which made it into C++20) it sounds as if `__builtin_memcpy` should be usable from a `constexpr` context. However, it= is not, as the following code demonstrates: ``` #include #include constexpr std::uint32_t extract(const std::uint8_t* data) noexcept { std::uint32_t num; __builtin_memcpy(&num, data, sizeof(std::uint32_t)); return num; } int main() { constexpr std::array a1 {{ 0xff, 0xff, 0xff, 0xff }}; constexpr auto val =3D extract(a1.data()); // <--- Error! return val; } ``` Compilation fails with: ``` : In function 'int main()': :14:33: in 'constexpr' expansion of 'extract(a1.std::array::data())' :7:21: error: '__builtin_memcpy(((void*)(& num)), ((const void*)(& a1.std::array::_M_elems)), 4)' is not a constant expressi= on 7 | __builtin_memcpy(&num, data, sizeof(std::uint32_t)); | ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ``` I would have expected this to compile and `__builtin_memcpy` being optimized away. Interestingly, removing the `constexpr` in front of the call to the function and thereby not calling it from a `constexpr` context compiles just fine and the optimizer is even able to optimize the call away and replace it by the returned value (`-1`). The `constexpr` keyword in front of the function definition seems then to j= ust be an indicator for inlining, similar to the `inline` keyword. But for this simple example, the compiler is even able to optimize it without `inline` or `constexpr` in front of the function definition. I think a `constexpr` context should not prevent compilation and optimizati= on, as the optimizer seems to be able to do that. BTW: Using e.g. `__builtin_bswap32` from a `constexpr` context is compiling= and optimizing just fine. See Compiler Explorer for a demonstration of the described behavior: https://godbolt.org/z/HaBt__=