public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Thomas Koenig <tkoenig@netcologne.de>
To: Paul Richard Thomas <paul.richard.thomas@gmail.com>,
	"fortran@gcc.gnu.org" <fortran@gcc.gnu.org>,
	gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [Patch, fortran] PR96320 - gfortran 8-10 shape mismatch in assumed-length dummy argument character array
Date: Sat, 1 Aug 2020 11:54:02 +0200	[thread overview]
Message-ID: <49a9e2c2-81e5-b5c5-5002-96808e9527b2@netcologne.de> (raw)
In-Reply-To: <CAGkQGiJGLSd7J1TP_PjuTJ9AEfPZ0-swqxSreOx9i6jpDL5XEQ@mail.gmail.com>

Hi Paul,

> This is my first foray into gfortran for quite a little while so I am going
> cautiously on this 'obvious' patch. The comment in the patch and the
> ChangLog are clear enough that no further explanation is needed.
> 
> Regtests on FC31.x86_64 - OK for trunk?

If I read the PR correctly, this is a F2008 feature.  Do you think
it should have a gfc_option.allow_std & GFC_STD_F2008 somewhere?

Apart from that, OK for trunk.

> I am a bit reluctant to get into backporting just yet because I am still
> groping my way round git. However, I will do it when I feel a bit braver!

Actually, backporting is not all that bad if the patch applies cleanly.
I don't know if you have done this recently, but it very much
makes sense to run

contrib/gcc-git-customization.sh

which will then give you access to commands like "git gcc-backport"
(there is tab completion) and others.


> 2020-07-31  Paul Thomas  <pault@gcc.gnu.org>
> 
> PR fortran/96320
> * interface.c (gfc_check_dummy_characteristics): If a module
> procedure arrives with assumed shape in the interface and
> deferred shape in the procedure itself, update the latter and
> copy the lower bounds.
> 
> 2020-07-31  Paul Thomas  <pault@gcc.gnu.org>
> 
> PR fortran/96320
> * gfortran.dg/module_procedure_4.f90 : New test.

With the ChangeLog formatted like this, I am afraid you will
run afoul of the ChangeLog style police :-(

In the Brave New World of git, you do not commit a ChangeLog
together with your patch, you put it into the git commit
message.

It is best if you run your patch through contrib/mklog.py
to get the template for your commit message. You can then copy
over the other information.

And you need a one-line description for the patch of at most
80 characters, with a period at the end.

And, I think, new test cases are added automatically to the
ChangeLogs.

The ChangeLog then look something like this:

Fix shape mismatch in assumed-length dummy argument character array.

gcc/fortran/ChangeLog:

2020-07-31  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/96320
         * interface.c (gfc_check_dummy_characteristics): If a module
	procedure arrives with assumed shape in the interface and
	deferred shape in the procedure itself, update the latter and
	copy the lower bounds.
         (compare_parameter): Fix whitespace.
         (gfc_procedure_use): Fix whitespace.


If you have already committed something that the ChangeLog style
police objects to, you can change that with "git commit --amend".

I hope this helps you in avoiding a few iterations of getting rejected
when pushing a change. I think it covers most of what I went through :-|

(I just discovered that there is a "git gcc-verify" which probably
does the tests before you push.  Maybe that could be helpful.)

Best regards

	Thomas

  reply	other threads:[~2020-08-01  9:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-31 15:44 Paul Richard Thomas
2020-08-01  9:54 ` Thomas Koenig [this message]
2020-08-01 10:16   ` Paul Richard Thomas
2021-01-06 20:23 Paul Richard Thomas
2021-01-06 20:24 ` Paul Richard Thomas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49a9e2c2-81e5-b5c5-5002-96808e9527b2@netcologne.de \
    --to=tkoenig@netcologne.de \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=paul.richard.thomas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).