On Fri, 6 Mar 2009, Geert Bosch wrote: > > this task may be more difficult. So lowering them early during > > gimplification looks like a more reasonable plan IMHO. > > Right, that was my intention. Still, I'll need to add code to > handle the new tree codes in fold(), right?
If you add new trapping codes to GENERIC I'd recommend *not* making fold() handle them. I don't think much folding is safe for the trapping codes when you want to avoid either removing or introducing traps. Either lower the codes in gimplification, or handle them explicitly in a few GIMPLE optimizations e.g. when constants are propagated in, but avoid general folding for them. Front ends should set TREE_SIDE_EFFECTS on trapping expressions so that fold knows it can't discard a subexpression (whose value doesn't matter to the value of the final expression) containing a trapping expression, e.g. 0 * (a +trap b) needs to evaluate (a +trap b) for its side effects. With this done, front ends generating trapping codes for -ftrapv and fold not trying to optimize the trapping codes, I'd hope fold and the rest of the language-independent compiler could stop caring about flag_trapv. -- Joseph S. Myers jos...@codesourcery.com
