On Thu, May 10, 2012 at 12:26 PM, Eric Botcazou <[email protected]> wrote:
>> As far as I can see this happens when we fold
>>
>> (bitsizetype) (#1 + 7) * 8 + 7 PLUS_EXPR 1
>>
>> which we fold to
>>
>> ((bitsizetype) (#1 + 7) + 1) * 8
>>
>> The #1 + 7 expression is computed in sizetype (which is now unsigned
>> and thus has defined overflow - thus we cannot optimize the widening
>> to bitsizetype).
>
> I see, thanks for the investigation.
>
>> As I previously suggested we can put in special knowledge into
>> size_binop, or maybe better, provide abstraction for conversion
>> of sizetype to bitsizetype that would associate the type
>> conversions. The original plan was of course to at some point
>> have PLUSNV_EXPR so we can explicitely mark #1 + 7 as not
>> overflowing. It might be that introducing those just for
>> size expressions right now (and then dropping them down
>> to regular PLUS_EXPRs during gimplification) might be
>> something to explore for 4.8.
>
> OK, I'll think about it. No objections by me to going ahead with the patches.
For example
Index: stor-layout.c
===================================================================
--- stor-layout.c (revision 187364)
+++ stor-layout.c (working copy)
@@ -791,6 +791,10 @@ start_record_layout (tree t)
tree
bit_from_pos (tree offset, tree bitpos)
{
+ if (TREE_CODE (offset) == PLUS_EXPR)
+ offset = size_binop (PLUS_EXPR,
+ fold_convert (bitsizetype, TREE_OPERAND (offset, 0)),
+ fold_convert (bitsizetype, TREE_OPERAND (offset, 1)));
return size_binop (PLUS_EXPR, bitpos,
size_binop (MULT_EXPR,
fold_convert (bitsizetype, offset),
fixes the specific testcase you provided. I suppose if stor-layout.c would
be more carefully handle advancing offset/bitpos, avoding repeated translations
between them, those issues would not exist. Of course the mere existence
of DECL_OFFSET_ALIGN complicates matters for no good reasons (well,
at least I did not find a good use of it until now ...).
Richard.
> --
> Eric Botcazou
