From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id B4B483858D20 for ; Tue, 30 Apr 2024 21:30:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B4B483858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B4B483858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714512635; cv=none; b=NSEe1gONleivVsXsuPGXU1LcDvBblFcvyQx6J5Mumpki5PDvfEViXCZSgnHMo8oYkor3TXOKozU8uXgrHNKFbDKVcjbwkC8Z3anq6N+k0DGa3HJcaRS4MwUosmTWTP6XzB+lghi3/CpVw7GYOaKN5wa3WW6wVcwmmA6tTSvr/BU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714512635; c=relaxed/simple; bh=F87/nsRrnJFDfrq3hr1fC18b/AamlmrtOf1Xy586qjc=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=Kc3QGxTNF/YZkVah9xvNqdFpnrcViwtCBgjCg188o2OznP/SXOAGHXNFMaQCYNCWKcVv4A7Uyg3767pgIF0JrLOksiTTc53s0vBFYlSPjLsLnSzr4y9WlPAct6iG4+gZh37plYgx6DA0xVzwsRu/2zwcNPQADf/C6DYp0+u2a4w= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1714512632; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=gV/8AYki5/xTTPJCiN3giaaYw2xzcDzV7QbYHaKVy80=; b=Mk2+KgWL4cJzC6ZddWP08qh65Uc/QFzWEvboW5hzu74uu9+vcjXrwQ5omcaVHRBsF7ntRJ B29p+xzoJpsM8Z4aRsd6mPw7G1zkjFEOYsS5Z/HJYcMjCoI50GluYtYCPg4P584VYUZ0uE Sh+q96m4mCsLJSBaqMOaujh89jtAVNA= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-633-2-iQV3vWMH2obZ9LGAHF5w-1; Tue, 30 Apr 2024 17:30:29 -0400 X-MC-Unique: 2-iQV3vWMH2obZ9LGAHF5w-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id AB03D18065B2; Tue, 30 Apr 2024 21:30:28 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.5]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5221020128EF; Tue, 30 Apr 2024 21:30:28 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 43ULUQlQ3091542 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 30 Apr 2024 23:30:26 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 43ULUPZJ3091541; Tue, 30 Apr 2024 23:30:25 +0200 Date: Tue, 30 Apr 2024 23:30:25 +0200 From: Jakub Jelinek To: Martin Jambor Cc: GCC Patches , Michal Jires , Gerald Pfeifer Subject: Re: [wwwdocs] Porting-to-14: Mention new pragma GCC Target behavior Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, Apr 30, 2024 at 11:12:30PM +0200, Martin Jambor wrote: > Would the following then perhaps describe the situation accurately? > Note that I have moved the whole thing to C++ section because it seems > porting issues in C because of this are quite unlikely. > > Michal, I assume that the file where this issue happened was written in > C++, right? > > Martin > > > > diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html > index c825a68e..1e67b0b3 100644 > --- a/htdocs/gcc-14/porting_to.html > +++ b/htdocs/gcc-14/porting_to.html > @@ -514,6 +514,51 @@ be included explicitly when compiling with GCC 14: > > > > +

Pragma GCC Target now affects preprocessor symbols

I'd use lowercase Target here > + > +

> +The behavior of pragma GCC Target and specifically how it affects ISA And here as well, perhaps even #pragma GCC target. Otherwise LGTM. > +macros has changed in GCC 14. In GCC 13 and older, the GCC > +target pragma defined and undefined corresponding ISA macros in > +C when using integrated preprocessor during compilation but not when > +preprocessor was invoked as a separate step or when using -save-temps. > +In C++ the ISA macro definitions were performed in a way which did not > +have any actual effect. > + > +In GCC 14 C++ behaves like C with integrated preprocessing in earlier > +versions. Moreover, in both languages ISA macros are defined and > +undefined as expected when preprocessing separately from compilation. > + > +

> +This can lead to different behavior, especially in C++. For example, > +functions the C++ snippet below will be (silently) compiled for an > +incorrect instruction set by GCC 14. > + > +

> +  #if ! __AVX2__
> +  #pragma GCC push_options
> +  #pragma GCC target("avx2")
> +  #endif
> +
> +  /* Code to be compiled for AVX2. */
> +
> +  /* With GCC 14, __AVX2__ here will always be defined and pop_options
> +  never called. */
> +  #if ! __AVX2__
> +  #pragma GCC pop_options
> +  #endif
> +
> +  /* With GCC 14, all following functions will be compiled for AVX2
> +  which was not intended. */
> +
> + > +

> +The fix in this case would be to remember > +whether pop_options needs to be performed in a new > +user-defined macro. > + > + > + > > > Jakub