From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5EFE23849AEF; Tue, 14 May 2024 00:44:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5EFE23849AEF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1715647474; bh=r6YTUN+ICGHDQ9M6gI9jtngoS2fMxWQmre6BZ/HzaqU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=NEevHfSBVvEGkwOt0KNVlvmkJrIFl5ti9P8iZBRwwla0DMlbUjekjA+JFITgzt9Zo AS3S21Ksh+3QIT8ygUYDUSraxwH6+LfCvrhbPAy+HjNyVeTW1ivY4rz61JZr2fEFgT JpWmtdoLVpI4kqml5kb+9wal5xjDlgZOi772D6cs= From: "sandra at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/113904] [OpenMP][5.0][5.1] Dynamic context selector 'user={condition(expr)}' not handled Date: Tue, 14 May 2024 00:44:32 +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: 14.0 X-Bugzilla-Keywords: accepts-invalid, openmp, rejects-valid, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: sandra at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113904 --- Comment #7 from sandra at gcc dot gnu.org --- My most recent metadirectives/dynamic selector patch set does include parti= al support for dynamic selectors. For C/C++ it handles expressions that refer= ence variables/functions that are globally visible, and for C++ also class fields/methods, references to the "this" pointer, etc, but it gives a "sorr= y" for references to parameters on the base function declaration. For Fortran= it still permits only constant expressions in selectors. https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650725.html I agree with Tobias's comment 3 that the right solution is to wrap these expressions in a function that has the same parameters as the associated ba= se decl, and that these generated functions can be internal and inline. But, = it might be more efficient to bypass actually creating functions and instead j= ust stash a parameter map (e.g. to match parameter positions to decls) along wi= th the expression so that the gimplifier can effectively do the inlining at the point where it synthesizes both the replacement call and the code to match dynamic selectors (in posted patch set above).=