You are right that using different setups for your tests can increase the chance of accidentally stumbling on some bugs. However, you should consider whether setting up a another testing rig makes sense from a business perspective of things – I suspect you want to sell or distribute useful code, rather than crafting The Perfect Code in your ivory tower.

I worry with the dominance of X86/AMD64 our code-base may unknowingly become less portable.

If your code only ever runs on x86 or AMD64 architectures, then there is little use for testing on other architectures – YAGNI applies here. You’d be better off by expanding your test suite to guarantee all documented behaviour, and by purging the code base of dubious constructs with the help of linters. Using multiple different compilers on different settings is also a low-cost, high-impact strategy for discovering bugs (e.g. GCC and Clang).

If however you explicitly support certain combinations of architectures and operating systems, you should also test those combinations.

If you nevertheless do want to test some more alien setups that are still used fairly commonly, I would recommend:

• Architecture: SPARC. OSes: Solaris family, Linux, BSD family. Endianness: big, possibly bi. Comments: massive parallelism.

• Architecture: ARM. OSes: Linux, BSD family, OpenSolaris. Endianness: little, possibly bi. Comments: used in embedded devices, mobile phones.

The features you listed can be tested by varying the following components in the setup:

• Endianess: architecture.
• Threading: OS, kernel settings, threading libraries, number of processors.
• Stack: ?
• Primitive sizes: preprocessor directives, compiler settings.
• Struct alignment: compilers.
• Optimizations: compiler settings.
• Other: compile using different libc implementations.

My primary exposure to cross-platform programming is reading through the source of the Perl interpreter. Here portability issues are adressed by:

• … detecting features provided by the used libc implementation, possibly substituting custom functions. This information is then recorded as a set of preprocessor definitions before compilation.
• … pervasively using macros for numeric types. The sizes can be set during compilation.
• … making threading optional, as the unthreaded version performs better. In the code, some sections are executed only when compiled with threading support.
• … mostly ignoring endianess, as this tends to sort itself out. Endianness only becomes relevant when doing something like interpreting a given bit pattern as a 16-bit BE number on a LE system.
• … explicitly listing supported platforms and also documenting portability issues or differing behaviour on these platforms.
• … running a huge test suite incl. a ton of regression tests that are executed on a network of CI boxes.

I think you’ve probably covered much of this already, but I’d give some further consideration to:

• Low memory environment, e.g. mobile with small RAM or embedded devices. While your current customers may not need this, who knows if your library is suddenly in huge demand for engine management systems or home routers.
• Highly concurrent environment, e.g. more threads and cores than you’ve ever considered possible. While you may have single-threaded and multi-threaded code paths as a compile option, it’s possible that a massive number of threads may expose contention you didn’t know you had.
• Can I supply my own allocators? If not, what happens if I redefine malloc or operator new() to use a slab allocator or otherwise non-standard memory mechanism – can your code still cope?
• Are you relying on initialisation order anywhere? Any statically-allocated variables?