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

[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

Post by 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
$ 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
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

[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

Post by Paul Richard Thomas
Dear All,
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

Post by 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
$ 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
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

[Damian Rouson]

Thanks, Paul!

Damian

On Sun, Aug 12, 2018 at 8:38 AM, Paul Richard Thomas <

Post by 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

Post by Paul Richard Thomas
Dear All,
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

Post by 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
$ 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
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

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

My thanks as well!


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

Thanks, Paul!

Damian

On Sun, Aug 12, 2018 at 8:38 AM, Paul Richard Thomas <***@gmail.com<mailto:***@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

Post by Paul Richard Thomas
Dear All,
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

Post by 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
$ 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
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