No, Vely does not understand C. Yes, gcc produces error messages when it comes to C code itself. However, the line number where the issue is located is exactly matched to the Vely source code using #line directive, so I would say 90+% of the time you don't have to look at the generated code. If that is not enough, you can use --c-lines to get the error reported from generated code, which is the exact error, and in that case, yes like you said you need to look at the generated code. Most of the time, however, just looking at the exact embedded statement is enough to figure out what the problem is.

I mentioned in another post that a C program could be parsed to the extent to allow better checking. Not to the point where you'd build a gcc-look-alike, but just enough for instance to know the type of the expression, and if the expression used in Vely statement is correct, and such. Perhaps that's something to consider. I thought about it here and there, but found it to be more useful to check for logical conflicts, such as not providing required arguments, balancing beginning and end of multi-part statement, incorrect usage and such. Typically, using the wrong type accounts for most of the issues, and gcc produces very good messages. Again those messages get matched to the source Vely file exact line number, and I found that correcting an issue isn't difficult.

Your tool sounds great, and if it works what you need it do, awesome! I do things like that all the time, and find that often times using tools is an overkill, and just skip it. There's time and place for everything.