[Bug middle-end/56362] New: bitfield refs over-optimized?

[Bug middle-end/56362] New: bitfield refs over-optimized?

[jay.krell at cornell dot edu]

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

             Bug #: 56362
           Summary: bitfield refs over-optimized?
    Classification: Unclassified
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jay.krell@cornell.edu


Our front end is a bit wierd.
We don't declare the fields of our structs.
We use bitfield refs to pick out the fields we know are there.


Something like this:


If in C you had the reasonable:


struct { int a,b,c,d } e;
 e.b => component_ref 


We have:
 struct /* size 16 bytes */ e;
 bitfield_ref(e, offset 4 bytes, size 4 bytes, type int)


 I have changed it so sometimes, instead: 
   *(int*)(&e + 4) 

e.g. when reading floating point fields,
but that defeats optimizations more.


so, then, while this mostly works, and generates better
code than the pointer offset + deref form, it does seem to
very occasionally not work.


I have not fully debugged this, at least not in years.


4.7.2/gcc/fold-const.c has this code:


      /* A bit-field-ref that referenced the full argument can be stripped.  */
      if (INTEGRAL_TYPE_P (TREE_TYPE (arg0))
      && TYPE_PRECISION (TREE_TYPE (arg0)) == tree_low_cst (arg1, 1)
      && integer_zerop (op2))
    return fold_convert_loc (loc, type, arg0);


I believe this is a bit too aggressive.
Such as when there is a sign extension implied.


I added these two conditions to make to make it less aggressive:
      && INTEGRAL_TYPE_P (type)
      && TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg0))

[Bug middle-end/56362] bitfield refs over-optimized?

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-18 10:50:53 UTC ---
BIT_FIELD_REFs never involve a sign-extension - the result has exactly the
precision of the number of bits referenced.

[Bug middle-end/56362] bitfield refs over-optimized?

[jay.krell at cornell dot edu]

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

--- Comment #2 from Jay <jay.krell at cornell dot edu> 2013-02-21 08:07:15 UTC ---
Looking back at other data I have..this has something to do with configure
-enable-checking..but I don't know exactly what.

I am *guessing* that the signedness of the bitfield ref and the signedess of
the element could vary. Stripping of the bitfield ref would therefore change
the type of the expression, and that could then be sign extended.

I doubt I can construct a repro in C, but I can poke around to see if C or Java
or Ada can produce such bitfield refs..