This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] expr.c: Fix PR middle-end/18008.


On Sun, 2004-10-17 at 10:21, Kazu Hirata wrote:
> Hi,
> 
> Attached is a patch to fix a regression, PR middle-end/18008.
> 
> Consider
> 
> struct B {
>   unsigned b : 2;
> };
> 
> void
> store (struct B *b, int v)
> {
>   b->b = v;
> }
> 
> After the tree optimizers run, I get
> 
>   b->b = (<unnamed type>) (unsigned char) v;
> 
> where <unnamed type> is a 2-bit integer type.  The problem is that we
> get ANDs from two places.  The first one is generated by the cast to
> (<unnamed type>).  The second one is from the assignment, more
> specifically store_bit_field.
> 
> The patch fixes the problem by stripping a narrowing conversion.
> 
> Personally, I don't like the way the patch fixes the problem because
> the tree optimizers make the types very strict for us so that we won't
> do a type-mismatched assignment, but now we are sort of breaking it.
> 
> Tested on i686-pc-linux-gnu.  Any comments?
Well, we could try to attack this earlier (in the tree optimizers).

If we look at the .dom3 dump we have:

  # BLOCK 0
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  D.1122_2 = (unsigned char) v_1;
  D.1123_3 = (<unnamed type>) D.1122_2;
  #   TMT.0_6 = V_MAY_DEF <TMT.0_5>;
  b_4->b = D.1123_3;
  return;
  # SUCC: EXIT [100.0%]
                                                                                

I would think we could turn that into

 # BLOCK 0
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  D.1122_2 = (unsigned char) v_1;   /* This will be removed */
  D.1123_3 = (<unnamed type>) v_1;  /* This line was changed */
  #   TMT.0_6 = V_MAY_DEF <TMT.0_5>;
  b_4->b = D.1123_3;
  return;
  # SUCC: EXIT [100.0%]



Which would result in the following .optimized

b->b = (<unnamed type>) v;

I don't know if that would help or not.  I also haven't investigated
how much work that would be.

An alternate approach is to fold statements after TER, which has the
same ultimate affect.  This is something I have played with and have
solid code around here to implement.  I never checked it in as most
of the stuff it was finding was stuff that ought to be addressed
earlier in the optimizer paths (such as the this example).

Jeff




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]