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 347113870C14; Thu, 11 Jan 2024 12:59:26 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 347113870C14
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1704977966;
	bh=jNKPl8+qN6CgRV4y6a6ogyuokhfLHZDp8lwJAs6ln5I=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=qR2CD6iL7r/mZ2DYu5O9r3ILQmE51X1NGNEJEupdVlrwpjcwlvIoJF6uwi7/vZP9o
	 qW+CjgyUeSlxtb12+7/SA1aS1WTaajuh027pKy0vVfcHn2rbS8gQhmAwvvWtEq4feQ
	 gjG62M/+g3v/SYd23s/jIfZSBSC6MxG6WkowFu+c=
From: "hubicka at ucw dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/109753] [13/14 Regression] pragma GCC target causes
 std::vector not to compile (always_inline on constructor)
Date: Thu, 11 Jan 2024 12:59:24 +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: 13.1.1
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hubicka at ucw dot cz
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: 13.3
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-109753-4-modPdpsmFv@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109753-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109753-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
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #14 from Jan Hubicka <hubicka at ucw dot cz> ---
> I think the issue might be that whoever is creating
> __static_initialization_and_destruction_0 fails to honor the active
> target pragma.  Which means back to my suggestion to have multiple ones
> when different target options are on the individual CTORs and any of them
> have always-inline (with always-inline we can't rely on an out-of-line co=
py
> to exist).

If I remember right, __static_initialization_and_destruction_0 call all
static constructors of priority 0. So it has really no active pragma
since it may change across translation unit.

We also have similar code in IPA where we collect constructors
across whole program.  Motivation was to get them inlined and obtain
better code locality. Back then Firefox had iostram constructor in every
object file and those ctors made whole text segment to be loaded on
demand during startup.

Probably correct solution would be to group construtor into groups by
compatible optimization/target pgramas in the inliner's definition.
A quick hack would be to generate wrapper calls which will "eat" the
always inline...=