bugs

Here's a list of some known problems in nwcc 0.8.3. It is not exhaustive; Searching for XXX on the nwcc code or trying to build large programs should find some more. However, these are the documented bugs. Please contact me if you found other issues that aren't listed here.

Architecture-independent

Unacceptable

Macroscopic

The preprocessor is a death trap, and probably much less usable than the compiler
There is no test suite for cross-compilation, so it's probably full of bugs
nasm/yasm support is probably worse than gas support now, which is a result of the default assembler change (the default assembler - now gas - always receives the most testing and debugging)
The separation between GNU C, C90, C99 is quite incomplete

Microscopic

Flexible array member initializers
Missing bitfield diagnostics for too large initializers
GNU rules for bitfield types larger than int/uint
Putting __attribute__s randomly anywhere in a declaration
Nested designated initializers
Static compound literals in constant expressions
Various other address arithmetic constructs in constant expressions
_Bool in constant expressions
Designated initializers mixed with anonymous unions
attribute aligned for "unpleasant" requests, such as at the beginning of data/bss segments
K&R function parameter/argument semantics
__builtin_constant_p() and __builtin_compatible_types() seem to be commonly used, but still aren't supported

Acceptable

Macroscopic

Advanced VLAs (VLA struct members, VLA function parameters, VLA typedefs, sizeof(T[var-expr]))
Nested function definitions
Complex and imaginary numbers
Genuine wide character support

Microscopic

Empty structs and arrays (definitions, initializers, alignment and allocation rules, etc)
Local labels (__label__)
Liberal cast-less conversion between pointers and integers
Most builtins (strcpy(), prefetch(), all maths stuff, setjmp() [could be a problem], etc)
Most attributes (vector, etc)
Optimization things (assuming fabs() will be inlined in some cases, the absence of which will cause linker errors when not linking with -lm)
Redefinition of inline functions
Anonymous structs (as in the GNU extension)
Union/struct casts
Enum forward declarations
gcc peculiarities such as enum types being unsigned by default, order of function argument evaluation, etc

All non-x86

Small structs passed and returned by value are always incompatible with the standard ABI. Instead of registers, nwcc currently uses stack space to pass them

All RISC (SPARC, MIPS, PowerPC)

Bitfields are completely broken; The layout is not ABI compatible, bitfield initializers don't work at all, and other problems. Total showstopper on Solaris (due to FILE definition in stdio)!
There is no inline assembly support

x86

Floating point code might still trigger x87 register allocation bugs, though there are currently no known ones
When a generated function receives char/short arguments, stack frame space is being used (probably even redundantly) before updating the stack pointer; This may cause invalid page faults when crossing the boundary of the lowest allocated stack page
Inline assembly support is somewhat incomplete and weak

AMD64

long double might still be subject to x87 register allocation problems
Inline assembly is even weaker than on x86

MIPS

This backend has not been significantly debugged or tested in a long time! There are most likely lots of unknown or undocumented bugs

Structs cannot be passed by value to variadic functions
long double is treated like double, thus breaking gcc/MIPSpro and library copatibility
nwcpp does not fully work with the system headers yet
alloca() doesn't work

PowerPC

On PPC32, some floating point to integer conversions are unimplemented
On Linux/PPC64, long double is wrongly implemented in terms of double
On PPC32, there are still a few buggy long long operations and argument passing problems
On AIX, the -mminimal-toc option is unimplemented

SPARC

This backend has not been significantly debugged or tested in a long time! There are most likely lots of unknown or undocumented bugs

Structs cannot be passed by value to variadic functions
There may still be problems with large branch target offsets and large displacements
long double cannot be passed to variadic functions

As you can see, most of the obvious RISC problems relate to parts of variadic functions, parts of floating point - particularly long double - and inline assembly. That's because these things are among the most painful ones to implement, yet also among the least frequently used ones.

However, MIPS, PPC and SPARC haven't received the same amount of work as x86 and AMD64, so there are probably still many bugs in even very basic language constructs in those backends.

The priority of fixing a particular bug is generally somewhat proportional to its likelihood of being encountered in real world code. For example, I can't recall ever running into a program that passes a struct to a variadic function by value, or that uses MIPS inline assembly. So you can imagine that these things will take me longer to get right than most other features.

If you'd like me to fix a particular known bug that causes problems for you, feel free to contact me. I'm also open to feature requests.