This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [REPOST] Invalid Code when reading from unaligned zero-sized array
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Jakub Jelinek <jakub at redhat dot com>, Bernd Edlinger <bernd dot edlinger at hotmail dot de>, Jeff Law <law at redhat dot com>
- Date: Fri, 13 Dec 2013 12:08:55 +0100
- Subject: Re: [REPOST] Invalid Code when reading from unaligned zero-sized array
- Authentication-results: sourceware.org; auth=none
- References: <DUB122-W20B5CD3C7B50824A33E21AE4D50 at phx dot gbl> <2470127 dot PP43Hpl86H at polaris> <CAFiYyc1PpLX1AjJOEC2bCRi+3tdqnkXKTmmA=zyC_DUWPWchfw at mail dot gmail dot com>
> 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