On Tue, 26 Jan 2021, Jakub Jelinek wrote: > On Tue, Jan 26, 2021 at 12:16:14PM +0100, Richard Biener wrote: > > > + /* Unless this is called during FE folding. */ > > > + if (cfun > > > + && (cfun->curr_properties & (PROP_trees | PROP_rtl)) == 0 > > > > don't you want && (cfun->curr_properties & PROP_trees) != 0? > > No, PROP_trees is misnamed and it actually means GIMPLE.
Doh. Patch doing s/PROP_trees/PROP_gimple/ pre-approved ;) > I could use (PROP_gimple_any | PROP_rtl) if that is more readable, > PROP_trees stands for: > (PROP_gimple_any | PROP_gimple_lcf | PROP_gimple_leh | PROP_gimple_lomp) > but I don't think we ever have any of the latter 3 set when PROP_gimple_any > is not set. I think PROP_gimple_any should be removed by the gimple lowering pass that sets PROP_gimple_lcf since the docs #define PROP_gimple_any (1 << 0) /* entire gimple grammar */ #define PROP_gimple_lcf (1 << 1) /* lowered control flow */ suggest that PROP_gimple_any means we can have sub-stmts for example? But anyway, since we don't seem to have a property for GENERIC and they are only introduced by gimplification even a cfun->curr_properties == 0 would work ... But yes, PROP_trees | PROP_rtl looks good to me as well. I guess we should document how those properties work ... (and discover we don't use them consistently). Richard.
