https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
We have, in .optimized:
__write_overflow_field (-1, 0);
always executed, unless kmemdup_noprof (...) == 0. At objsize time we have
__p_size_field_121 = -1;
...
<bb 54> [local count: 536073660]:
if (__p_size_field_121 < 0)
goto <bb 55>; [33.00%]
else
goto <bb 56>; [67.00%]
<bb 55> [local count: 176904307]:
__write_overflow_field (__p_size_field_121, 0);
---
<bb 48> [local count: 1072147320]:
- _114 = &MEM[(struct ieee80211_sub_if_data *)ifmsh_15 +
-16B].vif.bss_conf.mcast_rate;
- _115 = __builtin_dynamic_object_size (_114, 0);
- __p_size_116 = (const size_t) _115;
- _117 = &setup_20(D)->mcast_rate;
- _118 = __builtin_dynamic_object_size (_117, 0);
- __q_size_119 = (const size_t) _118;
- _120 = __builtin_dynamic_object_size (_114, 1);
- __p_size_field_121 = (const size_t) _120;
+ __p_size_116 = -1;
+ __q_size_119 = -1;
+ __p_size_field_121 = -1;
not sure how we arrive at those sizes - are we possibly confused by
the + -16B in the MEM?
enum { NUM_NL80211_BANDS };
...
int mcast_rate[NUM_NL80211_BANDS];
(probably too much reduced - that's 6 originally, but still with the same
result). It's interesting that we have
<bb 2> [local count: 1073741824]:
sdata_14 = IEEE80211_DEV_TO_SUB_IF (dev_12(D));
ifmsh_15 = &sdata_14->u.mesh;
so there's some odd "upcasting" happening here with applying a negative
offset to &sdata_14->u.mesh, it's definitely "interesting", and objsz
might think it can figure the size of what's being looked at (maybe
again too much reduced here, ieee80211_if_mesh is quite a bit larger
originally).
Also interesting that the original doesn't reference vif.bss_conf.mcast_rate
but vif.bss_conf.chanctx_conf - cvise must have reduced this somehow.
So possibly the reduction is invalid, I'll attach the original preprocessed
source.
