On 10/6/20 9:52 AM, Jakub Jelinek wrote:
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).
We know we need _at least_ two trees, so what's wrong with the above?
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;
We had that originally, but IIRC, the alignment didn't come out right.
Aldy
irange *r = (irange *) obstack_alloc (&m_obstack, nbytes);
return new (r) irange ((tree *) (r + 1), num_pairs);
without any new type.
Jakub
