https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70128
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Well, it is a question if it is -fno-strict-aliasing or -std=kernel thing.
Anyway, IMHO what matters is the points-to stuff:
Points-to sets
ANYTHING = { ANYTHING }
ESCAPED = { ESCAPED NONLOCAL __aeabi_uidiv __aeabi_idiv }
NONLOCAL = { ESCAPED NONLOCAL }
STOREDANYTHING = { }
INTEGER = { ANYTHING }
__aeabi_uidiv.0_1 = { __aeabi_uidiv }
__aeabi_uidiv = { ESCAPED NONLOCAL }
fn_addr_2 = { __aeabi_uidiv }
fn_addr.1_3 = { __aeabi_uidiv } same as fn_addr_2
derefaddrtmp(12) = { NONLOCAL }
_6 = { NONLOCAL __aeabi_uidiv }
_7 = { NONLOCAL __aeabi_uidiv } same as _6
...
Flow-insensitive points-to information
fn_addr.1_3, points-to vars: { } (escaped)
_7, points-to non-local, points-to vars: { } (escaped)
And the non-local is what makes the difference in between the two during DSE,
where ref_maybe_used_by_call_p_1 is called with the v7_coherent_kern_range
call, and pt_solutions_intersect then differs between the two stores.
The only thing that really surprises me is that the in the Red Hat bugzilla
bugreport I've referenced in the URL there is a claim this works with gcc 5.x,
that is a mystery to me. At least if I bisect this testcase on x86_64 with -Os
-fno-strict-aliasing, the two stores started to be removed with r165641, so
quite a while ago.
IMHO the kernel people have to change their code even if there is agreement we
should make -fno-strict-aliasing more forgiving in this case, because
4.[6-9]*/5 ought to be affected too.
