Re: adding attributes

[Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>]

Hi!

On Mon, 07 Nov 2022 11:04:17 +0000
Dave Love via Fortran <fortran@gcc.gnu.org> wrote:

> Bernhard Reutner-Fischer via Fortran <fortran@gcc.gnu.org> writes:
> 
> > I see.
> > So target_clones is one thing. What other attributes would be important?  
> 
> 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.  
> 
> 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.  
> 
> 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.  
> 
> 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.  
> 
> 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/gfortran.dg/compiler-directive_1.f90 
/scratch/src/gcc-13.mine/gcc/testsuite/gfortran.dg/compiler-directive_1.f90:33:15:

   33 |   cdecl => sub2
      |               1
Warning: ‘cdecl’ attribute ignored [-Wattributes]
/scratch/src/gcc-13.mine/gcc/testsuite/gfortran.dg/compiler-directive_1.f90:33:15: Warning: ‘cdecl’ attribute ignored [-Wattributes]
/scratch/src/gcc-13.mine/gcc/testsuite/gfortran.dg/compiler-directive_1.f90:34:17:

   34 |   stdcall => sub3
      |                 1
Warning: ‘stdcall’ attribute ignored [-Wattributes]
/scratch/src/gcc-13.mine/gcc/testsuite/gfortran.dg/compiler-directive_1.f90:34:17: Warning: ‘stdcall’ attribute ignored [-Wattributes]
/scratch/src/gcc-13.mine/gcc/testsuite/gfortran.dg/compiler-directive_1.f90:35:18:

   35 |   fastcall => sub4
      |                  1
Warning: ‘fastcall’ attribute ignored [-Wattributes]
/scratch/src/gcc-13.mine/gcc/testsuite/gfortran.dg/compiler-directive_1.f90:35:18: Warning: ‘fastcall’ 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.

> 
> 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,