From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AF86F3858C2C; Tue, 2 Jan 2024 16:54:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AF86F3858C2C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1704214489; bh=DI9/sKvUwH08neb2Hdj2MxLQX4/Z9/oM1HAKqacmhJE=; h=From:To:Subject:Date:From; b=NQj3vSoQ3fdhjlcHghqvK6jT8ugWDQN7Kmkx3dk3wqABs7NMsHE3wKwk9WwsaFvNL agxrLtWQ6DMmQT1gXcdhVen+3T5SE/Tjo4jj0rjW+sW8GiGd0r4Jz+SA3m4q2vT2k+ QVX7AtIA60sqdvMza9ZAusZ3kQyjWG44kzIaXW6M= From: "stefan at bytereef dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/113203] New: __attribute__ ((always_inline)) fails with C99/LTO/-Og. Date: Tue, 02 Jan 2024 16:54:48 +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: 14.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: stefan at bytereef dot org 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=3D113203 Bug ID: 113203 Summary: __attribute__ ((always_inline)) fails with C99/LTO/-Og. Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: stefan at bytereef dot org Target Milestone: --- This is similar to #107931. I'm opening a new issue because there are no indirect function calls and the problem occurs with -std=3Dc99 -flto -Og. foo.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D #include #include "foo.h" inline __attribute__ ((always_inline)) bool f(int x) { return (x > 2); } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D foo.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D #include bool f(int); =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D main.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D #include #include "foo.h" int main(int argc, char *argv[]) { (void)argv; if (f(argc)) { puts("yes"); } else { puts("no"); } return 0; } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D $ gcc -Wall -Wextra -std=3Dc99 -flto -Og -o main foo.c main.c foo.c: In function =E2=80=98main=E2=80=99: foo.c:5:1: error: inlining failed in call to =E2=80=98always_inline=E2=80= =99 =E2=80=98f=E2=80=99: function not considered for inlining 5 | f(int x) | ^ main.c:9:8: note: called from here 9 | if (f(argc)) { | ^ lto-wrapper: fatal error: /home/skrah/gcc/bin/gcc returned 1 exit status compilation terminated. /usr/bin/ld: error: lto-wrapper failed This is extracted from the mpdecimal project that has used C99 and always_inline for a decade without problems. The code was written before the amendment to the always_inline documentation in 2014 and always_inline has consistently produced a speedup of 1-2.5% even with -O3. My questions: 1) Since this is C99, should always_inline work without errors when -std=3D= c99 is active? If not, should -std=3Dc99 reject always_inline? 2) There is a clear demand for something like "really_inline" that ignores = the heuristics and just inlines whenever possible without errors or warnings. In practice that is how MSVC __forceinline or clang always_inline behave. Could that be added?=