Syntax check for IMPLICIT statement

James Van Buskirk

unread,

Apr 27, 2008, 7:22:05 PM4/27/08

to

In attempting to create a digestible version of a program that gives
gfortran an ICE and causes incorrect output for ifort, the critical
factor for both seems to be a line such as:

implicit character(len=*,kind=kind('A')) (Q)

In the sense that if the LEN is changed to 3 both ifort and gfortran
get happy with the code. Is this syntactically incorrect or simply
obscure enough that it didn't get sufficient testing on either
compiler?

C:\gfortran\clf\startest>type startest.f90
module mod
implicit character(len=*,kind=kind('A')) (Q)
parameter(Q1 = 'Test Me!')
parameter(Q2 = 'Test Me Too!')
contains
subroutine sub(Q3)
write(*,*) '#'//Q3//'#'
end subroutine sub
end module mod

program startest
use mod
implicit none
write(*,*) '#'//Q1//'#'
write(*,*) '#'//Q2//'#'
call sub('Test Me More!')
end program startest

C:\gfortran\clf\startest>gfortran startest.f90 -o startest

C:\gfortran\clf\startest>startest
#Test Me!#
#Test Me Too!#
#Test Me More!#

C:\gfortran\clf\startest>ifort startest.f90 -o startest
Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 9.1
Build 20061104
Copyright (C) 1985-2006 Intel Corporation. All rights reserved.

-out:startest.exe
-subsystem:console
startest.obj

C:\gfortran\clf\startest>startest
#Test Me!#
#Test Me Too!#
##

As you can see, this program is capable of reproducing the ifort
error but I haven't been able to make a small program that
reproduces the gfortran ICE.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

glen herrmannsfeldt

unread,

Apr 27, 2008, 7:46:23 PM4/27/08

to

James Van Buskirk wrote:

> In attempting to create a digestible version of a program that gives
> gfortran an ICE and causes incorrect output for ifort, the critical
> factor for both seems to be a line such as:

> implicit character(len=*,kind=kind('A')) (Q)

> In the sense that if the LEN is changed to 3 both ifort and gfortran
> get happy with the code. Is this syntactically incorrect or simply
> obscure enough that it didn't get sufficient testing on either
> compiler?

It is an interesting case. Since len=* can only be used in a
restricted set of cases, such variables would have to be used
in those cases. Still, I don't see any reason why it couldn't
work for those cases.

-- glen

Michael Metcalf

unread,

Apr 27, 2008, 7:42:29 PM4/27/08

to

"James Van Buskirk" <not_...@comcast.net> wrote in message
news:wpmdnYLdJ7wLl4jV...@comcast.com...

> In attempting to create a digestible version of a program that gives
> gfortran an ICE and causes incorrect output for ifort, the critical
> factor for both seems to be a line such as:
>
> implicit character(len=*,kind=kind('A')) (Q)
>

"For a scalar named constant or for a dummy argument ... a len-value may be
specified as an asterisk" ("Fortran 95/2003 Explained", Section 7.13).

HTH,

Mike Metcalf

glen herrmannsfeldt

unread,

Apr 27, 2008, 9:45:16 PM4/27/08

to

Michael Metcalf wrote:

Even so, it shouldn't ICE.

Still, I don't see, as James seems to believe, that dummy arguments and
named constants (also, external functions) can't be done through
IMPLICIT. It might be bad style, but is it illegal?

Does it only fail if used in a MODULE?

-- glen

James Van Buskirk

unread,

Apr 27, 2008, 11:15:11 PM4/27/08

to

"James Van Buskirk" <not_...@comcast.net> wrote in message
news:wpmdnYLdJ7wLl4jV...@comcast.com...

> As you can see, this program is capable of reproducing the ifort

> error but I haven't been able to make a small program that
> reproduces the gfortran ICE.

I still haven't been able to distill the above-mentioned ICE, but
here's a pretty small one:

C:\gfortran\clf\startest>type bug1.f90
module bug1
use ISO_C_BINDING
implicit none
contains
subroutine sub1(x)
type(C_PTR) x
write(*,'(z16.16)') transfer(x,0_C_INTPTR_T)
end subroutine sub1
subroutine sub2(x)
type(C_FUNPTR) x
write(*,'(z16.16)') transfer(x,0_C_INTPTR_T)
end subroutine sub2
end module bug1

