https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113372
--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Richard Biener from comment #15) > (In reply to Jakub Jelinek from comment #14) > > Created attachment 57085 [details] > > gcc14-pr113372.patch > > > > The non-propagation workaround which seems to fix^H^H^Hworkaround all those > > 4 issues (PR90348 testcase actually doesn't FAIL anymore, but I've verified > > the patch results in in and buf no longer being shared) can look like this. > > + || (INTEGRAL_TYPE_P (TREE_TYPE (use)) > + && TYPE_PRECISION (TREE_TYPE (use)) == POINTER_SIZE))) > > ptrofftype_p (TREE_TYPE (use)) Aren't there targets where pointers are larger than sizetype? I thought msp430, but that one uses __int20. > I think it should be enough to look at gimple_assing_rhs1, that works > for single non-invariant &a[i], for conversions and for offsetting of > an invariant address (pointer-plus). Is the invariant operand guaranteed to go first? If it is pointer, guess POINTER_PLUS_EXPR enforces that, and for sizetype addition guess an operand can't be ADDR_EXPR, there would need to be a cast in a separate stmt. So perhaps ok. As for Micha's fears, I can certainly try to dump statistics during bootstrap/regtest on how many variables were shared and/or their cumulative size without/with the patch and see if it has significant effects on real-world code.
