Private and equivalence

[Arno]

Dear all,

I try to install a large software package, but can only compile it when
changing the code. To understand what was going on, I have stripped down
the code to a minimum that still reproduces the compilation error:

/tmp/ifort3oqr1y.o: In function `funct_module_mp_init_':
funct_module.f90:(.text+0x1d): undefined reference to `data_module_mp_b_'

I am using the following:
compiler: Intel (12.0.3 20110309)
OS: Linux/Debian x86_64)

The code:

!*** main.f90 ***
program main

use funct_module

implicit none

call init()

end program main


!*** funct_module.f90 ***

module funct_module

use data_module

implicit none
private :: a

contains

subroutine init()

implicit none

a = 2.d0

end subroutine init

end module funct_module


!*** data_module.f90 ***

module data_module

public

real(kind=8) :: a,b
equivalence( a,b )

end module data_module

Personally, I dislike equivalence. Removing either equivalence in
data_module.f90 or private in funct_module.f90 solves the problem in this
case, but not in the actual program. I guess my question is if this code
is standard compliant, and, if so, what does the private statement mean
here, as the a change in 'a' in funct_module.f90 will also cause a change
of 'a' in data_module.f90 and as such it is visible outside
funct_module.f90!? And why does it compile when I remove the equivalence?

Best regards,

Arno

[Tobias Burnus]

On 02/07/2012 03:14 PM, Arno wrote:
> I have stripped down the code to a minimum that still
>
> reproduces the compilation error:
> /tmp/ifort3oqr1y.o: In function `funct_module_mp_init_':
> funct_module.f90:(.text+0x1d): undefined reference to `data_module_mp_b_'
>
> I am using the following:
> compiler: Intel (12.0.3 20110309)
> OS: Linux/Debian x86_64)

I think the program is valid.

It also compiles with four other compilers I tried. And it works with
the Intel compiler, if one places the whole program into a single file.
However, with three separate files, I can reproduce the error message
with ifort 11.0, 11.1, 12.0 and 12.1.

I think you should report the bug to Intel.

As work around, you could combine the files into a single file or use a
different compiler such as GCC's gfortran.*

Tobias
*Note: I am biased.

[Steve Lionel]

On 2/7/2012 9:14 AM, Arno wrote:

> Personally, I dislike equivalence. Removing either equivalence in
> data_module.f90 or private in funct_module.f90 solves the problem in this
> case, but not in the actual program. I guess my question is if this code
> is standard compliant, and, if so, what does the private statement mean
> here, as the a change in 'a' in funct_module.f90 will also cause a change
> of 'a' in data_module.f90 and as such it is visible outside
> funct_module.f90!? And why does it compile when I remove the equivalence?

I agree with Tobias that this is a bug in ifort and have escalated it as
issue DPD200178727. I also dislike equivalence.

--
Steve Lionel
Developer Products Division
Intel Corporation
Merrimack, 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

Refer to http://software.intel.com/en-us/articles/optimization-notice
for more information regarding performance and optimization choices in
Intel software products.

[Richard Maine]

Steve Lionel <steve....@intel.invalid> wrote:

> On 2/7/2012 9:14 AM, Arno wrote:
>
> > Personally, I dislike equivalence. Removing either equivalence in
> > data_module.f90 or private in funct_module.f90 solves the problem in this
> > case, but not in the actual program. I guess my question is if this code
> > is standard compliant, and, if so, what does the private statement mean
> > here, as the a change in 'a' in funct_module.f90 will also cause a change
> > of 'a' in data_module.f90 and as such it is visible outside
> > funct_module.f90!? And why does it compile when I remove the equivalence?
>
> I agree with Tobias that this is a bug in ifort and have escalated it as
> issue DPD200178727. I also dislike equivalence.

I agree with Tobias and Steve that the code is valid. (I also agree
about generally disliking equivalence, but that's a different matter).

I don't see that they answered the "what does the private statement
mean" part, so I'll give a go at that. (I might note a certain book that
I think covers this well, but I'm biased as I wrote that part. :-))

The private attribute applies only to a particular name - *NOT* to the
underlying entity. In a way, I think it unfortunate that the standard
even refers to private as an attribute because it isn't like other
attributes in that aspect. Most attributes actually imply something
about the entity in question. But private doesn't say anything about
that entity - just about its name. There are places in the standard
where PRIVATE has to be special-cased because of this distinction. The
distinction matters because there are sometimes ways to "get at" the
same entity by other names. Equivalence is one such way. Pointers are
another. Argument association is yet another.

So you should not think of private as making the entity private. It
doesn't do that. It just "hides" the name from USE association.

(Private is poorly named for multiple reasons. It doesn't even really
make the name private. The public attribute does make something public,
but the private attribute doesn't necessarily make anything private.
That bit of confusion took a long time to straighten out, which was done
mostly by removing all the ill-considered restrictions that made it
matter. It isn't directly applicable to the code shown anyway.)

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

[Arno]

Tobias, Steve, and Richard,

Thanks for the quick and clear responses.

Arno