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.
29285 Discussions

establishqq using default options

ereisch
New Contributor II
1,047 Views

It seems with the newer versions of the compiler (I'm using 19.1.1.217), when you compile a routine with "-assume nounderscore" and that routine has a block that looks like this:

USE IFESTABLISH
IMPLICIT NONE
INTEGER(INT_PTR_KIND())  :: DUMMY2, DUMMY3
PROCEDURE(ESTABLISHQQ_HANDLER) :: FORRTL_TRAP
PROCEDURE(ESTABLISHQQ_HANDLER), POINTER :: DUMMY
RETVAL = ESTABLISHQQ( FORRTL_TRAP, DUMMY2, DUMMY, DUMMY3 )

...it is now reverting to default attributes for the referenced function, and is attempting to resolve "forrtl_trap_" (with the trailing underscore), even though "-assume nounderscore" is specified in the build arguments.

0 Kudos
2 Replies
ereisch
New Contributor II
1,037 Views

After further investigation, this appears to be from the new inclusion of the

!DEC$ ATTRIBUTES DEFAULT :: establishqq_handler

line in ifestablish.f90.  The same line for "establishqq" was missing for awhile (and looks like it has been finally added), but I question whether the "ATTRIBUTES DEFAULT" should be in there for the handler routine abstract prototype.

0 Kudos
Steve_Lionel
Honored Contributor III
1,027 Views

Yes, that attribute needs to be there or else you could have set calling conventions different from what ESTABLISHQQ requires. I could argue that for abstract interfaces it should not affect external names, since an abstract interface has no external name. An oversight, in my opinion.

0 Kudos
Reply