Luke Dashjr

Forcing `-O0` in `codegen_c.cpp` "fixes" this issue. Re-applying `-O0 -fsection-anchors` reproduces it. Simply appending `-fno-section-anchors` by itself reproduces the bug as well (EDIT: this is a typo - I forgot...

But when is that assignment made?

Observing that `pthread_rwlock_t` should have a valid alignment for both `unsigned int` and `long int` and `__GI___pthread_rwlock_rdlock` is being called with rwlock=0x1000ef929, which is not aligned for either. The alignments...

Seems like `-O0` working was just a coincidence :(

Not sure how I got the original backtrace - having trouble getting one with the arguments not optimised out at this point (since `-O0` makes reproducing it hard). :/ Currently...

```c++ printf("%d\n", (int)alignof(pthread_mutex_t)); ``` tells me 8 I would expect if this were a system problem, the issue would affect a lot more than just mrustc...?

I don't know what I am looking for then

```c // struct ::"libc-0_2_62_Hd"::unix::linux_like::linux::pthread_mutex_t struct s_ZRG4ch4libc90_2_62_Hd4unix10linux_like5linux15pthread_mutex_t0g { t_ZRTA40Ca _0; // [u8; 40] } ; ```

Neither ffb0961ad3a1125ca7db3b6a48991023bcb4d0d7 (w/ patches) nor current master work for me, apparently due to issues unrelated to alignment (but it has been far too long to confirm the alignment-related issue is...

Yes, I was including patching 16d1d29 into ffb0961 of course. :) master is generating code that looks like (IIRC) `(int128_t)-ll` missing the constant number somehow