There was a question like this before, in 2011: Exotic architectures the standards committees care about
Now, I\'d like to ask a very similar question, but this time
Go looking for DSP cores, that's your best bet for "exotic" architectures.
For example, the Motorola/Freescale/NXP 56720 has a C++ compiler available from Tasking, but has 24-bit memory on three or more buses. I think the stack model on the device (at least the older 56K devices) was a hardware stack and didn't really fit the C/C++ model.
edit: more details...
The register model on this beast is odd:
The modulo and step size registers don't map to anything intrinsically modeled in C/C++, so there's always some oddball constructs and #pragma to help the compiler along to support circular buffers.
There's no stack pointer (no push or pop instruction). There's a hardware stack for function return addresses, but that's only 16 calls deep. The software has to manage overflows and local variables don't live in on the stack.
Because there's no stack, the compiler does weird things like static call tree analysis and puts local variables in overlayed memory pools. This means no re-entrant functions and necessarily only one context without much weirdness or severe performance penalties.
sizeof(int) = sizeof(char) = sizeof(short) = 1 = 24 bits
This means no byte access (at least on the old 56002, not sure about the 56300). I think it takes about 24 cycles to read/write a specific byte from an array of 24-bit integers. This core is not good and barrel shifting, masking, and or-ing
Not ALL DSP cores are like this of course, but they're usually varying degrees of 'weird' from the standard of 32/64 bit unified memory and sizeof(char)=1 expectations of GCC because of the intrinsic modulo pointers and multiple memory buses.