NVHPC allocation bug from fArgParse

[mwaxmonsky]

Using several of the latest releases on different versions of nvhpc on our Derecho system, we are seeing large allocation requests made by the line __T_COPY__(p%second, value) in pFUnit/extern/fArgParse/extern/gFTL-shared/extern/gFTL/include/v2/map/procedures.inc that results in the error:

0: ALLOCATE: 5188444652495619912 bytes requested
[Inferior 1 (process ****) exited with code 0177

From the stack trace:

(gdb) bt
#0  fp_stringactionmap::map_insert_key_value (this=..., key=..., value=...)
    at /src/submodules/pFUnit/extern/fArgParse/extern/gFTL-shared/extern/gFTL/include/v2/map/procedures.inc:180
#1  0x0000000000d83835 in fp_argparser::initialize_registry (this=...)
    at /src/submodules/pFUnit/extern/fArgParse/src/ArgParser.F90:120
#2  0x0000000000d8317b in fp_argparser::initialize (this=..., program_name=...)
    at /src/submodules/pFUnit/extern/fArgParse/src/ArgParser.F90:91
#3  0x0000000000d7ffce in fp_argparser::new_argparser_empty (program_name=...)
    at /src/submodules/pFUnit/extern/fArgParse/src/ArgParser.F90:77
#4  0x0000000000d1157f in set_command_line_options ()
    at /src/submodules/pFUnit/src/funit/FUnit.F90:373
#5  0x0000000000d029f9 in funit::generic_run (load_tests=0xe0ec8148e5894855, 
    context=...)
    at /src/submodules/pFUnit/src/funit/FUnit.F90:68
#6  0x000000000041f079 in pfunit::run (load_tests=-443987883)
    at /src/submodules/pFUnit/src/pfunit/pFUnit.F90:114
#7  0x000000000041daae in funit_main (load_tests=-443987883, 
    extra_initialize=-443987883, extra_finalize=-443987883)
    at /src/submodules/pFUnit/src/pfunit/pfunit_main.F90:16
#8  0x000000000041bb4e in main ()
    at /src/bin/nvhpc/run/unit-tests/interface/pfunit_example_test.F90:80

it looks like there is an uninitialized value in the p%second container:

(gdb) print p%second
$2 = ( abstractaction = (  ), destination = '\000', option_strings = ( elements = <not allocated>, vsize = 0 ), type = '\000', const = (  ), default = (  ), help = '\000', n_arguments = (  ), positional = .FALSE., choices = ( elements = <not allocated>, vsize = 0 ) )
(gdb) print value
$3 = ( abstractaction = (  ), destination = '\000', option_strings = ( elements = <not allocated>, vsize = 0 ), type = '\000', const = (  ), default = (  ), help = '\000', n_arguments = (  ), positional = .FALSE., choices = ( elements = <not allocated>, vsize = 0 ) )

Considering this works on GNU and Intel, I was thinking this might be an internal compiler exception but before running down the Nvidia engineers, I wanted to check if this might be undefined behavior in Fortran and instead the elements field should be defaulted to some value and GNU and Intel just happen to hide a potential issue?

I'm happy to send this over to Nvidia if this is on their end but wanted to check here first in case I'm missing an obvious issue with Fortran.

The issue is reproducible in our workflows using the stock ubuntu-latest images as well (https://github.com/TURBO-ESM/turbo-stack/actions/runs/25122445941/job/73626490516?pr=131)