-
Notifications
You must be signed in to change notification settings - Fork 13.4k
[flang] Preprocessor substitution in bind(C) names #96781
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Why not use stringizing and |
|
@llvm/issue-subscribers-flang-frontend Author: Brian Cornille (bcornille)
### Issue:
flang does not substitute preprocessor tokens in BIND(C) names. This reproducer contains continuation lines in the same spirit as #78797. This appears to be a workaround in order to get token pasting inside character/string literals. Open to discussing whether this should be intended behavior, but it is used extensively in the a customer codebase and we'd need to find an alternative solution.
### Reproducer:
#### main.F90
```Fortran
program main
implicit none
#define TEMP_LETTER b
#define VAL c
integer, parameter :: a_&
&b_c = 1
write(*,*) a_b_c
contains
subroutine test_&
&TEMP_LETTER&
&_wrapper_&
&VAL&
& (input) &
bind(C, name="test_&
&TEMP_LETTER&
&_&
&VAL&
&_f")
use iso_c_binding
integer :: input
end subroutine test_&
&TEMP_LETTER&
&_wrapper_&
&VAL
end program main
```
#### preprocessor output
`flang-new -E main.F90`
```Fortran
program main
implicit none
program main integer, parameter :: a_&
|
I can bring this back to the offending codebase, but am I correct in inferring that you would prefer not to support this pattern? |
Preprocessors have not been replacing macros in string literals since 1989. Not going to do it here. |
gfortran appears to fail on the provided example. >> gfortran -E main_stringize.F90
# 1 "main_stringize.F90"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "main_stringize.F90"
program main
implicit none
integer, parameter :: a_&
&b_c = 1
write(*,*) a_b_c
contains
subroutine test_&
&b&
&_wrapper_&
&c&
& (input) &
bind(C, name="test_&
&"//STR(TEMP_LETTER)//"&
&_&
&"//STR(VAL)//"&
&_f")
use iso_c_binding
integer :: input
end subroutine test_&
&b&
&_wrapper_&
&c
end program main Maybe it thinks that those lines are string literals. Guess that would be a bug in gfortran. |
Apparently the preprocessor as invoked by gfortran doesn't stringize. |
I have a solution that is portable to both gfortran and flang-new, but it's pretty ugly. I'll think about this some more. |
|
…literals To help port codes from compilers using pre-ANSI C preprocessors, which didn't care much about context when replacing macros, support the replacement of keyword macros in quoted character literals when (and only when) the name of the keyword macro constitutes the entire significant portion of a free form continuation line. See the new test case for a motivating example. Fixes llvm#96781.
llvm#96987) …literals To help port codes from compilers using pre-ANSI C preprocessors, which didn't care much about context when replacing macros, support the replacement of keyword macros in quoted character literals when (and only when) the name of the keyword macro constitutes the entire significant portion of a free form continuation line. See the new test case for a motivating example. Fixes llvm#96781.
Issue:
flang does not substitute preprocessor tokens in BIND(C) names. This reproducer contains continuation lines in the same spirit as #78797. This appears to be a workaround in order to get token pasting inside character/string literals. Open to discussing whether this should be intended behavior, but it is used extensively in the a customer codebase and we'd need to find an alternative solution.
Reproducer:
main.F90
preprocessor output
flang-new -E main.F90
gfortran behavior
gfortran -E main.F90
The text was updated successfully, but these errors were encountered: