> Instead I'd suggest to keep a 'last_field_array_p' flag that you can
> check at the end of the loop.
OK, I can do that.
> + && TREE_CODE (TREE_TYPE (field)) == ARRAY_TYPE
> + && !integer_zerop (TYPE_SIZE (TREE_TYPE (TREE_TYPE (field)))))
> + return;
> +
>
> Why does this exclude zero-sized element types? That looks odd to me ;)
Because the size cannot change if you add zero to it, even multiple times?
> Btw, the loop already has
>
> if (TREE_CODE (TREE_TYPE (field)) == ERROR_MARK
>
> || (TYPE_MODE (TREE_TYPE (field)) == BLKmode
>
> && ! TYPE_NO_FORCE_BLK (TREE_TYPE (field))
> && !(TYPE_SIZE (TREE_TYPE (field)) != 0
> && integer_zerop (TYPE_SIZE (TREE_TYPE (field)))))
>
> || ! tree_fits_uhwi_p (bit_position (field))
> || DECL_SIZE (field) == 0
> || ! tree_fits_uhwi_p (DECL_SIZE (field)))
>
> return;
>
> which then is supposed to
> handle struct { struct { char c[8]; } a; } - but it seems to
> special-case zero-sized
> members again, thus struct { struct { char c[0]; } a; } would still be
> broken after your patch?
Probably indeed, this test was added by the same patch that added the 0-sized
bitfield test in the RTL expander
http://gcc.gnu.org/ml/gcc-patches/2003-10/msg00823.html
and that I think is obsolete now. I can remove it.
> The issue Bernd raises is real as well, though we probably should fix this
> in a different way by using a different DECL_MODE based on the types
> size for asm register vars?
Really? The number of open PRs for register variables not behaving properly
at run time would make me think that this wouldn't be necessary bad...
> Btw, do you think we can recover from some of the now BLKmodes by
> having DECL_MODE != TYPE_MODE?
Well, if you want to do that, the straightforward solution is to keep the non-
BLKmode for the TYPE, put a flag on it and treat it as BLKmode when needed.
--
Eric Botcazou
