ICE with -warn interfaces for entry with dummy argument whose dimension is passed via common

[AndyMay]

This is a cut down from some very old code, define.F:

      subroutine defined_sub(a,b)
      implicit none
      integer n
      common /cn/ n
      double precision a
      integer b(n,n)
      return
      entry defined_entry(b)
      end

and corresponding call.F:

      subroutine calling
      implicit none
      integer n
      common /cn/ n
      integer b(n,n)
      call defined_entry(b)
      end

And then compiled with:

ifx -c -O0 -gen-interfaces nosource define.F
ifx -c -O0 -warn interfaces -nogen-interface call.F

gives:

          #0 0x000000000232d4ea
          #1 0x0000000002394d07
          #2 0x0000000002394e30
          #3 0x00007f699ee58dc0
          #4 0x0000000002133ef4
          #5 0x0000000002133b44
          #6 0x0000000002133bc6
          #7 0x0000000002133bc6
          #8 0x0000000002133bc6
          #9 0x000000000210af9d
         #10 0x00000000021378e0
         #11 0x000000000210d482
         #12 0x000000000226ae86
         #13 0x0000000002102617
         #14 0x0000000002101ba2
         #15 0x00000000021e8429
         #16 0x000000000219b75e
         #17 0x00000000021a3484
         #18 0x000000000219f1c6
         #19 0x000000000218040b
         #20 0x000000000218164b
         #21 0x000000000237a9a1
         #22 0x000000000226f846
         #23 0x0000000002452dbe
         #24 0x00007f699ee4324d __libc_start_main + 239
         #25 0x00000000020ab129

/tmp/ifx1289296839MjIeWN/ifx65rUfR.i: 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 call.F (code 3)

[Ron_Green]

In the past couple of months we have had at least 3 bug reports whose root cause is the ENTRY statement (and calls). So I am not surprised by this one.  We have one of our developers working on this part of the compiler, so your timing in reporting this is superb.  I will open a bug report and add this to his list of fixes needed.

Thank you for sending this to us!

Ron

[AndyMay]

Thanks very much for the quick response and opening a bug report. I discovered this only when porting to ifx because the "error #5633" string is now included in the ICE message and found by a grep I use, whereas for ifort it just displays the bare ICE message. That probably sounds odd, but we have a big code, much of it old, for which there is zero hope of it ever compiling with full interface checking. For anyone else in such a situation, particularly those with dependencies such as modules which determines the order of compilation, I will sketch out how I'm still able to make use of interface checking.

1. compile everything with -gen-interfaces nosource.

2. copy all the module files, not just those generated by the interface checking, to another copy of the code.

3. Hack the build system to recover from failure to compile due to interface errors to avoid stopping on first error, something like:

ifx -warn interfaces -no-diag-error-limit -nogen-interface -I/path/to/copied/modules file.F >file.log 2>&1 || ifx file.F

4. extract diagnostics from the logs:

grep '#[0-9]*:' *.log

In our case this is around 60,000 matches, so we then grep away the types of diagnostics that will never get fixed to find the ones that we really care about.

[Ron_Green]

It's the combination of ENTRY with an arg whose bounds are defined in the common block. It's an unusual combination. The bug ID is CMPLRLLVM-56291