Non-standard precedence of overloaded // operator and +

[Sideboard]

In a project we have an overloaded // operator to concat strings and numbers to a string. There appears to be a difference in precedence between gfortran and ifort/ifx. The following example compiles with gfortan but not with ifort/ifx. For the latter to work, you have to add parentheses to the addition in the (n-2)'th and n'th write line. Thus, ifort/ifx seem to assign the same precedence to // and +, defaulting to a left-to-right precedence. Otherwise the (n-1)'th line should fail as well. According to the Fortran Standard, the + operator should have a higher precedence than //.

program concat_plus
! check if program compiles with + having higher precedence than //

implicit none

interface operator(//)
procedure :: concat_str_int, concat_int_str
end interface operator(//)

write(*,*) "foo1234bar"
write(*,*) "foo" // "1234" // "bar"
write(*,*) "foo" // 1234
write(*,*) 1234 // "bar"
write(*,*) "foo" // 1234 // "bar"
write(*,*) "foo" // 1200 + 0034
write(*,*) 1200 + 0034 // "bar"
write(*,*) "foo" // 1200 + 0034 // "bar"

contains

! not a correct implementation
function concat_int_str(int, str) result(res)
integer, intent(in) :: int
character(*), intent(in) :: str
character(4+len(str)) :: res
res = "1234" // str
end function concat_int_str

! not a correct implementation
function concat_str_int(str, int) result(res)
character(*), intent(in) :: str
integer, intent(in) :: int
character(len(str)+4) :: res
res = str // "1234"
end function concat_str_int

end program concat_plus

[andrew_4619]

I don't know the answer to this question but a thought is, + my have precedence over // but does + have precedence of a user defined  operator? Is the fact  you overloaded  an intrinsic operator relevant to the precedence compared to if you had say called it @@ instead?

[Sideboard]

As far as I know, an overloaded intrinsic operator keeps its precedence. Even if your assumption was true, user-defined operators have to lowest precedence possible. So the effective left-to-right precedence I see in the example should not occur either way.

See also: https://fortran-lang.discourse.group/t/compilers-differ-in-operator-precedence/2937/11

[Steve_Lionel]

I agree with @Sideboard  that ifort has a bug here. As said, intrinsic operators don't change their precedence (nor associativity) when extended by the user. I wrote about this in Doctor Fortran in "Order! Order!" - Doctor Fortran (stevelionel.com)

[andrew_4619]

Many Thanks for clarifying, as I said I was just musing on the subject and know diddly squat on overloading operators. Personally I avoid overloading operators it can create confusing code IMO but I know other have quite different opinions. I do thinks like you have in your example with functions take an integer or real and return an allocatable string to a default or optional argument formatting string

[Barbara_P_Intel]

I filed a bug on this, CMPLRLLVM-39740.

It's not surprising that both ifx and ifort fail. They share the same front end that parses the code.

[Sideboard]

Thanks for filing the bug!

I am also not surprised that it occurs in both. But I would have guessed they share the same "backend", not "frontend". What is the difference for ifort/ifx?

[Steve_Lionel]

It's the other way around - ifort and ifx share a front-end, and have different back-ends. ifort uses Intel's IL0 backend that has been around for 20 years or so. ifx uses a LLVM-based backend.