------- Comment #4 from amylaar at gcc dot gnu dot org 2006-08-23 15:20 ------- As far as I can see, the only reason why we can have a REG_EH_REGION note on a non-call instruction is when the instruction may trap, and we compile with -fnon-call-exceptions.
(In reply to comment #3) > Here is a workaround. Although it doesn't solve the issue > completely, it'd be better than nothing. It prevents to > insert the mode switching code after the last insn of BB > when that insn has the REG_EH_REGION note. I think you can get an incorect mode this way, when the fall-thorough path is supposed to have a different mode than the abnormal edge destination. In fact, if the modes were the same, and not in conflict with the last insn of the source BB, LCM would be expected to place the mode switch into the source block or even earlier in the flow graph. I think the only sane way to handle this is not to emit any mode switching code for exception edges at the potential trapping site, and make the exception handling code assume no particular mode is present (unless the compiler can prove that an exception handler can only be reached from throwing/trapping sites that all have the same mode). > It also checks > if the last insn needs a mode which doesn't match with > the mode given by the mode switching code in such case. If HONOR_SNANS of flag_trapping_math is active together with -fnon-call-exceptions, such problems can be expected for floating point operations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28764
