Re: Support for NOINLINE attribute

[Harald Anlauf <anlauf@gmx.de>]

Pushed as:

commit 086a1df4374962787db37c1f0d1bd9beb828f9e3

Thanks,
Harald

On 2/12/23 22:28, Harald Anlauf via Gcc-patches wrote:
> Hi Rimvydas,
>
>> Gesendet: Sonntag, 12. Februar 2023 um 07:59 Uhr
>> Von: "Rimvydas Jasinskas" <rimvydasjas@gmail.com>
>> An: "Harald Anlauf" <anlauf@gmx.de>
>> Cc: "fortran" <fortran@gcc.gnu.org>
>> Betreff: Re: Support for NOINLINE attribute
>>
>> On Sat, Feb 11, 2023 at 11:26 PM Harald Anlauf <anlauf@gmx.de> wrote:
>>> 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?
>>>
>>>> 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.
>> Hmm both look the same to me, the silencing of false positive
>> diagnostics is already implied by spurious.  To simplify I have
>> changed it in v2 to just:
>> "add a hint that a given function cannot return" documentation could
>> be expanded later.
>>
>>> 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 agree with you.  I have removed SUPPORTS_WEAK check and fixed
>> indentation in v2.
>>
>> Regtested cleany on x86_64-pc-linux-gnu.
>>
>> Regards,
>> Rimvydas
>
> this version of the patch looks good to me, so it is basically OK
> to commit.
>
> There is one thing I cannot test, which is the handling of weak symbols
> on other platforms.  A quick glance at the C testcases suggests that
> someone with access to either an NVPTX or MingGW target might tell
> whether that particular target should be excluded.  So I'd like to wait
> for 24 hours for others to comment on this.
>
> I see that you've signed-off your patch.  Do you have commit rights?
> Otherwise I'll commit for you.  (I've CC'ed to gcc-patches@ for this
> purpose.)
>
> Thanks for the patch!
>
> Harald
>
>
>