ifort warning in sign function
in [Fortran]
|
Prev: qsort and C interoperability, was Re: "Optional" Arguments in Fortran?
Next: intrinsic function optional argument
From: Bart Vandewoestyne on 24 Feb 2010 04:14 I'm using the following 'trick' to define my real kinds up to 'quadruple precision': integer, parameter, public :: sp = kind(1.0) integer, parameter, public :: dp = selected_real_kind(2*precision(1.0_sp)) integer, parameter, public :: qp_preferred = & selected_real_kind(2*precision(1.0_dp)) integer, parameter, public :: qp = (1+sign(1,qp_preferred))/2*qp_preferred+ & (1-sign(1,qp_preferred))/2*dp However, when I compile this with ifort 11.1 20091130 on Linux i get the following warnings: numeric_kinds.f95(14): warning #7374: F95 standard requires all arguments be of the same type and same kind type parameter. [1] integer, parameter, public :: qp = (1+sign(1,qp_preferred))/2*qp_preferred+ & ---------------------------------------------^ numeric_kinds.f95(15): warning #7374: F95 standard requires all arguments be of the same type and same kind type parameter. [1] (1-sign(1,qp_preferred))/2*dp I know that qp_preferred is of default kind integer, but isn't the constant '1' also a default kind integer? Is there a way to cleanly avoid this warning and improve my code or is it the ifort compiler being too picky here? Thanks, Bart -- "Share what you know. Learn what you don't."
From: Richard Maine on 25 Feb 2010 04:15 Bart Vandewoestyne <MyFirstName.MyLastName(a)telenet.be> wrote: > I'm using the following 'trick' to define my real kinds up to 'quadruple > precision': [elided] > However, when I compile this with ifort 11.1 20091130 on Linux i get the > following warnings: > > numeric_kinds.f95(14): warning #7374: F95 standard requires all arguments > be of the same type and same kind type parameter. [1] integer, > parameter, public :: qp = (1+sign(1,qp_preferred))/2*qp_preferred+ & > ---------------------------------------------^ Well, the code as stands is standard conforming and does have both arguments as default kind. I am assumimg that: 1. There is no other context that changes things. Most things shown are explicit enough that not a lot is left to the inventive imagination, but I won't say it is impossible. A prior USE statement that made SIGN mean something else would be one obscure possibility, though that probably wouldn't cause this particular message. I doubt there is any such issue, but complete, compilable samples are always better to avoid even the obscure ones. For this case, just wraping module and end module statements around these ones would do the trick. NAG and g95 are both happy with the code shown when I do that. I don't have Intel Fortran handy. (I seem to recall that there is a Mac version, but I don't have it. It has been a long time since I even booted one of my Linux systems. I'd probably need to shuffle some hardware to do so - either that or install Linux in a virtual machine under VMWare). 2. Other context includes context outside of the source code. In particular, it includes compiler switches that put the compiler into "funny" (aka nonstandard) modes. For example, compiler switches that change the kind of literals or otherwise muck with the kind system. I'd guess that you aren't using any such... at least intentionally. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Bart Vandewoestyne on 25 Feb 2010 04:22 On 2010-02-25, Richard Maine <nospam(a)see.signature> wrote: > > 2. Other context includes context outside of the source code. In > particular, it includes compiler switches that put the compiler into > "funny" (aka nonstandard) modes. For example, compiler switches that > change the kind of literals or otherwise muck with the kind system. I'd > guess that you aren't using any such... at least intentionally. The code I have cited is wrapped in a module. I'm using the following compiler commands (my debug setup): ifort -c -g -stand f95 -implicitnone -fpe0 -check -warn -free -Tf numeric_kinds.f95 and I'm using the following compiler + architecture: bartv(a)sonic:~$ ifort --version ifort (IFORT) 11.1 20091130 Copyright (C) 1985-2009 Intel Corporation. All rights reserved. bartv(a)sonic:~$ uname -a Linux sonic 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 16:20:31 UTC 2009 i686 GNU/Linux bartv(a)sonic:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 9.10 Release: 9.10 Codename: karmic So for now, i still believe ifort is wrong with its warning. Kind regards, Bart -- "Share what you know. Learn what you don't."
From: dpb on 25 Feb 2010 09:47 Bart Vandewoestyne wrote: .... > All opinions are welcome! :-) > .... My opinion is this is one that should be posted to the Intel forum... :) --
From: Steve Lionel on 25 Feb 2010 11:36
On 2/25/2010 3:25 AM, Bart Vandewoestyne wrote: > Paul ends the thread by saying that the Intel compiler was not > the one generating the error message and no solution is mentioned > in the thread. However, i *do* have this issue with the Intel > compiler. From what I read in Paul's thread, i would also > suspect that the Intel compiler is wrong here? I think this is a bug in the Intel compiler and will report it to the developers. -- Steve Lionel Developer Products Division Intel Corporation Nashua, NH For email address, replace "invalid" with "com" User communities for Intel Software Development Products http://software.intel.com/en-us/forums/ Intel Software Development Products Support http://software.intel.com/sites/support/ My Fortran blog http://www.intel.com/software/drfortran |