gfortran does constant folding so aggressively that one has to be
careful when testing it. I have seen several instances lately
where it yields the correct answer if its constant folding
mechanism can come into play, but will be tripped up if not.
Another case in point:

C:\gfortran\james\cmplx>type test0.f90
module mykinds
implicit none
integer, parameter :: sp = selected_real_kind(6,37)
integer, parameter :: dp = selected_real_kind(15,307)
integer, parameter :: ep = selected_real_kind(18,4931)
integer, parameter :: qp_preferred = selected_real_kind(33,4931)
integer, parameter :: qp = (1+sign(1,qp_preferred))/2*qp_preferred+ &
(1-sign(1,qp_preferred))/2*ep
end module mykinds

This is now know as PR36186
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36186).

The real issue is that all other intrinsics (DBLE, REAL, etc.) are
simplified when they have a BOZ as argument, while in complex you can
prevent that by putting a nonconstant second arg. This might have been
overlooked during the BOZ design.

FX wrote:
(snip)

Fortran 2003 13.7.20:

"CMPLX (X, Y, KIND) has the complex value whose real
part is REAL (X, KIND) and whose imaginary part is
REAL (Y, KIND)."

Since CMPLX is defined in terms of REAL, the effect should be
the same as applying REAL to each argument separately.
If one is BOZ then it seems the usual BOZ rules should apply.

-- glen

Oops, sorry I wasn't clear, I'm not talking about the description of BOZ
in the standard, only about their implementation in gfortran.

"FX" alussinan.org> wrote in message
news:g01ij1$11gf$1@nef.ens.fr...

There is a buglet in the description of CMPLX in the standard:

"If X is complex, it is as if X were real with the value REAL(X,KIND)
and Y were present with the value AIMAG(X,KIND)."

Nice concise prose, but AIMAG doesn't take a KIND optional agument.
Maybe REAL(AIMAG(X),KIND) ?

"FX" alussinan.org> wrote in message
news:g016b4$2bbj$1@nef.ens.fr...

Well, there are also DCMPLX and COMPLEX. I didn't realize that
gfortran for Win64 already supports INTEGER*16. Interesting...

C:\gfortran\james\cmplx>type test2.f90
program test2
implicit none
real(4) x4
real(8) x8
real(10) x10
real(4), parameter :: p4 = 1.795195802051310421978653361874_4
real(8), parameter :: p8 = 1.795195802051310421978653361874_8
real(10), parameter :: p10 = 1.795195802051310421978653361874_10

A fix is ready, it'll be committed soon and will show up in your next
builds. Thanks for reporting this issue.

(Still sure you don't want to open a http://gcc.gnu.org/bugzilla
account?)

In article comcast.com>,
James Van Buskirk comcast.net> wrote:

That buglet seemed to have been squashed in the f95 standard Working
Draft of October 21, 1997, which says AIMAG(X), but it reappeared in
the f2003 Working Draft of May 10, 2004 and in the f2008 Working Draft
of 5th January 2007 :-(

John Harper mcs.vuw.ac.nz> wrote:

This "problem" is pretty much universal to all the intrinsics. You won't
find *ANY* new specifics for them. The number of specific names required
would be huge, not to speak of the fact that even what specifics were
appropriate would be compiler-dependent (because the number of kinds is
compiler dependent, and it would be problematic if changing kinds meant
that you no longer had a specific).

"FX" alussinan.org> wrote in message
news:g079lo$2ur$1@nef.ens.fr...

Cool. Thanks.

I was on the cusp of doing that at one point in time but there was
something that was a showstopper for me, although I can't remember
what it was just off the top of my head.

In http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36214 I noticed
that if you print out rd, you get 0000000040295400 with the r
line in force, but 00000000402953FD with it commented out. If
the high and low dwords are reversed you get 402953FD00000000 in
both cases. It might have something to do with rd being denormal
as well as being BOZ.