Trouble with Hollerith

James Van Buskirk

unread,

Dec 19, 2007, 3:21:17 PM12/19/07

to

I'm having some problems with the following program:

module mykinds
implicit none
integer, parameter :: ck = kind('x')
integer, parameter :: ik1 = selected_int_kind(2)
integer, parameter :: ik2 = selected_int_kind(4)
integer, parameter :: ik4 = selected_int_kind(9)
integer, parameter :: ik8 = selected_int_kind(18)
integer, parameter :: lk1 = ik1
integer, parameter :: lk2 = ik2
integer, parameter :: lk4 = ik4
integer, parameter :: lk8 = ik8
integer, parameter :: sp = selected_real_kind(6,30)
integer, parameter :: dp = selected_real_kind(15,300)
end module mykinds

module fun
use mykinds
implicit none
private
public f
interface f
module procedure f_c1, f_i1, f_i2, f_i4, f_i8
module procedure f_l1, f_l2, f_l4, f_l8
module procedure f_r4, f_r8, f_c4, f_c8
end interface f
contains
subroutine f_c1(x)
character(*,ck), intent(in) :: x

write(*,'(a,i0,a,i0,a)') 'Input was CHARACTER(',len(x), &
',',kind(x),')'
write(*,*) 'Value was "',x,'"'
end subroutine f_c1
subroutine f_i1(x)
integer(ik1), intent(in) :: x

write(*,'(a,i0,a)') 'Input was INTEGER(',kind(x),')'
write(*,*) 'Value was ', x
end subroutine f_i1
subroutine f_i2(x)
integer(ik2), intent(in) :: x

write(*,'(a,i0,a)') 'Input was INTEGER(',kind(x),')'
write(*,*) 'Value was ', x
end subroutine f_i2
subroutine f_i4(x)
integer(ik4), intent(in) :: x

write(*,'(a,i0,a)') 'Input was INTEGER(',kind(x),')'
write(*,*) 'Value was ', x
end subroutine f_i4
subroutine f_i8(x)
integer(ik8), intent(in) :: x

write(*,'(a,i0,a)') 'Input was INTEGER(',kind(x),')'
write(*,*) 'Value was ', x
end subroutine f_i8
subroutine f_l1(x)
logical(lk1), intent(in) :: x

write(*,'(a,i0,a)') 'Input was LOGICAL(',kind(x),')'
write(*,*) 'Value was ',trim(merge('.TRUE. ','.FALSE.',x))
end subroutine f_l1
subroutine f_l2(x)
logical(lk2), intent(in) :: x

write(*,'(a,i0,a)') 'Input was LOGICAL(',kind(x),')'
write(*,*) 'Value was ',trim(merge('.TRUE. ','.FALSE.',x))
end subroutine f_l2
subroutine f_l4(x)
logical(lk4), intent(in) :: x

write(*,'(a,i0,a)') 'Input was LOGICAL(',kind(x),')'
write(*,*) 'Value was ',trim(merge('.TRUE. ','.FALSE.',x))
end subroutine f_l4
subroutine f_l8(x)
logical(lk8), intent(in) :: x

write(*,'(a,i0,a)') 'Input was LOGICAL(',kind(x),')'
write(*,*) 'Value was ',trim(merge('.TRUE. ','.FALSE.',x))
end subroutine f_l8
subroutine f_r4(x)
real(sp), intent(in) :: x

write(*,'(a,i0,a)') 'Input was REAL(',kind(x),')'
write(*,*) 'Value was ', x
end subroutine f_r4
subroutine f_r8(x)
real(dp), intent(in) :: x

write(*,'(a,i0,a)') 'Input was REAL(',kind(x),')'
write(*,*) 'Value was ', x
end subroutine f_r8
subroutine f_c4(x)
complex(sp), intent(in) :: x

write(*,'(a,i0,a)') 'Input was COMPLEX(',kind(x),')'
write(*,*) 'Value was ', x
end subroutine f_c4
subroutine f_c8(x)
complex(dp), intent(in) :: x

