https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113372
--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 15 Jan 2024, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113372 > > Jakub Jelinek <jakub at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |rguenth at gcc dot gnu.org > > --- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > Seems this is invalid variable sharing during RTL, I'm afraid we have tons of > open bugs against that, and I'm afraid I don't know anything what to do on the > bitint lowering side. > Bitint lowering creates 3 large variables: > unsigned long bitint.8[75]; > unsigned long bitint.7[75]; > unsigned long bitint.6[100]; > where bitint.6 corresponds to > _3 = _2 % y_14(D); > and later when _3 isn't needed anymore to > _8 = -y_14(D); > bitint.7 corresponds to > _4 = -_3; > _5 = (unsigned _BitInt(4745)) _4; > and bitint.8 corresponds to > _7 = _5 * _6; > Reusing the same variable bitint.6 for 2 different _BitInt(6384) SSA_NAMEs > ought to be fine, they aren't live at the same time. > After lowering, we end up with: > .DIVMODBITINT (0B, 0, &bitint.6, 6384, &D.2796, -8, &y, -6384); > // Above fills in bitint.6 array > ... > loop which uses bitint.6 to compute bitint.7 > bitint.6 ={v} {CLOBBER(eos)}; > ... > .MULBITINT (&bitint.8, 4745, &bitint.7, 4745, &D.2795, -8); > // Above fills in bitint.8 array > ... > loop to compute bitint.6 > ... > loop which uses bitint.6 > ... > _21 = MEM[(unsigned long *)&bitint.8]; > _22 = (_BitInt(8)) _21; > _18 = _22; > return _18; > // I.e. use bitint.8 for the return value > > But unfortunately RTL expansion decides to use the same underlying memory for > bitint.6 and bitint.8 arrays, even when the second uses of bitint.6 happens > when bitint.8 is live. > > Or am I using incorrect CLOBBER kind when an underlying variable is used for > more than one SSA_NAME? Like should that be just eob rather than eos? I think it's OK, but likely the address-taken of bitint.8 somehow breaks things. Does RTL expansion properly handle internal-functions here?
