public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.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, 13 Feb 2024 20:29:21 +0000 [thread overview] Message-ID: <bug-113904-4-Wsx9cMmycJ@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-113904-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904 --- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> --- See comment 1 for remaining to-do items. I also note that the Fortran resolution comes too early - during parsing - as the following shows: module m implicit none contains subroutine test !$omp declare variant (foo) match(user={condition(myTrue)}) !$omp declare variant (bar) match(user={condition(myCond(1).and.myCond(2))}) logical, parameter :: myTrue = .true. end subroutine foo; end subroutine bar; end logical function myCond(i) integer :: i myCond = i < 3 end end module m This fails with the complete bogus: 5 | !$omp declare variant (foo) match(user={condition(myTrue)}) | 1 Error: property must be a constant logical expression at (1) As 'myTrue' is a scalar logical PARAMETER. The problem is just that this is not known when parsing '!$omp' - for that reason, Fortran separates parsing and resolution, which the current code does not handle as it comes way too early. * * * Otherwise: It looks as if - except for simple variable names (and probablyalso for functions calls w/o arguments) - we want to introduce an internal aux function like: logical function __m_MOD_test_DV_cond1() result(res) res = myCond(1).and.myCond(2) end which is then called when evaluating the run-time expression. With header files and, possibly, also C++ modules, we might be able to always inline the condition - with Fortran modules probably not, such that an aux function would be needed for the generic case.
next prev parent reply other threads:[~2024-02-13 20:29 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-02-13 11:26 [Bug middle-end/113904] New: " burnus at gcc dot gnu.org 2024-02-13 17:32 ` [Bug middle-end/113904] " burnus at gcc dot gnu.org 2024-02-13 19:56 ` cvs-commit at gcc dot gnu.org 2024-02-13 20:29 ` burnus at gcc dot gnu.org [this message] 2024-02-13 21:06 ` sandra at gcc dot gnu.org 2024-04-11 4:51 ` sandra at gcc dot gnu.org 2024-04-12 3:00 ` sandra at gcc dot gnu.org 2024-05-14 0:44 ` sandra at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-113904-4-Wsx9cMmycJ@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).