Hi Mark,
On 5/18/20 9:35 AM, Mark Eggleston wrote:
Please find attached a patch for PR39695 (this time it is attached).
Looks okay – with the "dg-(do )compile" change as remarked by Manfred.
[I did wonder whether BLOCK could cause problems with ns->proc_name, but
I couldn't come up with a case where one could have both a
function-return value issue and block.]
Thanks,
Tobias
Commit message:
Fortran : ProcPtr function results: 'ppr@' in error message PR39695
The value 'ppr@' is set in the name of result symbol, the actual
name of the symbol is in the procedure name symbol pointed
to by the result symbol's namespace (ns). When reporting errors for
symbols that have the proc_pointer attribute check whether the
result attribute is set and set the name accordingly.
2020-05-18 Mark Eggleston <markeggles...@gcc.gnu.org>
gcc/fortran/
PR fortran/39695
* resolve.c (resolve_fl_procedure): Set name depending on
whether the result attribute is set. For PROCEDURE/RESULT
conflict use the name in sym->ns->proc_name->name.
* symbol.c (gfc_add_type): Add check for function and result
attributes use sym->ns->proc_name->name if both are set.
Where the symbol cannot have a type use the name in
sym->ns->proc_name->name.
2020-05-18 Mark Eggleston <markeggles...@gcc.gnu.org>
gcc/testsuite/
PR fortran/39695
* gfortran.dg/pr39695_1.f90: New test.
* gfortran.dg/pr39695_2.f90: New test.
* gfortran.dg/pr39695_3.f90: New test.
* gfortran.dg/pr39695_4.f90: New test.
Tested on x86_64 using make check-fortran for master, gcc-8, gcc-9 and
gcc-10.
OK to to commit and backport?
-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander
Walter
