Felix:

Found TF which cannot be processed on GPU but survives CPU code (peak RSS ~15GB).

Implemented more memory clearing in https://github.com/AliceO2Group/AliceO2/pull/14999 now the same TF survives on GPU (peak allocation ~18 GB).

Note though, that this is at the price of more device<->host<->device data movement.

This should care of the bulk of the (smallish) difference. Remaining: verify with deterministic mode (& maybe check impact on timing, although recovery of TF is more important).

 

To bring back a thing of the past. In the CI and also local compilations on EPNs I observe always errors of this kind:

```

In file included from /opt/rocm-6.3.2/lib/llvm/lib/clang/18/include/cuda_wrappers/bits/basic_string.h:7:
In file included from /usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/basic_string.h:40:
In file included from /usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/ext/alloc_traits.h:34:
/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/alloc_traits.h:272:8: warning: 'destroy<o2::its::TrackITSExt>' is deprecated: use 'allocator_traits::destroy' instead [-Wdeprecated-declarations]
  272 |         { __a.destroy(__p); }
      |               ^
/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/alloc_traits.h:378:4: note: in instantiation of function template specialization 'std::allocator_traits<std::pmr::polymorphic_allocator<o2::its::TrackITSExt>>::_S_destroy<std::pmr::polymorphic_allocator<o2::its::TrackITSExt>, o2::its::TrackITSExt>' requested here

```

Notice that I see something like c++/11/... from what I assume that this is pulling in c++11?

This is of course just a deprecation warning so not actually critical (for now...).

But David and I had a chat about this a while back and had the following problem:

Almost pseudo CMake code:

```

set(CMAKE_HIP_HOST_COMPILER "$ENV{GCC_TOOLCHAIN_ROOT}/bin/gcc")

message(STATUS "SETTING CMAKE_HIP_HOST_COMPILER to ${CMAKE_HIP_HOST_COMPILER}") 

enable_language(HIP)

message(STATUS "HIP language enabled: ${CMAKE_HIP_COMPILER}")

message(STATUS "COMPILER to ${CMAKE_HIP_HOST_COMPILER}")

```

Output

```

-- SETTING CMAKE_HIP_HOST_COMPILER to /home/fschlepp/alice/sw/slc9_x86-64/GCC-Toolchain/v14.2.0-alice2-2/bin/gcc

-- HIP language enabled: /opt/rocm/llvm/bin/clang++

-- COMPILER to

```

Somehow after enable_language the host compiler is reset to what? probably system.

Would be nice to somehow repair this.