Arjen,
If this is your first go around with patching gfortran,
I'll suggest running the testsuite (if you haven't, see
step 5. below; if you have see step 6.). I suspect you
already know much of what I enumerate below, but it may
help others.
With a bug report, the workflow for me is/was
1. Check versions of the standard to determine if it is
a bug, and what is the expected result.
2. Identify where the problem can be addressed in source.
For you (or anyone else interested in gfortran development),
I suspect there a lot of question about how to do this
step and the structure of the gfortran source code. I can
answer some of those questions in follow-up emails. Send
them to fortran@ and CC me.
3. Develop patch.
I've done the first 3 steps. You are now at testing the patch.
4. Build gfortran with the patch. Assuming a Unix-like system,
I have gcc/gccx with the source and gcc/objx is the build
directory. So, for a first time build on an N cpu system do
% cd gcc/objx
% ../gcc/gccx/configure --prefix=$HOME/work/x \
--enable-languages=c,c++,fortran,lto \
--enable-bootstrap --disable-nls --enable-checking
% make -j N-1 bootstrap && make install
Otherwise,
% cd gcc/objx
% make -j N-1 && make install
This installs everything in $HOME/work/x.
5. Run the testsuite to check for regressions. If any occur,
fix regressions or fix the patch.
% make -j N-1 check-fortran
% tail gcc/testsuite/gfortran/gfortran.sum
=== gfortran Summary ===
# of expected passes 58647
# of expected failures 253
# of unsupported tests 92
objx/gcc/gfortran version 12.0.0 20210816 (experimental) (GCC)
With the C937 and C949 patches, I changed "typespec" to
"type-spec" in nearby unrelated error messages. Both are
being used and type-spec matches the standard. This may
cause a regression, so one or more testcases may need a change.
The C937 patch did not cause a regression. The C949 one
did. You'll see a line like
# of unexpected failures 7
The file gcc/testsuite/gfortran/gfortran.log contains the
buildlog, which is huge. You can find the failures with
a search for lines containing ^FAIL.
6. Prepare ChangeLog.
This has changed with git so you'll need to ask Tobias,
Thomas, Harald, or on the gcc@ list for guidance.
7. Submit patch to fortran@gcc and gcc-patches@gcc asking
for review.
8. Wait a few days. Ping fortran@gcc and gcc-patches@gcc.
9. Wait a few days. Ping fortran@gcc and gcc-patches@gcc.
As I developed, the original patch and presumably you reviewed
it for correctness, you can probably skip step 9.
10. Wait a few days. Commit patch with or without a review.
I do not know if you need any explicit access/permission to
commit a patch. I iknow very little about git and how it
works.
At this point, you can either backport the patch to release
branches or close the PR. For me, I always did a backport
if it was a trivial task. At some point, HEAD will diverge
sufficiently from a branch, I would then stop backporting.
--
steve
On Thu, Aug 19, 2021 at 05:10:47PM +0200, Arjen Markus wrote:
> I have applied the patches locally (take care to restore the tabs ;)).
> Should I now commit these changes or is there a more formal procedure
> involved?
>
> Regards,
>
> Arjen
>
> Op do 19 aug. 2021 om 08:59 schreef Arjen Markus <arjen.markus...@gmail.com
> >:
>
> > Hi Steve,
> >
> > I am willing to take up this challenge ;), as well as the patch for C949.
> > It would be my next attempt to get acquainted with the source code (a first
> > step hopefully to actively contribute).
> >
> > Regards,
> >
> > Arjen
> >
> > Op di 17 aug. 2021 om 21:02 schreef Steve Kargl via Fortran <
> > fortran@gcc.gnu.org>:
> >
> >> For those that might care, I draw your attention to
> >>
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101951
> >>
> >> Good opportunity for a lurker to step forward and
> >> become a gfortran committer. Otherwise, this patch
> >> will fester in bugzilla the dozen or so other patches
> >> I've attached to PRs.
> >>
> >> --
> >> Steve
> >>
> >
--
Steve
