# Implementation of a parametrized objective function without using module variables or internal subroutines

**URL:** https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919
**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:** 1
**Showing post:** 41

<div class="post-metadata">

### 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")

</div>

> [@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 <binary>`,

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

```

---

_[View the full topic](https://fortran-lang.discourse.group/t/implementation-of-a-parametrized-objective-function-without-using-module-variables-or-internal-subroutines/9919)._