Bug 86906 - erroneous name clash with renaming in use statement

Bug 86906 - erroneous name clash with renaming in use statement

[Damian Rouson]

gfortran 6.4, 7.3, and 8.2 all produce the error message below when
attempting to use a renamed type in the same scope as the variable that
motivated the renaming:

$ cat foo.f90
module foo
  type config
  end type
end module
  use foo, only: foo_config => config
contains
  subroutine cap
    integer config
    type(foo_config) extra
  end subroutine
end

$ gfortran foo.f90
foo.f90:9:26:

     integer config
                  2
     type(foo_config) extra
                          1
Error: The type ‘config’ cannot be host associated at (1) because it is
blocked by an incompatible object of the same name declared at (2)

$ gfortran --version
GNU Fortran (GCC) 8.2.0

Re: Bug 86906 - erroneous name clash with renaming in use statement

[Paul Richard Thomas]

Dear All,

This fixes the bug and regtests OK:
Index: /home/pault/svn/trunk/gcc/fortran/resolve.c
===================================================================
*** /home/pault/svn/trunk/gcc/fortran/resolve.c    (revision 262445)
--- /home/pault/svn/trunk/gcc/fortran/resolve.c    (working copy)
*************** resolve_fl_variable_derived (gfc_symbol
*** 12071,12076 ****
--- 12076,12082 ----
       namespace.  14.6.1.3 of the standard and the discussion on
       comp.lang.fortran.  */
    if (sym->ns != sym->ts.u.derived->ns
+       && !sym->ts.u.derived->attr.use_assoc
        && sym->ns->proc_name->attr.if_source != IFSRC_IFBODY)
      {
        gfc_symbol *s;

The gotcha that causes the bug appears in the subsequent line
gfc_find_symbol (sym->ts.u.derived->name, sym->ns, 0, &s);

The symbol for the derived type retains the original name; it is the
symtree that is renamed. Comparing the symbol names is bound to cause
the clash.

I will clear my tree of the work on PR80477 and PR86481 (finalization
stuff) and will commit the fix as obvious.

Cheers

Paul

On Thu, 9 Aug 2018 at 22:36, Damian Rouson <damian@sourceryinstitute.org> wrote:
>
> gfortran 6.4, 7.3, and 8.2 all produce the error message below when
> attempting to use a renamed type in the same scope as the variable that
> motivated the renaming:
>
> $ cat foo.f90
> module foo
>   type config
>   end type
> end module
>   use foo, only: foo_config => config
> contains
>   subroutine cap
>     integer config
>     type(foo_config) extra
>   end subroutine
> end
>
> $ gfortran foo.f90
> foo.f90:9:26:
>
>      integer config
>                   2
>      type(foo_config) extra
>                           1
> Error: The type ‘config’ cannot be host associated at (1) because it is
> blocked by an incompatible object of the same name declared at (2)
>
> $ gfortran --version
> GNU Fortran (GCC) 8.2.0



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Re: Bug 86906 - erroneous name clash with renaming in use statement

[Paul Richard Thomas]

Fixed on trunk as r263494 and 8-branch as r263498.

Cheers

Paul
On Sun, 12 Aug 2018 at 09:55, Paul Richard Thomas
<paul.richard.thomas@gmail.com> wrote:
>
> Dear All,
>
> This fixes the bug and regtests OK:
> Index: /home/pault/svn/trunk/gcc/fortran/resolve.c
> ===================================================================
> *** /home/pault/svn/trunk/gcc/fortran/resolve.c    (revision 262445)
> --- /home/pault/svn/trunk/gcc/fortran/resolve.c    (working copy)
> *************** resolve_fl_variable_derived (gfc_symbol
> *** 12071,12076 ****
> --- 12076,12082 ----
>        namespace.  14.6.1.3 of the standard and the discussion on
>        comp.lang.fortran.  */
>     if (sym->ns != sym->ts.u.derived->ns
> +       && !sym->ts.u.derived->attr.use_assoc
>         && sym->ns->proc_name->attr.if_source != IFSRC_IFBODY)
>       {
>         gfc_symbol *s;
>
> The gotcha that causes the bug appears in the subsequent line
> gfc_find_symbol (sym->ts.u.derived->name, sym->ns, 0, &s);
>
> The symbol for the derived type retains the original name; it is the
> symtree that is renamed. Comparing the symbol names is bound to cause
> the clash.
>
> I will clear my tree of the work on PR80477 and PR86481 (finalization
> stuff) and will commit the fix as obvious.
>
> Cheers
>
> Paul
>
> On Thu, 9 Aug 2018 at 22:36, Damian Rouson <damian@sourceryinstitute.org> wrote:
> >
> > gfortran 6.4, 7.3, and 8.2 all produce the error message below when
> > attempting to use a renamed type in the same scope as the variable that
> > motivated the renaming:
> >
> > $ cat foo.f90
> > module foo
> >   type config
> >   end type
> > end module
> >   use foo, only: foo_config => config
> > contains
> >   subroutine cap
> >     integer config
> >     type(foo_config) extra
> >   end subroutine
> > end
> >
> > $ gfortran foo.f90
> > foo.f90:9:26:
> >
> >      integer config
> >                   2
> >      type(foo_config) extra
> >                           1
> > Error: The type ‘config’ cannot be host associated at (1) because it is
> > blocked by an incompatible object of the same name declared at (2)
> >
> > $ gfortran --version
> > GNU Fortran (GCC) 8.2.0
>
>
>
> --
> "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

Re: Bug 86906 - erroneous name clash with renaming in use statement

[Damian Rouson]

Thanks, Paul!

Damian

On Sun, Aug 12, 2018 at 8:38 AM, Paul Richard Thomas <
paul.richard.thomas@gmail.com> wrote:

> Fixed on trunk as r263494 and 8-branch as r263498.
>
> Cheers
>
> Paul
> On Sun, 12 Aug 2018 at 09:55, Paul Richard Thomas
> <paul.richard.thomas@gmail.com> wrote:
> >
> > Dear All,
> >
> > This fixes the bug and regtests OK:
> > Index: /home/pault/svn/trunk/gcc/fortran/resolve.c
> > ===================================================================
> > *** /home/pault/svn/trunk/gcc/fortran/resolve.c    (revision 262445)
> > --- /home/pault/svn/trunk/gcc/fortran/resolve.c    (working copy)
> > *************** resolve_fl_variable_derived (gfc_symbol
> > *** 12071,12076 ****
> > --- 12076,12082 ----
> >        namespace.  14.6.1.3 of the standard and the discussion on
> >        comp.lang.fortran.  */
> >     if (sym->ns != sym->ts.u.derived->ns
> > +       && !sym->ts.u.derived->attr.use_assoc
> >         && sym->ns->proc_name->attr.if_source != IFSRC_IFBODY)
> >       {
> >         gfc_symbol *s;
> >
> > The gotcha that causes the bug appears in the subsequent line
> > gfc_find_symbol (sym->ts.u.derived->name, sym->ns, 0, &s);
> >
> > The symbol for the derived type retains the original name; it is the
> > symtree that is renamed. Comparing the symbol names is bound to cause
> > the clash.
> >
> > I will clear my tree of the work on PR80477 and PR86481 (finalization
> > stuff) and will commit the fix as obvious.
> >
> > Cheers
> >
> > Paul
> >
> > On Thu, 9 Aug 2018 at 22:36, Damian Rouson <damian@sourceryinstitute.org>
> wrote:
> > >
> > > gfortran 6.4, 7.3, and 8.2 all produce the error message below when
> > > attempting to use a renamed type in the same scope as the variable that
> > > motivated the renaming:
> > >
> > > $ cat foo.f90
> > > module foo
> > >   type config
> > >   end type
> > > end module
> > >   use foo, only: foo_config => config
> > > contains
> > >   subroutine cap
> > >     integer config
> > >     type(foo_config) extra
> > >   end subroutine
> > > end
> > >
> > > $ gfortran foo.f90
> > > foo.f90:9:26:
> > >
> > >      integer config
> > >                   2
> > >      type(foo_config) extra
> > >                           1
> > > Error: The type ‘config’ cannot be host associated at (1) because it is
> > > blocked by an incompatible object of the same name declared at (2)
> > >
> > > $ gfortran --version
> > > GNU Fortran (GCC) 8.2.0
> >
> >
> >
> > --
> > "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
>

Re: Bug 86906 - erroneous name clash with renaming in use statement

[Clune, Thomas L. (GSFC-6101)]

My thanks as well!


On Aug 12, 2018, at 12:26 PM, Damian Rouson <damian@sourceryinstitute.org<mailto:damian@sourceryinstitute.org>> wrote:

Thanks, Paul!

Damian

On Sun, Aug 12, 2018 at 8:38 AM, Paul Richard Thomas <paul.richard.thomas@gmail.com<mailto:paul.richard.thomas@gmail.com>> wrote:
Fixed on trunk as r263494 and 8-branch as r263498.

Cheers

Paul
On Sun, 12 Aug 2018 at 09:55, Paul Richard Thomas
<paul.richard.thomas@gmail.com<mailto:paul.richard.thomas@gmail.com>> wrote:
>
> Dear All,
>
> This fixes the bug and regtests OK:
> Index: /home/pault/svn/trunk/gcc/fortran/resolve.c
> ===================================================================
> *** /home/pault/svn/trunk/gcc/fortran/resolve.c    (revision 262445)
> --- /home/pault/svn/trunk/gcc/fortran/resolve.c    (working copy)
> *************** resolve_fl_variable_derived (gfc_symbol
> *** 12071,12076 ****
> --- 12076,12082 ----
>        namespace.  14.6.1.3 of the standard and the discussion on
>        comp.lang.fortran.  */
>     if (sym->ns != sym->ts.u.derived->ns
> +       && !sym->ts.u.derived->attr.use_assoc
>         && sym->ns->proc_name->attr.if_source != IFSRC_IFBODY)
>       {
>         gfc_symbol *s;
>
> The gotcha that causes the bug appears in the subsequent line
> gfc_find_symbol (sym->ts.u.derived->name, sym->ns, 0, &s);
>
> The symbol for the derived type retains the original name; it is the
> symtree that is renamed. Comparing the symbol names is bound to cause
> the clash.
>
> I will clear my tree of the work on PR80477 and PR86481 (finalization
> stuff) and will commit the fix as obvious.
>
> Cheers
>
> Paul
>
> On Thu, 9 Aug 2018 at 22:36, Damian Rouson <damian@sourceryinstitute.org<mailto:damian@sourceryinstitute.org>> wrote:
> >
> > gfortran 6.4, 7.3, and 8.2 all produce the error message below when
> > attempting to use a renamed type in the same scope as the variable that
> > motivated the renaming:
> >
> > $ cat foo.f90
> > module foo
> >   type config
> >   end type
> > end module
> >   use foo, only: foo_config => config
> > contains
> >   subroutine cap
> >     integer config
> >     type(foo_config) extra
> >   end subroutine
> > end
> >
> > $ gfortran foo.f90
> > foo.f90:9:26:
> >
> >      integer config
> >                   2
> >      type(foo_config) extra
> >                           1
> > Error: The type ‘config’ cannot be host associated at (1) because it is
> > blocked by an incompatible object of the same name declared at (2)
> >
> > $ gfortran --version
> > GNU Fortran (GCC) 8.2.0
>
>
>
> --
> "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