[PUSHED] Fix off-by-one storage problem in irange_allocator.
Andrew MacLeod
amacleod@redhat.com
Tue Oct 6 17:58:21 GMT 2020
On 10/6/20 1:48 PM, Jakub Jelinek wrote:
> On Tue, Oct 06, 2020 at 01:41:54PM -0400, Andrew MacLeod wrote:
>> On 10/6/20 1:32 PM, Jakub Jelinek via Gcc-patches wrote:
>>> On Tue, Oct 06, 2020 at 10:42:12AM -0600, Martin Sebor wrote:
>>>> The manual documents the [0] extension and mentions but discourages
>>>> using [1]. Nothing is said about other sizes and the warnings such
>>>> as -Warray-bounds have been increasingly complaining about accesses
>>>> past the declared constant bound (it won't complain about past-
>>>> the-end accesses to a mem[1], but will about those to mem[2]).
>>>>
>>>> It would be nice if existing GCC code could eventually be converted
>>>> to avoid relying on the [1] hack. I would hope we would avoid making
>>>> use of it in new code (and certainly avoid extending its uses to other
>>>> sizes).
>>> I don't see how we could, because [0] is an extension and GCC needs to
>>> support host compilers that don't support it, and similarly [] is an
>>> extension in C++ and can't be relied on.
>>> Changing say rtl or gimple structs from the way we define them currently
>>> to say templates dependent on the size of the embedded arrays is I'm
>>> afraid not really possible.
>>>
>>> Jakub
>>>
>> Aldy is currently testing this.. I presume this is what you had in mind?
> Yes.
> I'm not actually sure if it is best to use struct irange (and why struct
> irange rather than just irange?) for the r variable, whether it shouldn't
> be unsigned char * or whatever is best suitable type for placement new.
bah, the struct is a carry over from when it was struct new_ir. doh.
as to the type for placement new, I dunno.
>
>> diff --git a/gcc/value-range.h b/gcc/value-range.h
>> index 94b48e55e77..c86301fe885 100644
>> --- a/gcc/value-range.h
>> +++ b/gcc/value-range.h
>> @@ -668,13 +668,13 @@ irange_allocator::allocate (unsigned num_pairs)
>> if (num_pairs < 2)
>> num_pairs = 2;
>>
>> - struct newir {
>> - irange range;
>> - tree mem[1];
>> - };
>> - size_t nbytes = (sizeof (newir) + sizeof (tree) * 2 * (num_pairs - 1));
>> - struct newir *r = (newir *) obstack_alloc (&m_obstack, nbytes);
>> - return new (r) irange (r->mem, num_pairs);
>> + // Allocate the irange and required memory for the vector.
>> + struct irange *r = (irange *) obstack_alloc (&m_obstack, sizeof (irange));
>> +
>> + size_t nbytes = sizeof (tree) * 2 * num_pairs;
>> + tree *mem = (tree *) obstack_alloc (&m_obstack, nbytes);
>> +
>> + return new (r) irange (mem, num_pairs);
>> }
>>
>> inline irange *
>
> Jakub
More information about the Gcc-patches
mailing list