write(*,'(a,i0,a)') 'Input was COMPLEX(',kind(x),')'
write(*,*) 'Value was ', x
end subroutine f_c8
end module fun

program hated
use fun
implicit none
character(4) stuff

! call f(4HUGLY)
call f('xyz')
call f(1_1)
call f(1_2)
call f(1_4)
call f(1_8)
call f(.TRUE._1)
call f(.TRUE._2)
call f(.TRUE._4)
call f(.TRUE._8)
call f(1.0_4)
call f(1.0_8)
call f((1.0_4,0.0_4))
call f((1.0_8,0.0_8))
if(.NOT.((.NOT..TRUE. .AND. 2).OR.(.TRUE. .AND. 2))) then
stuff = '@#$%'
read(stuff,100)
100 format(4HUGLY)
write(*,100)
else
write(*,*) 2.0**-3*5
end if
end program hated

Now, with ifort it compiles flawlessly:

C:\gfortran\clf\xor>ifort hated.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.

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

C:\gfortran\clf\xor>hated
Input was CHARACTER(3,1)
Value was "xyz"
Input was INTEGER(1)
Value was 1
Input was INTEGER(2)
Value was 1
Input was INTEGER(4)
Value was 1
Input was INTEGER(8)
Value was 1
Input was LOGICAL(1)
Value was .TRUE.
Input was LOGICAL(2)
Value was .TRUE.
Input was LOGICAL(4)
Value was .TRUE.
Input was LOGICAL(8)
Value was .TRUE.
Input was REAL(4)
Value was 1.000000
Input was REAL(8)
Value was 1.00000000000000
Input was COMPLEX(4)
Value was (1.000000,0.0000000E+00)
Input was COMPLEX(8)
Value was (1.00000000000000,0.000000000000000E+000)
@#$%

But gfortran seems to want to complain about it:

C:\gfortran\clf\xor>c:\gfortran\win64\bin\x86_64-pc-mingw32-gfortran
hated.f90 -
ohated
hated.f90:127.50:

if(.NOT.((.NOT..TRUE. .AND. 2).OR.(.TRUE. .AND. 2))) then
1
Error: Operands of logical operator '.and.' at (1) are LOGICAL(4)/INTEGER(4)

This seems to me to be in conflict with

http://gcc.gnu.org/onlinedocs/gfortran/Implicitly-convert-LOGICAL-and-INTEGER-values.html#Implicitly-convert-LOGICAL-and-INTEGER-values

which says that GNU Fortran allows the implicit conversion between
LOGICAL and INTEGER values. Also when the if...then...else stuff
is commented out so that both blocks are executed, we get an error

At line 129 of file hated.f90
Fortran runtime error: Constant string in input format
(4HUGLY)
^

from gfortran, whereas this syntax is supposed to be allowed, e.g.

http://en.wikipedia.org/wiki/Hollerith_constant

and then when the offending READ statement is commented out,
the last two lines of output are:

UGLY
0.62500000

contradicting the ifort results. Which compiler is right?
Also if the line

call f(4HUGLY)

is commented out, both compilers refuse to accept the code, even
though e.g.

http://gcc.gnu.org/onlinedocs/gfortran/Hollerith-constants-support.html#Hollerith-constants-support

says Hollerith constants are supported in function arguments.
Perhaps a member of the group with more experience in Hollerith
constants can explain these issues with clarity.

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

FX

unread,

Dec 19, 2007, 4:05:50 PM12/19/07

to

> hated.f90:127.50:
>
> if(.NOT.((.NOT..TRUE. .AND. 2).OR.(.TRUE. .AND. 2))) then
> 1
> Error: Operands of logical operator '.and.' at (1) are LOGICAL(4)/INTEGER(4)
>
> This seems to me to be in conflict with
>
> http://gcc.gnu.org/onlinedocs/gfortran/Implicitly-convert-LOGICAL-and-INTEGER-values.html#Implicitly-convert-LOGICAL-and-INTEGER-values

I think this is only true for assignments, ie you can assign a logical
value to an integer lhs and the other way around. The doc needs fixing.

