From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay4-3.pub.mailoutpod1-cph3.one.com (mailrelay4-3.pub.mailoutpod1-cph3.one.com [46.30.212.13]) by sourceware.org (Postfix) with ESMTPS id 99ABB3861893 for ; Tue, 4 Aug 2020 07:25:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 99ABB3861893 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=carewolf.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=linux@carewolf.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=carewolf.com; s=20191106; h=content-type:content-transfer-encoding:mime-version:references:in-reply-to: message-id:date:subject:to:from:from; bh=cxZJr7cKK/TWmWgsZLtuHjO/dhS4sF5DKxvGYDKY5DM=; b=BWGtDk4i1TByiseRprKZw5/RZw6bFeMkLdbFz7KFWBgXh19cei8+WePA0v7moK6mD0j35ZUPS4j3R 7E4SKxe+EOSaFvcux088viCXL2WaN7/X6YsWqrqdZeiSZpGtp0nR87E42f03P20E4zub+xVqM49zLp s4vkdnavjZySEeGq+zj3C1Np/Hkeenz6g37Rx8UG9c0qwuwy3fhBQJplRb99gktpQHCRUtyOHqraaq rosIzeCoNUBfebR7xuB9D2Nod1R147o6U/6Jw2qSByOnfRuy8nz49NKBgiCo8SA/xDdAt8vwffYDa2 9WQqBpeYajodHLcMZmV3Tuqcebcqf1A== X-HalOne-Cookie: 4b4af0da45d120ab368dab5c5a6ba56748463830 X-HalOne-ID: bc3602cf-d623-11ea-9b1e-d0431ea8bb10 Received: from twilight.localnet (cable-158-181-75-180.cust.telecolumbus.net [158.181.75.180]) by mailrelay4.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id bc3602cf-d623-11ea-9b1e-d0431ea8bb10; Tue, 04 Aug 2020 07:25:56 +0000 (UTC) From: Allan Sandfeld Jensen To: gcc@gcc.gnu.org, Florian Weimer Subject: Re: Non-inlined functions and mixed architectures Date: Tue, 04 Aug 2020 09:25:55 +0200 Message-ID: <11575926.O9o76ZdvQC@twilight> In-Reply-To: <87ft9d2v9x.fsf@oldenburg2.str.redhat.com> References: <2928315.e9J7NaK4W3@twilight> <5625598.lOV4Wx5bFT@twilight> <87ft9d2v9x.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP 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@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 07:26:00 -0000 On Montag, 27. Juli 2020 10:54:02 CEST Florian Weimer wrote: > * Allan Sandfeld Jensen: > > On Montag, 27. Juli 2020 10:33:35 CEST Florian Weimer wrote: > >> * Allan Sandfeld Jensen: > >> > A problem that I keep running into is functions defined headers, but > >> > used > >> > in sources files that are compiled with different CPU feature flags > >> > (for > >> > runtime CPU feature selection). > >> > > >> > We know to make sure the functions are inlinable and their address > >> > never > >> > taken, but of course in debug builds they are still not inlined. Every > >> > so > >> > often the functions get compiled using some of the optional CPU > >> > instructions, and if the linker selects the optimized versions those > >> > instructions can then leak through to instances compiled with different > >> > CPU flags where the instructions aren't supposed to be used. This > >> > happens > >> > even in unoptimized debug builds as the extended instruction selections > >> > doesn't count as an optimization. > >> > >> You need to provide source code examples. This isn't supposed to happen > >> if you declare the functions as static inline. If a function is emitted > >> for any reason, it will be local this particular object file. > >> > >> Plain inline (for C++) works differently and will attempt to share > >> implementations. > > > > static inline? Hadn't thought of that in a shared header file. > > > > Is harder to do with inline methods in C++ classes though. > > Ahh, and anonymous namespaces (the equivalent for that for member > functions) do not work in such cases because the representation of the > class still needs to be shared across API boundaries. With an anonymous > namspace, that would be undefined. > So, would it be possible to have a gcc extension or future C++ attribute that worked like static on global functions but could be used on member functions (both static and otherwise)? Perhaps make it universal so it did the same no matter where it was used instead of being contextual like 'static'. Best regards 'Allan