program test
use bug1
implicit none
call sub1(transfer(7_C_INTPTR_T,C_NULL_PTR))
call sub2(transfer(7_C_INTPTR_T,C_NULL_FUNPTR))
end program test

C:\gfortran\clf\startest>gfortran bug1.f90 -obug1
bug1.f90:7: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

What seems to be getting gfortran down is the TRANSFERs in
the actual arguments. Switching to C_LOC for the invocation
of sub1 fixes that call up, but for sub2 you have to go all
the way to a temporary variable to prevent ICE:

C:\gfortran\clf\startest>type bug1a.f90
module bug1
use ISO_C_BINDING
implicit none
contains
subroutine sub1(x)
type(C_PTR) x
write(*,'(z16.16)') transfer(x,0_C_INTPTR_T)
end subroutine sub1
subroutine sub2(x)
type(C_FUNPTR) x
write(*,'(z16.16)') transfer(x,0_C_INTPTR_T)
end subroutine sub2
subroutine sub3() bind(C)
end subroutine sub3
end module bug1

program test
use bug1
implicit none
integer, target :: i
type(C_FUNPTR) p

p = C_FUNLOC(sub3)
call sub1(C_LOC(i))
call sub2(C_FUNLOC(sub3)) ! Causes ICE
call sub2(p) ! No ICE
end program test

C:\gfortran\clf\startest>gfortran bug1a.f90 -obug1a
bug1a.f90: In function 'test':
bug1a.f90:25: internal compiler error: in expand_expr_addr_expr_1, at
expr.c:680
3
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

James Van Buskirk

unread,

Apr 28, 2008, 1:11:09 AM4/28/08

to

"James Van Buskirk" <not_...@comcast.net> wrote in message

news:2rOdnebmkc-n3IjV...@comcast.com...

> I still haven't been able to distill the above-mentioned ICE, but
> here's a pretty small one:

I still haven't gotten to that one, but here is one that was hard
to isolate:

C:\gfortran\clf\startest>type bug2.f90
module mod1
use ISO_C_BINDING, only: p => C_PTR
use ISO_C_BINDING, only: C_INTPTR_T
implicit none
private
public sub
interface sub
module procedure sub1
end interface sub
contains
subroutine sub1(x)
type(p) x

write(*,'(a,z16.16)') 'In sub1, x = ', transfer(x,0_C_INTPTR_T)
end subroutine sub1
end module mod1

module mod2
use ISO_C_BINDING, only: p => C_FUNPTR
use ISO_C_BINDING, only: C_INTPTR_T
implicit none
private
public sub
interface sub
module procedure sub1
end interface sub
contains
subroutine sub1(x)
type(p) x

write(*,'(a,z16.16)') 'In sub1, x = ', transfer(x,0_C_INTPTR_T)
end subroutine sub1
end module mod2

module bug2
use ISO_C_BINDING
use mod1
use mod2
implicit none
interface sub
module procedure sub2
end interface sub
contains
subroutine sub2(x)
character(*) x

write(*,'(a,a)') 'In sub2, x = ', x
end subroutine sub2
subroutine sub4() bind(C)
end subroutine sub4
end module bug2

program test
use bug2

implicit none
integer, target :: i

type(C_FUNPTR) fp

call sub(C_LOC(i))
call sub('Hello')
fp = C_FUNLOC(sub4)
call sub(fp)
end program test

C:\gfortran\clf\startest>gfortran bug2.f90 -obug2
bug2.f90:37.11:

use mod1
1
Warning: Although not referenced, 'sub' at (1) has ambiguous interfaces
bug2.f90:54.11:

use bug2
1
Error: Ambiguous interfaces 'sub1' and 'sub1' in generic interface 'sub' at
(1)

It seems to require that the particular sub1 that takes a type(C_PTR)
dummy and the one that takes a type(C_FUNPTR) dummy are used to
make instances of the same generic subroutine in their own modules,
and then the two generics are conbined in the another module.
The problem doesn't show if all subroutines are defined in the
same module and used there to make the generic in one step. Also
other types don't collide destructively like these two do.

James Van Buskirk

unread,

Apr 28, 2008, 2:32:40 AM4/28/08

to

"James Van Buskirk" <not_...@comcast.net> wrote in message

news:oa-dnXRJnLb6wYjV...@comcast.com...

