| Issue |
172456
|
| Summary |
[flang] Companion processor can differ from C
|
| Labels |
flang
|
| Assignees |
|
| Reporter |
foxtran
|
In some cases, it may be desirable to provide direct bindings to C++ or other languages that use mangling schemes different from C. Another use case is binding to specific symbol versions that include additional prefixes or suffixes. For example, Apple's framework Accelerate has the following declaration for `ddot` function in ILP64 mode:
```fortran
interface
pure function ddot(n,dx,incx,dy,incy) bind(C, name="ddot$NEWLAPACK$ILP64")
import
integer(c_int64_t), intent(in) :: n
real(c_double), intent(in) :: dx(*)
integer(c_int64_t), intent(in) :: incx
real(c_double), intent(in) :: dy(*)
integer(c_int64_t), intent(in) :: incy
real(c_double) :: ddot
end function ddot
end interface
```
while traditional interface is:
```fortran
interface
pure function ddot(n,dx,incx,dy,incy) bind(C, name="")
import
integer(c_int64_t), intent(in) :: n
real(c_double), intent(in) :: dx(*)
integer(c_int64_t), intent(in) :: incx
real(c_double), intent(in) :: dy(*)
integer(c_int64_t), intent(in) :: incy
real(c_double) :: ddot
end function ddot
end interface
```
At the current moment, flang does not accept such names: https://godbolt.org/z/YvM5nYExz
8.5.5 from Fortran 2023 standard specifies that
> If the value of the `scalar-default-char-constant-expr` after discarding leading and trailing blanks has nonzero length, it shall be valid as an identifier on the `companion processor`.
And `companion processor`, according to 5.5.7,
> might or might not be a mechanism that conforms to the requirements of ISO/IEC 9899:2018.
Therefore, enforcing conformance to valid C identifier rules is too restrictive.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
