Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.
29281 Discussions

Spurious interface conflict warning

IanH
Honored Contributor III
622 Views

Current ifort/ifx (and many versions previous - I've tolerated this one for a while) generate a spurious "error #8000: conflict between local interface block and external ..." with the following example code (note need to compile twice). 

 

>mkdir build

>ifx /c /standard-semantics /check:all /warn:all file1.f90 file2.f90 /module:build\ /object:build\
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2024.2.0 Build 20240602
Copyright (C) 1985-2024 Intel Corporation. All rights reserved.

file2.f90(2): remark #7712: This variable has not been used.   [ARG_B]
RECURSIVE SUBROUTINE Factory(arg_b, arg_d)
-----------------------------^
file2.f90(2): remark #7712: This variable has not been used.   [ARG_D]
RECURSIVE SUBROUTINE Factory(arg_b, arg_d)
------------------------------------^

>ifx /c /standard-semantics /check:all /warn:all file1.f90 /module:build\ /object:build\
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2024.2.0 Build 20240602
Copyright (C) 1985-2024 Intel Corporation. All rights reserved.

file1.f90(21): error #8000:  There is a conflict between local interface block and external interface block.   [ARG_D]
    RECURSIVE SUBROUTINE Factory(arg_b, arg_d)
----------------------------------------^
compilation aborted for file1.f90 (code 1)

 

The warning disappears if the call to the external procedure inside the Proc module procedure is commented out.  In the original code, other trivial and seemingly unrelated changes also result in the warning going away, so something is not well.

 

0 Kudos
1 Reply
Devorah_H_Intel
Moderator
446 Views

@IanH, Thank you for the test case and the bug report. I tested it internally and got the same results. This report has now been escalated to compiler engineering for a fix. 

0 Kudos
Reply