From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by sourceware.org (Postfix) with ESMTPS id 44DFD384F495; Mon, 21 Nov 2022 20:13:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 44DFD384F495 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x52c.google.com with SMTP id z20so16336344edc.13; Mon, 21 Nov 2022 12:13:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=NZVbGUwEf8TN/JWfvIUYa8dTf+kuCtaqBb3NyVpyT20=; b=kpF3lDqB/oJBwMoLE9VpH+DdvoES27PdbUUvzX/0CrZe64wdk1CnHqUOKEStNMk0I2 UoBW+nULuLuuNjefMQHIosgj0ch5HlD6arVI5MA6X78ILEMoCo+kOrBWoJWvugNkLC+t WI04yOytvXl+2pIi2UsykQtsxQTwoqW5XutxLf3cINgmFb2E/0qQY5mx0x7pJZJamb8u k2DJK2fs2jkJUeubAh3m1SDY4ZI3bkfwpf/0aTaOSjAz+/c44fW1Fe71dMTNi8E4d4HN ia12BxNQwsqmS08TQ19mRS5nZc1jK3GHcBogtFf8ZCod1W1LuB643oCgAwjuTyKaZMXk PGEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NZVbGUwEf8TN/JWfvIUYa8dTf+kuCtaqBb3NyVpyT20=; b=2Gpbv9DsKJ3r3TvDnEizcp91FEkJWrKtXbzhgFbxrLtCnzYLaodOcZWSotFGdi3s4s 84dIYaAsZtFM+cJWptPYEbSVXNevZfGT882wtszn/dG9H91RbpcGwoTRBEdeSsrci+5g DioX4WYNOmzZOUfYpcUGnHi+BtIryo/l3ljdY07m9PSW8lG8qXKqHBj3WY1YvtU7oBKT UvY8T+gYebBnf/zeMp4r7CBDohxVOxtM2ijsgeRi04IwDRlvnp9oK+LTIs06C9CAp3kl 3oP72+RcnyqnwLWrfLslTUnLqU3BXG+vZkPMCGwd19cxL+J/qtk9HAd7Rs8zcKl0mq6S AUiw== X-Gm-Message-State: ANoB5pnGUnxcoduv0aJ3vwOVusYpNhTgfotFBWKB0tlccl9YPDG59GuK D03uEtXzm9IsptawXE1QjZw= X-Google-Smtp-Source: AA0mqf72SlMjy5SDTJcMdsAuFHpXJ7bJGMk1l1zWl4Yj5T2GCFMjsZVM87nCbEF/1stWK0qiRLrBYQ== X-Received: by 2002:aa7:dd4d:0:b0:45c:98a9:7bbf with SMTP id o13-20020aa7dd4d000000b0045c98a97bbfmr1791626edw.372.1669061630424; Mon, 21 Nov 2022 12:13:50 -0800 (PST) Received: from nbbrfq (80-110-214-113.static.upcbusiness.at. [80.110.214.113]) by smtp.gmail.com with ESMTPSA id ku20-20020a170907789400b00773f3cb67ffsm5324353ejc.28.2022.11.21.12.13.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Nov 2022 12:13:50 -0800 (PST) Date: Mon, 21 Nov 2022 21:13:46 +0100 From: Bernhard Reutner-Fischer To: Mikael Morin Cc: rep.dot.nop@gmail.com, gcc-patches@gcc.gnu.org, Bernhard Reutner-Fischer , gfortran ML Subject: Re: [PATCH 2/2] Fortran: Add attribute flatten Message-ID: <20221121211346.2d9c6a35@nbbrfq> In-Reply-To: <7b9995a0-792a-8931-a2cd-6bf89130d5bd@orange.fr> References: <20221110102031.1366016-1-aldot@gcc.gnu.org> <20221110102031.1366016-3-aldot@gcc.gnu.org> <7b9995a0-792a-8931-a2cd-6bf89130d5bd@orange.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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: On Mon, 21 Nov 2022 12:24:11 +0100 Mikael Morin wrote: > > --- a/gcc/fortran/decl.cc > > +++ b/gcc/fortran/decl.cc > (...) > > @@ -11849,7 +11850,9 @@ gfc_match_gcc_attributes (void) > > if (strcmp (name, ext_attr_list[id].name) == 0) > > break; > > > > - if (id == EXT_ATTR_LAST) > > + if (strcmp (name, "flatten") == 0) > > + known_attr0args = true; /* Handled below. We do not need a bit. */ > > I don't see the point to have all the attributes needing a bit except > one that doesn't but needs a specific handling. > What does it look like without the 1/2 patch and if one bit is also used > for flatten, like the other attributes? I've changed target_clones not to use a bit locally because it's not needed. From my understanding, we only need the bits for attributes that change the calling convention or the caller(at least so far, but that does make sense to me). Remember that we store these bits in the module. Presumably because we have to make sure that a program/module uses the correct calling convention for a module function annotated with such an attribute (think cdecl, stdcall, fastcall, dllimport, dllexport, or the non-implemented regparm, sseregparm) or for attributes that otherwise influence the callers or callees (like deprecated or no_arg_check). Attributes like target_clones or flatten or (probably) optimize etc, do not influence the callees, so we really do not need to store them in the module. Can you think of a reason to store them nevertheless? > > + else if (id == EXT_ATTR_LAST) > > { > > gfc_error ("Unknown attribute in !GCC$ ATTRIBUTES statement at %C"); > > return MATCH_ERROR; > > > diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi > > index 06e4c8c00a1..be650f28b62 100644 > > --- a/gcc/fortran/gfortran.texi > > +++ b/gcc/fortran/gfortran.texi > > @@ -3280,6 +3280,14 @@ contains > > end module mymod > > @end smallexample > > > > +@node flatten > > + > > +Procedures annotated with the @code{flatten} attribute have their > > +callees inlined, if possible. > I'm not a native speaker, but I find this sentence confusing. > The words of the gcc manual you are refering to seem more clear: "every > call inside the function is inlined, if possible". Me neither and it was a bit too brief. I've changed this to: Every call inside a procedure annotated with the @code{flatten} attribute is inlined, if possible. Please refer to @ref{Top,,Common Function Attributes,gcc,Using the GNU Compiler Collection (GCC> for details about the respective attribute. Is that better? That said, i think this whole attribute section in the manual is not structured too well. I'd prefer to have a list of attributes like in the "Common Function Attributes" section in the extend.texi. Maybe it would be better to just start a new list of attributes at the end of the current @subsection ATTRIBUTES directive, a subsubsection with "Other attributes" and just itemize the new ones? We'd point people to the Top docs once for further details and then just briefly list the attributes we support. Would that be acceptable? Many thanks for your comments! > > > +Please refer to > > +@ref{Top,,Common Function Attributes,gcc,Using the GNU Compiler Collection (GCC)} > > +for details about the respective attribute. > > + > > The attributes are specified using the syntax > > > > @code{!GCC$ ATTRIBUTES} @var{attribute-list} @code{::} @var{variable-list} >