> I still haven't gotten to that one, but here is one that was hard
> to isolate:

Still haven't made it to the mythic ICE but I have another stumbling
block:

C:\gfortran\clf\startest>type bug3.f90
program bug3
use ISO_C_BINDING, only: C_INTPTR_T, C_NULL_PTR, C_NULL_FUNPTR
use ISO_C_BINDING, only: C_PTR, C_LOC
implicit none
type(C_PTR) p1
integer, target :: i1

p1 = C_LOC(i1)
write(*,'(a,z16.16)') 'p1 = ', transfer(p1,0_C_INTPTR_T)
end program bug3

C:\gfortran\clf\startest>gfortran bug3.f90 -obug3
bug3.f90:8.8:

p1 = C_LOC(i1)
1
Error: Can't convert TYPE(_gfortran_iso_c_binding_c_ptr) to TYPE(c_ptr) at
(1)

Do I just have a bad build or is everyone else seeing all this stuff?

James Van Buskirk

unread,

Apr 28, 2008, 3:10:52 AM4/28/08

to

"James Van Buskirk" <not_...@comcast.net> wrote in message

news:w8GdnfQgK-Ic8ojV...@comcast.com...

> Still haven't made it to the mythic ICE but I have another stumbling
> block:

At last I have attained that bug which so many of its brethren have
sacrificed their lives to conceal:

C:\gfortran\clf\startest>type bug4a.f90
module mykinds
implicit none
integer, parameter :: ck1 = kind('x')
end module mykinds

module mergetest_c1
use mykinds
implicit character(len=*,kind=ck1) (Q)
private
public mergetest
interface mergetest
module procedure mergetest_template
end interface mergetest
contains
subroutine mergetest_template(Qtsource, Qfsource)
write(*,'(a,1x,a)') Qtsource, Qfsource
end subroutine mergetest_template
end module mergetest_c1

program bug4
use mykinds
use mergetest_c1
implicit none

call mergetest(ck1_'Hello', ck1_'world')
end program bug4

C:\gfortran\clf\startest>gfortran bug4a.f90 -obug4a
bug4a.f90:12: internal compiler error: in create_function_arglist, at
fortran/tr
ans-decl.c:1488

Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

GAME OVER (for now...)

Janne Blomqvist

unread,

Apr 28, 2008, 3:28:49 AM4/28/08

to

On 2008-04-28, James Van Buskirk <not_...@comcast.net> wrote:
> Do I just have a bad build or is everyone else seeing all this stuff?

I think few people are as eager as you in exploring all the dark
corners of the F2003 standard. ;-)

Thanks, and keep up the good work!

--
Janne Blomqvist

Herman D. Knoble

unread,

Apr 28, 2008, 7:44:21 AM4/28/08

to

On Sun, 27 Apr 2008 17:22:05 -0600, "James Van Buskirk" <not_...@comcast.net> wrote:

Skip Knoble

Herman D. Knoble

unread,

Apr 28, 2008, 7:52:59 AM4/28/08

to

On Mon, 28 Apr 2008 00:32:40 -0600, "James Van Buskirk" <not_...@comcast.net> wrote:

This one works correctly using g95.
Skip

Herman D. Knoble

unread,

Apr 28, 2008, 7:55:29 AM4/28/08

to

On Mon, 28 Apr 2008 01:10:52 -0600, "James Van Buskirk" <not_...@comcast.net> wrote:

This one works correctly using g95

Skip

Herman D. Knoble

unread,

Apr 28, 2008, 7:57:06 AM4/28/08

to

On Sun, 27 Apr 2008 21:15:11 -0600, "James Van Buskirk" <not_...@comcast.net> wrote:

This one fails using g95

Skip

Steve Lionel

unread,

Apr 28, 2008, 12:01:13 PM4/28/08

to

On Sun, 27 Apr 2008 17:22:05 -0600, "James Van Buskirk"
<not_...@comcast.net> wrote:

>In attempting to create a digestible version of a program that gives
>gfortran an ICE and causes incorrect output for ifort, the critical
>factor for both seems to be a line such as:
>
> implicit character(len=*,kind=kind('A')) (Q)

I have reported this to the developers - thanks.
--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://support.intel.com/support/performancetools/fortran
My Fortran blog
http://www.intel.com/software/drfortran