Hi Henri! Am 02.06.26 um 1:15 PM schrieb Henri Menke:
Hi Harald,Thanks for the quick feedback. Please find the patch for v2 attached. Let me briefly address the requested changes point-by-point. - Renamed FORCEINLINE to ALWAYS_INLINE and added a plain INLINE attribute. INLINE only sets DECL_DECLARED_INLINE_P, while ALWAYS_INLINE additionally sets DECL_DISREGARD_INLINE_LIMITS. - The new EXT_ATTR_INLINE and EXT_ATTR_ALWAYS_INLINE values are now appended at the end of the enum, before EXT_ATTR_LAST, so the existing bit positions in the module-file bitmask are preserved. I also added a source comment before the enum noting that new attributes must be appended for this reason. - The mutual-exclusion check now covers both INLINE and ALWAYS_INLINE against NOINLINE. While implementing these changes, I have also noticed a difference from the C always_inline attribute. Because ALWAYS_INLINE sets DECL_DISREGARD_INLINE_LIMITS directly rather than attaching an always_inline attribute, it does not force inlining at -O0. For now I have left it at that, because attaching an attribute to the declaration would make this patch a bit more complicated. If you would prefer the exact C semantics I am happy to attach the real attribute instead.
No, your current solution is really fine with me.
One note on the testsuite. The ALWAYS_INLINE test simply checks that the procedure is inlined at -O. The plain INLINE test needs more care, because a small procedure is inlined at -O2 regardless of the attribute. That test therefore switches off automatic inlining with - fno-inline-small-functions -fno-inline-functions -fno-inline-functions- called-once and then verifies that the INLINE attribute alone re- enables inlining for that one procedure. I added a comment in the test explaining this, but I worry about the robustness of this check, especially on other platforms that I cannot test.
This is also fine. There is only one thing I noted while playing with your new testcase inline_2.f90: depending on the ordering of the lines !GCC$ ATTRIBUTES inline :: bar !GCC$ ATTRIBUTES noinline :: bar one gets a warning that either looks correct or confusing. The way you've chosen it for the testcase I get:13 | !GCC$ ATTRIBUTES noinline :: bar ! { dg-warning "INLINE. at .1. is incompatible with .NOINLINE." }
| 1
Warning: Attribute »INLINE« at (1) is incompatible with »NOINLINE« for
»bar« and will be ignored
This is because the order in which the attributes are processed is not taken into account by your new checks. Anyway, I think this is rather a cosmetic issue and not a real problem. Besides, there is a minor whitespace issue your can check yourself:% ./contrib/check_GNU_style.sh 0001-fortran-add-INLINE-and-ALWAYS_INLINE-attributes.patch
Blocks of 8 spaces should be replaced with tabs.
83:+ { "inline", EXT_ATTR_INLINE, NULL },
84:+ { "always_inline",EXT_ATTR_ALWAYS_INLINE,NULL },
It is hard to see without this hint, but after "NULL" there
shall be a tab. I can fix this myself.
Bootstrapped and regtested on x86_64-pc-linux-gnu with --enable- languages=c,c++,fortran, no regressions.
If nobody else speaks up, particularly w.r.t. the warnings mentioned above, I'll commit for you tomorrow. Thanks for the patch! Harald
Kind regards, Henri On Mon, 2026-06-01 at 21:15 +0200, Harald Anlauf wrote:Hi Henry! Am 01.06.26 um 9:49 AM schrieb Henri Menke:Hi Harald! First of all thank you very much for your fast and careful review! On Sun, 2026-05-31 at 21:55 +0200, Harald Anlauf wrote:Hi Henri! Am 31.05.26 um 8:01 PM schrieb Henri Menke:gfortran already understands the !GCC$ ATTRIBUTES NOINLINE directive to suppress inlining of a procedure, but there was no way to request the opposite, equivalent to the C always_inline attribute. This adds a FORCEINLINE attribute usable as !GCC$ ATTRIBUTES forceinline :: my_procedure Since Fortran has no 'inline' keyword, the translation sets both DECL_DECLARED_INLINE_P and DECL_DISREGARD_INLINE_LIMITS on the function declaration; setting only the latter would make the middle-end warn that the always-inline function "might not be inlinable". FORCEINLINE and NOINLINE are mutually exclusive. In the middle-end the DECL_UNINLINABLE flag set by NOINLINE always takes precedence, so a combination of the two would silently ignore FORCEINLINE. To avoid that surprise the directive parser warns and drops FORCEINLINE when both are applied to the same procedure, whether in one directive or in two.While I think that options controlling inlining are desirable, I wonder if "FORCEINLINE" is a good choice. Also, why is there no regular "INLINE"? A commercial Fortran compiler I use at work supports "INLINE" and "ALWAYS_INLINE" with semantics comparable to gcc. My preference would be to follow this convention also for gfortran. (The Intel compiler has INLINE and FORCEINLINE, but according to the documentation these are used differently (and at the call site!), so there would be potential confusion of users.)You are of course right. I have to admit that I took the name FORCEINLINE from the Intel compiler without realizing that Intel's INLINE/FORCEINLINE are call-site directives with semantics different from what I implemented here. That mismatch would indeed be a source of confusion and I fully agree that we should follow the INLINE / ALWAYS_INLINE convention instead. For the next revision I would propose to: - rename FORCEINLINE to ALWAYS_INLINE, keeping the current semantics (DECL_DECLARED_INLINE_P + DECL_DISREGARD_INLINE_LIMITS, i.e. the equivalent of __attribute__((always_inline))) - add INLINE as a plain inlining hint that only sets DECL_DECLARED_INLINE_P and leaves the inliner's size limits in effect (in line with the C "inline" keyword) - keep the mutual-exclusion handling, now between {INLINE,ALWAYS_INLINE} and NOINLINE. Does that sound okay?Yes, this sounds fine with me.A real problem of your patch is that it shifts the enums EXT_ATTR_*, after which the module files compiler from previous versions of gfortran are incompatible with those after the patch. This must be fixed.Thanks, I did not realize that the EXT_ATTR_* values end up in the module files (and there also seems to be no source comment warning about this). As far as I can tell, appending the new values at the end of the enum (before EXT_ATTR_LAST), and likewise appending the corresponding rows at the end of ext_attr_list[], leaves the existing bit positions untouched. Old modules would then continue to read correctly and only modules that actually use the new attributes would be unreadable by an older gfortran, which seems unavoidable.The externally visible extension attributes (attr->ext_attr) are saved to/restored from module files, and since this is a bitmask, appending at the end is the way to go. We want to avoid surprises if a harmless bit in another gfortran version is suddenly interpreted e.g. as NORETURN...Would that approach be acceptable (append at the end), or would you rather see the module version bumped? Since I just started contributing to GCC, I'm not sure what is the appropriate practice.Appending at the end would be currently harmless in the sense that the new bits would likely be ignored by an older gfortran version (IIRC). You could extend the comment before the enum definition to indicate that new attributes must be added at the end (before EXT_ATTR_LAST). One wish from my side: can you attach patches to your mails? This reduces the risk of whitespace struggles on my end. Thanks, HaraldKind regards, HenriHaraldBootstrapped and regtested on x86_64-pc-linux-gnu (--enable-languages=c,c++,fortran): all three stages built and the stage 2/3 comparison succeeded, and the gfortran testsuite shows no regressions (75375 expected passes, 335 expected failures, 0 unexpected failures), with the two new tests passing. gcc/fortran/ChangeLog: * gfortran.h (enum ext_attr_id_t): Add EXT_ATTR_FORCEINLINE. * decl.cc (ext_attr_list): Add "forceinline". (gfc_match_gcc_attributes): Warn about and drop FORCEINLINE when it is combined with NOINLINE on the same symbol. * trans-decl.cc (build_function_decl): Handle EXT_ATTR_FORCEINLINE by setting DECL_DECLARED_INLINE_P and DECL_DISREGARD_INLINE_LIMITS. * gfortran.texi (ATTRIBUTES directive): Document FORCEINLINE. gcc/testsuite/ChangeLog: * gfortran.dg/forceinline_1.f90: New test. * gfortran.dg/forceinline_2.f90: New test. Signed-off-by: Henri Menke <[email protected]> --- gcc/fortran/decl.cc | 13 +++++++++++ gcc/fortran/gfortran.h | 1 + gcc/fortran/gfortran.texi | 5 ++++ gcc/fortran/trans-decl.cc | 9 +++++++ gcc/testsuite/gfortran.dg/forceinline_1.f90 | 26 +++++++++++++++++++++ gcc/testsuite/gfortran.dg/forceinline_2.f90 | 14 +++++++++++ 6 files changed, 68 insertions(+) create mode 100644 gcc/testsuite/gfortran.dg/forceinline_1.f90 create mode 100644 gcc/testsuite/gfortran.dg/forceinline_2.f90 diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc index 166b10d4cd4..aa5b291ac41 100644 --- a/gcc/fortran/decl.cc +++ b/gcc/fortran/decl.cc @@ -12847,6 +12847,7 @@ const ext_attr_t ext_attr_list[] = { { "no_arg_check", EXT_ATTR_NO_ARG_CHECK, NULL }, { "deprecated", EXT_ATTR_DEPRECATED, NULL }, { "noinline", EXT_ATTR_NOINLINE, NULL }, + { "forceinline", EXT_ATTR_FORCEINLINE, NULL }, { "noreturn", EXT_ATTR_NORETURN, NULL }, { "weak", EXT_ATTR_WEAK, NULL }, { NULL, EXT_ATTR_LAST, NULL } @@ -12925,6 +12926,18 @@ gfc_match_gcc_attributes (void)sym->attr.ext_attr |= attr.ext_attr; + /* FORCEINLINE and NOINLINE are mutually exclusive. Inthe middle-end + DECL_UNINLINABLE (set by NOINLINE) always wins, so FORCEINLINE would + be silently ignored. Warn and drop it instead. */ + if ((sym->attr.ext_attr & (1 << EXT_ATTR_FORCEINLINE)) + && (sym->attr.ext_attr & (1 << EXT_ATTR_NOINLINE))) + { + gfc_warning (0, "Attribute %<FORCEINLINE%> at %C is incompatible " + "with %<NOINLINE%> for %qs and will be ignored", + sym->name); + sym->attr.ext_attr &= ~(1 << EXT_ATTR_FORCEINLINE); + } + if (gfc_match_eos () == MATCH_YES) break;diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.hindex 37a8582e36d..440ad050bcb 100644 --- a/gcc/fortran/gfortran.h +++ b/gcc/fortran/gfortran.h @@ -886,6 +886,7 @@ typedef enum EXT_ATTR_NO_ARG_CHECK, EXT_ATTR_DEPRECATED, EXT_ATTR_NOINLINE, + EXT_ATTR_FORCEINLINE, EXT_ATTR_NORETURN, EXT_ATTR_WEAK, EXT_ATTR_LAST, EXT_ATTR_NUM = EXT_ATTR_LAST diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi index a930cc1dc9c..255a9235f60 100644 --- a/gcc/fortran/gfortran.texi +++ b/gcc/fortran/gfortran.texi @@ -3397,6 +3397,11 @@ requires an explicit interface. deprecated procedure, variable or parameter; the warning can be suppressed with @option{-Wno-deprecated-declarations}. @item @code{NOINLINE} -- prevent inlining given function. +@item @code{FORCEINLINE} -- force inlining of a given function, ignoring the +inlining size limits. This is the counterpart of @code{NOINLINE} and +corresponds to the C @code{always_inline} attribute. @code{FORCEINLINE} and +@code{NOINLINE} are mutually exclusive; specifying both for the same procedure +makes @code{FORCEINLINE} ignored with a warning. @item @code{NORETURN} -- add a hint that a given function cannot return. @item @code{WEAK} -- emit the declaration of an external symbol as a weak symbol rather than a global. This is primarily useful in defining library diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans- decl.cc index 1bcbfdfd2c9..da291c976ba 100644 --- a/gcc/fortran/trans-decl.cc +++ b/gcc/fortran/trans-decl.cc @@ -2652,6 +2652,15 @@ build_function_decl (gfc_symbol * sym, bool global) if (attr.ext_attr & (1 << EXT_ATTR_NOINLINE)) DECL_UNINLINABLE (fndecl) = 1;+ /* Mark forceinline functions. Fortran has no 'inline'keyword, so set + DECL_DECLARED_INLINE_P as well; otherwise the middle-end warns that the + always-inline function "might not be inlinable". */ + if (attr.ext_attr & (1 << EXT_ATTR_FORCEINLINE)) + { + DECL_DECLARED_INLINE_P (fndecl) = 1; + DECL_DISREGARD_INLINE_LIMITS (fndecl) = 1; + } + /* Mark noreturn functions. */ if (attr.ext_attr & (1 << EXT_ATTR_NORETURN)) TREE_THIS_VOLATILE (fndecl) = 1; diff --git a/gcc/testsuite/gfortran.dg/forceinline_1.f90 b/gcc/testsuite/gfortran.dg/forceinline_1.f90 new file mode 100644 index 00000000000..2058c088662 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/forceinline_1.f90 @@ -0,0 +1,26 @@ +! { dg-do compile } +! { dg-options "-O -fdump-tree-optimized" } +! +! Verify that !GCC$ ATTRIBUTES forceinline forces inlining: the helper +! procedure is inlined into its caller and no standalone call remains. + +subroutine caller(a, n) + implicit none + integer, intent(in) :: n + real, intent(inout) :: a(n) + call helper(a, n) + call helper(a, n) +contains + subroutine helper(x, m) + implicit none + integer, intent(in) :: m + real, intent(inout) :: x(m) +!GCC$ ATTRIBUTES forceinline :: helper + integer :: i + do i = 1, m + x(i) = x(i) + 1.0 + end do + end subroutine helper +end subroutine caller + +! { dg-final { scan-tree-dump-not "helper" "optimized" } } diff --git a/gcc/testsuite/gfortran.dg/forceinline_2.f90 b/gcc/testsuite/gfortran.dg/forceinline_2.f90 new file mode 100644 index 00000000000..44e4c107034 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/forceinline_2.f90 @@ -0,0 +1,14 @@ +! { dg-do compile } +! +! FORCEINLINE and NOINLINE are mutually exclusive. Specifying both for the +! same procedure must warn and drop FORCEINLINE, whether they appear in one +! directive or in separate directives. + +subroutine foo() +!GCC$ ATTRIBUTES forceinline, noinline :: foo ! { dg-warning "FORCEINLINE. at .1. is incompatible with .NOINLINE." } +end subroutine foo + +subroutine bar() +!GCC$ ATTRIBUTES forceinline :: bar +!GCC$ ATTRIBUTES noinline :: bar ! { dg-warning "FORCEINLINE. at .1. is incompatible with .NOINLINE." } +end subroutine bar
