Unfortunately Doom has a lot of undefined behavior (because it's a 30 year old codebase) so if you enable UBSAN you're inundated with warnings. Finding this specific needle in that haystack would take quite a lot of effort.
> Right, my humor there was that I'm assuming people specifically did non-debug flags for the build as an optimization.
It used to be the case that the presence of debug symbols would affect GCC code generation. Nowadays that should be fixed. I think it still affects the speed of compilation so if you're building the whole system from source you might want to avoid it.
> In theory it should only be about writing a new build script (not based on `wmake` but on a real `make`). And then workout the tiny flag/preprocessor/C compiler discrepancies.
For mostly C code like the original Doom source, yes. But it looks like FastDoom people have added quite a bit of assembly. That needs to be ported to AT&T syntax. Or you need to find out if Intel syntax works in your version of DJGPP's gas. While this should work nowadays I have not tried it. Then there's other differences like Watcom mapping low memory by default into the low part of the address space but DJGPP needing explicit mapping or access.
