This is the mail archive of the
mailing list for the GCC project.
Re: [patch, fortran] Fix PR 91443
- From: Janne Blomqvist <blomqvist dot janne at gmail dot com>
- To: Thomas Koenig <tkoenig at netcologne dot de>
- Cc: "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 15 Aug 2019 21:52:41 +0300
- Subject: Re: [patch, fortran] Fix PR 91443
- References: <firstname.lastname@example.org>
On Thu, Aug 15, 2019 at 2:35 PM Thomas Koenig <email@example.com> wrote:
> Hello world,
> this patch fixes PR 91443, in which we did not warn about a mismatched
> external procedure. The problem was that the module this was called in
> was resolved before parsing of the procedure ever started.
> The approach taken here is to move the checking of external procedures
> to a stage after normal resolution. And, of course, fix the resulting
> fallout from regression-testing :-)
> There is also one policy change in the patch. Previously, we only warned
> about mismatched declarations. Now, this is a hard error unless the
> user specifies -std=legacy. The reason is that we have not yet solved
> our single declaration problem, but it cannot be solved unless all
> of a procedure's callers match. People who have such broken code
> should at least be made aware that they have a problem. However, I would
> like to have some sort of agreement on this point before the patch
> is committed. This can also be changed (see the code at the bottom
> of frontend-passes.c).
Personally, I'm fine with making this a hard error. As we've recently
seen with the varargs & missing charlengths in LAPACK saga, mismatches
can cause extremely subtle issues that can cause silent corruption and
take an expert to figure out.
> Once this is in, the next step is to issue errors for mismatching
> calls where the callee is not in the same file. This can be done
> with the infrastructure of this patch.
> So, OK for trunk?
The patch itself looks Ok. One worry, are you introducing an
O(N**2)(?) algorithm (looping over all symbols for every symbol?), and
does this cause performance issues when compiling some gigantic F77
If this worry is unfounded, Ok for trunk.