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 ESMTP id 41EC73858C60 for ; Fri, 16 Aug 2024 11:15:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 41EC73858C60 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 41EC73858C60 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1723806925; cv=none; b=csSQlL8mXuh5Ug8TDzdocLJYIhn8ib/irKWQw2CHtU8QAuzyY74PMBiTg317ZvIWGtffgNYWtJUYRP512ydP1URjecg8iA4wU6BkleY0z97fHRRQ721rWX34ZSJur35rVRhiz7DWw8gfoC/q5RvY2T28GTZdx6RkL2WltjedYbo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1723806925; c=relaxed/simple; bh=4I6zR6DRKaPqKFkZO/RUenlM9rclvqQHSfyiAadjZLs=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=tG3wqEdPqzUkdhNp+lA7h2/gN7fqY8JK7tFBjDJzuCuwVhOUFEJ2qQVQPJMyJ8M8PrUEJpawe1AbGoKw5JBieVCWhfnhqXWsAfpTj5hHV6YEMkmemGtLJ4t8aidrI3PXc2jVTliAI9eF8qMp6k/Riax31Jslrld1SUIrX/NEwGw= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1723806922; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=iw8PkR7Lct48hnmGTNqakLMIVwpCWgEuwGMQStFfmQE=; b=bQZBdwvXe61cnASg5myjGA0FTpAUr3O3FHIy6ggzKatzzEICG9i1BNBlLgNwp3ToNLXiEu Xbg4fA/5ig7UZHCxihZgf6O/uvBRvmjwI/riN0vVF6sIuxNSvn0wZ7OAYNYEheWYL1wVEw t9330WI6h9pupeFD4cTNpRt+yRLXi7E= Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-228-UW0ThtMPOsOOYaUtO_p-Zg-1; Fri, 16 Aug 2024 07:15:17 -0400 X-MC-Unique: UW0ThtMPOsOOYaUtO_p-Zg-1 Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15]) (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 mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 164B81955BFA; Fri, 16 Aug 2024 11:15:16 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.8]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 3DB741954B04; Fri, 16 Aug 2024 11:15:14 +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 47GBFCKb3522153 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Aug 2024 13:15:12 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 47GBFCoA3522152; Fri, 16 Aug 2024 13:15:12 +0200 Date: Fri, 16 Aug 2024 13:15:12 +0200 From: Jakub Jelinek To: Sandra Loosemore Cc: gcc-patches@gcc.gnu.org, tburnus@baylibre.com Subject: Re: [PATCH v3 05/12] OpenMP: C++ front-end support for metadirectives Message-ID: Reply-To: Jakub Jelinek References: <20240720204231.2229891-1-sloosemore@baylibre.com> <20240720204231.2229891-6-sloosemore@baylibre.com> MIME-Version: 1.0 In-Reply-To: <20240720204231.2229891-6-sloosemore@baylibre.com> X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15 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=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,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 List-Id: On Sat, Jul 20, 2024 at 02:42:24PM -0600, Sandra Loosemore wrote: > + const char *old_name = IDENTIFIER_POINTER (name); > + char *new_name = (char *) alloca (strlen (old_name) + 32); XALLOCAVEC like for the C FE patch. > + /* FIXME: I believe it is an unimplemented feature rather > + than a user error to have non-constant expressions > + inside "declare variant". */ > + t = metadirective_p > + ? cp_parser_expression (parser) > + : cp_parser_constant_expression (parser); > if (t != error_mark_node) > { > t = fold_non_dependent_expr (t); > - if (!value_dependent_expression_p (t) > + if (!metadirective_p > + && !value_dependent_expression_p (t) > && (!INTEGRAL_TYPE_P (TREE_TYPE (t)) > || !tree_fits_shwi_p (t))) > error_at (token->location, "property must be " > "constant integer expression"); > + if (metadirective_p > + && !INTEGRAL_TYPE_P (TREE_TYPE (t))) Shouldn't this be && !type_dependent_expression_p (t) before the !INTEGRAL_TYPE_P check? I mean template void foo () { #pragma omp metadirective ... user={condition(N)} ... ... } should be valid, or just typename T and foo (T x) and condition(x). > + error_at (token->location, > + "property must be integer expression"); > --- a/gcc/cp/parser.h > +++ b/gcc/cp/parser.h > @@ -450,6 +450,13 @@ struct GTY(()) cp_parser { > /* Pointer to state for parsing omp_loops. Managed by > cp_parser_omp_for_loop in parser.cc and not used outside that file. */ > struct omp_for_parse_data * GTY((skip)) omp_for_parse_state; > + > + /* Set if we are processing a statement body associated with a > + metadirective variant. */ > + bool in_metadirective_body; > + > + vec * GTY((skip)) metadirective_body_labels; > + unsigned metadirective_region_num; Again, there is unnecessary padding here (pointer, 8-bit bool, pointer, 32-bit unsigned) and maybe put the stuff into a separate structure and just use a pointer to it? Like the omp_for_parse_state. Though, it is less important than in the C++ FE. > }; > > /* In parser.cc */ > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc > index 108e929b8ee..109121be501 100644 > --- a/gcc/cp/pt.cc > +++ b/gcc/cp/pt.cc > @@ -17851,6 +17851,79 @@ tsubst_omp_clauses (tree clauses, enum c_omp_region_type ort, > return new_clauses; > } > > +/* Like tsubst_copy, but specifically for OpenMP context selectors. */ > +static tree > +tsubst_omp_context_selector (tree ctx, tree args, tsubst_flags_t complain, > + tree in_decl) > +{ > + tree new_ctx = NULL_TREE; > + for (tree set = ctx; set; set = TREE_CHAIN (set)) > + { > + tree selectors = NULL_TREE; > + for (tree sel = OMP_TSS_TRAIT_SELECTORS (set); sel; > + sel = TREE_CHAIN (sel)) > + { > + enum omp_ts_code code = OMP_TS_CODE (sel); > + tree properties = NULL_TREE; > + tree score = OMP_TS_SCORE (sel); > + tree t; > + > + if (score) > + { > + score = tsubst_expr (score, args, complain, in_decl); > + score = fold_non_dependent_expr (score); I think for partial template specialization processing_template_decl can be true, so wonder if in that case it shouldn't again not diagnose anything if score is still value dependent expression. > + switch (omp_ts_map[OMP_TS_CODE (sel)].tp_type) > + { > + case OMP_TRAIT_PROPERTY_DEV_NUM_EXPR: > + case OMP_TRAIT_PROPERTY_BOOL_EXPR: > + t = tsubst_expr (OMP_TP_VALUE (OMP_TS_PROPERTIES (sel)), > + args, complain, in_decl); > + t = fold_non_dependent_expr (t); > + if (!INTEGRAL_TYPE_P (TREE_TYPE (t))) > + error_at (cp_expr_loc_or_input_loc (t), > + "property must be integer expression"); And similarly here. Also, where do we do instantiation of the declare variant selectors (if we do that at all)? Jakub