[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