On Mon, 10 Jun 2013, Iyer, Balaji V wrote: > > You don't say what the actual error was, and neither does the original PR. > > But if it was an ICE from an EXCESS_PRECISION_EXPR getting to the > > gimplifier, > > that suggests that c_fully_fold isn't getting called somewhere it should be > > - and > > probably calling c_fully_fold is the correct fix rather than inserting a > > cast. If you > > can get such ICEs for EXCESS_PRECISION_EXPR, it's quite possible you might > > get > > them for C_MAYBE_CONST_EXPR as well (e.g. try using 0 / 0, or compound > > literals of variably modified type, in various places in the affected > > expressions), > > which should be fixed by using c_fully_fold but not by inserting a cast. > > It was not. It was actually a type mismatch between double and long > double caught in verify_gimple_in_seq function. So, is it OK for trunk?
A cast still doesn't make sense conceptually. Could you give a more detailed analysis of what the trees look like at this point where you are inserting this cast, and how you get to a mismatch? EXCESS_PRECISION_EXPR can be thought of as a conversion operator. It should only appear at the top level of an expression. At the point where excess precision should be removed - the value converted to its semantic type - either the expression with excess precision should be folded using c_fully_fold (if this is the expression of an expression statement, or otherwise will go inside a tree that c_fully_fold does not recurse inside), or the operand of the EXCESS_PRECISION_EXPR should be converted to the semantic type with the "convert" function. In neither case is generating a cast appropriate; that's for when the user actually wrote a cast in their source code. -- Joseph S. Myers jos...@codesourcery.com
