From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by sourceware.org (Postfix) with ESMTPS id BB0943858D3C for ; Thu, 10 Nov 2022 12:25:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BB0943858D3C 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-ej1-x635.google.com with SMTP id k2so4595595ejr.2 for ; Thu, 10 Nov 2022 04:25:49 -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=hEgYC9t1jNDesnNBfbNdCQtosdfIxNagqLd5lr8iyvY=; b=b2UBXoYPsEacuEho9bT5VrIBWgxJn0Ups0khFMOHu3C82ayM7RgV1qfuBBetj4xyM9 ptA/G5078A0+jJkTHJzyAfLWabtfgYSKQtKcahpf3GhFbSHLZiuGe1DQWdLxreW5yMk5 gNG9QcPmDb8xVBP/J8KtRaLUcm3gb61IfEHJx6CFabcAq/avovYglWzCVXHmllkreXyZ mDhVMgMBw5m6psxPquxB/Eiw6eKEh7pevN9pEL73OOvt77SrJjc+GglilvRXHRO9T43G 3rMmKo8ga3nPyKHhps2LgfHvucJka8u4drwoe+p5hpTb0exzuZ+uPALdEb5Y4KMm/7O5 vHZA== 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=hEgYC9t1jNDesnNBfbNdCQtosdfIxNagqLd5lr8iyvY=; b=PXz9jXl/Udunqvoy9MP5waDgogvANSqqAQ9E6+DEcpS/HjlvyI1PTg/NS5ZD+mOJkV 9gqYJTaTXrw/hnvyeijgCoeBqnGpFjVFfguk3S0AHMfA6TYsMu1PNg/Sk9zaMeONSMo4 cLny0Tg+63irkANoGPfB2sb9iB3qx+wPJk5mSlOq8EWlwQbMXBgZiZ3TLuj45AOz9Neo b2h2yn7CL/RE7QVJD79VygzWu8AfUg76xVF7RSRuza0/h8PoWyi17UfYy9VABz58nEcy hYrMH0dMdZ8EEdpmMdIc7IrQcy8leMnNoMpqiguq62SwL0ooCP4j29iUIX5OtN8btzHB MneQ== X-Gm-Message-State: ACrzQf1bV9HHPHcuQXEa3pUqOCSpEEsHiT5mSchjqyNURzSkcePSJlkx GiF3oBG1ItFSr0xJMr9V9dA= X-Google-Smtp-Source: AMsMyM5pq3PQMUJM1h6Xq4lE4+/tU/n0CdkPgV28VkgFvYgwcgAb/GPu92r4S5GY6pBLag/U32ucSg== X-Received: by 2002:a17:907:3f85:b0:733:3f0e:2f28 with SMTP id hr5-20020a1709073f8500b007333f0e2f28mr56951613ejc.376.1668083148291; Thu, 10 Nov 2022 04:25:48 -0800 (PST) Received: from nbbrfq (80-110-214-113.static.upcbusiness.at. [80.110.214.113]) by smtp.gmail.com with ESMTPSA id ed13-20020a056402294d00b00459e3a3f3ddsm8537527edb.79.2022.11.10.04.25.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Nov 2022 04:25:48 -0800 (PST) Date: Thu, 10 Nov 2022 13:25:44 +0100 From: Bernhard Reutner-Fischer To: Dave Love via Fortran Cc: rep.dot.nop@gmail.com, Dave Love Subject: Re: adding attributes Message-ID: <20221110132544.4c3b246a@nbbrfq> In-Reply-To: <87zgd381qm.fsf@manchester.ac.uk> References: <87pmecdni6.fsf@manchester.ac.uk> <20221030084839.118ef0c8@nbbrfq> <87edund73d.fsf@manchester.ac.uk> <20221103001926.725fd9bf@nbbrfq> <87zgd381qm.fsf@manchester.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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: Hi! On Mon, 07 Nov 2022 11:04:17 +0000 Dave Love via Fortran wrote: > Bernhard Reutner-Fischer via Fortran writes: >=20 > > I see. > > So target_clones is one thing. What other attributes would be important= ? =20 >=20 > At least optimization-related ones could be useful, and possibly others. > I haven't made a list, but could do. Please do. And yes, i can see that __attribute__((__optimize__(...))) would be useful. > dynamic dispatch in libraries. (The worst thing about gfortran for > system management is the lack of backwards-compatibility in module > formats and libgfortran.) yea. IIRC there was discussion a couple of years back what we could do about the module format. Nowadays i'd probably just use JSON, but i did not think too much about it. Needless to say that rewriting the mio (module I/O) would take more than one evening :) I remember some wrinkles there when i played around with the fortran-fe-stringpool idea (which reminds me i should pickup again, maybe). > > But since you cannot mix target_clones across arch-boundaries, > > supporting those for a distro will probably be rather ugly anyway. =20 >=20 > Yes, you need simple pre-processing, as you do for the attributes in C, > unless there was some extra guard facility added. Yes indeed. But this would be much easier to handle if we'd have actual arch defines. Until we have, you'd have to run this through cpp manually which is doable but not all that convenient IMHO. Hm, didn't we have a syntax for arch conditions in the math vec? We could hijack that, but it's probably still better to just fix the arch defines as that's generally useful. > > heh, me neither. Luckily yesterday was a holiday, so what i ended up > > with was the following, fya. =20 >=20 > Gosh; I thought it would take a while even if you knew your way around. > I didn't want to spoil a holiday! (I'd aim to do such things on work > time.) No problem, it was just for fun. I spent most of the time to scratch my head why the attribute didn't work for i had wrapped it in an arch ifdef for the testsuite to cover both i386 and ppc. And of course i only noticed very, very late what was really going on ;) > > I've added a > > /* Attributes set by compiler extensions (!GCC$ ATTRIBUTES). */ > > unsigned ext_attr:EXT_ATTR_NUM; > > + tree ext_attr_args; > > > > to struct symbol_attribute where i can prepare the tree_list for the > > attrs right from the start. The lowering is then rather simple and > > uniform, just chainon the prepared attributes and be done. =20 >=20 > If I understand correctly, I could go through and add ones that look > useful (for debate). I have experience of using several in C (at least > once even for g77 runtime). Yes please, that'd be interesting. > > target_clones does not require a bump in the module format, i'd say, > > because the main entry point does not change. Will have to check if > > the clones do not end up being emitted in the module, they shouldn't be. > > Other attributes _may_ require a change in the module format though. > > These would need checking on a per case basis. =20 >=20 > I don't understand the module format, but I wouldn't have expected > relevant attributes to change interfaces. Well that should probably not be needed indeed for most attributes, yes. But then, i do think we stream out the ext_attr, at least for certain attributes like "cdecl", the dll{im,ex}port, {std,fast}call et al. See module.cc, mio_symbol_attribute. So the bits that change the calling convention have to be brought to the attention of the module consumer probably. Think regparm or sseregparm for example i guess. That said, if i comment out the invalid cases of the test, i get with gcc-12: $ gfortran -c -o /tmp/out0.o /scratch/src/gcc-13.mine/gcc/testsuite/gfortra= n.dg/compiler-directive_1.f90=20 /scratch/src/gcc-13.mine/gcc/testsuite/gfortran.dg/compiler-directive_1.f90= :33:15: 33 | cdecl =3D> sub2 | 1 Warning: =E2=80=98cdecl=E2=80=99 attribute ignored [-Wattributes] /scratch/src/gcc-13.mine/gcc/testsuite/gfortran.dg/compiler-directive_1.f90= :33:15: Warning: =E2=80=98cdecl=E2=80=99 attribute ignored [-Wattributes] /scratch/src/gcc-13.mine/gcc/testsuite/gfortran.dg/compiler-directive_1.f90= :34:17: 34 | stdcall =3D> sub3 | 1 Warning: =E2=80=98stdcall=E2=80=99 attribute ignored [-Wattributes] /scratch/src/gcc-13.mine/gcc/testsuite/gfortran.dg/compiler-directive_1.f90= :34:17: Warning: =E2=80=98stdcall=E2=80=99 attribute ignored [-Wattributes] /scratch/src/gcc-13.mine/gcc/testsuite/gfortran.dg/compiler-directive_1.f90= :35:18: 35 | fastcall =3D> sub4 | 1 Warning: =E2=80=98fastcall=E2=80=99 attribute ignored [-Wattributes] /scratch/src/gcc-13.mine/gcc/testsuite/gfortran.dg/compiler-directive_1.f90= :35:18: Warning: =E2=80=98fastcall=E2=80=99 attribute ignored [-Wattributes] so i'm not sure what these attributes do or are supposed to do really, but i didn't look. And in addition there is typo s/consitency/consistency/ in the test. >=20 > Anyway, thanks! You're welcome. PS: You might have seen the patch to add "flatten". As can be seen, it should now be rather straightforward to add simple attributes for procedures. cheers,