Hi Rimvydas,
> On Fri, Feb 10, 2023 at 11:07 PM Harald Anlauf via Fortran
> <[email protected]> wrote:
> >-NOINLINE: I disagree with Steve here; we shouldn't invent a new
> > syntax (noinline on/off), and rather follow what other compilers
> > provide (INLINE/NOINLINE).
> It would also be very complicated to implement this, attribute applies
> to declaration and not the use location. Way better would be just to
> forward optimization pragmas see
> https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html
> say !GCC$ OPTIMIZE "-O1" subroutine foo() .... !GCC$ OPTIMIZE "-O2"
> subroutine bar(), or maybe even !GCC$ push_options subroutine
> foor()... end subroutine !GCC$ pop_options
if somebody wants to tackle this approach - defining options for
single translation units or whole modules - fine with me, but I
don't see this high on the priority list. Besides, attributes are
very compiler dependent beasts.
The annotation of loops and loop nests in gfortran is slightly less
expressive than what I am familiar with when using some commercial
($$$$) compilers, but that uses a different infrastructure within gcc.
> However I have no idea where to even start looking to get these
> working (this would be location based pragmas). NOINLINE already took
> me quite some time to study other gcc frontends while trying to find
> where it could be hooked in gfortran frontend. There could be other
> special cases in the code where attributes need to be applied
> explicitly again, say OMP.
OpenMP is already explicitly handled in gfortran and follows the
standard.
>
> > - NORETURN: this is an important attribute, as your testcases show.
> > However:
> >
> > +@item @code{NORETURN} -- add hint that given function cannot return. This
> > +makes slightly better code. More importantly, it helps avoid spurious
> > warnings
> > +of uninitialized variables.
> >
> > I would not claim "This makes slightly better code", but rather
> > that it provides additional optimiztion opportunities.
> I took those from gcc/doc/extend.texi:25383 with a bit of shortening.
> I'm not a native speaker, so it is hard for me to condense information
> into short readable descriptions :-)
I am also not a native speaker, like many others contributing, but let
me quote the relevant orignal paragraph:
"The @code{noreturn} keyword tells the compiler to assume that
@code{fatal} cannot return. It can then optimize without regard to what
would happen if @code{fatal} ever did return. This makes slightly
better code. More importantly, it helps avoid spurious warnings of
uninitialized variables."
My reading of this original paragraph differs very much from the
intention I get from the shortened version. Would you please reread?
> > Can you explain why you wrote that it should help to "avoid spurious
> > warnings of uninitialized variables"? While this attribute does provide
> > a useful hint to the compiler, a user should not focus on that attribute
> > just to silence the compiler.
> Same, from extend.texi, see gcc/testsuite/gfortran.dg/noreturn-3.f90
> It is about marking dead conditional branches, so that the compiler
> can prove proper initialization (no -Wmaybe-uninitialized given). It
> should behave the same as in C frontend.
True. And that's the whole point (IMHO), not silencing the compiler.
> > - WEAK: I do not like the way it is coded in the provided patch.
> > If a target does not support it, we should not generate an error,
> > but rather emit a warning that it is not supported.
> > It appears that declare_weak() already does that.
> I took the idea from Ada frontend see gcc/ada/gcc-interface/utils.cc:7210
> I would generally prefer a hard error here, libraries like MPI could
> break spectacularly if weak symbols would get emitted as global.
But shouldn't we rather follow what the C family of compilers in the
first place does for a particular target? Most relevant libraries
for Fortran code are either C/C++ or Fortran anyway, including any
of the common MPI implementations, so should we care about Ada?
I normally work on platforms where weak symbols are supported,
but maybe someone else has an opinion on it.
> Maybe it would be better later add support to use the trick from
> finclude/math-vector-fortran.h like:
> !GCC$ ATTRIBUTES weak :: SYM if('x86_64')
> just an idea, but i'm fine with anything allowing me not sed
> "/SYM/s/.globl/.weak/" through assembly intermediates in makefile
> rules.
Frankly, I think that would really look ugly, besides the fact that
a platform either does support weak symbols or not, independent of
the symbol.
> Once the fine details get ironed out I could prepare patch series of
> each attribute as its own separate patch, but given the proximity of
> changes locations maybe a single patch is OK?
I think a single patch would be fine.
Thanks for working on this!
Harald
> Regards,
> Rimvydas
>
