From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 05A61385B50C; Tue, 25 Jun 2024 11:13:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 05A61385B50C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1719313982; bh=TQ3+Y2kxXfR+ir8NKiC4tBckksJZtblkrFcKitTLR50=; h=From:To:Subject:Date:From; b=V+GZiFOFB2DQ/R8lhwTeLqlSx/q4k1d0KYWedGabqu7aQ0XRpAPEYZgZaQQioGq2h I5Woazq9vF0VmHGg4d7iV2Q17L4j0ls1z7hS3L3ZrkXfXY0BY74UMF3sT8XJyGqDyn EhwFg82cpO2xu5U3Z1u4OXZ9vCcKpshwlDUv+aAA= From: "pkeir at outlook dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/115639] New: Large variations in compilation times involving static_assert Date: Tue, 25 Jun 2024 11:13:01 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 15.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: pkeir at outlook dot com 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: 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=3D115639 Bug ID: 115639 Summary: Large variations in compilation times involving static_assert Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: pkeir at outlook dot com Target Milestone: --- I often want to be sure that an expression is evaluated at compile time, wh= ile also checking that it produces the expected value. With a `constexpr` funct= ion called `big_calc`, expected to return zero, I might either use: static_assert(0=3D=3Dbig_calc()); // (1) ...or: constexpr int ret =3D big_calc(); // (2) static_assert(0=3D=3Dret); Surprisingly, the first of these (1) takes around 76% longer than the second (2) to compile. constexpr int big_calc() { long i =3D 1, count =3D 0, n =3D (1<<22); for (; i < n; i++) count =3D count + i; bool b =3D count =3D=3D (i * (i - 1)) / 2; return 0; } This is true even when `big_calc` involves more calculations. I am using Ub= untu 24.04 with an Intel i9-13900K, and g++ (GCC) 15.0.0 20240623 (experimental). With `n` of `big_calc` set at `(1<<22)` (as above) average compilation times are 6.5 secs. for approach (1); and 3.7 secs. for approach (2). With `n` of `big_calc` set at `(1<<24)` average compilation times are 28.3 secs. for approach (1); and 16.2 secs. for approach (2). time /opt/gcc-latest/bin/g++ -std=3Dc++20 performance-bug-double-constant-eval.cpp -fconstexpr-ops-limit=3D$((2**31-1= )) -fconstexpr-loop-limit=3D$((2**31-1)) Other approaches to invoke `big_calc` (e.g. SFINAE/Concepts class/function templates) are also slow; and have the performance profile of method (1). Perhaps the constant expression is being evaluated twice. It does look odd that the `big_calc` function returns zero. This was reduced from a larger problem. Curiously, if `big_calc` instead returns a boolean (= i.e. `b`), and the `0=3D=3D` part of each constant expression is removed, the is= sue disappears. This is reminiscent of a recently resolved Clang issue (https://github.com/llvm/llvm-project/issues/92924), though with 2 notable differences: firstly, with GCC the problem only arises when the `big_calc` function is actually invoked; and secondly, the `-Wno-invalid-constexpr` fl= ag makes no difference to the performance with GCC.=