inconsistent association status with null() as actual argument

[Ferdinand_T_]

Dear community,

I got confused with the output from the program below.

• Is the code valid Fortran?
• And is the Intel compiler right, or should the output be well defined (I was expecting 'F')?

The program passes null() as an actual argument to a subroutine polymorphic dummy pointer argument. The association status inside the subroutine is not consistently defined and depends on compiler-version and options (and can change when code is added):

module m
    implicit none

    type :: t
    end type
contains

    subroutine test(p)
        class(t), pointer :: p
        print *, associated(p)
    end subroutine
end module

program p
    use m
    call test(null())
end program

! Results with "Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64"
! System: Red Hat Enterprise Linux Server release 7.4
!
! $ifort test.f90
! Version 14.0.4.211 Build 20140805: F
! Version 15.0.3.187 Build 20150407: F
! Version 16.0.4.258 Build 20160811: T
! Version 17.0.6.256 Build 20171215: T
! Version 18.0.1.163 Build 20171018: F
!
! $ifort test.f90 -O0
! Version 14.0.4.211 Build 20140805: F
! Version 15.0.3.187 Build 20150407: F
! Version 16.0.4.258 Build 20160811: T
! Version 17.0.6.256 Build 20171215: T
! Version 18.0.1.163 Build 20171018: T

Kind regards
Ferdinand

PS: From  https://software.intel.com/en-us/node/679609 ; , I understand that null() should indeed work in this context.

[FortranFan]

Can you retry your tests with -standard-semantics compiler option specified in all test instances?

https://software.intel.com/en-us/fortran-compiler-18.0-developer-guide-and-reference-standard-semantics

Anytime you're using Fortran 2003 or later features, I suggest you apply the -standard-semantics option.  I don't see the problem with Intel compiler 17.0 with this option and any /O setting.

Also, given your calling program, I think the interface for your test subprogram should have INTENT(IN) - you may want to review the Fortran standard document regarding this.

[Ferdinand_T_]

Hi FortranFan,

thank you for looking into this!

I ran with -standard-semantics, and again repeated all tests with "intent(in)" for the dummy argument, and got all the same results:

ifort  output  output (-O0)  same w. intent(in)?
18.0   F       T             yes
17.0   T       T             yes
16.0   T       T             yes
15.0   F       F             yes
14.0   F       F             yes

The compiler does not issue any warnings or errors in any case.
With intent(in), the pointer is no longer definable, which one could assume to change the effect of the optimizations, but this example could just be too simple for it to have an impact.

Additionally, I repeated the tests on a local machine (ubuntu linux) and the latest ifort 18.0.1, again with similar results (any optimization level > 0 yields F, O0 yields T).

On this machine, I also tested adding the "mold" option of the null() intrinsic, again without changing the result.

Maybe this is a difference between Windows (since you used "/O" flags) and Linux versions?

Nevertheless, if the code is allowed to terminate with undefined result, there is no issue with different behaviour on different plattforms. However if I could confirm that my code is standard conforming, then that would be a compiler issue...

Best
Ferdinand

PS: I found another documented example with null() being used as actual argument (no intent declared) here:
https://www.ibm.com/support/knowledgecenter/en/SSGH4D_12.1.0/com.ibm.xlf121.aix.doc/language_ref/null-mold.html

[Ferdinand_T_]

PS:
Same results also for Linux openSUSE Leap 42.2.
Ifort 13.1.3.192 gives 'T', both with and without -O0 or -standard-semantics.

[Steve_Lionel · Accepted solution]

Looks like a compiler bug to me. -standard-semantics would have no effect on this. Please report it through the Intel Online Service Center.

[FortranFan]

Ferdinand T. wrote:

..

Maybe this is a difference between Windows (since you used "/O" flags) and Linux versions? ..

The problem is not seen on Windows.  As mentioned upthread, it'll be good if you submit a support incident:

https://supporttickets.intel.com/?lang=en-US

[Juergen_R_R]

I would also say, it is a compiler bug. The code does work as expected with all versions of gfortran and nagfor and even with PGI. 

[Juergen_R_R]

Oh, forgot do say, that (on Linux) I can confirm Ferdinand's findings with all different version (I don't have access to the 14 version any more,

but for the others, I find the same)

[Ferdinand_T_]

Thank you all for your help!
Your assessment of this issue as being a bug, and not Fortran-related, helps me improving my command of the Fortran language.

@Juergen:

Glad you confirmed the reported behaviour on Linux, and that it is not just me doing something stupid.

@Steve, FortranFan:

Unfortunately, I failed several times to sign up for support. The FAQs state I should use Internet Explorer, hence the problem might be related to my usage of Firefox on Ubuntu. Right now I am not inclined to pursue further attempts of getting in contact with Intel support on this, but I believe anyone interested in, or affected by, Intel compiler bugs like this one will find it nicely documented in this forum now.

Furthermore, workarounds are simple, i.e. using a nullified pointer variable instead of the null() expression, or simply enabling some optimization in ifort 18.

Best regards
Ferdinand

[Steve_Lionel]

You don't need Internet Explorer, and if you can post here you can log in to the Online Service Center.

[Ferdinand_T_]

Ok, I might give it an other try.

At the moment, I can sign in and also see my profile at https://www.intel.com/content/www/us/en/secure/profile/my-intel.html
However, once I click the "New Support Request" button, the following happens:

• (1) I click the 'Request Support' button on the "Online Service Center"-page
• (2) The sign-up page "Create a Support Account" appears with a form holding my personal information except for the phone-number (field is blank and outlined in red)
• (3) I enter my Phone-number (and select the correct Country-code), confirm the 'legal' part and submit
• (4) A 'Thank you for signing up with Intel® Support' page appears. It says 'A verification email has been sent to you.', but I do not receive it.

Now I have two options:

(A)

• I click the 'resend email' link and receive the email.
• I follow the link in the email
• A page opens that thanks me for confirming my email address, and eventually I get redirected to the sign-in form.
• I enter my credentials and a blank page (https://www.intel.com/) opens (just whitespace between <body> tags).
• ... continue with (1)

(2)

• I click the link in "After verifying your email address, please sign in." directly
  Alternatively, I click the link in "If you are an existing intel.com user, please sign in here"
• ... continue with (2)

I have not found a way to break the cycle yet. Either I do something entirely wrong, or I should contact the support. However, clicking on "Need more help? 'Contact support' on the Online Service Center page doesn't do anything for me... and I am stuck with the same results after restarting browser, using different computer, sign out / in etc.

Best
Ferdinand

[Steve_Lionel]

Try filling out the "Site Support or Non-Technical Questions" form at https://software.intel.com/en-us/support/ and explain the problems you're having registering/signing in. They will direct it to the right department.