Bug 37274 - [Regression on 4.3?] error: type name is ambiguous.
[Regression on 4.3?] error: type name is ambiguous.
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: fortran
4.3.1
: P3 normal
: ---
Assigned To: Paul Thomas
: rejects-valid
Depends on:
Blocks: 32834
  Show dependency treegraph
 
Reported: 2008-08-29 07:41 UTC by Salvatore Filippone
Modified: 2008-09-23 06:28 UTC (History)
1 user (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work: 4.2.4
Known to fail: 4.4.0
Last reconfirmed: 2008-09-01 10:27:17


Attachments
test case (5.82 KB, text/plain)
2008-08-29 07:42 UTC, Salvatore Filippone
Details
A reduced version of the testcase (1.10 KB, text/x-fortran)
2008-08-29 15:29 UTC, Paul Thomas
Details
another testcase with comments telling how to get/not get the error (2.02 KB, text/x-fortran)
2008-08-30 12:12 UTC, Mikael Morin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Salvatore Filippone 2008-08-29 07:41:49 UTC
With the attached test case I get: 
[sfilippo@localhost type_ambiguity]$ gfortran -v -c type_ambiguity.f90 
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3.1/configure --prefix=/usr/local/gcc43 --with-mpfr=/usr/local/mpfr --with-gmp=/usr/local/gmp
Thread model: posix
gcc version 4.3.1 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic'
 /usr/local/gcc43/libexec/gcc/i686-pc-linux-gnu/4.3.1/f951 type_ambiguity.f90 -quiet -dumpbase type_ambiguity.f90 -mtune=generic -auxbase type_ambiguity -version -fintrinsic-modules-path /usr/local/gcc43/lib/gcc/i686-pc-linux-gnu/4.3.1/finclude -o /tmp/cc6I26kb.s
GNU F95 (GCC) version 4.3.1 (i686-pc-linux-gnu)
        compiled by GNU C version 4.3.1, GMP version 4.2.2, MPFR version 2.3.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
type_ambiguity.f90:283.14:

  type(vector) :: new_pos  ! the new vertex position, after smoothing
             1
Error: Type name 'vector' at (1) is ambiguous

I cannot see any ambiguity in the source code. 

The code compiles cleanly on 4.2.4, fails on 4.4-20080822, compiles cleanly on Intel 10.1.015 and on XLF 10.1. 

The code has been extracted from an application, and has been heavily pruned. 

The Intel compiler  gives a warning about an intent(out) variable not being set, but this is an artifact of pruning the test case. 

The most puzzling things are the two workarounds that I have found so far: 
1. In the subroutine smooth_mesh, comment the USE statement at line 279. 
   This is not an option in the original application code, though. 
2. In the subroutine smooth_mesh, switch the order of the USE statements at    lines 277/278; this also fixes the original application code. 

I cannot see anything illegal in the code, so I presume it is a reject-valid; however even if the code is shown to be illegal, the reported error does precious little to help the user. 


Salvatore
Comment 1 Salvatore Filippone 2008-08-29 07:42:35 UTC
Created attachment 16159 [details]
test case
Comment 2 Paul Thomas 2008-08-29 08:31:35 UTC
Confirmed

Salvatore, what is the date on your 4.2.4?  Is it the release version - ie. 19th May 2008?

Cheers

Paul
Comment 3 Salvatore Filippone 2008-08-29 08:39:15 UTC
Yes, it's the release.

[sfilippo@localhost type_ambiguity]$ gfortran -v -c type_ambiguity.f90 
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2.4/configure 
Thread model: posix
gcc version 4.2.4
 /usr/local/libexec/gcc/i686-pc-linux-gnu/4.2.4/f951 type_ambiguity.f90 -quiet -dumpbase type_ambiguity.f90 -mtune=generic -auxbase type_ambiguity -version -I /usr/local/lib/gcc/i686-pc-linux-gnu/4.2.4/finclude -o /tmp/ccZJJLfj.s
GNU F95 version 4.2.4 (i686-pc-linux-gnu)
        compiled by GNU C version 4.2.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 as -V -Qy -o type_ambiguity.o /tmp/ccZJJLfj.s
GNU assembler version 2.17.50.0.12-4 (i386-redhat-linux) using BFD version 2.17.50.0.12-4 20070128
[sfilippo@localhost type_ambiguity]$ 
Comment 4 Salvatore Filippone 2008-08-29 08:46:13 UTC
Does it have anything to do with 36374? 
Comment 5 Paul Thomas 2008-08-29 08:54:16 UTC
(In reply to comment #4)
> Does it have anything to do with 36374? 
> 

Salvatore,

I don't think so, since this PR is a regression. Anyway, I'll take a look at them both together.... in a few days. I'm still not entirely back in action after my move to Barcelona and the theft of my laptop; in particular, I still do not have a working tree that I can use for debugging.

As soon as posssible.... honest!

Paul
Comment 6 Paul Thomas 2008-08-29 15:29:16 UTC
Created attachment 16163 [details]
A reduced version of the testcase

I still do not feel much the wiser - making vector visible in class motion makes the problem go away.  This evidently gives the component 'law_y' of 'motion' a visible type that is no longer ambiguous with the "real" 'vector'.

Paul
Comment 7 Mikael Morin 2008-08-30 11:27:07 UTC
I think this should be rejected :

module class_vector
  implicit none
  type vector
  end type vector
end module class_vector

module tools_math
  implicit none
  interface lin_interp
     function lin_interp_v()
       use class_vector
       type(vector ) :: lin_interp_v
     end function lin_interp_v
  end interface
end module tools_math

module smooth_mesh
  use tools_math    
  implicit none
  type(vector ) :: new_pos  ! vector shouldn't be available IMHO 
end module smooth_mesh

I find this behavior very confusing, inconsistent with the concept of scoping 
units. 
While I understand that vector should make its way to the tools_math.mod file
for lin_interp_v's type checking, it should be kept local to that function. 
I haven't seen it explicitely in the standard though. 

Salvatore, as a workaround you can put a private statement in modules
where you "use module" from within a function. 
Comment 8 Mikael Morin 2008-08-30 12:12:27 UTC
Created attachment 16171 [details]
another testcase with comments telling how to get/not get the error

Look at the comments in module class_bc_math. 
This is very strange.
Comment 9 Mikael Morin 2008-08-30 12:17:39 UTC
Forget comment #8. 
I was testing with version 4.3.1
Comment 10 Salvatore Filippone 2008-08-30 14:00:52 UTC
(In reply to comment #7)
> I think this should be rejected :
> 
I think your example should be rejected, but it is not like my code, where smooth_mesh explicitly USEs class_vector. So, I am not sure what's your point. 

Salvatore 

Comment 11 Mikael Morin 2008-08-31 21:16:52 UTC
(In reply to comment #10)
> I think your example should be rejected, but it is not like my code, where
> smooth_mesh explicitly USEs class_vector. So, I am not sure what's your point. 

My point is this:
As you said in your first comment, there is no ambiguity in your code. 
vector is defined in only one module which is used when needed in other modules.
Moreover you use private statements to prevent use associated entities from being exported in those modules. 
Doing this way, no module but class_vector exports vector. No ambiguity possible
What my example shows is that tools_math (and other modules in your code) export vector as well. Ambiguities are possible. 

As gfortran seems to handle simple ambiguities correctly, what I'm underlying is not the bug, but it might be part of it. 
Comment 12 Mikael Morin 2008-08-31 21:52:21 UTC
Actually, my comment #7 seems to be more related to bug #36374.
Comment 13 Mikael Morin 2008-08-31 23:34:23 UTC
(In reply to comment #12)
> Actually, my comment #7 seems to be more related to bug #36374.
No, it's not
Comment 14 Salvatore Filippone 2008-09-01 08:13:30 UTC
(In reply to comment #11)

> My point is this:
> As you said in your first comment, there is no ambiguity in your code. 
> vector is defined in only one module which is used when needed in other
> modules.
> Moreover you use private statements to prevent use associated entities from
> being exported in those modules. 
Well, the code would be legal even without the private statement, I can USE definitions directly or indirectly as many times as I like. Or at least so I understand.....
Salvatore
Comment 15 Paul Thomas 2008-09-01 10:27:17 UTC
Since I am homing in on a solution, I might as well take it on.

Cheers

Paul
Comment 16 Paul Thomas 2008-09-04 21:22:23 UTC
> I find this behavior very confusing, inconsistent with the concept of scoping 
> units. 
(In reply to comment #7)
> I think this should be rejected :

Lahey and deep contemplation agree with you:-)

I am trying to understand why this happens - it's not just interfaces but contained functions too.

Paul

Comment 17 Paul Thomas 2008-09-17 07:31:31 UTC
(In reply to comment #16)
Lest anybody is worrying about the patch that I posted, I cannot commit until tonight or tomorrow morning.

Since my laptop was stolen, I have no means to update my tree nor commit anything when I am on the road - my work laptop does not give me administrator rights:-(

Paul
Comment 18 Paul Thomas 2008-09-17 22:25:17 UTC
Subject: Bug 37274

Author: pault
Date: Wed Sep 17 22:23:51 2008
New Revision: 140434

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140434
Log:
2008-09-18  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/37274
	PR fortran/36374
	* module.c (check_for_ambiguous): New function to test loaded
	symbol for ambiguity with fixup symbol.
	(read_module): Call check_for_ambiguous.
	(write_symtree): Do not write the symtree for symbols coming
	from an interface body.

	PR fortran/36374
	* resolve.c (count_specific_procs ): New function to count the
	number of specific procedures with the same name as the generic
	and emit appropriate errors for and actual argument reference.
	(resolve_assumed_size_actual): Add new argument no_formal_args.
	Correct logic around passing generic procedures as arguments.
	Call count_specific_procs from two locations.
	(resolve_function): Evaluate and pass no_formal_args.
	(resolve call): The same and clean up a bit by using csym more
	widely.

	PR fortran/36454
	* symbol.c (gfc_add_access): Access can be updated if use
	associated and not private.

2008-09-18  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/37274
	* gfortran.dg/used_types_22.f90: New test.
	* gfortran.dg/used_types_23.f90: New test.

	PR fortran/36374
	* gfortran.dg/generic_17.f90: New test.
	* gfortran.dg/ambiguous_specific_2.f90: New test.
	* gfortran.dg/generic_actual_arg.f90: Add test for case that is
	not ambiguous.

	PR fortran/36454
	* gfortran.dg/access_spec_3.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/access_spec_3.f90
    trunk/gcc/testsuite/gfortran.dg/ambiguous_specific_2.f90
    trunk/gcc/testsuite/gfortran.dg/generic_17.f90
    trunk/gcc/testsuite/gfortran.dg/used_types_22.f90
    trunk/gcc/testsuite/gfortran.dg/used_types_23.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/module.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/symbol.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/generic_actual_arg.f90

Comment 19 Paul Thomas 2008-09-17 22:30:22 UTC
Fixed on trunk

Thanks for the report

Paul
Comment 20 Paul Thomas 2008-09-23 06:27:16 UTC
Subject: Bug 37274

Author: pault
Date: Tue Sep 23 06:25:39 2008
New Revision: 140578

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140578
Log:
2008-09-23  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/37274
	PR fortran/36374
	* module.c (check_for_ambiguous): New function to test loaded
	symbol for ambiguity with fixup symbol.
	(read_module): Call check_for_ambiguous.
	(write_symtree): Do not write the symtree for symbols coming
	from an interface body.

	PR fortran/36374
	* resolve.c (count_specific_procs ): New function to count the
	number of specific procedures with the same name as the generic
	and emit appropriate errors for and actual argument reference.
	(resolve_assumed_size_actual): Add new argument no_formal_args.
	Correct logic around passing generic procedures as arguments.
	Call count_specific_procs from two locations.
	(resolve_function): Evaluate and pass no_formal_args.
	(resolve call): The same and clean up a bit by using csym more
	widely.

	PR fortran/36454
	* symbol.c (gfc_add_access): Access can be updated if use
	associated and not private.

2008-09-23  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/37274
	* gfortran.dg/used_types_22.f90: New test.
	* gfortran.dg/used_types_23.f90: New test.

	PR fortran/36374
	* gfortran.dg/generic_17.f90: New test.
	* gfortran.dg/ambiguous_specific_2.f90: New test.
	* gfortran.dg/generic_actual_arg.f90: Add test for case that is
	not ambiguous.

	PR fortran/36454
	* gfortran.dg/access_spec_3.f90: New test.

Added:
    branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/access_spec_3.f90
    branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/ambiguous_specific_2.f90
    branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/generic_17.f90
    branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/used_types_22.f90
    branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/used_types_23.f90
Modified:
    branches/gcc-4_3-branch/gcc/fortran/ChangeLog
    branches/gcc-4_3-branch/gcc/fortran/module.c
    branches/gcc-4_3-branch/gcc/fortran/resolve.c
    branches/gcc-4_3-branch/gcc/fortran/symbol.c
    branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/generic_actual_arg.f90

Comment 21 Paul Thomas 2008-09-23 06:28:13 UTC
Fixed on trunk and 4.3.

Thanks for the report

Paul

PS The original problem was not present in 4.3 but the reduced version was.