public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/56362] New: bitfield refs over-optimized?
@ 2013-02-17 10:28 jay.krell at cornell dot edu
2013-02-18 10:51 ` [Bug middle-end/56362] " rguenth at gcc dot gnu.org
2013-02-21 8:07 ` jay.krell at cornell dot edu
0 siblings, 2 replies; 3+ messages in thread
From: jay.krell at cornell dot edu @ 2013-02-17 10:28 UTC (permalink / raw)
To: gcc-bugs
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))
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug middle-end/56362] bitfield refs over-optimized?
2013-02-17 10:28 [Bug middle-end/56362] New: bitfield refs over-optimized? jay.krell at cornell dot edu
@ 2013-02-18 10:51 ` rguenth at gcc dot gnu.org
2013-02-21 8:07 ` jay.krell at cornell dot edu
1 sibling, 0 replies; 3+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-02-18 10:51 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug middle-end/56362] bitfield refs over-optimized?
2013-02-17 10:28 [Bug middle-end/56362] New: bitfield refs over-optimized? jay.krell at cornell dot edu
2013-02-18 10:51 ` [Bug middle-end/56362] " rguenth at gcc dot gnu.org
@ 2013-02-21 8:07 ` jay.krell at cornell dot edu
1 sibling, 0 replies; 3+ messages in thread
From: jay.krell at cornell dot edu @ 2013-02-21 8:07 UTC (permalink / raw)
To: gcc-bugs
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..
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-02-21 8:07 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-17 10:28 [Bug middle-end/56362] New: bitfield refs over-optimized? jay.krell at cornell dot edu
2013-02-18 10:51 ` [Bug middle-end/56362] " rguenth at gcc dot gnu.org
2013-02-21 8:07 ` jay.krell at cornell dot edu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).