* [PATCH] PR fortran/63797 - Bogus ambiguous reference to 'sqrt' @ 2021-04-15 20:52 Harald Anlauf 2021-04-16 7:06 ` Bernhard Reutner-Fischer 0 siblings, 1 reply; 7+ messages in thread From: Harald Anlauf @ 2021-04-15 20:52 UTC (permalink / raw) To: fortran, gcc-patches [-- Attachment #1: Type: text/plain, Size: 838 bytes --] Hello everybody, we currently write the interface for intrinsic procedures to module files although that should not be necessary. (F2018:15.4.2.1 actually states that interfaces e.g. of intrinsic procedures are 'explicit'.) This lead to bogus errors due to an apparently bogus ambiguity. A simple solution is to just avoid writing that (redundant) information to the module file. Regtested on x86_64-pc-linux-gnu. OK for (current) mainline? Or rather wait after 11 release? Thanks, Harald PR fortran/63797 - Bogus ambiguous reference to 'sqrt' The interface of an intrinsic procedure is automatically explicit. Do not write it to the module file. gcc/fortran/ChangeLog: * module.c (write_symtree): Do not write interface of intrinsic procedure to module file. gcc/testsuite/ChangeLog: * gfortran.dg/pr63797.f90: New test. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: pr63797.patch --] [-- Type: text/x-patch, Size: 2041 bytes --] diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c index 4db0a3ac76d..b4b7b437f86 100644 --- a/gcc/fortran/module.c +++ b/gcc/fortran/module.c @@ -6218,6 +6218,9 @@ write_symtree (gfc_symtree *st) if (check_unique_name (st->name)) return; + if (strcmp (sym->module, "(intrinsic)") == 0) + return; + p = find_pointer (sym); if (p == NULL) gfc_internal_error ("write_symtree(): Symbol not written"); diff --git a/gcc/testsuite/gfortran.dg/pr63797.f90 b/gcc/testsuite/gfortran.dg/pr63797.f90 new file mode 100644 index 00000000000..1131e8167b1 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/pr63797.f90 @@ -0,0 +1,60 @@ +! { dg-do compile } +! PR63797 - Bogus ambiguous reference to 'sqrt' + +module mod1 + implicit none + real, parameter :: z = sqrt (0.0) + real :: w = sqrt (1.0) + interface + pure real function sqrt_ifc (x) + real, intent(in) :: x + end function sqrt_ifc + end interface +contains + pure function myroot () result (f) + procedure(sqrt_ifc), pointer :: f + intrinsic :: sqrt + f => sqrt + end function myroot +end module mod1 + +module mod2 + implicit none + type t + real :: a = 0. + end type + interface sqrt + module procedure sqrt + end interface +contains + elemental function sqrt (a) + type(t), intent(in) :: a + type(t) :: sqrt + sqrt% a = a% a + end function sqrt +end module mod2 + +module mod3 + implicit none + abstract interface + function real_func (x) + real :: real_func + real, intent (in) :: x + end function real_func + end interface + intrinsic :: sqrt + procedure(real_func), pointer :: real_root => sqrt +end module mod3 + +program test + use mod1 + use mod2 + use mod3 + implicit none + type(t) :: x, y + procedure(sqrt_ifc), pointer :: root + root => myroot () + y = sqrt (x) + y% a = sqrt (x% a) + z - w + root (x% a) + y% a = real_root (x% a) +end program test ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] PR fortran/63797 - Bogus ambiguous reference to 'sqrt' 2021-04-15 20:52 [PATCH] PR fortran/63797 - Bogus ambiguous reference to 'sqrt' Harald Anlauf @ 2021-04-16 7:06 ` Bernhard Reutner-Fischer 2021-04-16 7:38 ` Tobias Burnus 2021-04-16 8:32 ` Paul Richard Thomas 0 siblings, 2 replies; 7+ messages in thread From: Bernhard Reutner-Fischer @ 2021-04-16 7:06 UTC (permalink / raw) To: Harald Anlauf via Fortran; +Cc: rep.dot.nop, Harald Anlauf On Thu, 15 Apr 2021 22:52:01 +0200 Harald Anlauf via Fortran <fortran@gcc.gnu.org> wrote: > Hello everybody, > > we currently write the interface for intrinsic procedures to module > files although that should not be necessary. (F2018:15.4.2.1 actually > states that interfaces e.g. of intrinsic procedures are 'explicit'.) > This lead to bogus errors due to an apparently bogus ambiguity. > A simple solution is to just avoid writing that (redundant) information > to the module file. I'd put the standard reference you cite in a comment before the check. Does this change the module format in an incompatible way, i.e. does this require a module format version bump? What happens when we read an existing module that names an intrinsic? Without bumping the module version, we'd run into the same issue as before, don't we? If we did not bump the module version yet for gcc-11 then i would suggest to defer the patch for gcc-12 and bump then. Even if we'd skip reading existing intrinsic now, we'd break interop with older compiler versions if we would stop writing them without bumping the module format, i think? > Regtested on x86_64-pc-linux-gnu. OK for (current) mainline? > Or rather wait after 11 release? > > Thanks, > Harald ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] PR fortran/63797 - Bogus ambiguous reference to 'sqrt' 2021-04-16 7:06 ` Bernhard Reutner-Fischer @ 2021-04-16 7:38 ` Tobias Burnus 2021-04-16 7:57 ` Bernhard Reutner-Fischer 2021-04-16 8:32 ` Paul Richard Thomas 1 sibling, 1 reply; 7+ messages in thread From: Tobias Burnus @ 2021-04-16 7:38 UTC (permalink / raw) To: Bernhard Reutner-Fischer, Harald Anlauf via Fortran; +Cc: Harald Anlauf On 16.04.21 09:06, Bernhard Reutner-Fischer via Fortran wrote: > Does this change the module format in an incompatible way, i.e. does > this require a module format version bump? Not having looked it in detail but I doubt it – it is just a symbol which is not output. > What happens when we read an existing module that names an intrinsic? > Without bumping the module version, we'd run into the same issue as > before, don't we? ... > Even if we'd skip reading existing intrinsic now, we'd break interop > with older compiler versions if we would stop writing them without > bumping the module format, i think? From the function name ("write_symtree"), gfortran only skips writing it; it still reads all symtrees which are in the .mod file. As this is the only change of Harald's patch, it should be: * .mod by old compiler → used by new/old compiler: bogus error for 'sqrt'. * .mod by new compiler → used by new/old compiler: works after the patch Thus, from that side there should be no issue. And I see no point in bumping the .mod version to force the recompilation; those running into the corner case can still do 'make clean && make' and all others can keep using the old version. Tobias ----------------- Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank Thürauf ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] PR fortran/63797 - Bogus ambiguous reference to 'sqrt' 2021-04-16 7:38 ` Tobias Burnus @ 2021-04-16 7:57 ` Bernhard Reutner-Fischer 0 siblings, 0 replies; 7+ messages in thread From: Bernhard Reutner-Fischer @ 2021-04-16 7:57 UTC (permalink / raw) To: Tobias Burnus; +Cc: rep.dot.nop, Harald Anlauf via Fortran, Harald Anlauf On Fri, 16 Apr 2021 09:38:27 +0200 Tobias Burnus <tobias@codesourcery.com> wrote: > On 16.04.21 09:06, Bernhard Reutner-Fischer via Fortran wrote: > > > Does this change the module format in an incompatible way, i.e. does > > this require a module format version bump? > Not having looked it in detail but I doubt it – it is just a symbol > which is not output. > > What happens when we read an existing module that names an intrinsic? > > Without bumping the module version, we'd run into the same issue as > > before, don't we? > ... > > Even if we'd skip reading existing intrinsic now, we'd break interop > > with older compiler versions if we would stop writing them without > > bumping the module format, i think? > > From the function name ("write_symtree"), gfortran only skips writing it; > it still reads all symtrees which are in the .mod file. > As this is the only change of Harald's patch, it should be: > > * .mod by old compiler → used by new/old compiler: bogus error for 'sqrt'. > > * .mod by new compiler → used by new/old compiler: works after the patch > > Thus, from that side there should be no issue. So we'd need to skip (intrinsic) when reading existing modules written by an older compiler to fix the issue for good, as said. But maybe that's overkill. > And I see no point in bumping the .mod version to force the recompilation; > those running into the corner case can still do 'make clean && make' and > all others can keep using the old version. That might not always be possible but admittedly that's a corner case, yes. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] PR fortran/63797 - Bogus ambiguous reference to 'sqrt' 2021-04-16 7:06 ` Bernhard Reutner-Fischer 2021-04-16 7:38 ` Tobias Burnus @ 2021-04-16 8:32 ` Paul Richard Thomas 2021-04-16 11:02 ` Paul Richard Thomas 1 sibling, 1 reply; 7+ messages in thread From: Paul Richard Thomas @ 2021-04-16 8:32 UTC (permalink / raw) To: Bernhard Reutner-Fischer; +Cc: Harald Anlauf via Fortran, Harald Anlauf Hi All, Harald, that is to say the least of it an elegant and minimalist fix. With the patch applied, gfortran behaves like the "other brand" and regtests OK. Bernhard correctly points out that there should be a comment. Not only this, there must be an F2003 standard check, since F95 forbids over-riding of elemental intrinsics. I see as I am writing that Tobias has dealt with the point about module version. I agree entirely with Tobias. The fact that the patch is permissive in suppressing an incorrect error means that it cannot break anything. This patch, once modified as above, should be pushed to master right immediately and, since it affects F2003 compliance, backported to 10-branch. Many thanks, Harald - good work! Paul On Fri, 16 Apr 2021 at 08:41, Bernhard Reutner-Fischer via Fortran < fortran@gcc.gnu.org> wrote: > On Thu, 15 Apr 2021 22:52:01 +0200 > Harald Anlauf via Fortran <fortran@gcc.gnu.org> wrote: > > > Hello everybody, > > > > we currently write the interface for intrinsic procedures to module > > files although that should not be necessary. (F2018:15.4.2.1 actually > > states that interfaces e.g. of intrinsic procedures are 'explicit'.) > > This lead to bogus errors due to an apparently bogus ambiguity. > > A simple solution is to just avoid writing that (redundant) information > > to the module file. > > I'd put the standard reference you cite in a comment before the check. > > Does this change the module format in an incompatible way, i.e. does > this require a module format version bump? > > What happens when we read an existing module that names an intrinsic? > Without bumping the module version, we'd run into the same issue as > before, don't we? > > If we did not bump the module version yet for gcc-11 then i would > suggest to defer the patch for gcc-12 and bump then. > > Even if we'd skip reading existing intrinsic now, we'd break interop > with older compiler versions if we would stop writing them without > bumping the module format, i think? > > > Regtested on x86_64-pc-linux-gnu. OK for (current) mainline? > > Or rather wait after 11 release? > > > > Thanks, > > Harald > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] PR fortran/63797 - Bogus ambiguous reference to 'sqrt' 2021-04-16 8:32 ` Paul Richard Thomas @ 2021-04-16 11:02 ` Paul Richard Thomas 2021-04-16 14:31 ` Harald Anlauf 0 siblings, 1 reply; 7+ messages in thread From: Paul Richard Thomas @ 2021-04-16 11:02 UTC (permalink / raw) To: Bernhard Reutner-Fischer; +Cc: Harald Anlauf via Fortran, Harald Anlauf Hi Harald, This is the output from a completely tedious Zoom meeting: /* From F2003 onwards, intrinsic procedures are no longer subject to the restriction, "that an elemental intrinsic function here be of type integer or character and each argument must be an initialization expr of type integer or character" is lifted so that intrinsic procedures can be over-ridden. This requires that the intrinsic symbol not appear in the module file, thereby preventing ambiguity when USEd. */ if (strcmp (sym->module, "(intrinsic)") == 0 && (gfc_option.allow_std & GFC_STD_F2003)) return; Modify or replace the comment, as desired. The change to the condition gives the desired result in terms of standard compliance. Regards Paul On Fri, 16 Apr 2021 at 09:32, Paul Richard Thomas < paul.richard.thomas@gmail.com> wrote: > Hi All, > > Harald, that is to say the least of it an elegant and minimalist fix. With > the patch applied, gfortran behaves like the "other brand" and regtests OK. > > Bernhard correctly points out that there should be a comment. Not only > this, there must be an F2003 standard check, since F95 forbids over-riding > of elemental intrinsics. > > I see as I am writing that Tobias has dealt with the point about module > version. I agree entirely with Tobias. The fact that the patch is > permissive in suppressing an incorrect error means that it cannot break > anything. > > This patch, once modified as above, should be pushed to master right > immediately and, since it affects F2003 compliance, backported to 10-branch. > > Many thanks, Harald - good work! > > Paul > > > > > > On Fri, 16 Apr 2021 at 08:41, Bernhard Reutner-Fischer via Fortran < > fortran@gcc.gnu.org> wrote: > >> On Thu, 15 Apr 2021 22:52:01 +0200 >> Harald Anlauf via Fortran <fortran@gcc.gnu.org> wrote: >> >> > Hello everybody, >> > >> > we currently write the interface for intrinsic procedures to module >> > files although that should not be necessary. (F2018:15.4.2.1 actually >> > states that interfaces e.g. of intrinsic procedures are 'explicit'.) >> > This lead to bogus errors due to an apparently bogus ambiguity. >> > A simple solution is to just avoid writing that (redundant) information >> > to the module file. >> >> I'd put the standard reference you cite in a comment before the check. >> >> Does this change the module format in an incompatible way, i.e. does >> this require a module format version bump? >> >> What happens when we read an existing module that names an intrinsic? >> Without bumping the module version, we'd run into the same issue as >> before, don't we? >> >> If we did not bump the module version yet for gcc-11 then i would >> suggest to defer the patch for gcc-12 and bump then. >> >> Even if we'd skip reading existing intrinsic now, we'd break interop >> with older compiler versions if we would stop writing them without >> bumping the module format, i think? >> >> > Regtested on x86_64-pc-linux-gnu. OK for (current) mainline? >> > Or rather wait after 11 release? >> > >> > Thanks, >> > Harald >> > > > -- > "If you can't explain it simply, you don't understand it well enough" - > Albert Einstein > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] PR fortran/63797 - Bogus ambiguous reference to 'sqrt' 2021-04-16 11:02 ` Paul Richard Thomas @ 2021-04-16 14:31 ` Harald Anlauf 0 siblings, 0 replies; 7+ messages in thread From: Harald Anlauf @ 2021-04-16 14:31 UTC (permalink / raw) To: Paul Richard Thomas, fortran, gcc-patches Cc: Bernhard Reutner-Fischer, Harald Anlauf via Fortran [-- Attachment #1: Type: text/plain, Size: 1833 bytes --] Hi Paul, all, having really enjoyed the review process, I've now committed Paul's version including his comment. See also attached. Thanks, Harald Gesendet: Freitag, 16. April 2021 um 13:02 Uhr Von: "Paul Richard Thomas" <paul.richard.thomas@gmail.com> An: "Bernhard Reutner-Fischer" <rep.dot.nop@gmail.com> Cc: "Harald Anlauf via Fortran" <fortran@gcc.gnu.org>, "Harald Anlauf" <anlauf@gmx.de> Betreff: Re: [PATCH] PR fortran/63797 - Bogus ambiguous reference to 'sqrt' Hi Harald, This is the output from a completely tedious Zoom meeting: /* From F2003 onwards, intrinsic procedures are no longer subject to the restriction, "that an elemental intrinsic function here be of type integer or character and each argument must be an initialization expr of type integer or character" is lifted so that intrinsic procedures can be over-ridden. This requires that the intrinsic symbol not appear in the module file, thereby preventing ambiguity when USEd. */ if (strcmp (sym->module, "(intrinsic)") == 0 && (gfc_option.allow_std & GFC_STD_F2003)) return; Modify or replace the comment, as desired. The change to the condition gives the desired result in terms of standard compliance. Regards Paul PR fortran/63797 - Bogus ambiguous reference to 'sqrt' The interface of an intrinsic procedure is automatically explicit. Do not write it to the module file to prevent wrong ambiguities on USE. gcc/fortran/ChangeLog: PR fortran/63797 * module.c (write_symtree): Do not write interface of intrinsic procedure to module file for F2003 and newer. gcc/testsuite/ChangeLog: PR fortran/63797 * gfortran.dg/pr63797.f90: New test. Co-authored-by: Paul Thomas <pault@gcc.gnu.org> [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: pr63797.patch --] [-- Type: text/x-patch, Size: 2552 bytes --] diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c index 4db0a3ac76d..089453caa03 100644 --- a/gcc/fortran/module.c +++ b/gcc/fortran/module.c @@ -6218,6 +6218,17 @@ write_symtree (gfc_symtree *st) if (check_unique_name (st->name)) return; + /* From F2003 onwards, intrinsic procedures are no longer subject to + the restriction, "that an elemental intrinsic function here be of + type integer or character and each argument must be an initialization + expr of type integer or character" is lifted so that intrinsic + procedures can be over-ridden. This requires that the intrinsic + symbol not appear in the module file, thereby preventing ambiguity + when USEd. */ + if (strcmp (sym->module, "(intrinsic)") == 0 + && (gfc_option.allow_std & GFC_STD_F2003)) + return; + p = find_pointer (sym); if (p == NULL) gfc_internal_error ("write_symtree(): Symbol not written"); diff --git a/gcc/testsuite/gfortran.dg/pr63797.f90 b/gcc/testsuite/gfortran.dg/pr63797.f90 new file mode 100644 index 00000000000..1131e8167b1 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/pr63797.f90 @@ -0,0 +1,60 @@ +! { dg-do compile } +! PR63797 - Bogus ambiguous reference to 'sqrt' + +module mod1 + implicit none + real, parameter :: z = sqrt (0.0) + real :: w = sqrt (1.0) + interface + pure real function sqrt_ifc (x) + real, intent(in) :: x + end function sqrt_ifc + end interface +contains + pure function myroot () result (f) + procedure(sqrt_ifc), pointer :: f + intrinsic :: sqrt + f => sqrt + end function myroot +end module mod1 + +module mod2 + implicit none + type t + real :: a = 0. + end type + interface sqrt + module procedure sqrt + end interface +contains + elemental function sqrt (a) + type(t), intent(in) :: a + type(t) :: sqrt + sqrt% a = a% a + end function sqrt +end module mod2 + +module mod3 + implicit none + abstract interface + function real_func (x) + real :: real_func + real, intent (in) :: x + end function real_func + end interface + intrinsic :: sqrt + procedure(real_func), pointer :: real_root => sqrt +end module mod3 + +program test + use mod1 + use mod2 + use mod3 + implicit none + type(t) :: x, y + procedure(sqrt_ifc), pointer :: root + root => myroot () + y = sqrt (x) + y% a = sqrt (x% a) + z - w + root (x% a) + y% a = real_root (x% a) +end program test ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-04-16 14:31 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-04-15 20:52 [PATCH] PR fortran/63797 - Bogus ambiguous reference to 'sqrt' Harald Anlauf 2021-04-16 7:06 ` Bernhard Reutner-Fischer 2021-04-16 7:38 ` Tobias Burnus 2021-04-16 7:57 ` Bernhard Reutner-Fischer 2021-04-16 8:32 ` Paul Richard Thomas 2021-04-16 11:02 ` Paul Richard Thomas 2021-04-16 14:31 ` Harald Anlauf
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).