Trick ignores simulation build errors

[dandexter]

On Linux, I have noticed Trick will ignore errors encountered during the simulation build process and yet you will end up with a compiled and linked simulation executable. This is unacceptable behavior for simulations used for making engineering decisions, analysis, V&V, or interfacing with hardware like emulators. Unless you manually scroll through the console output for the entire sim build process you would not know there were errors and the sim should not be trusted for any verification or validation efforts.

By default, Trick should stop building a simulation when any error is encountered instead ignoring them.

For example, I see many errors like this one (related to issues #1553 and #1556):

/usr/include/wchar.h:155:24: error: '__malloc__' attribute takes no arguments
  __attribute_malloc__ __attr_dealloc_free;
                       ^

[amishscientist]

I would want to know what the return code the compiler is returning. If it is an error it should be non zero. That is the only thing make checks. I would just wrap that line in a script and check the return code. If the compiler is not signaling that it is an error that is one thing that is more complicated. It's nother if trick isn't getting the return code because something is masking it.

[alexlin0]

I am wondering if this is related to an older issue, #1095

[sharmeye]

This will require some investigation to determine why these errors are ignored and sim model errors are not.

[sharmeye]

This appears not to be an actual error. This "error" is coming from clang during ICG processing. This only seems to occur when gcc is defined as the compiler. It is known that clang and gcc 11 are incompatible because of, among other things, the change in the malloc call in gcc. Clang is throwing this "error" while parsing the gcc headers. No object is created, no compilation is occurring, and this behavior doesn't appear when compiler is chosen to be clang at configuration. We'll continue to investigate but this doesn't seem, at the moment, to be like something you would want to stop a compilation for, b/c no actual compilation error is occurring. All this does is stop ICG from processing gcc headers?

[dandexter]

My underlying concern still exists. The build process encountered an error during the ICG process and it was ignored. This resulted in a simulation being built with missing interfaces. It appears it was gcc in the issues cited but in general it appears ICG Errors are not caught and that is the point.

[hchen99]

The error msg was really clang diag msg not gcc compilation msg. The error shown in this issue is due to the incompatibility between clang and gcc. ICG could be customized to handle the clang diag msgs whichever way needed. However, ICG doesn't compile any code and it only generates certain files using certain aspect of clang that are to be compiled by gcc later. The real missing interfaces will result in compilation termination at gcc compilation phase.

[sharmeye]

I think we've answered this question and made the updates to go along with it. I'm going to close this issue as resolved.