On Fri, Feb 10, 2023 at 11:07 PM Harald Anlauf via Fortran <fortran@gcc.gnu.org> wrote: > I actually like the idea of supporting the suggested attributes, > provided they work and behave the same way with and without LTO. All these three declaration attributes apply the same regardless of LTO, LTO just expands what optimizations see during link time.
>-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 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. > - 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 :-) > 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. > - 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. 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. 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? Regards, Rimvydas
