From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 8334938930FB; Fri, 29 Jan 2021 08:55:23 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8334938930FB
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/98209] [8/9/10/11 Regression] printf failed with O1
 or above
Date: Fri, 29 Jan 2021 08:55:23 +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: 9.3.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 8.5
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-98209-4-yRuE2gjk5z@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-98209-4@http.gcc.gnu.org/bugzilla/>
References: <bug-98209-4@http.gcc.gnu.org/bugzilla/>
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-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jan 2021 08:55:23 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98209

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #10)
> I think the *intrin.h example is not really relevant as their direct
> caller is very unlikely to differ in setting.

In bugfree code sure.
When writing code, because there are so many ISA extensions it is often the
case one attempts to use an intrinsic that requires other ISA flags, and re=
ly
on the compiler to diagnose that.
So, if we e.g. wanted to redeclare always_inline as being inlinable to anyt=
hing
regardless of target and optimize flags, we'd need to add another attribute=
 and
stick it on all the intrinsic that would say but for these require it.
But, even for the _FORTIFY_SOURCE inlines, I'm not really sure we e.g. want=
 to
inline them into -O0 functions, because fortification relies on -O1+.=