https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #2) > I'd say the bug is in determine_min_objsize, which makes assumption that are > simply not valid in GIMPLE after optimizations. > Before fre3 we have: > _2 = &ptr.0_1->header.magic; > _3 = __builtin_strcmp (_2, "x"); > ... > _4 = &ptr.0_1->buffer; > _5 = __builtin_strcmp (_4, "ab"); > but fre3 changes that to: > _2 = &ptr.0_1->header.magic; > _3 = __builtin_strcmp (_2, "x"); > ... > _5 = __builtin_strcmp (_2, "ab"); > because it determines that _2 and _4 have the same value. They do, but > determine_min_objsize attempts to argue from this change that the strcmp > will never be true, because &ptr.0_1->header.magic is a 2 byte array in a > struct inside of union. The source didn't have such an expression there > though. > So, either we change GIMPLE and claim that such properties need to be > preserved, in that case SCCVN would need to either not do that optimization > (and other passes too) or say modify the expression that is kept say to > ptr.0_1 or &ptr.0_1->buffer as one that has the larger minimum object size, > or determine_min_objsize simply can't make such assumptions. determine_min_objsize cannot make such assumptions (when producing answers used for optimization rather than just warnings). We're sort-of fencing off FRE to aid the warning machinery but only for zero-offset components and only before IPA inlining.
