[Bug sanitizer/114217] -fsanitize=alignment false positive with intended unaligned struct member access

["akihiko.odaki at daynix dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114217

--- Comment #13 from Akihiko Odaki <akihiko.odaki at daynix dot com> ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Akihiko Odaki from comment #11)
> > So there are two constructs invoking UBs but ignored by UBSan: 1)
> 
> That is an understatement. UBSan is a best effort which diagnoses some forms
> of undefined behavior.  There are tons of undefined behavior UBSan doesn't
> catch,
> most importantly e.g. aliasing violations, but far from limited to just that.
> If a program is diagnostic free with -fsanitize=undefined,address , it
> doesn't mean it is UB free, but the goal is that if there is diagnostic,
> there is a real UB in the program.

Right. I just listed the two relevant constructs and don't intend to say they
are the only case that UBSan doesn't catch.

> 
> You are basically asking for the PR80797 fix to be reverted just because you
> aren't willing to fix UB in your code.  That is not going to happen, we've
> been diagnosing this for almost 7 years now, I think clang even for 11
> years, it is a real UB and other projects have been able to cope with it. 
> By reverting the change new UB in other programs couldn't be discovered.

I'm not asking for reverting PR80797. See f() and f2() I wrote earlier:
u64 f(struct dir_entry *entry)
{
    return get_unaligned(&entry->offset);
}

u64 f2(u64 *offset)
{
    return get_unaligned(offset);
}

Both f(NULL) and f2(NULL) should be caught and there should be no discrepancy
in behavior for these two functions. However, there is a discrepancy when it
comes to -fsanitize=alignment.

I'm not saying ignoring UB in f() is the only sensible option either. Catching
UBs in both f() and f2() is a logical option.