Hi Thomas,
I discovered the bit about the ChangeLogs last night but thanks for the
warning:-)
The commit message reads:
This patch fixes PR96320. See the explanatory comment in the testcase.
2020-08-01 Paul Thomas <pa...@gcc.gnu.org>
gcc/fortran
PR target/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.
gcc/testsuite/
PR target/96320
* gfortran.dg/module_procedure_4.f90 : New test.
Setting standard F2003 results in a whole pile of errors, starting with:
../pr96320/pr96320.f90:19:12:
19 | module subroutine bar1(arg)
| 1
Error: Fortran 2008: MODULE prefix at (1)
and a bit later:
../pr96320/pr96320.f90:23:12:
23 | module subroutine bar2(arg)
| 1
Error: Fortran 2008: MODULE prefix at (1)
Cheers
Paul
On Sat, 1 Aug 2020 at 10:54, Thomas Koenig <tkoe...@netcologne.de> wrote:
> 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 <pa...@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 <pa...@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 <pa...@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
>
--
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein
