Chris said:
[...]
The includes could be spliced in-line into the decrypted output,
could they not?
That would require a decryptor with most of the power
of the preprocessor: Able to parse #include lines (possibly
with macros), able to evaluate #ifdef and #if and so on,
searching for inclusions in the same places the compiler
would (taking the compiler's flags into account), generating
#line directives ...
Some of this power might not be needed in the O.P.'s
scenario (he might know that his generated code doesn't
use #ifdef, for example), but he hasn't said what features
of C he's willing to forgo.
It seems to me the O.P. is looking at the wrong piece
of the tool chain. An encrypted file system on a RAM disk
seems more suitable, putting the protect-the-source burden
on the compiler's environment rather than on the compiler
itself.
It also seems to me that the O.P.'s quest is ultimately
futile, since the Black Hats can replace his gcc with a
hacked version of their own, one that simply copies the
decrypted source to somewhere else. Perhaps it's time to
take a step back and ponder the reasons for wanting to shield
the source, and how much effort they justify.