http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47639

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-02-08 
12:09:09 UTC ---
Ugh.  We lower

  [LP 1] D.2691_8 = v1_6(D) / v2_7(D);

to

  D.2699_13 = BIT_FIELD_REF <v1_6(D), 32, 0>;
  D.2700_14 = BIT_FIELD_REF <v2_7(D), 32, 0>;
  D.2701_15 = D.2699_13 / D.2700_14;
  D.2702_16 = BIT_FIELD_REF <v1_6(D), 32, 32>;
  D.2703_17 = BIT_FIELD_REF <v2_7(D), 32, 32>;
  D.2704_18 = D.2702_16 / D.2703_17;
  [LP 1] D.2691_8 = {D.2701_15, D.2704_18};

now the most ugly part of that is we construct a big tree with
the CONSTRUCTOR and then feed that to force_gimple_operand ...

What I did in the patch that caused this is to make
{D.2701_15, D.2704_18} not throw - which exposes this bug.

We can hide this issue again by properly clearing EH info on
the CONSTRUCTOR statement, leaving the issue alone that we'd
really need to move EH info to the piecewise computations,
split the block, add new EH edges, etc.

Not worthwhile for stage4 and not a regression.

C++ testcase that fails with -fnon-call-exceptions only:

typedef int __attribute__ ((vector_size (8))) vec;

vec foo (vec v1, vec v2)
{
  try
    {
      return v1 / v2;
    } 
  catch (...)
    {
      throw;
    } 
}

Reply via email to