Alright here we go… and let me preface this with saying that I’m sorry for not being more uplifting in the following.
ARMv7 (which is likely what you are targeting) is a 32bit target, as is JavaScript, WASM, and i386. Today most of modern computing runs on 64bit machines across the major operating systems (Windows, Linux, macOS, iOS). With some reservations for Android on 32bit arm, MIPS and others.
My firm belief is that ghc on armv7 is the least (by a wide margin) tested compiler. The amount of minor linking bugs and others that were fixed just over the last few month don’t make me too hopeful either.
armv7 is also severely constraint in concurrency primitives, potential softfloat and other mild annoyances like thumb/non-thumb interworking when linking foreign libraries, …
My suggestion would be to use a 64bit operating system on your raspberry pi3, if you can, and use a recent ghc 8.10.4+. Anything prior to 8.10.3 is pretty much guaranteed to not be thread safe.
That being said, yes you can use haskell on raspberry pis, we even have relatively large haskell projects like that cardano-node running on raspberry pis. (Now whether or not that’s a good idea and if the raspberry pi is actually powerful enough to run a node right now sufficiently is a different question, but you can run it on a raspberry pi without segfaults).
You can even cross compile haskell to raspberry pi (on linux only though).
One final note regarding:
More concerning is that, if the build behaves differently on Pi, and can throw runtime errors like segfault, then how can I be certain what other errors, or unexpected behavior, it can yield?
The simple yet slightly terrifying answer is: you can’t. It will always behave slightly differently. It’s a different machine, a different codegen, different in-memory linker (if it’s used), a different runtime system (the rts has lots of architecture conditionals).
While we try to make sure the behaviour is identical across architectures and operating systems (e.g. see the test-suite that tries to cover a lot of cases), by virtue of not being identical code, making total statements on identical behaviour is sadly not possible. It will behave identical up to the level our test-suite ensures it does. And I believe this is the same for pretty much every other language as well, unless you have an abstract machine, and verified bug-free implementations for that abstract machine for each target.