However, as raised here, the OpenMP standard prohibits privatisation of statement function variables. See 5.2 section 5.3:
Variables that appear in namelist statements, in variable format expressions, and in expressions for statement function definitions, must not be privatized.
I have a PR preventing statement function variable privatization.
Should Flang follow the standard in preventing this privatization, or should we continue to support it?
I’m generally fine with following the standards closely, but I’d like to check with some of the AMD customers to see if they’d have trouble when this is actually treated as an error.
When a feature is already supported by other compilers, is used by applications, and doesn’t change the semantics of a conforming program, supporting that feature improves portability and tends to be the right thing to do.
As a general principle, this compiler will accept by default and without complaint many legacy features, extensions to the standard language, and features that have been deleted from the standard, so long as the recognition of those features would not cause a standard-conforming program to be rejected or misinterpreted.
Besides GFortran, IFORT and IFX also support privatization of variables referenced in statement functions.
But when privatization is performed through the default clause, there is a change in behavior.
Consider this program:
program test
sf(iexp)=func(iimp)+iexp
iimp = 11
iexp = 22
!$omp parallel default(firstprivate)
!$omp single
iexp = sf(iexp)
!$omp end single
!$omp end parallel
print *, iimp
contains
integer function func(i)
i = i * 3
func = i
end function
end program
AFAIK this is a standard-conforming program, that should print 33, as iimp shouldn’t be privatized. When privatization is allowed, however, it prints 11 instead.
Other non-standard features, which do conflict with the current standard specification of the Fortran programming language, are accepted if enabled by command-line options.
Thanks for the clever example. It seems current flang-new and gfortran print 11 here, but armflang (classic flang) correctly prints 33. I don’t have IFORT and IFX available to test.
From this example I think we should follow classic flang and not privatise these variables. Would that be okay @klausler and @sscalpone?
I think we should remove support for privatisation of statement function variables because of @luporl’s example which produces different results for the base language. Are you okay with this?
Looks like GNU, Intel, and Fujitsu all privatize variables referenced in statement functions, so whether or not you support the extension, you should at least emit a portability warning message that might help debug codes that depend on it (or not)…