... the BOZ literals as integers and then converted the integers to reals. This incorrect behavior can only be seen when gfortran can't do constant folding. This is now know as PR36186 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36186). A fix is ready, it'll be committed soon and ...

... integers and then converted the integers to reals. This incorrect behavior can only be seen when gfortran can't do constant folding. This is now know as PR36186 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36186). CMPLX has so many effective specific functions that you just knew you could trip it up somewhere!...

... cmplx(z'40052A7FA9D2F8EA',KIND=dp) write(*,*) cmplx(b'01000000000000001010100101010011111111& &010100111010010111110001110100110110111100',KIND=qp) write...b'01000000000000001010100101010011111111& &010100111010010111110001110100110110111100',x,qp) write(*,*) cmplx(o'100001245237724722761646674',x,qp) write(*,*) ...when gfortran can't do constant folding. CMPLX has so many effective ...

...@comcast.com>, James Van Buskirk <not_valid@comcast.net> wrote: "FX" <coudert@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 ...

...gfortran for Win64 already supports INTEGER*16. Interesting... C:\gfortran\james\cmplx>type test2.f90 program test2 implicit none real(4) x4...'1') write(*,*) 12345678901234567890_16 end program test2 C:\gfortran\james\cmplx>gfortran test2.f90 -otest2 C:\gfortran\james\cmplx>test2 ( 1.7951958 , 4.61314012E+18) ( 1.7951958020513104000 , 0.0000000000000-(00000E-4933)...

...$1@nef.ens.fr... Oops, sorry I wasn't clear, I'm not talking about the description of BOZ in the standard, only about their implementation in gfortran. 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 ...

... a nonconstant second arg. This might have been overlooked during the BOZ design. 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 ...

"FX" <coudert@alussinan.org> wrote in message news:g079lo$2ur$1@nef.ens.fr... A fix is ready, it'll be committed soon and will show up in your next builds. Thanks for reporting this issue. Cool. Thanks. (Still sure you don't want to open a http://gcc.gnu.org/bugzilla account?) I was on the cusp of doing that at one point in time but there was something that was a ...

John Harper <harper@mcs.vuw.ac.nz> wrote: But AIMAG has another problem: it is both generic and specific, but the specific version is a default real function of a default complex argument only. Pity there isn't a specific DAIMAG intrinsic function, not to mention DCABS, DCCOS, DCEXP, DCLOG, DCONJ, DCSIN, DCSQRT. This "problem" is pretty much universal to all the intrinsics. You ...

>> This might have been overlooked during the BOZ design. If one is BOZ then it seems the usual BOZ rules should apply. 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