From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) by sourceware.org (Postfix) with ESMTPS id E83EB385840F for ; Fri, 24 Feb 2023 12:03:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E83EB385840F 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-oi1-x232.google.com with SMTP id y184so1440879oiy.8 for ; Fri, 24 Feb 2023 04:03:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0axrK+friRYbV4phm86fuj48BX0IAJ24OE5054kwu8s=; b=i3g1PYdsp1rWgOFZnoC5JdxOmxdcLz3FzQq8no8ogUf/OFKMV+46f+5kZU5p4eBrN8 6upOhotTukANCZNT3/ew6zubN/7cnOmB/s1FQy+P1UT50/5XZUQCKWU8/pQ7YFXMCvOS 8PKwOWOTXeF0EsMpwqzZOVN21NzoTMEZtz7z80jovAtHdBdJCT4KMxsyvPL1Fcaoygft ADHGjw/C0MvMhSIqhhD3p47mkM8cum64QckBGsLon+FAoLu0yr5SysHYwFQkqnYYjqp2 a563RwS1rVIr116bBH42hHegM+pqG0wMr+x5397BE0cVRgqS/CP05mNXjxi2Phg8E0om PvtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0axrK+friRYbV4phm86fuj48BX0IAJ24OE5054kwu8s=; b=SVrjHhb+2yhArf6Ug0/iEvs8SWj+RiaBonLZBkP3KPr4UvnCl75xEuBxH9OQOIq/wW SdREaRBfKgB2K1Dlw9C4m2cK86nwDV5qjkukvA3QsRALMRNWZDAB5gzmDO5wFV5Xa9F5 2XO7287YVivsRN8iLnxoqz68WL/o3favqIZTCeDLH2sjBoEoENHiE/Uu76wjf5d3C/yb XpbpgC6Co4318H96/wK6C4aWcGyCTRLvIGYEEsA6Os+ZtmSW2dXfnHSywqF5NNdCTpjt vt+5A0mMy5nEV2zEsQh6VC58zIrvwqY5L5Wfn6L6Xmru1q99YK1cIyLZy+8PKKEFV9Y7 ZVwA== X-Gm-Message-State: AO0yUKVv/z/ZFn3zFcrTtl1FTwhzEI8MbXIeFRJXJfxE5p7w+oRQDbFp 7BGWOsqqAlNpVkvAC6/1a46gycgfY3KDPUjr0h4nwmYtKuk= X-Google-Smtp-Source: AK7set9wAudg+opCrPS0heZKeFBELA/UPoSUo6VckhMb2VqtGo6RKBvj/SK8bVM1LmvJGf00iU/X0zPUi4JWI+Di1Rc= X-Received: by 2002:a05:6808:1:b0:378:9c80:ab73 with SMTP id u1-20020a056808000100b003789c80ab73mr924361oic.7.1677240200416; Fri, 24 Feb 2023 04:03:20 -0800 (PST) MIME-Version: 1.0 References: <20230218213547.3c619661@nbbrfq> <20230224081954.06d7e800@nbbrfq> In-Reply-To: <20230224081954.06d7e800@nbbrfq> From: Rimvydas Jasinskas Date: Fri, 24 Feb 2023 14:02:58 +0200 Message-ID: Subject: Re: Support for NOINLINE attribute To: Bernhard Reutner-Fischer Cc: Rimvydas Jasinskas via Fortran Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-8.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,KAM_SHORT,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: Hello Bernhard, On Fri, Feb 24, 2023 at 9:20 AM Bernhard Reutner-Fischer wrote: > > > * decl.cc: Add EXT_ATTR_NOINLINE, EXT_ATTR_NORETURN, EXT_ATTR_WEAK. > > > * gfortran.h (ext_attr_id_t): Ditto. > > > > We had that discussion recently here.. > > Which of these are required to be recorded to the module and why, > > exactly? Please elaborate. > The aforementioned discussion was here: > https://gcc.gnu.org/pipermail/fortran/2022-November/058542.html > > So, again, please elaborate why you need to store each of NOINLINE, > NORETURN, WEAK in the module? 1. In .mod files technically only NORETURN needs to be stored for module contained procedures callsites. It should be handled the same as the DEPRECATED attribute. module foo !GCC$ ATTRIBUTES noreturn :: abort_msg contains subroutine abort_msg(cmsg) ! ... end subroutine) end module Otherwise there will be failure in already added test: FAIL: gfortran.dg/noreturn-1.f90 -O detect falling off end of noreturn (test for warnings, line 9) 2. The NOINLINE attribute can be excluded from on-disk .mod file until/if there would be added a way to inline say scalar functions that evaluate to constants at compile time when compiling with optimizations. 3. The WEAK attribute certainly needs to be excluded from on-disk generated .mod files, I do not see a legitimate use case where such information would be used in module imports. Except maybe for FL_SUBMODULE cases that I so far have not investigated how it interacts with FL_MODULE. My attempt to mask out NOINLINE/WEAK was with: diff --git a/gcc/fortran/module.cc b/gcc/fortran/module.cc index 601497e0998..1789be88b73 100644 --- a/gcc/fortran/module.cc +++ b/gcc/fortran/module.cc @@ -2245,7 +2245,7 @@ static void mio_symbol_attribute (symbol_attribute *attr) { atom_type t; - unsigned ext_attr,extension_level; + unsigned ext_attr,extension_level,ext_mask; mio_lparen (); @@ -2255,7 +2255,12 @@ mio_symbol_attribute (symbol_attribute *attr) attr->if_source = MIO_NAME (ifsrc) (attr->if_source, ifsrc_types); attr->save = MIO_NAME (save_state) (attr->save, save_status); - ext_attr = attr->ext_attr; + /* Do not save EXT_ATTR_NOINLINE and EXT_ATTR_WEAK into .mod file. */ + ext_mask = (1 << EXT_ATTR_LAST) - 1; + ext_mask -= 1 << EXT_ATTR_NOINLINE; + ext_mask -= 1 << EXT_ATTR_WEAK; + + ext_attr = attr->ext_attr & ext_mask; mio_integer ((int *) &ext_attr); attr->ext_attr = ext_attr; And results in failures for testcases submitted for review in part2 and part3 patches: FAIL: gfortran.dg/noinline-2.f90 -O scan-tree-dump-times dom2 "foo \\\\(" 4 FAIL: gfortran.dg/weak-2.f90 -O scan-assembler weak[^ \\t]*[ \\t]_?__foo_MOD_abc I am not sure if this is a correct place to do such masking and/or why it results in these specific failures. Regards, Rimvydas