Re: GCC miscompilation with __seg_fs

[Andrew Pinski <pinskia@gmail.com>]

On Mon, Mar 13, 2023 at 8:46 AM Jakub Jelinek via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> On Mon, Mar 13, 2023 at 06:24:47PM +0300, Sergey Bugaev wrote:
> > Hello,
> >
> > while exploring the generated assembly for an entirely unrelated
> > reason, I found out that GCC eliminates stores through THREAD_SELF
> > when it's declared using __seg_fs. This is easily reproducible outside
> > of glibc; here's a sample reproducer (I've also put it on Godbolt [0]
> > for easy exploration):
>
> Smaller testcase:
> typedef struct
> {
>   void *tcb;
>   int some_member;
> } tcbhead_t;
>
> void
> assign_through_self (void)
> {
>   (*(tcbhead_t * __seg_fs *) __builtin_offsetof (tcbhead_t, tcb))->some_member = 42;
> }
>
> From what I can see, GCC has been DSE removing these since https://gcc.gnu.org/r6-4645
> when __seg_fs support has been introduced.
> One can work-around it using -fno-delete-null-pointer-checks.
> You could also hide the fact that it is based on 0 pointer from the
> compiler...
>
> While GCC has targetm.addr_space.zero_address_valid hook (which AFAIK only
> x86 overrides), we use it only in very few spots right now.
>
> Feel free to file a bug report in GCC bugzilla, but that won't improve
> anything on the already released compilers.

I am 99% sure this is https://gcc.gnu.org/PR102733 or at least related to it.

Thanks,
Andrew Pinski

>
>         Jakub
>