The compiler still generates st2 and ld2 pseudo-opcodes. I used a perl script to hack around this problem. This means that compiling now requires perl as well as the compiler driver, the preprocessor, the assembler, the compiler proper and the linker.
lcc-3.6 will not do 64-bit types. This means that low level file meddling can't be done with lcc-compiled programs. Luckily, stdio can be made to work, so all is not lost. There's an lcc-4.0 beta for DEC Alpha architecture that does do 64-bit types, so maybe effort should be delayed until the lcc-4.0 beta becomes 4.0 production.
The ANSI-C preprocessor that comes with lcc-3.6 doesn't act exactly like gcc's preprocessor. For example, a malloc-checking package may #define a macro for malloc(). The lcc cpp won't correctly expand the __P() macro for malloc in the system's /usr/include/stdlib.h.
The test cases distributed with lcc-3.6 are all based on doing a diff on "trusted" assembly code versus what the newly-built compiler outputs. NetBSD's assembler requires just enough differences in the assembly code to make this painful.