Bug 36454 - too cautionous alias checking with renamed variables/types from modules (Error: ACCESS specification already specified)
Summary: too cautionous alias checking with renamed variables/types from modules (Erro...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Paul Thomas
URL:
Keywords: rejects-valid
Depends on:
Blocks: 32834
  Show dependency treegraph
 
Reported: 2008-06-06 21:42 UTC by Thomas Orgis
Modified: 2008-09-23 06:28 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.2.3 4.3.0 4.4.0
Last reconfirmed: 2008-09-06 18:02:24


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Orgis 2008-06-06 21:42:39 UTC
It seems that the standard (or at least the standard literature) is not clear on this one, but Sun and Intel compilers agree that it's good.
The problem we have is actually about a derived type that gets two different alias names in USE/ONLY statements. In the end, it should be treated as two different types but it is really one implementation.
It works the same with plain integers, so I use these for illustration.
Example program:

module base
	integer :: baseint
end module

module a
	use base, ONLY: aint => baseint
end module

module b
	use base, ONLY: bint => baseint
end module

module c
	use a
	use b
	private
	public :: aint, bint
end module

program user
	use c, ONLY: aint, bint

	aint = 3
	bint = 8
	write(*,*) aint
end program

gfortran (4.1, 4.2, 4.3), and incidentally also g95 (if that interests anyone;-) refuse this with:
 public :: aint, bint
                    1
Error: ACCESS specification at (1) was already specified

If you just remove the private/public stuff in module c, like that:

module c
	use a
	use b
end module

The code compiles fine and I get the expected output fromt the main program:

           8

...which is the value of baseint, set through bint and read through aint.
It feels like gfortran is too eager in error checking there on harmless code. I am not sure if this code is strictly Fortran90 conforming... but I read that a variable is allowed to have different aliases; just didn't find mentioning of one module making public several of these.
Comment 1 Thomas Orgis 2008-06-06 21:45:29 UTC
Oh, btw: I reckon that this is independent of host system, but for reference: I tested this on x86-64-linux (gfortran 4.1.2 or such) and x86-linux (4.2.3 and 4.3.0).
Comment 2 Tobias Burnus 2008-06-07 06:18:18 UTC
CONFIRM.
Paul, as out module.c expert, do you have an idea how to solve this?
Comment 3 Paul Thomas 2008-09-06 18:02:24 UTC
(In reply to comment #2)
> CONFIRM.
> Paul, as out module.c expert, do you have an idea how to solve this?
>
 
Yes, I have a fix - see the list, either tonight or tomorrow.

Cheers

Paul
Comment 4 Paul Thomas 2008-09-17 22:25:16 UTC
Subject: Bug 36454

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 5 Paul Thomas 2008-09-17 22:33:08 UTC
Fixed on trunk.

I'll wait a few days and fix on 4.3.

Thanks for the report

Paul
Comment 6 Paul Thomas 2008-09-23 06:27:16 UTC
Subject: Bug 36454

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 7 Paul Thomas 2008-09-23 06:28:51 UTC
Fixed on trunk and 4.3.

Thanks for the report

Paul