Re: [PATCH, Fortran] Optionally suppress no-automatic overwrites recursive warning - for approval

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH, Fortran] Optionally suppress no-automatic overwrites recursive warning - for approval

Steve Kargl
On Thu, Sep 26, 2019 at 09:45:28AM +0100, Mark Eggleston wrote:
> Original thread starts here
> https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01185.html
>
> OK to commit?
>

I'm not a big fan of option proliferation.  If you don't
want to see warns just use -w.  Of course, this is just
MHO.

--
Steve
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH, Fortran] Optionally suppress no-automatic overwrites recursive warning - for approval

Mark Eggleston
PING - OK to commit?

On 02/10/2019 09:00, Mark Eggleston wrote:

>
> On 28/09/2019 17:50, Steve Kargl wrote:
>> On Thu, Sep 26, 2019 at 09:45:28AM +0100, Mark Eggleston wrote:
>>> Original thread starts here
>>> https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01185.html
>>>
>>> OK to commit?
>>>
>> I'm not a big fan of option proliferation.  If you don't
>> want to see warns just use -w.  Of course, this is just
>> MHO.
> Unfortunately -w switches off ALL warnings.
>
--
https://www.codethink.co.uk/privacy.html

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH, Fortran] Optionally suppress no-automatic overwrites recursive warning - for approval

Jeff Law
In reply to this post by Steve Kargl
On 10/25/19 2:35 AM, Tobias Burnus wrote:

> On 9/26/19 10:45 AM, Mark Eggleston wrote:
>> Original thread starts here
>> https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01185.html
>> OK to commit?
>
> As Steve, I am not really happy about adding yet another option and
> especially not about legacy features. On the other hand, I see that
> legacy code is still used.
>
> Having said this, the patch is OK from my side.
>
> Tobias
>
> PS: I was also not that happy about the BOZ changes by Steve, which
> broke code here – but, fortunately, adding int( ,kind=) around it was
> sufficient and that code was supposed to be F2003 standard conforming. 
> I could ping the authors and is now fixed. Still, I wonder how much code
> broke due to that change; code is not that simple to fix. – But, in
> general, I am very much in favour in having valid Fortran 2018 code (can
> be fixed form, old and use old features, that's fine).
So across Fedora the BOZ stuff tripped 2-3 packages.  In comparison the
function argument stuff broke 30-40 packages, many of which still don't
build without -fallow-argument-mismatch.

jeff

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH, Fortran] Optionally suppress no-automatic overwrites recursive warning - for approval

Steve Kargl
In reply to this post by Steve Kargl
On Fri, Oct 25, 2019 at 10:35:24AM +0200, Tobias Burnus wrote:

> On 9/26/19 10:45 AM, Mark Eggleston wrote:
>
> PS: I was also not that happy about the BOZ changes by Steve, which
> broke code here – but, fortunately, adding int( ,kind=) around it was
> sufficient and that code was supposed to be F2003 standard conforming. 
> I could ping the authors and is now fixed. Still, I wonder how much code
> broke due to that change; code is not that simple to fix. – But, in
> general, I am very much in favour in having valid Fortran 2018 code (can
> be fixed form, old and use old features, that's fine).
>

My BOZ patch brought gfortran closer to an actual comforming
Fortran compiler while providing an option that would allow
quite a few documented and undocumented extensions.  If the
patch broke some of your code, and -fallow-invalid-boz did not
allow the code to compile, and you were forced to use INT(, kind=)
to get it to compile, then, no, the code was not conforming.

And since you mention F2003, for the record

C410  (R411) A boz-literal-constant shall appear only as a
      data-stmt-constant in a DATA statement, as the actual
      argument associated with the dummy argument A of the
      numeric intrinsic functions DBLE, REAL or INT, or as
      the actual argument associated with the X or Y dummy
      argument of the intrinsic function CMPLX.

--
Steve