From: Bart Vandewoestyne on
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
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
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
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
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