Fun with renames
James Van Buskirk
module m
implicit none
type t
integer i
end type t
end module m
module n
use m, only: a=>t
implicit none
private
public a
end module n
module oh
use n
use n, only: b=>a
implicit none
private
public a, b
end module oh
C:\gfortran\clf\opengl>gfortran -c bug1.f90
bug1.f90:20.11:
public a, b
1
Error: Symbol 'a' at (1) has no IMPLICIT type
C:\gfortran\clf\opengl>gfortran -v
Built by Equation Solution <http://www.Equation.com>.
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=c:/gcc_equation/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/
lto-wrapper.exe
Target: x86_64-w64-mingw32
Thread model: win32
gcc version 4.6.0 20101218 (experimental) (GCC)
Maybe it's getting so late that even the compiler is getting tired...
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
Steve Lionel
I noted with interest that Intel Fortran gives pretty much the same error:
c:\Projects>ifort -c rename.f90
Intel(R) Visual Fortran Compiler XE for applications running on IA-32,
Version 12.0.1.127 Build 20101116
Copyright (C) 1985-2010 Intel Corporation. All rights reserved.
rename.f90(16): remark #6536: All symbols from this module are already
visible due to another USE; the ONLY clause will have no effect. Rename
clauses, if any,
will be honored. [N]
use n
-------^
rename.f90(20): error #6404: This name does not have a type, and must
have an explicit type. [A]
public a, b
----------^
How likely is it that both compilers have the same bug? In this case,
not very. It's not a bug.
Here's what the standard (F2008) here has to say:
4 7 An accessible entity in the referenced module has one or more
local identifi ers. These identifi ers are
5 the identfii er of the entity in the referenced module if that
identi fier appears as an only-use-name or as the
6 de fined-operator of a generic-spec in any only for that module,
7 each of the local-names or local-de fined-operators that the entity
is given in any rename for that module,
8 and
9 the identi fier of the entity in the referenced module if that
identifi er does not appear as a use-name or
10 use-de fined-operator in any rename for that module.
The key words here are in lines 9 and 10: "if that identifier does not
appear as a use-name or use-defined-operator in any rename for that module."
You probably thought, as I did initially, that both the original name A
and the rename B were local identifiers for the same entity, but the
standard says that if the use-name (A in this case) is in *any* rename
for that module, then that use-name is NOT a local identifier for the
entity.
Therefore, both gfortran and Intel Fortran are correct in complaining
that identifier A has no type. I suppose one might quibble a bit with
the wording of the Intel diagnostic 6536 - while the ONLY is indeed
ignored, the rename part of the ONLY is not - but I think the intent is
clear.
--
Steve Lionel
Developer Products Division
Intel Corporation
Merrimack, NH
For email address, replace "invalid" with "com"
User communities for Intel Software Development Products
http://software.intel.com/en-us/forums/
Intel Software Development Products Support
http://software.intel.com/sites/support/
My Fortran blog
http://www.intel.com/software/drfortran
Refer to http://software.intel.com/en-us/articles/optimization-notice
for more information regarding performance and optimization choices in
Intel software products.
glen herrmannsfeldt
(snip)
> Here's what the standard (F2008) here has to say:
> 4 7 An accessible entity in the referenced module has one or more
> local identifi^Lers. These identifi^Lers are
(snip)
Could you post again without control characters in it?
It seems to have control-L and control-O which really confuse
my news reader. In the line above, there are ^L between the i and e
in identifiers, both times.
-- glen
James Van Buskirk
news:8oeoes...@mid.individual.net...
> On 12/26/2010 1:23 AM, James Van Buskirk wrote:
>> C:\gfortran\clf\opengl>gfortran -c bug1.f90
>> bug1.f90:20.11:
>> public a, b
>> 1
>> Error: Symbol 'a' at (1) has no IMPLICIT type
> I noted with interest that Intel Fortran gives pretty much the same error:
Since this goes way back to Boxing Day, let's review the issue and a
couple of workarounds:
C:\gfortran\clf\opengl>ifort -c bug1.f90
Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 9.1
Build 20061104
Copyright (C) 1985-2006 Intel Corporation. All rights reserved.
bug1.f90(20) : Error: This name does not have a type, and must have an
explicit
type. [A]
public a, b
----------^
compilation aborted for bug1.f90 (code 1)
C:\gfortran\clf\opengl>type bug1a.f90
module m
implicit none
type t
integer i
end type t
end module m
module n
use m, only: a=>t
implicit none
private
public a
end module n
module oh
use n, only: a
use n, only: b=>a
implicit none
private
public a, b
end module oh
C:\gfortran\clf\opengl>gfortran -c bug1a.f90
C:\gfortran\clf\opengl>ifort -c bug1a.f90
Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 9.1
Build 20061104
Copyright (C) 1985-2006 Intel Corporation. All rights reserved.
C:\gfortran\clf\opengl>type bug1b.f90
module m
implicit none
type t
integer i
end type t
end module m
module n
use m, only: a=>t
implicit none
private
public a
end module n
module helper
use n
end module helper
module oh
use helper
use n
use n, only: b=>a
implicit none
private
public a, b
end module oh
C:\gfortran\clf\opengl>gfortran -c bug1b.f90
bug1b.f90:25.11:
public a, b
1
Error: Symbol 'a' at (1) has no IMPLICIT type
C:\gfortran\clf\opengl>ifort -c bug1b.f90
Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 9.1
Build 20061104
Copyright (C) 1985-2006 Intel Corporation. All rights reserved.
C:\gfortran\clf\opengl>
Since the compilers have lost their unanimity, we may ask: which
compiler is wrong now? Well, I think the answer is gfortran
because in this last case identifier a should come through OK from
module helper.
Reading the passage you quoted several times I guess it means that
if you have a bunch of USE statements for one module, the way to
interpret them is to collect all the USE statements into one big USE
statement which has an ONLY clause if all USE statements for that
module have ONLY clauses and expand any <identifier> in any only
to <identifier> => <identifier>. So you have to look at all the
USE statements for a given module to see what any one of them
means if that one USE statement has no ONLY clause. That's kind of
a mind-bending rule, but by this rule bug1.f90 is indeed faulty,
but bug1a.f90 and bug1b.f90 (that gfortran rejects) should be OK.
How often can one download a trial version of ifort? From time to
time I want to find out if some code I'm trying out will work on it,
for example the test cases at
http://groups.google.com/group/comp.lang.fortran/msg/9a6e79b9143568cb?hl=en
or the program at
http://home.comcast.net/~kmbtib/Fortran_stuff/example2.zip (64-bit only)
but since Intel changed their pricing schedule from 'pay when you
need an upgrade' to 'pay every year' I can't afford to keep current
and I never know whether my code is going to trip up ifort as so
often before.
Steve Lionel
> Could you post again without control characters in it?
>
> It seems to have control-L and control-O which really confuse
> my news reader. In the line above, there are ^L between the i and e
> in identifiers, both times.
This was pasted from the PDF of the draft F2008, and yes, it did paste
with control characters where there are links to other parts of the
document. Here it is in text form.
4 7 An accessible entity in the referenced module has one or more local
identifiers. These identifiers are
5 the identifier of the entity in the referenced module if that
identifier appears as an only-use-name or as the
6 defined-operator of a generic-spec in any only for that module,
7 each of the local-names or local-defined-operators that the entity is
given in any rename for that module,
8 and
9 the identifier of the entity in the referenced module if that
identifier does not appear as a use-name or
10 use-defined-operator in any rename for that module.
Steve Lionel
> Since the compilers have lost their unanimity, we may ask: which
> compiler is wrong now? Well, I think the answer is gfortran
> because in this last case identifier a should come through OK from
> module helper.
I agree.
> Reading the passage you quoted several times I guess it means that
> if you have a bunch of USE statements for one module, the way to
> interpret them is to collect all the USE statements into one big USE
> statement which has an ONLY clause if all USE statements for that
> module have ONLY clauses and expand any<identifier> in any only
> to<identifier> => <identifier>.
Well, the way I would look at it is:
1. If any of the USE statements for a given module omits an ONLY clause,
then any other ONLY clause for that module is ignored. This makes a lot
of sense, really.
2. If any of the USE statements for a given module has a rename clause,
then the use-names from those rename clauses are not accessible. You can
treat it as if it was a single USE with the collection of renames.
> So you have to look at all the
> USE statements for a given module to see what any one of them
> means if that one USE statement has no ONLY clause. That's kind of
> a mind-bending rule, but by this rule bug1.f90 is indeed faulty,
> but bug1a.f90 and bug1b.f90 (that gfortran rejects) should be OK.
I agree that bug1a and bug1b are ok.
> How often can one download a trial version of ifort?
If you are using Linux, you can download the free non-commercial version
which is good for a year of updates. But you're using Windows. As for
the trial versions, I think the list of email addresses gets reset for
each new release, but I'm sure you can work out how to deal with that,
if all you're doing is testing.
Steve Lionel
Grr - still missed parts on the paste. Let's try again.
This is from 11.2.2 in F2008, 11.2.1 in F2003.
4 An accessible entity in the referenced module has one or more local
identifiers. These identifiers are
5 - the identifier of the entity in the referenced module if that
identifier appears as an only-use-name or as the
6 defined-operator of a generic-spec in any only for that module,
7 - each of the local-names or local-defined-operators that the entity
is given in any rename for that module,
8 and
9 - the identifier of the entity in the referenced module if that
James Van Buskirk
> Well, the way I would look at it is:
> 1. If any of the USE statements for a given module omits an ONLY clause,
> then any other ONLY clause for that module is ignored. This makes a lot of
> sense, really.
> 2. If any of the USE statements for a given module has a rename clause,
> then the use-names from those rename clauses are not accessible. You can
> treat it as if it was a single USE with the collection of renames.
I think that the above interpretation has a lacuna:
C:\gfortran\clf\opengl>type bug1c.f90
module m
implicit none
type t
integer i
end type t
end module m
module n
use m, only: a=>t
implicit none
private
public a
end module n
module oh
use n
use n, only: b=>a
use n, only: a
implicit none
private
public a, b
end module oh
C:\gfortran\clf\opengl>gfortran -c bug1c.f90
C:\gfortran\clf\opengl>ifort /c bug1c.f90
Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 9.1
Build 20061104
Copyright (C) 1985-2006 Intel Corporation. All rights reserved.
bug1c.f90(16) : Warning: Only rename information from the ONLY qualifiers
for th
is external module will be processed since all entities from the external
module
have been declared public [N]
use n
-------^
bug1c.f90(21) : Error: This name does not have a type, and must have an
explicit
type. [A]
public a, b
----------^
compilation aborted for bug1c.f90 (code 1)
In this case I think a is covered under the first bullet as a use-
only name. Does ifort still reject this one?
Let's try another way:
C:\gfortran\clf\opengl>type bug1d.f90
module m
implicit none
type t
integer i
end type t
end module m
module n
use m, only: a=>t
implicit none
private
public a
end module n
module oh
use n
use n, only: b=>a, a=>a
implicit none
private
public a, b
end module oh
C:\gfortran\clf\opengl>gfortran -c bug1d.f90
C:\gfortran\clf\opengl>ifort /c bug1d.f90
Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 9.1
Build 20061104
Copyright (C) 1985-2006 Intel Corporation. All rights reserved.
C:\gfortran\clf\opengl>
In this case gfortran, ifort, and myself are of one opinion. Will
you make it unanimous?
Jerry DeLisle
>
> In this case gfortran, ifort, and myself are of one opinion. Will
> you make it unanimous?
>
James,
Once you get this all sorted out, could you make sure we get a bug report for
the cases that are bugs?
Cheers,
Jerry
James Van Buskirk
news:4D23DECF...@verizon.net...
> James,
One reason for discussing the issues here is that there is room for
more people to comment on the problem and Steve Lionel's remarks
were indeed very illuminating. He quoted this passage from N1830.pdf,
section 11.2.2 which is hard to convert to text with all the bullets
and ligatures:
"More than one USE statement for a given module may appear
in a specification part. If one of the USE statements is
without an ONLY option, all public entities in the module
are accessible. If all the USE statements have ONLY options,
only those entities in one or more of the only-lists are
accessible.
An accessible entity in the referenced module has one or
more local identifiers. These identifiers are
o the identifier of the entity in the referenced module
if that identifier appears as an only-use-name or as
the defined-operator of a generic-spec in any only for
that module,
o each of the local-names or local-defined-operators that
the entity is given in any rename for that module, and
o the identifier of the entity in the referenced module
if that identifier does not appear as a use-name or
use-defined-operator in any rename for that module."
And that showed gfortran to be correct in rejecting bug1.f90:
C:\gfortran\clf\opengl>type bug1.f90
module m
implicit none
type t
integer i
end type t
end module m
module n
use m, only: a=>t
implicit none
private
public a
end module n
module oh
use n
use n, only: b=>a
implicit none
private
public a, b
end module oh
C:\gfortran\clf\opengl>gfortran -c bug1.f90
bug1.f90:20.11:
public a, b
1
Error: Symbol 'a' at (1) has no IMPLICIT type
because identifier 'a' appears as a use-name in the rename b=>a
for module n, so it doesn't come through under its own name as it
would otherwise from the third bulleted clause above.
But Steve and I seemed to be in agreement that gfortran was
incorrect to reject bug1b.f90:
C:\gfortran\clf\opengl>type bug1b.f90
module m
implicit none
type t
integer i
end type t
end module m
module n
use m, only: a=>t
implicit none
private
public a
end module n
module helper
use n
end module helper
module oh
use helper
use n
use n, only: b=>a
implicit none
private
public a, b
end module oh
C:\gfortran\clf\opengl>gfortran -c bug1b.f90
bug1b.f90:25.11:
public a, b
1
Error: Symbol 'a' at (1) has no IMPLICIT type
In this case identifier 'a' didn't appear as a use-name in any
rename for module 'helper' so it should have made it through under
the first bulleted clause.
gfortran also has a different outcome from ifort in the case of
bug1c.f90:
C:\gfortran\clf\opengl>type bug1c.f90
module m
implicit none
type t
integer i
end type t
end module m
module n
use m, only: a=>t
implicit none
private
public a
end module n
module oh
use n
use n, only: b=>a
use n, only: a
implicit none
private
public a, b
end module oh
C:\gfortran\clf\opengl>ifort -c bug1c.f90
Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 9.1
Build 20061104
Copyright (C) 1985-2006 Intel Corporation. All rights reserved.
bug1c.f90(16) : Warning: Only rename information from the ONLY qualifiers
for th
is external module will be processed since all entities from the external
module
have been declared public [N]
use n
-------^
bug1c.f90(21) : Error: This name does not have a type, and must have an
explicit
type. [A]
public a, b
----------^
compilation aborted for bug1c.f90 (code 1)
In this case I think gfortran is correct in accepting my example
because identifier 'a' appears as an only-use-name in the line:
use n, only: a
so it should pass under the first bulleted clause above, but
Steve hasn't had time to confirm or refute my opinion as yet.
I'm not sure if ifort still rejects bug1c.f90 because the
version I have is very old.
My opinion therefore is that it is a problem that requires a
close reading of the standard and it seems that developing an
intiution for what identifiers are available requires testing
out ones first impressions and getting roughed up a bit as
happened to me. That's one of the reasons I post so many
examples: there really aren't convenient ways to express in
human language the concepts behind programming languages and
you have to make small examples to test your understanding
just as a baby learns by babbling and seeing how those around
him respond to it.
Oh, one more question for you, Jerry, because you seem to handle
I/O issues and work in Windows or at least Cygwin: in a Windows
application you don't get a console to start out with and I was
trying to make one with AllocConsole and in fact one appeared
and I could write to it via WriteConsole but I could get
write(*,*) or write(6,*) to write to it. In ifort supposedly
once you invoke AllocConsole you can issue WRITE statements to
it, but under gfortran:
C:\gfortran\clf\opengl2>type console.f90
module win
use ISO_C_BINDING
implicit none
private
integer, parameter, public :: BOOL = C_INT
integer, parameter, public :: DWORD = C_LONG
integer, parameter, public :: HANDLE = C_INTPTR_T
integer, parameter, public :: HINSTANCE = HANDLE
integer(BOOL), parameter, public :: BOOL_TRUE = 1
integer(DWORD), parameter, public :: GENERIC_READ =
int(Z'80000000',DWORD)
integer(DWORD), parameter, public :: GENERIC_WRITE =
int(Z'40000000',DWORD)
integer(DWORD), parameter, public :: FILE_SHARE_WRITE = &
int(Z'00000002',DWORD)
integer(DWORD), parameter, public :: OPEN_EXISTING = 3
integer(DWORD), parameter, public :: STD_OUTPUT_HANDLE = -11_DWORD
type, bind(C), public :: SECURITY_ATTRIBUTES_T
integer(DWORD) nLength
type(C_PTR) lpSecurityDescriptor
integer(BOOL) bInheritHandle
end type SECURITY_ATTRIBUTES_T
public WinSleep
interface
subroutine WinSleep(dwMilliseconds) bind(C,name='Sleep')
import
implicit none
!GCC$ ATTRIBUTES STDCALL :: WinSleep
integer(DWORD),value :: dwMilliseconds
end subroutine WinSleep
end interface
public AllocConsole
interface
function AllocConsole() bind(C,name='AllocConsole')
import
implicit none
!GCC$ ATTRIBUTES STDCALL :: AllocConsole
integer(BOOL) AllocConsole
end function AllocConsole
end interface
public CreateFile
interface
function CreateFile(lpFileName,dwDesiredAccess,dwSharedMode, &
lpSecurityAttributes,dwCreationDisposition,dwFlagsAndAttributes, &
hTemplateFile) bind(C,name='CreateFileA')
import
implicit none
!GCC$ ATTRIBUTES STDCALL :: CreateFile
integer(HANDLE) CreateFile
character(kind=C_CHAR) lpFileName(*)
integer(DWORD),value :: dwDesiredAccess
integer(DWORD),value :: dwSharedMode
type(SECURITY_ATTRIBUTES_T) lpSecurityAttributes
integer(DWORD),value :: dwCreationDisposition
integer(DWORD),value :: dwFlagsAndAttributes
integer(HANDLE),value :: hTemplateFile
end function CreateFile
end interface
public SetStdHandle
interface
function SetStdHandle(nStdHandle,hHandle) bind(C,name='SetStdHandle')
import
implicit none
!GCC$ ATTRIBUTES STDCALL :: SetStdHandle
integer(BOOL) SetStdHandle
integer(DWORD),value :: nStdHandle
integer(HANDLE),value :: hHandle
end function SetStdHandle
end interface
public WriteConsole
interface
function WriteConsole(hConsoleOutput,lpBuffer, &
nNumberOfCharsToWrite,nNumberOfCharsWritten, &
lpReserved) bind(C,name='WriteConsoleA')
import
implicit none
!GCC$ ATTRIBUTES STDCALL :: WriteConsole
integer(BOOL) WriteConsole
integer(HANDLE),value :: hConsoleOutput
character(kind=C_CHAR) lpBuffer(*)
integer(DWORD),value :: nNumberOfCharsToWrite
integer(DWORD) nNumberOfCharsWritten
type(C_PTR),value :: lpReserved
end function WriteConsole
end interface
end module win
recursive function WinMain(hInstance_,hPrevInstance,lpCmdLine, &
nCmdShow) bind(C, name='WinMain')
use win
use ISO_C_BINDING
implicit none
!GCC$ ATTRIBUTES STDCALL :: WinMain
integer(C_INT) WinMain
integer(HINSTANCE), value :: hInstance_
integer(C_INTPTR_T), value :: hPrevInstance
type(C_PTR), value :: lpCmdLine
integer(C_INT), value :: nCmdShow
integer(C_INT) result4
type(SECURITY_ATTRIBUTES_T) lpSecurityAttributes
integer(HANDLE) consoleHandle
integer(DWORD) nWritten
result4 = AllocConsole()
lpSecurityAttributes = SECURITY_ATTRIBUTES_T( &
nLength = int(C_SIZEOF(lpSecurityAttributes),DWORD), &
lpSecurityDescriptor = C_NULL_PTR, &
bInheritHandle = BOOL_TRUE)
consoleHandle = CreateFile('CONOUT$'//achar(0), &
ior(GENERIC_READ,GENERIC_WRITE),FILE_SHARE_WRITE, &
lpSecurityAttributes,OPEN_EXISTING,0_DWORD,0_HANDLE)
result4 = SetStdHandle(STD_OUTPUT_HANDLE,consoleHandle)
! WriteConsole works
!result4 = WriteConsole(consoleHandle,'In new console!'// &
! achar(13)//achar(10),17,nWritten,C_NULL_PTR)
write(6,*) 'In new console!'
call WinSleep(1000)
end function WinMain
C:\gfortran\clf\opengl2>gfortran -mwindows -fno-range-check
console.f90 -oconsol
e
C:\gfortran\clf\opengl2>console
At this point a console appears for 1 second but nothing gets
written to it. If the statement invoking WriteConsole is
uncommented the output from that statement does appear in the
console. You probably know better than anyone what I am
doing wrong in the above example.