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.133.124]) by sourceware.org (Postfix) with ESMTPS id E0EBB38582A7 for ; Mon, 4 Jul 2022 15:15:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E0EBB38582A7 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-94-ddrRtlxbNlaFDV9aNx0z0Q-1; Mon, 04 Jul 2022 11:15:03 -0400 X-MC-Unique: ddrRtlxbNlaFDV9aNx0z0Q-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0BE2C811E80; Mon, 4 Jul 2022 15:15:03 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.30]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B518D40D282E; Mon, 4 Jul 2022 15:15:02 +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 264FExbG1676063 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 4 Jul 2022 17:15:00 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 264FExqW1676062; Mon, 4 Jul 2022 17:14:59 +0200 Date: Mon, 4 Jul 2022 17:14:58 +0200 From: Jakub Jelinek To: Marcel Vollweiler , gcc-patches@gcc.gnu.org, Tobias Burnus Subject: Re: [PATCH] OpenMP, libgomp: Environment variable syntax extension. Message-ID: Reply-To: Jakub Jelinek References: <392c847d-e798-2be3-a808-6888de6c90cd@codesourcery.com> <73621930-22ce-c3f1-61e0-f15683f8b281@codesourcery.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.11.54.2 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=-3.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE 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.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2022 15:15:06 -0000 On Thu, Jun 30, 2022 at 01:40:24PM +0200, Jakub Jelinek via Gcc-patches wrote: > On Fri, Jun 10, 2022 at 03:59:37PM +0200, Marcel Vollweiler wrote: > > > I'm not sure we can rely on execv on all targets that do support libgomp. > > > Any reason why you actually need this, rather than using > > > dg-set-target-env-var directive(s) and perhaps return 0; if getenv doesn't > > > return the expected values? > > > > Interesting topic. After some (internal) discussions I think the best way is to > > set the environment variables explicitely instead using dg-set-target-env-var. > > The reason is that dg-set-target-env-var does not work for remote testing (which > > seems to be a common test environment). For remote testing dejagnu immediately > > aborts the test case with UNSUPPORTED which is specified in the corresponding > > extension and makes sence from my point of view as the test assumption cannot be > > fulfilled (since the environment variables are not set on remote targets). > > It also means that whenever dg-set-target-env-var is set in the test file, the > > execution of the test case is not tested on remote targets. > > The only reason why dg-set-target-env-var is supported on native only right > now is that I'm never doing remote testing myself and so couldn't test that. > There is no inherent reason why the env vars couldn't be propagated over to > the remote and set in the environment there. > So trying to work around that rather than at least trying to change > dg-set-target-env-var so that it works with the remote testing you do looks > wrong. > If dg-set-target-env-var can be made to work remotely, it will magically > improve those 130+ tests that use it already together with the newly added > tests. > > So, I'd suggest to just use dg-set-target-env-var and incrementally work on > making it work for remote testing if that is important to whomever does > that kind of testing. Could be e.g. a matter of invoking remotely > env VAR1=val1 VAR2=val2 program args > instead of program args. If env is missing on the remote side, it could > be UNSUPPORTED then. essentially where we now do: if { [info exists set_target_env_var] \ && [llength $set_target_env_var] != 0 } { if { [is_remote target] } { return [list "unsupported" ""] } set-target-env-var } in the is_remote case check (ideally cached) whether env program works on the target using remote exec with the env vars temporarily disabled and trying something like env MYVAR=value and if that succeeds and prints MYVAR=value in the output, don't return [list "unsupported" ""] and instead continue without doing that set-target-env-var/restore-target-env-var stuff and after this big block wrap also call_remote and if it is exec and the env vars are around (same stuff as how the intercepted ${tool}_load does this), prepend env and the vars in VAR=value format before the rest of args. Jakub