Instead of testing compilation with GHDL's mcode backend only, this PR adds another job for testing with GHDL's LLVM backend too. However, GHDL LLVM chokes on the usage of pin_bit_information in libraries ibm and clib. I asked Tristan about it in ghdl/ghdl#1772.
The last commit in this PR comments all those attributes so that GHDL can analyse/elaborate them. Yet, Tristan commented:
But in fact the aggregate is not valid. The type is an array of an array of a string, but the length of the strings is not the same.
This is not the reason of the crash, but even if the feature were handled, the source won't be analyzed successfully.
Therefore, I will mark this PR as draft, for discussion. If those attributes are used 200+ times in this codebase, I would expect them to be supported in whichever internal VHDL simulator/synthesiser used in IBM.
Instead of testing compilation with GHDL's mcode backend only, this PR adds another job for testing with GHDL's LLVM backend too. However, GHDL LLVM chokes on the usage of
pin_bit_information
in librariesibm
andclib
. I asked Tristan about it in ghdl/ghdl#1772.The last commit in this PR comments all those attributes so that GHDL can analyse/elaborate them. Yet, Tristan commented:
Therefore, I will mark this PR as draft, for discussion. If those attributes are used 200+ times in this codebase, I would expect them to be supported in whichever internal VHDL simulator/synthesiser used in IBM.