Sergi Siso

new_symbol should also be careful with "RoutineSymbols" as renaming them can break the callercallee expectations

I will close this since it is a subset of #2592 functionality which will introduce the `routine.symbol`

Both solutions are fine and it's up to the caller to decide what it wants: renaming-import or exact name only. The only thing that is not good is that currently...

Going to the integration test folder with the debugger it shows: ``` Program received signal SIGSEGV, Segmentation fault. 0x00007fffc0a4bd26 in __pgi_uacc_rb_find (T=0x3fd8f5c28f5c28f6, key=41560128) at ../../src/rbtree.c:348 warning: 348 ../../src/rbtree.c: No such...

Also the log shows many `nvfortran-Warning- The -gpu=[no]managed option is deprecated; please use -gpu=mem:managed or -gpu=mem:separate instead"`, ~~aren't these updated in this PR?~~ Ah no, this lives inside the nemo...

yes, nemov4 now uses 25.1

The Symbol.is_array generic implementation is also probably wrong, it defaults to False when for a generic symbol we don't know, I think it is meant the be `is_array_access` mentioned above

I vote for 1. But why do we have to check for valid prefixes at all and not just be fine with what the user says in the transformation option?

If the reason is not clear I would prefer to remove the restriction altogether, sure that in general makes sense to do one profiling at a time, but I still...

I am not sure I understand the benefit of this (but it introduces some complexity with the implicit generic name). The type is still not in the metadata, to know...