Bug 32727

Summary: [4.3 regression] bogus error: Error: Symbol 'sort' referenced at (1) not found in module 'util'
Product: gcc Reporter: Joost VandeVondele <Joost.VandeVondele>
Component: fortranAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: normal CC: dfranke, gcc-bugs, hjl.tools, P.Schaffnit, pault, tkoenig
Priority: P3 Keywords: rejects-valid
Version: 4.3.0   
Target Milestone: 4.3.0   
Host: Target:
Build: Known to work: 4.2.0
Known to fail: 4.3.0 Last reconfirmed:
Bug Depends on:    
Bug Blocks: 29975    
Attachments: testcase

Description Joost VandeVondele 2007-07-11 05:26:01 UTC
as discussed in PR 29975, with gcc version 4.3.0 20070710 (experimental) I get:

gfortran -c test.f90
test.f90:784.44:

  USE util,                            ONLY: sort
                                           1
Comment 1 Joost VandeVondele 2007-07-11 05:27:19 UTC
Created attachment 13883 [details]
testcase
Comment 2 Joost VandeVondele 2007-07-11 05:49:27 UTC
FYI, all three modules are needed to trigger the bug. 
Comment 3 Tobias Burnus 2007-07-11 06:38:22 UTC
Working: 2007-07-09-r126478
Failing: 2007-07-10-r126510

I believe it is due to the patch
 r126509 | pault | 2007-07-10 07:11:00 +0200 (Di, 10 Jul 2007) | 28 lines
        PR 32634 [...]
        * module.c (write_generic): Write the local name of the
        interface.
but I might be wrong and it is one of:
 r126486 | dfranke | 2007-07-09 16:56:49 +0200 (Mon, 09 Jul 2007) | 14 lines
 r126493 | kargl | 2007-07-09 21:41:37 +0200 (Mon, 09 Jul 2007) | 6 lines
 r126496 | fxcoudert | 2007-07-10 00:00:52 +0200 (Tue, 10 Jul 2007) | 6 lines

The error message is:

  USE util,                            ONLY: sort
                                           1
Error: Symbol 'sort' referenced at (1) not found in module 'util'


Reduced test case:

MODULE kinds
  INTEGER, PARAMETER :: dp = SELECTED_REAL_KIND ( 14, 200 )
END MODULE kinds

MODULE util
  USE kinds,                           ONLY: dp
  INTERFACE sort
     MODULE PROCEDURE sort2
  END INTERFACE
CONTAINS
  SUBROUTINE sort2 ( )
  END SUBROUTINE sort2
END MODULE util

MODULE graphcon
  USE util,                            ONLY: sort
END MODULE graphcon
Comment 4 Daniel Franke 2007-07-11 08:33:57 UTC
No error up to and including r126496. That leaves only Paul's patch ...
Comment 5 Paul Thomas 2007-07-12 04:58:08 UTC
(In reply to comment #4)
> No error up to and including r126496. That leaves only Paul's patch ...
> 
Daniel,

Could you please revert r126496 and re-open the PR? - I can do nothing about it for 10 days or more.

Cheers

Paul
Comment 6 Paul Thomas 2007-07-12 06:22:29 UTC
(In reply to comment #5)

Daniel,

Hmmm!  Cancel that - I'll have a slot this evening where I can either fix it or revert it myself.  Just leave it to me but, I'll let you know if I am unable to do the business.

Paul - who is run off his feet but wants to fix those bugs...
Comment 7 Daniel Franke 2007-07-12 06:31:27 UTC
Subject: Bug 32727

Author: dfranke
Date: Thu Jul 12 06:31:12 2007
New Revision: 126572

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126572
Log:
2007-07-12  Daniel Franke  <franke.daniel@gmail.com>

        PR fortran/32634
        PR fortran/32727
        * module.c: Reverted Paul's patch from 2007-07-10.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/module.c

Comment 8 Daniel Franke 2007-07-12 06:36:27 UTC
Sorry, too late :(
Comment 9 Joost VandeVondele 2007-07-12 06:57:45 UTC
(In reply to comment #8)
> Sorry, too late :(

Fine with me :-), I can give gfortran another round of testing today... thanks

BTW, if you revert a patch, you should add the testcase that is the reason it. To avoid regressing again if the patch gets re-applied. Similarly, you should xfail the other testcase that now fails.
Comment 10 Daniel Franke 2007-07-12 07:27:29 UTC
> BTW, if you revert a patch, you should add the testcase that is the reason
> it. To avoid regressing again if the patch gets re-applied. Similarly, you
> should xfail the other testcase that now fails.

Joost,

good point. I thought about XFAIL, but then again, probably nobody will notice that there's something wrong since it's expected to fail. Hence I concluded that it would be preferable to have people asking about a testsuite failure twice a day then to hide the problem it in an xfail :)

However, if Paul does find the time today, I'm positive that he will set it right -- otherwise I will implement your suggestion tomorrow.
Comment 11 Tobias Burnus 2007-07-12 17:39:52 UTC
*** Bug 32741 has been marked as a duplicate of this bug. ***
Comment 12 Paul Thomas 2007-07-12 20:05:12 UTC
Subject: Bug 32727

Author: pault
Date: Thu Jul 12 20:04:59 2007
New Revision: 126600

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

	PR fortran/32634
	PR fortran/32727
	* module.c (write_generic): Restore patch of 2007-07-10 and use
	symbol name if there are no use names. 

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

	PR fortran/32727
	* gfortran.dg/interface_17.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/interface_17.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/module.c
    trunk/gcc/testsuite/ChangeLog

Comment 13 Paul Thomas 2007-07-12 20:26:09 UTC
Thanks for the very prompt report.

I would use your cp2k testcase but it does not compile on Cygwin - it runs out of memory during compilation. When I have a moment, I'll break itup.

Fixed on trunk

Paul
Comment 14 Joost VandeVondele 2007-07-13 07:14:27 UTC
(In reply to comment #13)
> I would use your cp2k testcase but it does not compile on Cygwin - it runs out
> of memory during compilation. When I have a moment, I'll break itup.

yes, it can be trivially split after every module, and compiled in that order. The other option is to check (a fixed version) out from cvs. See 
http://cp2k.berlios.de/download.html. That might initially be a few minutes more work to setup, but has the advantage that make -j X speeds up testing and that miscompilations can be more easily found.