This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch] Fix size of array with zero-sized element in Ada
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Eric Botcazou <ebotcazou at adacore dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 2 Oct 2009 12:37:17 +0200
- Subject: Re: [Patch] Fix size of array with zero-sized element in Ada
- References: <200910021213.16789.ebotcazou@adacore.com>
On Fri, Oct 2, 2009 at 12:13 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
> Hi,
>
> this is a corner case but the consensus is that the size of an array with
> non-aliased zero-sized element must be zero in Ada, whatever its extent.
>
> The following patchlet is needed to achieve that. ?Tested on i586-suse-linux,
> OK for mainline?
Hmm. On the no-undefined-overflow branch I also had to fixup things there.
I wonder if testing the condition _before_ doing the subtraction wouldn't be
more appropriate. Something like
if (integer_onep (fold_binary (LT_EXPR, boolean_type_node,
ub, lb)))
length = size_zero_node;
else
length = size_binop (...
? That should be more robust and doesn't rely on TREE_OVERFLOW.
I can't btw see how your patch fulfills "whatever its extent" - why should
TREE_OVERFLOW be set for like lb == 0 and ub == 16? The only
way is that the FE already makes sure that ub - lb + 1 == 0, no?
Thanks,
Richard.
> 2009-10-02 ?Eric Botcazou ?<ebotcazou@adacore.com>
>
> ? ? ? ?* stor-layout.c (layout_type) <ARRAY_TYPE>: Make sure that an array of
> ? ? ? ?zero-sized element is zero-sized if the length has overflowed.
>
>
> 2009-10-02 ?Eric Botcazou ?<ebotcazou@adacore.com>
>
> ? ? ? ?* gnat.dg/array10.adb: New test.
> ? ? ? ?* gnat.dg/object_overflow.adb: Tweak.
>
>
> --
> Eric Botcazou
>