https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104644
--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 23 Feb 2022, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104644 > > --- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > I think the FEs rely on such trees not being folded. Does it? I think it simply relies on the overflow being "sticky" and not lost so that for bswap (100000000 * 1000000000) you get sth with TREE_OVERFLOW. That's also what we do when folding 1(OVF) + 2, we return 3(OVF). Sure, not folding is a possibility as well but isn't fold_const_call_1 eventually invoked from GIMPLE as well where TREE_OVERFLOW doens't have any semantics? I suppose we could use force_fit_type instead of wide_int_to_tree for building the result here.
