Nonmoving collector is broken on i386

(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/ghc/ghc/testsuite/tests/concurrent/should_run/readMVar1 +RTS -xn
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[New Thread 0xf79ffb40 (LWP 48)]
[New Thread 0xf71feb40 (LWP 49)]
[New Thread 0xf67ffb40 (LWP 50)]
[New Thread 0xf5dffb40 (LWP 51)]
readMVar1: internal error: updateRemembSetPushThunk: invalid thunk pushed: p=0xf7aeee38, type=61577
    (GHC version 8.10.0.20191117 for i386_unknown_linux)
    Please report this as a GHC bug:  https://www.haskell.org/ghc/reportabug

Thread 4 "readMVar1:w" received signal SIGABRT, Aborted.
[Switching to Thread 0xf67ffb40 (LWP 50)]
0xf7fd89d9 in __kernel_vsyscall ()
(gdb) bt
#0  0xf7fd89d9 in __kernel_vsyscall ()
#1  0xf7d32dd0 in __libc_signal_restore_set (set=0xf67fcf90) at ../sysdeps/unix/sysv/linux/nptl-signals.h:79
#2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#3  0xf7d34297 in __GI_abort () at abort.c:89
#4  0x080ba541 in rtsFatalInternalErrorFn (s=0x810325c "updateRemembSetPushThunk: invalid thunk pushed: p=%p, type=%d", 
    ap=0xf67fd234 "8\356\256\367\211", <incomplete sequence \360>) at rts/RtsMessages.c:186
#5  0x080ba3c2 in barf (s=0x810325c "updateRemembSetPushThunk: invalid thunk pushed: p=%p, type=%d") at rts/RtsMessages.c:48
#6  0x080bfeb6 in updateRemembSetPushThunkEager (cap=0x81214c0 <MainCapability>, info=0x80dcbf8, thunk=0xf7aeee38) at rts/sm/NonMovingMark.c:631
#7  0x080bfd6c in updateRemembSetPushThunk (cap=0x81214c0 <MainCapability>, thunk=0xf7aeee38) at rts/sm/NonMovingMark.c:572
#8  0x080bfeda in updateRemembSetPushThunk_ (reg=0x81214cc <MainCapability+12>, p=0xf7aeee38) at rts/sm/NonMovingMark.c:638
#9  0x080da2d1 in stg_marked_upd_frame_info ()
#10 0x081214cc in MainCapability ()
#11 0xf7aeee38 in ?? ()
#12 0xf7aeee38 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

The problem here appears to be the get_volatile_itbl call. Specifically, updateRemembSetPushThunkEager calls it to get the info table of a thunk. However, get_volatile_itbl calls INFO_PTR_TO_STRUCT rather than THUNK_INFO_PTR_TO_STRUCT. It turns out that (presumably due to alignment) these do the same thing on 64-bit platforms but differ on 32-bit.