From patchwork Sun Oct 15 14:42:06 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gerald Pfeifer X-Patchwork-Id: 1848965 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4S7jd96M42z20Vq for ; Mon, 16 Oct 2023 01:42:21 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C41193858284 for ; Sun, 15 Oct 2023 14:42:19 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from hamza.pair.com (hamza.pair.com [209.68.5.143]) by sourceware.org (Postfix) with ESMTPS id 627503858D33 for ; Sun, 15 Oct 2023 14:42:08 +0000 (GMT) ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 627503858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.68.5.143 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697380929; cv=none; b=Hme7taqquRhC68ACQYO462YzLRMwnVvUVMsh7OMEYK9MRcCxRtj/hf/ejCICqJXZIAdwrtR1bbFsXfUDTXB6blklUWsCkomsqAkpHQMZumy+aMLEmn9SuSjNWeP5bLEa9tMTo/b/RRFNsdkYWPdk4WlaMDYwwKXpy7VQpn74I9o= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697380929; c=relaxed/simple; bh=26ruN3U/ObFpMQ+ScfyoGVy3dfYY2TU3tyleqP+JpiU=; h=Date:From:To:Subject:MIME-Version:Message-Id; b=Uba/UKTEHGV14x8fiFsobycAjbIcvvPZrxYCDtaby2Q3NcMAPQ0Wp2LGLTAQx7E96cLwdbf4d4YIDrPM+R1/24KZ7ircMmVeOVC5t8Sz/W1LHbSTw4MUEq5HydybfvRzOj6sOKmuVUvg4Xx0RVcDXXAnA6B9sUjBezPJGCccnOY= ARC-Authentication-Results: i=1; server2.sourceware.org DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 627503858D33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=pfeifer.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=pfeifer.com Received: from hamza.pair.com (localhost [127.0.0.1]) by hamza.pair.com (Postfix) with ESMTP id F0A8F33ED2; Sun, 15 Oct 2023 10:42:07 -0400 (EDT) Received: from naga.localdomain (188-23-4-206.adsl.highway.telekom.at [188.23.4.206]) (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 hamza.pair.com (Postfix) with ESMTPSA id 62B9733EED; Sun, 15 Oct 2023 10:42:07 -0400 (EDT) Date: Sun, 15 Oct 2023 16:42:06 +0200 (CEST) From: Gerald Pfeifer To: gcc-patches@gcc.gnu.org cc: Jakub Jelinek Subject: [pushed] wwwdocs: gcc-9: Editorial changes to porting_to.html MIME-Version: 1.0 X-Scanned-By: mailmunge 3.11 on 209.68.5.143 Message-Id: <20231015144207.F0A8F33ED2@hamza.pair.com> X-Spam-Status: No, score=-9.3 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_NONE, SPF_PASS, 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Of course GCC 9 is not exactly fresh, though since I found this in a local tree still worth pushing. Pushed. Gerald --- htdocs/gcc-9/porting_to.html | 31 ++++++++++++++++--------------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/htdocs/gcc-9/porting_to.html b/htdocs/gcc-9/porting_to.html index 796c402e..fc85dae2 100644 --- a/htdocs/gcc-9/porting_to.html +++ b/htdocs/gcc-9/porting_to.html @@ -64,22 +64,23 @@ and provide solutions. Let us know if you have suggestions for improvements! that const qualified variables without mutable member are predetermined shared, but as an exception may be specified in the firstprivate clause. OpenMP 4.0 dropped this rule, - but in the hope that the incompatible change will be reverted GCC kept - implementing the previous behavior. Now that for OpenMP 5.0 it has been + but in the hope that this incompatible change will be reverted GCC kept + the previous behavior. Now that for OpenMP 5.0 it has been confirmed this is not going to change, GCC 9 started implementing the - OpenMP 4.0 and later behavior. When not using default + OpenMP 4.0 and later behavior. When not using a default clause or when using default(shared), this makes no - difference, but if using default(none), previously the - choice was not specify the const qualified variables - on the construct at all, or specify in firstprivate clause. - In GCC 9 as well as for OpenMP 4.0 compliance, those variables need - to be specified on constructs in which they are used, either in - shared or in firstprivate clause. Specifying - them in firstprivate clause is one way to achieve - compatibility with both older GCC versions and GCC 9, another option + difference. When using default(none), previously the + choice was not to specify const qualified variables + on the construct at all, or specify them in the + firstprivate clause. + In GCC 9 as well as for OpenMP 4.0 compliance those variables need + to be specified on constructs in which they are used, either in a + shared or in a firstprivate clause. Specifying + them in a firstprivate clause is one way to achieve + compatibility with both older GCC versions and GCC 9. Another option is to drop the default(none) clause. In C++, const variables with constant initializers which are not - odr-used in the region, but replaced with their constant initializer + odr-used in the region, but replaced with their constant initializer, are not considered to be referenced in the region for default(none) purposes.

@@ -93,8 +94,8 @@ and provide solutions. Let us know if you have suggestions for improvements! for (int i = 0; i < a; i += b) ; // The above used to compile with GCC 8 and older, but will - // not anymore with GCC 9. firstprivate(a, b) clause needs - // to be added for C, for C++ it could be just firstprivate(a) + // not anymore with GCC 9. A firstprivate(a, b) clause needs + // to be added for C; for C++ it could be just firstprivate(a) // to make it compatible with all GCC releases. } const int huge_array[1024] wwwdocs: = { ... }; @@ -104,7 +105,7 @@ and provide solutions. Let us know if you have suggestions for improvements! use (huge_array[i] wwwdocs:); // Similarly, this used to compile with GCC 8 and older and // will not anymore. Adding firstprivate(huge_array) is - // probably undesirable here, so, either + // probably undesirable here, so either // default(none) shared(huge_array) should be used and it will // only support GCC 9 and later, or default(none) should be // removed and then it will be compatible with all GCC releases