Bug 34335 - [4.3 Regression] valid code rejected when reordering USE statements
[4.3 Regression] valid code rejected when reordering USE statements
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: fortran
4.3.0
: P3 normal
: ---
Assigned To: Paul Thomas
: rejects-valid
: 34339 (view as bug list)
Depends on:
Blocks: 32834 29975
  Show dependency treegraph
 
Reported: 2007-12-04 13:37 UTC by Janus Weil
Modified: 2007-12-06 07:06 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.2.1
Known to fail: 4.3.0
Last reconfirmed: 2007-12-05 15:18:19


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Janus Weil 2007-12-04 13:37:23 UTC
Consider the following piece of code:


module A
  type A_type
    real comp
  end type
end module A

module B
  use A
  private
  type(A_type) :: B_var
  public:: B_var
end module B

program C
  use B
  use A
  type(A_type):: A_var
end program C


This is rejected with the error message

  type(A_type):: A_var
             1
Error: Derived type 'a_type' at (1) is being used before it is defined

Please note that the error is only thrown under the condition that the USE statements in program C appear in the same order as shown above. When you exchange them and put "use A" first (or remove "use B"), then the error goes away. This makes me wonder if this bug is somehow related to PR33295.

Also the error only appears with the funny combination of PUBLIC and PRIVATE in module B. Admittedly, it looks a little strange and is not very useful, but nevertheless I think it's valid Fortran (someone correct me if I'm wrong).
Comment 1 Janus Weil 2007-12-04 13:44:46 UTC
The code above fails for recent trunk builds (rev. 130582) on i686-pc-linux-gnu, but is known to work for 4.2.1 as well as 4.3.0 rev. 127773 (from August 24, 2007).
Comment 2 Janus Weil 2007-12-04 14:55:39 UTC
The error also appears on x86_64. It must have been introduced somewhere between Nov. 23 and 26:
- rev. 130365 works
- rev. 130431 fails
Comment 3 Tobias Burnus 2007-12-04 19:07:28 UTC
Paul, do you have an idea? My (un)educated guess is that the fix for PR 33541
(patch to not import "y" when using "use foo; use foo, only: x => y") caused this.
Comment 4 Janus Weil 2007-12-04 21:16:31 UTC
(In reply to comment #3)
> Paul, do you have an idea? My (un)educated guess is that the fix for PR 33541
> (patch to not import "y" when using "use foo; use foo, only: x => y") caused
> this.

I don't think your guess is uneducated at all. I nailed the error down to revision 130395, which is Paul's fix for PR33541.
Comment 5 Tobias Burnus 2007-12-04 22:06:48 UTC
*** Bug 34339 has been marked as a duplicate of this bug. ***
Comment 6 Paul Thomas 2007-12-05 15:18:19 UTC
(In reply to comment #5)
> *** Bug 34339 has been marked as a duplicate of this bug. ***
> 

OK Thanks all - I'm onto it.

Paul
Comment 7 Paul Thomas 2007-12-06 06:14:11 UTC
Subject: Bug 34335

Author: pault
Date: Thu Dec  6 06:13:59 2007
New Revision: 130643

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130643
Log:
2007-12-06  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/34335
	* module.c (find_symbol): Do not return symtrees with unique
	names, which shows that they are private.

2007-12-06  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/34335
	* gfortran.dg/used_types_19.f90: New test.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/testsuite/ChangeLog

Comment 8 Paul Thomas 2007-12-06 06:14:52 UTC
Fixed on trunk

Paul
Comment 9 Tobias Burnus 2007-12-06 07:06:29 UTC
The actual commit is:
http://gcc.gnu.org/viewcvs?view=rev&revision=130642

Thanks for the fix!