TK Chia and others have been working on adding DOS C/C++ compiler-isms to GCC as well as improving the the codegen to make it more hospitable for DOS apps. So far, the FreeDOS kernel compilable by gcc-ia16.
It's more than that. It's also supporting the 16 bit Windows calling conventions, __ss pointers, __cs pointers, __huge pointers, etc. There's also dealing with chips that don't have an x87 processor.
OSI considers it valid[0]. The issue FSF has[1] is a requirement for publishing source code which IMO is very underspecified (i mean FSF's issue, not the license's which seems to not be anything special). I can't see how exactly that makes the license non-free, if anything it ensures the source will be available. The issues DFSG had can be found here[2] but they're also not something that would be an issue in practice for the compiler itself - the most practical issue would be the requirement to provide the code for a year but in practice OWv2 is published via GitHub anyway (and i doubt if it moved anywhere else anyone involved would say "no" if asked to provide sources in case they somehow become inaccessible to the entire internet before a year passes).
Also none of those are "not free enough" (FSF claims so but it doesn't seem to explain why) and they're really about the license itself, not how it applies in practice to OpenWatcom.
(FWIW: I'm in agreement with you that DMC++ is likely superior, I'm more curious about what OpenWatcom's deficiencies in relation to it are, and I reckon there are probably only a few people as familiar and qualified than yourself to comment)
When i made a small raytracing benchmark a few years ago[0] OpenWatcom produced better code than DMC (note it was C, not C++), though they were both crushed by Visual C++ 6.
Ok, i tried with the latest versions of both (DMC 8.57 - though the compiler advertises itself as 8.42n - and the latest build from OpenWatcom).
DMC version: Elapsed time = 7.593 seconds
OW2 version: Elapsed time = 6.344 seconds
While i'm using a different CPU than the one from the previous benchmark, the relative results are practically identical (OW version is ~1.195 times faster for the old results and ~1.196 with the new results). VC6 is still faster than both.
FWIW i do not think these different matter that much in practice anyway, if anyone is going to target those old machines nowadays it'd be for retrocoding fun and in those cases if performance is a concern you'd most likely just want to use assembly anyway. IMO as long as a compiler does some basic optimizations to get mostly there it is fine. Some years ago i wrote a small maze rasterizer[0] in C to run on an original IBM PC and i tried to compile it with both Turbo C and OpenWatcom... and there was zero difference in performance since the main render loop was done by generated machine code, so OW's optimizer was optimizing stuff that didn't really need optimizing anyway :-P.
Doom was written mainly in C but the important bits like the span rasterization for the DOS version were written in assembly. The released code was for the Linux version that didn't use assembly so the DOS was only as part of a README file[0]. The sound code was licensed (and thus never released to the public) and most likely also used assembly as that was common at the time.
Quake also used assembly for a few bits (also, like Doom, had C versions for portability).
That is what i meant when i wrote "use assembly", not to write the entire game in assembly (which is why i also gave my maze renderer as an example - pretty much all of it was in C except a tiny part).
I used Open Watcom 2 in production, together with JWasm and JWlink, everything worked perfectly. Though I remember a couple issues I had and reported mainstream, they fixed it relatively quickly.
