Randy, Thanks for the report. I am not sure why we use the d.. version of any of those functions. I have eliminated them in the branch barry/remove-dreal and merged that to next. If all the testing looks good on it we will put it into maint (the next patch) and master.
Barry On Sep 29, 2014, at 3:42 PM, Randall Mackie <rlmackie...@gmail.com> wrote: > I recently ran into an issue with include/finclude/petscsysdef.h and the > definition of PetscImaginaryPart, which is defined as daimag(a) in the case > PETSC_MISSING_DREAL is not defined. > > > 1) As far as I know, daimag is not a valid fortran statement, and I suspect > that here you might want dimag. > > > 2) That being said, I was wondering why all my compiles using gfortran worked > fine and didn't complain, whereas an Intel 2015 compilation did complain > about daimag. > > Turns out Intel and gfortran have different behaviors for the dreal test in > config/BuildSystem/config/types.py. > Gfortran gives an *error* saying the argument in the call to dreal should be > COMPLEX(8) and not REAL(4), whereas Intel just *warns* that the argument data > type is incompatible with the intrinsic procedure. Since gfortran does not > compile the dreal code test, it sets PETSC_MISSING_DREAL to 1, and uses aimag. > > But I'm curious just what exactly you are trying to test for? DREAL is a > valid extension if the argument is double complex. So dreal(dcmplx(3.0,0.0)) > will work just fine, but your test of dreal(3.0) is not a valid statement and > should fail. > > Furthermore, I'm not sure I understand the need for the dreal stuff, since > real, conjg, aimag all return values of the same kind as the argument for the > case of complex variables. > > > Thanks, Randy Mackie
