# Implementation of a parametrized objective function without using module variables or internal subroutines **URL:** \ **Category:** Uncategorized\ **Created:** [July 13, 2025, 3:28am UTC](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919 "2025-07-13T03:28:14Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![zaikunzhang](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/zaikunzhang/32/785_2.png) [@zaikunzhang](https://fortran-lang.discourse.group/u/zaikunzhang)\ **Post date:** [July 14, 2025, 7:34am UTC](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919/22 "2025-07-14T07:34:09Z")
> [@ivanpribec](#): > > There is not a single occurence of the word “thread” in the Fortran standard (J3/24-007). So thread-safety is something beyond the Fortran standard. Then let us use “recursion-safe”. I do believe “recursion” is a subject of Fortran standards. Module variables are not recursion-safe. I have observed this in real applications. Or let me put it in this way: how to implement the code in my question without using module variables or internal procedures? We want to avoid these two constructs for what so ever reason that is unspecified. Thanks. ---
**Author:** ![chchanvit](https://avatars.discourse-cdn.com/v4/letter/c/a88e4f/32.png) [@chchanvit](https://fortran-lang.discourse.group/u/chchanvit)\ **Post date:** [July 14, 2025, 2:03pm UTC](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919/23 "2025-07-14T14:03:31Z")
@zaikunzhang I think the answer to your question is that of @RonShepard, which posted it at the same time as you posted. Therefore, I think you might miss it. ---
**Author:** ![zaikunzhang](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/zaikunzhang/32/785_2.png) [@zaikunzhang](https://fortran-lang.discourse.group/u/zaikunzhang)\ **Post date:** [July 14, 2025, 2:16pm UTC](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919/24 "2025-07-14T14:16:44Z")
Thank you @chchanvit. But I hope the implementation of such a basic use case will not depend on external libraries like OpenMP. Why is it basic? It is essentially an example from the Fortran standard, which implements it using internal procedures. I have been hoping that it can be implemented using derived types (this does **not** mean to change the interface of `solver` to accept a derived type as an input), but my knowledge about derived types is not sufficient, and nobody has suggest such a solution yet. The LLMs have attempted in this direction but none of them has suggested a valid implementation. ---
**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\ **Post date:** [July 14, 2025, 2:33pm UTC](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919/25 "2025-07-14T14:33:32Z")
> [@zaikunzhang](#): > > Why is it basic? It is essentially an example from the Fortran standard, which implements it using internal procedures. At this level you need to distinguish, the Fortran standard from a Fortran processor _implementation_. Older versions of GCC (pre 13) chose a particular design implementations (executable stack) which has become problematic in recent years due to increased cyber-security concerns. It seems the initial effort to introduce internal procedures as arguments into `gfortran` started back in 2010: [Tobias Burnus - RFC: Function pointer to internal function](https://gcc.gnu.org/legacy-ml/gcc-patches/2010-09/msg00211.html) Flang for instance chose a different approach, also using trampolines: [Trampolines for pointers to internal procedures. — The Flang Compiler](https://flang.llvm.org/docs/InternalProcedureTrampolines.html) ---
**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\ **Post date:** [July 14, 2025, 2:34pm UTC](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919/26 "2025-07-14T14:34:15Z")
> [@zaikunzhang](#): > > My approach is to use an internal procedure as you mentioned. But this leads to executable stack, which is a security issue. It is not allowed on some systems, and it causes a segfault of MATLAB R2025a. > > Another approach is to pass the hyperparameter using a module variable, but it is not thread-safe or recursion-safe? > > Is it possible to have a standard-confirming implementation that is thread-safe without internal procedures? I think currently you have to use internal procedures. For example the NAG compiler implements them without executable stack and it does support recursion (I am not sure about thread safety, but I think it might be related). How would you do this in C? Isn’t this exactly the same problem as in Fortran? For this reason most 3rd party libraries allow you to pass user data. If they don’t, that’s a deficiency of the 3rd party library I think. Then you have to be careful about recursion/threads, as you pointed out. ---
**Author:** ![zaikunzhang](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/zaikunzhang/32/785_2.png) [@zaikunzhang](https://fortran-lang.discourse.group/u/zaikunzhang)\ **Post date:** [July 14, 2025, 2:37pm UTC](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919/27 "2025-07-14T14:37:03Z")
> [@ivanpribec](#): > > At this level you need to distinguish, the Fortran standard from a Fortran processor _implementation_. I mean the Fortran standard itself. See the example in Note 12.18 on page 290 of WD 1539-1 J3/10-007r1, F2008 Working Document. ---
**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\ **Post date:** [July 14, 2025, 2:43pm UTC](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919/28 "2025-07-14T14:43:22Z")
> [@zaikunzhang](#): > > My approach is to use an internal procedure as you mentioned. But this leads to executable stack, which is a security issue. It is not allowed on some systems, and it causes a segfault of MATLAB R2025a. All I’m trying to say is, this isn’t an issue of the Fortran standard, but a particular version of the compiler you are using (potentially indirectly through the MATLAB MEX tools). Other compiler-implementors have found ways to handle this problem in a way that doesn’t require an executable stack. ---
**Author:** ![zaikunzhang](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/zaikunzhang/32/785_2.png) [@zaikunzhang](https://fortran-lang.discourse.group/u/zaikunzhang)\ **Post date:** [July 14, 2025, 2:46pm UTC](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919/29 "2025-07-14T14:46:17Z")
I hope Fortran is more capable than C in this respect, because Fortran is supposed to be **the** language for scientific computing. In modern/popular languages such as C++, Python, Julia, and MATLAB, this can be implemented easily using closures, lambda expressions, anonymous functions, … ---
**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\ **Post date:** [July 14, 2025, 3:11pm UTC](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919/30 "2025-07-14T15:11:15Z")
> [@zaikunzhang](#): > > In modern/popular languages such as C++, Python, Julia, and MATLAB, this can be implemented easily using closures, lambda functions, anonymous functions, … I am not sure you can use a lambda function to pass to a C library that only expects a pointer, without user data. Here is an example: [https://grok.com/share/bGVnYWN5\_f8024618-48cd-41c0-b0ed-102f3cfbf8cc](https://grok.com/share/bGVnYWN5_f8024618-48cd-41c0-b0ed-102f3cfbf8cc) Can you provide C++ code that does what you want? Then we can brainstorm how to do it in Fortran. ---
**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\ **Post date:** [July 14, 2025, 3:24pm UTC](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919/31 "2025-07-14T15:24:00Z")
> [@zaikunzhang](#): > > In modern/popular languages such as C++, Python, Julia, and MATLAB, this can be implemented easily using closures, lambda expressions, anonymous functions, … There are some fundamental problems here for languages like C and Fortran, more details here: [Funarg problem - Wikipedia](https://en.wikipedia.org/wiki/Funarg_problem). With C++ the situation is a bit different; lambdas and `std::function` work well when used within the confines of C++, but as @certik has just alluded, it faces the same limitations when trying to pass code and data across language boundaries. For example a lambda function can be converted to a C compatible function pointer, [only under certain restrictions](https://stackoverflow.com/a/28746827/4283055), namely that it doesn’t capture any variables from the enclosing scope. As @themos has written [before,](https://fortran-lang.discourse.group/t/is-it-possible-to-define-the-product-of-2-procedure-pointers-at-runtime/7450/13) > Personal take: The essence of Fortran is that all executable code is present at program start. Fortran will not compose executable code at runtime, and if it ever does it shouldn’t be called Fortran anymore. In Fortran, data comes and goes but code is written in stone. To tie back to what @certik said, > [@certik](#): > > How would you do this in C? Isn’t this exactly the same problem as in Fortran? For this reason most 3rd party libraries allow you to pass user data. If they don’t, that’s a deficiency of the 3rd party library I think. To achieve the parameterized function while preserving reentrancy, the `solver` would need to “open” a way to pass data (in C this would be the `void *` omni-parameter). ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [July 14, 2025, 4:38pm UTC](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919/32 "2025-07-14T16:38:29Z")
> [@ivanpribec](#): > > As @themos has written [before,](https://fortran-lang.discourse.group/t/is-it-possible-to-define-the-product-of-2-procedure-pointers-at-runtime/7450/13) > > > Personal take: The essence of Fortran is that all executable code is present at program start. Fortran will not compose executable code at runtime, and if it ever does it shouldn’t be called Fortran anymore. In Fortran, data comes and goes but code is written in stone. I think this might be overstating the case a little, but basically I agree with the idea. In a von Neumann machine, both machine instructions and data are treated the same, both modifiable at runtime, and even in a self-modifying way. Prior to that development, the instructions were typically encoded on, for example, paper tape and could not be modified by the program at run time. In a similar way, in a Harvard machine the instructions and the data are kept separate, and for both security reasons and performance reasons, the instructions are usually compiled before execution and kept fixed, while the data can grow, shrink, and of course be modified at run time. On machines that allow it, I have seen self-modifying code written in fortran (although not exactly within the standard, so it is nonportable and of course very machine-specific). The idea is to take a simple function that requires only a few instructions. An example might be a function that squares it argument. When that function is called the first time, it places the result in the return register in the usual way, but then it goes on and looks at the return address and modifies the calling sequence at that point of the code to eliminate the branch-store-branch-retrieve function operations and to place the function evaluation operations inline. If the calling code ever executes the instructions at that address again, then the function operation is effectively evaluated inline with no overhead associated with the branch-store-branch-retrieve function call. When the calling overhead associated with functions and subroutines is slow, as it was for early computers, this is a significant performance improvement, and it allows the high-level code to be written in a way that requires the function evaluation to be written only once and used any number of times by the calling program. Of course, in modern times with multiuser machines on networks it is easy to see how such a programming approach could be abused, so this kind of self-modifying code is not allowed by most modern operating systems. This also brings up the difference in compiled and interpreted languages. In an interpreted language, the compilation steps, turning human readable character sequences into machine instructions, is done at run time, and often only a single instruction or a small group of instructions at a time. In the languages that work this way, the instructions are often discarded immediately after they are used, and if that section of code is executed again, they are regenerated, used, and discarded repeatedly. I have wondered how the efforts related to interpreted versions of fortran fit with this model. ---
**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\ **Post date:** [July 14, 2025, 6:20pm UTC](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919/33 "2025-07-14T18:20:16Z")
> [@ivanpribec](#): > > To achieve the parameterized function while preserving reentrancy, the `solver` would need to “open” a way to pass data (in C this would be the `void *` omni-parameter). The other way is to use internal functions. For example the NAG compiler implements them without executable stack by using global context, and the user callback examines this global context and finds the appropriate data (parent scope variables) so that it works correctly with recursion etc. I am not sure if it is thread safe, but I think it could be made thread safe as well. (LFortran also uses this technique, but so far we only implemented one level global context, so it’s not thread safe yet.) ---
**Author:** ![Harper](https://avatars.discourse-cdn.com/v4/letter/h/b5ac83/32.png) [@Harper](https://fortran-lang.discourse.group/u/Harper)\ **Post date:** [July 14, 2025, 11:16pm UTC](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919/34 "2025-07-14T23:16:29Z")
There is a way to have executable code not present at program start: with `execute_command_line(command)` where `command` is a character string evaluated at run time. The problem with it is of course that it’s different in different operating systems. ---
**Author:** ![zaikunzhang](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/zaikunzhang/32/785_2.png) [@zaikunzhang](https://fortran-lang.discourse.group/u/zaikunzhang)\ **Post date:** [July 15, 2025, 12:07am UTC](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919/35 "2025-07-15T00:07:31Z")
> [@certik](#): > > Can you provide C++ code that does what you want? Then we can brainstorm how to do it in Fortran. I don’t program in C++. So I refer to [Lambdas and Closures in C++. A lambda function is a function that… | by Pranay Kumar | Medium](https://pranayaggarwal25.medium.com/lambdas-closures-c-d5f16211de9a) : _A_ _ **closure** _ _is any function that_ _ **closes over** _ _the_ _ **environment** _ _in which it was defined. This means that it can access variables, not in its parameter list._ My understanding may be wrong. ---
**Author:** ![zaikunzhang](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/zaikunzhang/32/785_2.png) [@zaikunzhang](https://fortran-lang.discourse.group/u/zaikunzhang)\ **Post date:** [July 15, 2025, 12:14am UTC](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919/36 "2025-07-15T00:14:04Z")
> [@ivanpribec](#): > > As @themos has written [before,](https://fortran-lang.discourse.group/t/is-it-possible-to-define-the-product-of-2-procedure-pointers-at-runtime/7450/13) > > > Personal take: The essence of Fortran is that all executable code is present at program start. Fortran will not compose executable code at runtime, and if it ever does it shouldn’t be called Fortran anymore. In Fortran, data comes and goes but code is written in stone. This is very interesting. Then what do you think about the examples mentioned below? @ivanpribec > [@zaikunzhang](#): > > see a [similar example](https://fortran-lang.discourse.group/t/is-creating-nested-subroutines-functions-considered-good-practice-in-fortran/6545/17) of root finding by @ivanpribec in a [previous discussion](https://fortran-lang.discourse.group/t/is-creating-nested-subroutines-functions-considered-good-practice-in-fortran/6545) if mine is not clear enough; see also the example in Note 12.18 on page 290 of WD 1539-1 J3/10-007r1, F2008 Working Document. ---
**Author:** ![jwmwalrus](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jwmwalrus/32/4483_2.png) [@jwmwalrus](https://fortran-lang.discourse.group/u/jwmwalrus)\ **Post date:** [July 15, 2025, 12:48am UTC](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919/37 "2025-07-15T00:48:31Z")
Fortran internal procedures are not real closures (since the scope in which they are defined does not survive the parent’s call). GCC has nested functions for C, but it’s just an extension (that was probably used as a basis for gfortran’s internal procedures). Since newer versions of gfortran seem to fix the issue of executable stack, you may want to try those… …Or combine @ivanpribec 's and @RonShepard 's answers for a module-based approach. ---
**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\ **Post date:** [July 15, 2025, 2:47am UTC](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919/38 "2025-07-15T02:47:29Z")
> [@zaikunzhang](#): > > I don’t program in C++. So I refer to [Lambdas and Closures in C++. A lambda function is a function that… | by Pranay Kumar | Medium](https://pranayaggarwal25.medium.com/lambdas-closures-c-d5f16211de9a) : > > _A_ _ **closure** _ _is any function that_ _ **closes over** _ _the_ _ **environment** _ _in which it was defined. This means that it can access variables, not in its parameter list._ > > My understanding may be wrong. This is correct. But you cannot pass the C++ lambda function into some function call that expects a function pointer. To be specific, I think you can pass it as long as the lambda function does not capture any variables, but that’s not what you were asking above. Thus it seems what you are asking is possible in neither C++ nor Fortran. However, maybe you are asking about the following (please correct me if I am wrong): within C++, you can indeed use lambda functions with `std::function`, as @ivanpribec mentioned above, and it will pass in the context correctly. And you are asking for an equivalent feature in Fortran: so that you can write a library in Fortran that expects just a function call (not just a C function pointer, but an equivalent of `std::function`, that can accept a context implicitly as a language feature) and you want to be able to pass in a context, just like lambda functions allow in C++. Is this what you are asking? ---
**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\ **Post date:** [July 15, 2025, 7:54am UTC](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919/39 "2025-07-15T07:54:28Z")
The example in Note 12.18 (omitting the interface for procedure `integrate`) is, ```auto REAL FUNCTION MY_INTEGRATION(N, A, B) RESULT(INTEGRAL) ! Integrate f(x)=x^n over [a,b] USE ISO_C_BINDING INTEGER, INTENT(IN) :: N REAL, INTENT(IN) :: A, B INTEGRAL = INTEGRATE(MY_F, REAL(A, C_FLOAT), REAL(B, C_FLOAT)) ! This will call the internal function MY_F to calculate f(x). ! The above interface of INTEGRATE must be explicit and available. CONTAINS REAL(C_FLOAT) FUNCTION MY_F(X) BIND(C) ! Integrand REAL(C_FLOAT), VALUE :: X MY_F = X**N ! N is taken from the host instance of MY_INTEGRATION. END FUNCTION END FUNCTION MY_INTEGRATION ``` The internal procedure is compiled into the executable: [https://godbolt.org/z/fq6ofsb4E](https://godbolt.org/z/fq6ofsb4E) ---
**Author:** ![zaikunzhang](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/zaikunzhang/32/785_2.png) [@zaikunzhang](https://fortran-lang.discourse.group/u/zaikunzhang)\ **Post date:** [July 15, 2025, 8:27am UTC](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919/40 "2025-07-15T08:27:35Z")
> [@ivanpribec](#): > > All I’m trying to say is, this isn’t an issue of the Fortran standard, but a particular version of the compiler you are using (potentially indirectly through the MATLAB MEX tools). MATLAB plays the least role in the topic under discussion. Whether it works or not does not affect how Fortran should fix this issue. I mentioned it just in case it is useful to someone. Please ignore it. > [@ivanpribec](#): > > Other compiler-implementors have found ways to handle this problem in a way that doesn’t require an executable stack. Excuse me for being frank, but this is not more than wishful thinking as of today. Even gfortran has not fixed it yet up to version 14.2.0, if ever (see below). I have not tested ifx. I will not see this as being fixed until **three years** after both `ifx` and `gfortran` have fixed it. Why three years? Because major operating systems do not adopt the latest versions of compilers for stability. For example, the latest LTS of Ubuntu, namely 24.40, takes gfortran-13, which was released in 2023. ```bash $ gfortran-14 --version && gfortran-14 -std=f2008 -Wall optim.f90 -o optimize GNU Fortran (Ubuntu 14.2.0-4ubuntu2~24.04) 14.2.0 Copyright (C) 2024 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. /usr/bin/ld: warning: /tmp/ccT3VNhU.o: requires executable stack (because the .note.GNU-stack section is executable) ``` ---
**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\ **Post date:** [July 15, 2025, 8:38am UTC](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919/41 "2025-07-15T08:38:31Z")
> [@fedebenelli](#): > > -ftrampoline-impl=heap And what about with this option: [Code Gen Options (Using the GNU Compiler Collection (GCC))](https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-ftrampoline-impl) ? The software supply chain can only move at the rate of the slowest link. The longer you stick with old tools, the longer they’ll need to be around, and the longer you’ll be subject to the security vulnerability. Edit: I just checked on SLES 15 ```txt > gfortran --version GNU Fortran (Spack GCC) 14.2.0 ... > gfortran optim.f90 /usr/bin/ld: warning: /tmp/cccpkks1.o: requires executable stack (because the .note.GNU-stack section is executable) > gfortran -ftrampoline-impl=heap optim.f90 > ``` One can verify that the routines to allocate the trampoline on the heap (i.e. `__gcc_nested_func_ptr_*`) are now used: ```txt > gfortran -ftrampoline-impl=stack optim.f90 /usr/bin/ld: warning: /tmp/ccxoR5pl.o: requires executable stack (because the .note.GNU-stack section is executable) > nm -u a.out U _gfortran_set_args@GFORTRAN_8 U _gfortran_set_options@GFORTRAN_8 w __gmon_start__ U __libc_start_main@GLIBC_2.34 > gfortran -ftrampoline-impl=heap optim.f90 > nm -u a.out U __gcc_nested_func_ptr_created@GCC_14.0.0 U __gcc_nested_func_ptr_deleted@GCC_14.0.0 U _gfortran_set_args@GFORTRAN_8 U _gfortran_set_options@GFORTRAN_8 w __gmon_start__ U __libc_start_main@GLIBC_2.34 ``` To verify you can also look into the ELF binary with the command `readelf -l `, With `gfortran -ftrampoline-impl=stack`: ```txt GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 0x10 ``` RWE for Read,Write,Execute With `gfortran -ftrampoline-impl=heap` ```txt GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 0x10 ``` The E is gone now. With `ifx` I get no linker warning, and `readelf -l` shows: ```txt GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 0x10 ``` Same for `nagfor`, no linker warning, and only read,write: ```txt GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 0x10 ``` [Previous page](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919.md?page=1) [Next page](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919.md?page=3)