From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6138 invoked by alias); 31 Oct 2019 09:35:48 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 6086 invoked by uid 89); 31 Oct 2019 09:35:47 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,KAM_MANYTO autolearn=no version=3.3.1 spammy=HX-Languages-Length:1308, H*f:sk:mpt7e4l, H*MI:sk:mpt7e4l, H*i:sk:mpt7e4l X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (207.211.31.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 31 Oct 2019 09:35:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1572514544; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8bjIKcFzbrbDuwLBGo3dzYSc+SOBCOhvCNwwr2W482M=; b=S/0dpImf3gHYlpeAnEBqcMdLU04c88Q0Mx7dVhIYrCJ9g7B/UnYZ6jBKmpxTe/GtqDI0Xz rwFIaQXoX91jsu5rp5pINqEaUtvczL7aeiqPftdrV/zkp6DYAiHHrhOF91k1hDGi/SOaK/ Md8Yp1GuqunbijZZ4m6EVd6cvy3JuUk= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-11-UAqTWfGLMP6M0CqjvNDzCA-1; Thu, 31 Oct 2019 05:35:43 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 80D0F1800D56; Thu, 31 Oct 2019 09:35:41 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.36.118.135]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EF88D60852; Thu, 31 Oct 2019 09:35:40 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id x9V9ZbQT029874; Thu, 31 Oct 2019 10:35:37 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id x9V9ZXMc029873; Thu, 31 Oct 2019 10:35:33 +0100 Date: Thu, 31 Oct 2019 09:39:00 -0000 From: Jakub Jelinek To: Szabolcs Nagy , Richard Biener , Uros Bizjak , Tom de Vries , Martin Jambor , nd , "gcc-patches@gcc.gnu.org" , Segher Boessenkool , Richard Earnshaw , Andreas Krebbel , richard.sandiford@arm.com Subject: Re: [RFC PATCH] targetm.omp.device_kind_arch_isa and OpenMP declare variant kind/arch/isa handling Message-ID: <20191031093533.GE4650@tucnak> Reply-To: Jakub Jelinek References: <20191029171531.GI4650@tucnak> <20191030144824.GY4650@tucnak> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg02211.txt.bz2 On Thu, Oct 31, 2019 at 09:16:00AM +0000, Richard Sandiford wrote: > > Yes, it is indeed not clear, subject to ongoing discussions. > > My reading of the spec was that all the *-name-list are comma > > separated lists of identifiers, some others in the committee > > want now (yesterday's discussions) string literals instead > > when I and others pointed out that isa(core-avx512) can't be valid, > > but strangely only for isa/arch/extension but not e.g. for > > kind or vendor which would still take identifier lists etc. >=20 > Might be completely wrong, but wouldn't the identifiers be subject to > macro expansion? That would make it harder to use the pragmas safely > in system headers. Well, all the identifiers in the OpenMP/OpenACC pragmas after the omp are subject to macro expansion, including clause names etc., so even #define device foobar #pragma omp declare variant (foo) match (device=3D{kind(host)}) is a problem, or macro redefinition of declare, variant, match, kind or host. That said, for the arch and isa it is perhaps a bigger problem, as can be seen in the c-c++-common/gomp/declare-variant-9.c testcase where I had to #undef i386 because in non-strict modes that is defined... Jakub