--
FX

Richard Maine

unread,

Dec 19, 2007, 4:13:45 PM12/19/07

to

James Van Buskirk <not_...@comcast.net> wrote:
[much elided stuff]

> ...contradicting the ifort results. Which compiler is right?

Pretty much everything in the (elided) code is nonstandard, so the
question of which compiler is "right" is largely meaningless. I'm not
going to bother to comment on the wisdom of using such things. The code,
after all, looks a lot like an intentional exploration of the features,
which is a fine experiment to run.

I agree that it can be instructive to observe the different ways in
which different compilers handle these things, but I don't think you can
say that any of them are "right", just "different". I suppose I'm
sounding "politically correct" with that wording. So be it. :-)

> Also if the line
>
> call f(4HUGLY)
>
> is commented out, both compilers refuse to accept the code, even
> though e.g.
>
>
http://gcc.gnu.org/onlinedocs/gfortran/Hollerith-constants-support.html#
Hollerith-constants-support
>
> says Hollerith constants are supported in function arguments.

But it doesn't say anything about Holleriths in generic functions. Yes,
it makes a difference - a huge one. Of course, like everything else in
the elided code, this is nonstandard. Holleriths have never coexisted in
a standard with user generics. But even if one were to guess at
plausible extensions, I would not think that this would be on the list.
There are several things that are allowed for specific function
references, but are not allowed with generics. Of course, Hollerith
aren't on the list because of not being in the standard at all any more,
but it seems a pretty goof guess that they would be excluded from
generics anyway.

