On Tue, Oct 06, 2020 at 09:37:21AM +0200, Aldy Hernandez via Gcc-patches wrote:
> Pushed as obvious.
>
> gcc/ChangeLog:
>
> * value-range.h (irange_allocator::allocate): Increase
> newir storage by one.
> ---
> gcc/value-range.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/value-range.h b/gcc/value-range.h
> index 94b48e55e77..7031a823138 100644
> --- a/gcc/value-range.h
> +++ b/gcc/value-range.h
> @@ -670,7 +670,7 @@ irange_allocator::allocate (unsigned num_pairs)
>
> struct newir {
> irange range;
> - tree mem[1];
> + tree mem[2];
> };
> size_t nbytes = (sizeof (newir) + sizeof (tree) * 2 * (num_pairs - 1));
> struct newir *r = (newir *) obstack_alloc (&m_obstack, nbytes);
So, we essentially want a flexible array member, which C++ without extension
doesn't have, and thus need to rely on the compiler handling the trailing
array as a poor men's flexible array member (again, GCC does for any size,
but not 100% sure about other compilers, if they e.g. don't handle that way
just size of 1).
Is there any reason why the code is written that way?
I mean, we could just use:
size_t nbytes = sizeof (irange) + sizeof (tree) * 2 * num_pairs;
irange *r = (irange *) obstack_alloc (&m_obstack, nbytes);
return new (r) irange ((tree *) (r + 1), num_pairs);
without any new type.
Jakub
