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 5733E3858D28 for ; Mon, 11 Sep 2023 11:54:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5733E3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1694433273; 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=mRdfilCocPJqJRIsXp0EldbNeQwwyS4FgXmJMV2BsPE=; b=GNh1n4Z/A/ayCL09RtNB6WP/PFIw81dq6WfOKoGJJqXPQalThoD2WmBqQ7vAUEMegMV5mt XgwFrG0nj8Xl4SxUifQGzUr68dvORroKVLj2fFNLgQz5TgFoDsZoGMFdWaNoFc1iyfPf2j dQ3qP4M3UzEUPaN8El8b7x4LMKM0b3E= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-434-N_ijPXgoOFKUAlySYZGIgw-1; Mon, 11 Sep 2023 07:54:29 -0400 X-MC-Unique: N_ijPXgoOFKUAlySYZGIgw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A1B613C1C983; Mon, 11 Sep 2023 11:54:29 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.225.209]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6543A2027045; Mon, 11 Sep 2023 11:54:29 +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 38BBsRNF1266637 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 11 Sep 2023 13:54:27 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 38BBsQlO1266636; Mon, 11 Sep 2023 13:54:26 +0200 Date: Mon, 11 Sep 2023 13:54:26 +0200 From: Jakub Jelinek To: Tobias Burnus , David Malcolm Cc: gcc-patches Subject: Re: [Patch] OpenMP (C only): omp allocate - extend parsing support, improve diagnostic (was: [Patch] OpenMP (C only): omp allocate - handle stack vars, improve diagnostic) Message-ID: Reply-To: Jakub Jelinek References: <2b31f97f-22a4-3b47-c0d8-4fb01dea7c1c@codesourcery.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 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.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP 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: Hi! One question to David below, CCed. On Mon, Sep 11, 2023 at 01:44:07PM +0200, Tobias Burnus wrote: > --- a/gcc/c/c-decl.cc > +++ b/gcc/c/c-decl.cc > @@ -681,6 +681,11 @@ decl_jump_unsafe (tree decl) > if (VAR_P (decl) && C_DECL_COMPOUND_LITERAL_P (decl)) > return false; > > + if (flag_openmp > + && VAR_P (decl) > + && lookup_attribute ("omp allocate", DECL_ATTRIBUTES (decl))) > + return true; > + > /* Always warn about crossing variably modified types. */ > if ((VAR_P (decl) || TREE_CODE (decl) == TYPE_DECL) > && c_type_variably_modified_p (TREE_TYPE (decl))) > @@ -724,6 +729,12 @@ c_print_identifier (FILE *file, tree node, int indent) > c_binding_oracle = save; > } > I think we want a function comment here. > +void > +c_mark_decl_jump_unsafe_in_current_scope () > +{ > + current_scope->has_jump_unsafe_decl = 1; > +} > + > + if (DECL_SOURCE_LOCATION (allocator) > DECL_SOURCE_LOCATION (var)) > + { > + error_at (OMP_CLAUSE_LOCATION (nl), > + "allocator variable %qD must be declared before %qD", > + allocator, var); > + inform (DECL_SOURCE_LOCATION (allocator), "declared here"); > + inform (DECL_SOURCE_LOCATION (var), "declared here"); I think this will be confusing to users when the inform is the same in both cases. I'd use "allocator declared here" in the first case. And, am really not sure if one can just simply compare location_t like that. Isn't there some function which determines what source location is before another one? David? > + if (EXPR_LOCATION (*l) < DECL_SOURCE_LOCATION (var)) > + break; Likewise. > --- /dev/null > +++ b/gcc/testsuite/c-c++-common/gomp/allocate-12.c > @@ -0,0 +1,46 @@ > +/* TODO: enable for C++ once implemented. */ > +/* { dg-do compile { target c } } */ > + > +typedef enum omp_allocator_handle_t I think all the c-c++-common tests declaring omp_allocator_handle_t should have #if __cplusplus >= 201103L : __UINTPTR_TYPE__ #endif here (even if they are just { target c } for now, we'd certainly forget to adjust them). Jakub