Setting of a generic at elaboration in OSVVM co-sim tests causes crash

[wyvernSemi]

Two of the OSVVM co-simulation tests set top level generics using the -g elaboration option, but this crashes the process with the following output:

nvc --std=08 -H 128m --work=osvvm_CoSim_TbAxi4:/home/simon/OSVVM/nvc/VHDL_LIBS/nvc-1.9-devel/OSVVM_COSIM_TBAXI4 -L /home/simon/OSVVM/nvc/VHDL_LIBS/nvc-1.9-devel -e -gINT_POLARITY='0' TbAb_InterruptCoSim2
** Fatal: type kind T_SUBTYPE does not have item I_LITERALS
[0x40a170] ../src/object.c:211 object_lookup_failed
[0x409e15] ../src/type.c:372 type_enum_literal.cold
[0x44c967] ../src/elab.c:1703 elab_top_level_generics
[0x44c967] ../src/elab.c:1812 elab_top_level
[0x44cddd] ../src/elab.c:1888 elab
[0x40d270] ../src/nvc.c:358 elaborate
[0x40d270] ../src/nvc.c:1387 process_command
[0x40a76e] ../src/nvc.c:1512 main

Removing the -g from the command line and the elaboration does not fail. it does not matter whether the options sets the value to that already the default, or sets it a different value.

I have adapted the bundle for #612 to add generics and set them with the compile.sh script. It will pass when no generic option given and crash when one is.
testcase.tar.gz

[JimLewis]

@wyvernSemi Thanks for reporting this one. I was just coming out to do that.

[nickg]

The -g option didn't work with subtypes of enumerated types. Should be fixed now.

[JimLewis]

Thanks Nick

[wyvernSemi]

All OSVVM co-simulation tests are now passing on both Linux and Windows/MSYS2 in my development tree. On MSYS2 I needed to change the elaboration option to use normal --load option for foreign code instead of the NVC_FOREIGN_OBJ environment variable as per the workaround for issue #581. As this issue is closed now I'm guessing that the changes also removed the environment variable as this no longer worked. This means that the co-simulation features won't work on Windows/MSYS2 for the latest release of OSVVM 2023.01, which uses the environment variable, but should be fixed at the next release.

[nickg]

Yes sorry I should have mentioned on the other ticket instead of just closing it: Windows now works the same as Linux where the plugin is only needed at runtime with the --load option and not linked directly against the DLL generated from the VHDL code.