Holleriths are inherently about a type mismatch, putting character data
in a noncharacter variable (as character variables didn't exist then).
When Holleriths were in the language, a Hollerith actual argumentg could
match with any of several dummy argument types.

This doesn't fit well with the concept of generics, where type matching
is used to select the appropriate specific. I don't think you'd have any
luck at all trying to "sell" that one.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

Steve Lionel

unread,

Dec 19, 2007, 4:36:08 PM12/19/07

to

On Dec 19, 3:21 pm, "James Van Buskirk" <not_va...@comcast.net> wrote:

> if(.NOT.((.NOT..TRUE. .AND. 2).OR.(.TRUE. .AND. 2))) then
> 1
> Error: Operands of logical operator '.and.' at (1) are LOGICAL(4)/INTEGER(4)

Although the Intel compiler allows this (it is an extension dating
back at least to VAX FORTRAN V1 in 1978 if not earlier), this is a
VERY bad idea. The value of .TRUE. could be anything when converted
to integer, and different compilers use different values. I know you
were just trying things, but please don't write code like this for
real. I would not encourage gfortran to pick up this extension - I'm
lobbying to have it give a warning by default in ifort. If gfortran
wants to pick it up, please make it off by default (or at least a
default warning.)

> UGLY
> 0.62500000
>
> contradicting the ifort results. Which compiler is right?

Both. Neither. You have two consecutive operators, which is non-
standard. The interpretation of this is implementation-dependent.
ifort allows this but notes that operator precedence might give you
unexpected results. In fact, an identical example is used in the
ifort documentation. Here's what it says:

---
Ordinarily, the exponentiation operator would be evaluated first in
the following example. However, because Intel Fortran allows the
combination of the exponentiation and minus operators, the
exponentiation operator is not evaluated until the minus operator is
evaluated:

A**-B*C is evaluated as A**(-(B*C))
Note that the multiplication operator is evaluated first, since it
takes precedence over the minus operator.

When consecutive operators are used with constants, the unary plus or
minus before the constant is treated the same as any other operator.
This can produce unexpected results. In the following example, the
multiplication operator is evaluated first, since it takes precedence
over the minus operator:

X/-15.0*Y is evaluated as X/-(15.0*Y)
---

So gfortran is evaluating it as (2.0**(-3))*5 and ifort as 2.0**(-
(3*5))

I can't quite understand the gfortran choice, based on normal
precedence rules, but hey, it's an extension and it can do anything it
likes.

> Also if the line
>
> call f(4HUGLY)
>
> is commented out, both compilers refuse to accept the code, even
> though e.g.
>

> http://gcc.gnu.org/onlinedocs/gfortran/Hollerith-constants-support.ht...

>
> says Hollerith constants are supported in function arguments.
> Perhaps a member of the group with more experience in Hollerith
> constants can explain these issues with clarity.

The ifort documentation says:

---
If an actual argument is a Hollerith constant (for example, 4HABCD),
the corresponding dummy argument must have a numeric data type.
---

Now, this works as long as there isn't a generic involved. If there
is, ifort fails to resolve the generic, even if there is only one
match. I'll note that in your example there are many possible
matches, so one might expect an error about an ambiguous generic.

I guess I'd call it a bug that ifort doesn't resolve Hollerith
constants in generics, but, really!

Steve

Steve Lionel

unread,

Dec 19, 2007, 4:39:33 PM12/19/07

to

On Dec 19, 4:36 pm, Steve Lionel <steve.lio...@intel.com> wrote:

> I guess I'd call it a bug that ifort doesn't resolve Hollerith
> constants in generics, but, really!

I see that Richard and I were posting at the same time. I'm going to
go with his view that Holleriths don't participate in generic matching
if for no other reason that they don't have a type or kind.

Steve

Richard Maine

unread,

Dec 19, 2007, 5:02:48 PM12/19/07

to

Steve Lionel <steve....@intel.com> wrote:

> On Dec 19, 3:21 pm, "James Van Buskirk" <not_va...@comcast.net> wrote:
>
> > if(.NOT.((.NOT..TRUE. .AND. 2).OR.(.TRUE. .AND. 2))) then
> > 1
> > Error: Operands of logical operator '.and.' at (1) are LOGICAL(4)/INTEGER(4)
>
> Although the Intel compiler allows this (it is an extension dating
> back at least to VAX FORTRAN V1 in 1978 if not earlier), this is a
> VERY bad idea.

In addition to the reasons that Steve mentions, there is another bit of
nastiness burried in this kind of extension.

Although the standard doesn't define a "logical .and. integer"
operation, it allows the user to do so. If a compiler defines such an
operation as an extension, it can interact poorly with contradicting
user definitions.

The standard doesn't allow the user to override the standard intrinsic
operations. For example, the user can't redefine "logical .and.
logical". A compiler that implements "logical .and. integer" as an
extension would also have to allow user overriding of that in order to
be standard conforming. (Alternatively, the compiler could have a switch
to turn off the extension.) While that could be done, it introduces an
extra level of complication in that generic overrides would have
diffferent rules for standard operations as opposed to compiler
extension operations. Seems like there is good oportunity for bugs
there.

James Van Buskirk

unread,

Dec 19, 2007, 5:16:28 PM12/19/07

to

"Steve Lionel" <steve....@intel.com> wrote in message
news:478e6453-a708-4612...@i29g2000prf.googlegroups.com...

> I see that Richard and I were posting at the same time. I'm going to
> go with his view that Holleriths don't participate in generic matching
> if for no other reason that they don't have a type or kind.

C:\gfortran\clf\xor>type kindly.f90
! File: kindly.f90
! Public domain 2007 James Van Buskirk
program kindly
implicit none

write(*,*) kind(4HUGLY)
end program kindly
! End of file: kindly.f90

C:\gfortran\clf\xor>C:\gfortran\win64\bin\x86_64-pc-mingw32-gfortran
kindly.f90
-okindly
kindly.f90:6.21:

write(*,*) kind(4HUGLY)
1
Warning: Extension: Hollerith constant at (1)

C:\gfortran\clf\xor>kindly
1

C:\gfortran\clf\xor>ifort kindly.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.

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

C:\gfortran\clf\xor>kindly
4

Steve Lionel

unread,

Dec 19, 2007, 5:40:06 PM12/19/07

to

On Dec 19, 5:16 pm, "James Van Buskirk" <not_va...@comcast.net> wrote:

> implicit none
>
> write(*,*) kind(4HUGLY)
> end program kindly

> 4

The ifort manual sayeth:
---
Hollerith constants have no intrinsic data type. In most cases, the
default integer data type is assumed.
---

What would you expect:

print *, kind(10HABCDEFGHIJ)

to display?

The description of KIND says that the argument can be of "any
intrinsic type", but Hollerith constants have no intrinsic type. I
suppose one could argue that KIND(4HABCD) should give an error, but I
can't get too heated up about that one.

To paraphrase Monty Python, "this is an issue for laying down and
avoiding..."

Steve

John Harper

unread,

Dec 19, 2007, 6:58:31 PM12/19/07

to

In article <1i9ddcl.u9xxai1i4t3hfN%nos...@see.signature>,
Richard Maine <nos...@see.signature> wrote:
>
>but it seems a pretty goof guess ...

Does that get the c.l.f prize for the year's most entertaining typo?
You have only a few days to try and beat it :-)

