ICE ifx with interface + declara

[foxtran]

Hello!

The following, most probably not correct, code:

      subroutine s1(a,b,c)
        real*8 a(*), b(*), c(*)
        interface
          subroutine c1
          end subroutine c1
        end interface
        call s2(c1)
      end subroutine s1
      subroutine s2(a,b,c,calc)
        real*8 a(*), b(*), c(*)
        interface
          subroutine calc(a,b,c)
          end subroutine calc
        end interface
      end subroutine s2
      subroutine c1(a,b,c)
        real*8 a(*), b(*), c(*)
      end subroutine c1

 creates ifx' ICE:

 ifx ifx_ICE.f
          #0 0x00000000021c51e2
          #1 0x0000000002228e97
          #2 0x0000000002228fc0
          #3 0x00007f9c47755f10
          #4 0x000000000215de56
          #5 0x00000000021f59cd
          #6 0x00000000021faa86
          #7 0x00000000021f8968
          #8 0x00000000021f7921
          #9 0x0000000002111bfa
         #10 0x00000000021115bd
         #11 0x00000000022e13ce
         #12 0x00007f9c47738c87 __libc_start_main + 231
         #13 0x0000000001f51aa9

ifx_ICE.f: error #5633: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report.  Note: File and line given may not be explicit cause of this error.
compilation aborted for ifx_ICE.f (code 3)

I used the following ifx:

ifx --version
ifx (IFX) 2023.2.0 20230721
Copyright (C) 1985-2023 Intel Corporation. All rights reserved.

[TobiasK]

Hello @foxtran,

thanks for reporting this. Agreed an ICE should never happen. I escalated it to our developers.

Best

Tobias

[TobiasK]

@foxtran

sorry for the bad news, the compiler team refused to fix this issue since the code is wrong. We believe IFORT compiling this code is even worse than the ICE of ifx.

Did you report this issue because it is generating an ICE or do you really have a need to compile this code?

Best

Tobias

[foxtran]

Thank you!

I reported this because it generates ICE. If it will generate compilation errors it is acceptable for me.

Currently, I have updated such code to external/proper interfaces.

And I would be extremely happy if such code won't compile at any time.

[TobiasK · Accepted solution]

@foxtran,

We agree that ICE is not a nice thing but even after looked at it in more detail, we are don't see a way to detect this coding error and stop compilation without producing an ICE.

[FortranFan]

---

@TobiasK wrote:

@foxtran,

We agree that ICE is not a nice thing but even after looked at it in more detail, we are don't see a way to detect this coding error and stop compilation without producing an ICE.

..
@foxtran wrote:

That is very strange.

---

@TobiasK , Intel Support Team:

Please push back harder on the Intel Fortran compiler team, their response that "we .. don't see a way to detect this coding error and stop compilation without producing an ICE" does NOT show Intel in a good light.  More effort is required.

Please note the code in the original post is vintage fixed-form from the early days of a few Fortran 90 features making their way into usage.  As such, compilers from 1990s - over 20 years ago - can attempt to process the code.

See an illustration below using Compaq Visual Fortran from year 2001 below which does NOT generate an ICE but gives an error that OP might accept:

C:\temp>f90 -c s.f
Compaq Visual Fortran Optimizing Compiler Version 6.6 (Update A)
Copyright 2001 Compaq Computer Corp. All rights reserved.

s.f
s.f(7) : Warning: Routine S2 called with different number and/or type of actual arguments in earlier call - C attribute required if intended.
        call s2(c1)
-------------^

Also, a fairly recent `gfortran` version generates an error OP may be quite happy with:

C:\temp>gfortran -c s.f
s.f:7:16:

    7 |         call s2(c1)
      |                1
Error: Invalid procedure argument at (1)
s.f:16:19:

    4 |           subroutine c1
      |                       2
......
   16 |       subroutine c1(a,b,c)
      |                   1
Warning: 'c1' has the wrong number of arguments between (1) and (2)

Surely IFX 2024 can do better than an ICE, no?

[foxtran]

That is very strange.

I supposed that ifx uses multiple passes to read fortran source code. At first pass, it takes all definitions of all routines/variables and, in the second one, it substitutes known definitions where are used. And in the second pass, it sees that there is two definitions of single routine at compiler fails to ICE. So, the fix would be just a detection of such collisions.

I do not know exactly how ifx works, so I may have totally wrong picture about this.

[TobiasK]

Sorry, the decision is final.
The only thing I can offer you is to use the -warn interfaces compiler option which stops compilation.