Looking for information on error code #9186

[urb]

A module that has been working with several other compilers gives me an
error using ifx (IFX) 2025.3.2 20260112.

The message is

       M_unicode.F90(4303): error #9186: The dummy arguments of the specific
                            procedure defining a defined assignment or defined operator cannot both
                            be unlimited polymorphic.   [CONCAT_G_G]
       interface operator(//); module procedure :: concat_g_g; end interface operator(//)
       --------------------------------------------^
       /dev/shm/ifx2105017917IKHT0J/ifxgEPL2L.i90: warning #6178: The return
       value of this FUNCTION has not been defined.   [NEW]
       compilation aborted for M_unicode.F90 (code 1)

I am looking in the standard trying to identify where that error might
be prescribed, as it has been working with other compilers and it saves
a lot of coding if it should work (I know how to get around the error,
but it would take considerably more code).

I admit I was not sure if that construct would work or not at the time
I created it but was pleasantly surprised when trying it worked (up
till now).

I am primarily trying to ascertain if this is a bug that should be
reported or if I need to recode that functionality and so far have not
found anything in the standard that says error #9186 should be the case.

PS:
The code is at

    https://github.com/urbanjost/M_unicode

PPS:
The module allows working with UTF-8 source files and manipulating
Unicode characters by their codebase which I created primarily as a
work-around for Intel not supporting Unicode, but subsequently I find
I like it better than the optional Fortran Unicode support anyway; but
that makes it particularly important the module work with Intel/ifx as
ifx does not support the Unicode extension. Are there plans to add the
Unicode extension support anytime soon to ifx?

[Steve_Lionel · Accepted solution]

F2023, 15.4.3.4.2p1: If the operator is an intrinsic-operator (R608), the number of dummy arguments shall be consistent with the intrinsic uses of that operator, and the types, kind type parameters, or ranks of the dummy arguments shall differ from those required for the intrinsic operation (10.1.5), treating a CLASS (*) dummy argument as not differing in type or kind.

For example, how is the compiler supposed to know if it can call CONCAT_G_G for C1//C2 where both C1 and C2 are default character? It's ambiguous.

[urb]

The M_unicode github repository now uses a number of small procedures in a generic interface to disambiguate operator(//) using a standard-conforming method, so the // operator works with ifx as intended now.  I see a few mentions in previous discussions about wanting to use Unicode with ifort/ifx.  This module allows for using UTF-8 encoded Unicode source files and data in a (hopefully) intuitive manner without requiring the compiler to support the ISO-10646 extension (which ifx currently does not) so if anyone wants to try it feedback is welcome.   https://github.com/urbanjost/M_unicode 

A simple example converting case in a few languages that have that concept:

     program demo_lower
     use iso_fortran_env, only : stdout => output_unit
     use M_unicode,       only : lower, unicode_type, assignment(=), trim
     use M_unicode,       only : ut => unicode_type, operator(==)
     implicit none
     character(len=*),parameter :: g='(*(g0))'
     type(unicode_type) :: pangram
     type(unicode_type) :: diacritics
     type(unicode_type) :: expected
       !
       ! a sentence containing every letter of the English alphabet
       pangram="THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG"
       expected="the quick brown fox jumps over the lazy dog"
       call test(pangram,expected)
       !
       ! Slovak pangram
       PANGRAM    = 'VYPÄTÁ DCÉRA GRÓFA MAXWELLA S IQ NIŽŠÍM AKO &
       &KÔŇ NÚTI ČEĽAĎ HRÝZŤ HŔBU JABĹK.'
       expected   = 'vypätá dcéra grófa maxwella s iq nižším ako &
       &kôň núti čeľaď hrýzť hŕbu jabĺk.'
       call test(pangram,expected)
       !
       ! contains each special Czech letter with diacritics exactly once
       DIACRITICS='PŘÍLIŠ ŽLUŤOUČKÝ KŮŇ ÚPĚL ĎÁBELSKÉ ÓDY.'
       expected ='příliš žluťoučký kůň úpěl ďábelské ódy.'
       print g,'("A horse that was too yellow-ish moaned devilish odes")'
       call test(diacritics,expected)
     contains
     subroutine test(in,expected)
     type(unicode_type),intent(in) :: in
     type(unicode_type),intent(in) :: expected
     type(unicode_type)            :: lowercase
     character(len=*),parameter    :: nl=new_line('A')
         write(stdout,g)in%character()
         lowercase=lower(in)
         write(stdout,g)lowercase%character()
         write(stdout,g)merge('PASSED','FAILED',lowercase == expected ),nl
     end subroutine test
     end program demo_lower


fpm: Entering directory '/home/urbanjs/venus/V600/github/ENCODING/M_unicode'

THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG
the quick brown fox jumps over the lazy dog
PASSED

VYPÄTÁ DCÉRA GRÓFA MAXWELLA S IQ NIŽŠÍM AKO KÔŇ NÚTI ČEĽAĎ HRÝZŤ HŔBU JABĹK.
vypätá dcéra grófa maxwella s iq nižším ako kôň núti čeľaď hrýzť hŕbu jabĺk.
PASSED

("A horse that was too yellow-ish moaned devilish odes")
PŘÍLIŠ ŽLUŤOUČKÝ KŮŇ ÚPĚL ĎÁBELSKÉ ÓDY.
příliš žluťoučký kůň úpěl ďábelské ódy.
PASSED

[urb]

Two other compilers (gfortran, flang) allowed it because they prevent overloading default intrinsic behavior first, and do not look at the overload of the intrinsic unless it is not satisfied by the default behavior.  So when it worked with those two and not with ifx I was hoping the other two were correct. Your solution is pretty clear that is not the case, even though the other compilers did not flag it as non-standard behavior when I added flags to enforce conforming to the standard. I still need to add non-default kinds to the work-around but it works on all three compilers.

[Steve_Lionel]

It's easy to miss edge cases such as this one. Back in the day, we had people, not part of the development team, writing unit tests for every rule in the standard, and that found LOTS of missed cases. Sadly, these QA teams were disbanded as a cost-savings measure and we're all the worse for it. Developers who write their own unit tests are very likely to write tests to their own understanding of the standard, not what it actually says. It's harder when rules are spread out through the text - the standard tries very hard to not say something more than once, as it will end up being wrong in one or more instances over time.