The code in the iverilog 1171 issue is invalid and you should remove it from the list of issues found by this project. I have not outright rejected it from the Icarus side because there are enhancements we can implement to prevent iverilog from trying to do what the user asks when they are outside the realm of possibilities (e.g. creating exa-bit values). There are also still some outright invalid constructs in the simple example provided that I provided more details for today.
The reason iverilog appears to be hanging is it is being requested to create a value that is larger than will fit in memory. My guess is main memory is filling up and then the program starts swapping which makes it very slow to make progress, but if you check it should still be running and is diligently trying to create the value until it will eventually consume all the memory/swap on the machine. This could take a significant amount of time. The fact that other tools do not have an issue does not negate the fact that both the original and the updated code are doing something that should cause any simulator to run out of memory unless they have some very esoteric optimizations.
I have verified that one of the big-3 simulator fails on the code not because of memory, but because it does not support all the expression constructs in the given context.
pronesto
commented
1 month ago
The code in the iverilog 1171 issue is invalid and you should remove it from the list of issues found by this project. I have not outright rejected it from the Icarus side because there are enhancements we can implement to prevent iverilog from trying to do what the user asks when they are outside the realm of possibilities (e.g. creating exa-bit values). There are also still some outright invalid constructs in the simple example provided that I provided more details for today.
The reason iverilog appears to be hanging is it is being requested to create a value that is larger than will fit in memory. My guess is main memory is filling up and then the program starts swapping which makes it very slow to make progress, but if you check it should still be running and is diligently trying to create the value until it will eventually consume all the memory/swap on the machine. This could take a significant amount of time. The fact that other tools do not have an issue does not negate the fact that both the original and the updated code are doing something that should cause any simulator to run out of memory unless they have some very esoteric optimizations.
I have verified that one of the big-3 simulator fails on the code not because of memory, but because it does not support all the expression constructs in the given context.