-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john....@vuw.ac.nz phone (+64)(4)463 5662 fax (+64)(4)463 5045

FX

unread,

Dec 19, 2007, 7:07:24 PM12/19/07

to

> So gfortran is evaluating it as (2.0**(-3))*5 and ifort as 2.0**(-
> (3*5))
>
> I can't quite understand the gfortran choice, based on normal
> precedence rules, but hey, it's an extension and it can do anything it
> likes.

In Excel, 2^-3*5 is evaluated to 0.625. So is it in Unix bc and R. Maybe
the same logic prevailed there.

But of course, as you say, the only right thing to do is not to use it.

--
FX

James Van Buskirk

unread,

Dec 19, 2007, 8:11:52 PM12/19/07

to

"FX" <cou...@alussinan.org> wrote in message
news:fkcbns$2fug$1...@nef.ens.fr...

> In Excel, 2^-3*5 is evaluated to 0.625. So is it in Unix bc and R. Maybe
> the same logic prevailed there.

In Excel, what is -2.0^3 or atan2(2.0,3.0) ? I think that following
Excel's logic is a bad idea.

> But of course, as you say, the only right thing to do is not to use it.

That's why I think that run-on operators and mixed integer-logical
operations should only work if they're enabled by a switch, never as
a compiler default. These syntaxes are really mistakes I hope for
a Fortran compiler to catch before they cause any damage. Programs
can require so much nonstandard syntax that it doesn't do any good to
turn on standards checking. If ever they were intended they would
be for the most part easy to fix (well except maybe for a sum of
minterms) and if not intended you want to nail them before they
become an incomprehensible tradition.

James Van Buskirk

unread,

Dec 19, 2007, 9:29:55 PM12/19/07

to

"Steve Lionel" <steve....@intel.com> wrote in message

news:d59b9c2d-5624-4109-9358-

> What would you expect:

> print *, kind(10HABCDEFGHIJ)

> to display?

I see you're getting in the Christmas spirit, Steve!

C:\gfortran\clf\xor>type wprobe.f90
program wprobe
implicit none
write(*,*) kind(4HUGLY)
write(*,*) kind(10HABCDEFGH)
write(*,*) Z'594C4755'
write(*,*) O'13123043525'
write(*,*) B'01011001010011000100011101010101'
write(*,*) 3.59370785E+15
write(*,*) 1498171221
write(*,*) 'UGLY'
write(*,*) 4HUGLY
write(*,'(z8.8)') 4HUGLY
write(*,'(o11.11)') 4HUGLY
write(*,'(b32.32)') 4HUGLY
write(*,'(i11.11)') 4HUGLY
! write(*,'(e15.7)') 4HUGLY
end program wprobe

C:\gfortran\clf\xor>c:\gfortran\win64\bin\x86_64-pc-mingw32-gfortran

wprobe.f90
-owprobe
wprobe.f90:3.21:

write(*,*) kind(4HUGLY)
1
Warning: Extension: Hollerith constant at (1)

wprobe.f90:4.31:

write(*,*) kind(10HABCDEFGH)
1
Error: Syntax error in argument list at (1)
wprobe.f90:11.16:

write(*,*) 4HUGLY