[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695 markeggleston at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from markeggleston at gcc dot gnu.org --- Committed to master and backported.
[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695 --- Comment #10 from CVS Commits --- The releases/gcc-8 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:15e518600a9ef82b55d2ec75d8d41d767132f475 commit r8-10261-g15e518600a9ef82b55d2ec75d8d41d767132f475 Author: Mark Eggleston Date: Thu May 7 08:02:02 2020 +0100 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. Backport from master. 2020-05-20 Mark Eggleston 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-20 Mark Eggleston 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. (cherry picked from commit eb069ae8819c3a84d7f78becc5501e21ee3a9554)
[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:7c9bfd404691e5dac7e32830ae6d9726ccf59683 commit r9-8608-g7c9bfd404691e5dac7e32830ae6d9726ccf59683 Author: Mark Eggleston Date: Thu May 7 08:02:02 2020 +0100 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. Backported from master. 2020-05-20 Mark Eggleston 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-20 Mark Eggleston 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. (cherry picked from commit eb069ae8819c3a84d7f78becc5501e21ee3a9554)
[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:8358ac9bbc57d6986c9bd5dd17c0331a60114f45 commit r10-8160-g8358ac9bbc57d6986c9bd5dd17c0331a60114f45 Author: Mark Eggleston Date: Thu May 7 08:02:02 2020 +0100 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. Backported from master. 2020-05-20 Mark Eggleston 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-20 Mark Eggleston 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. (cherry picked from commit eb069ae8819c3a84d7f78becc5501e21ee3a9554)
[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695 --- Comment #7 from CVS Commits --- The master branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:eb069ae8819c3a84d7f78becc5501e21ee3a9554 commit r11-524-geb069ae8819c3a84d7f78becc5501e21ee3a9554 Author: Mark Eggleston Date: Thu May 7 08:02:02 2020 +0100 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-20 Mark Eggleston 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-20 Mark Eggleston 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.
[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695 --- Comment #6 from markeggleston at gcc dot gnu.org --- Created attachment 47688 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47688=edit attempt to fix remaining issues Initial attempt at fixing the remaining issues. See attached patch. function f() intrinsic :: sin procedure(sin), pointer :: f f => sin end function f now has this error: 3 | procedure(sin), pointer :: f | 1 Error: Procedure pointer 'f' at (1) shall not be elemental function g() interface subroutine g() end subroutine g end interface pointer g real g ! "cannot have a type" end function now has this error: 7 | real g ! "cannot have a type" |1 Error: Symbol 'g' at (1) cannot have a type Is this error suitable or should it be something else? While trying to get a different error I found the following: function g() interface subroutine g() end subroutine g end interface real g ! "cannot have a type" end function gives theses errors: pr39695-2.f90:6:8: 6 | real g ! "cannot have a type" |1 Error: Symbol 'g' at (1) cannot have a type pr39695-2.f90:3:16: 3 | subroutine g() |1 Error: PROCEDURE attribute conflicts with RESULT attribute in 'ppr@' at (1) Note the 'ppr@' above. There may be more of them.
[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695 markeggleston at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2009-12-17 21:05:39 |2020-1-10 CC||markeggleston at gcc dot gnu.org --- Comment #5 from markeggleston at gcc dot gnu.org --- Still exists on trunk (10.0 revision 280100).
[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695 --- Comment #3 from janus at gcc dot gnu.org --- Another example: proc_ptr_result_4.f90 in the testsuite yields the following error since 4.9 (see also PR59428): procedure(sin), pointer :: f 1 Error: Procedure pointer 'ppr@' at (1) shall not be elemental function f() intrinsic :: sin procedure(sin), pointer :: f f = sin end function f
[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695 --- Comment #4 from janus at gcc dot gnu.org --- As noted by Dominique in comment 2: Comment 1 is fixed since 4.8, and out of the three cases in comment 0 only the second one persists (together with comment 3).
[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- As for 4.8.1 and trunk (r200371), only the second test in comment #0 gives the 'ppr@' name: real g ! cannot have a type 1 Error: Symbol 'ppr@' at (1) cannot have a type The first test does not give any error and the third one gives (once) integer function h(x) ! is missing the pointer attribute (twice!) 1 Error: Procedure pointer result 'h' at (1) is missing the pointer attribute The error for the test in comment #1 is p = f() ! Invalid f() returns a LOGICAL(1) function, but p is a REAL one 1 Error: Interface mismatch in procedure pointer assignment at (1): Type/rank mismatch in function result for 4.8.1 and p = f() ! Invalid f() returns a LOGICAL(1) function, but p is a REAL one 1 Error: Interface mismatch in procedure pointer assignment at (1): Type mismatch in function result (REAL(4)/LOGICAL(1)) for the trunk.
[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
-- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-17 21:05:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695
[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
--- Comment #1 from janus at gcc dot gnu dot org 2009-06-26 12:18 --- Another test case for this can be found in PR40541: program test procedure(real), pointer :: p p = f() ! Invalid f() returns a LOGICAL(1) function, but p is a REAL one contains function f() pointer :: f interface logical(1) function f() end function end interface f = .true._1 end function f end program test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695
