[PUSHED] Fix off-by-one storage problem in irange_allocator.

[Andrew MacLeod]

On 10/6/20 1:58 PM, Andrew MacLeod via Gcc-patches wrote:
> 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.
>
The authorities inform me that void * is preferred.. so.. final spin, in 
testing now:



-------------- next part --------------
A non-text attachment was scrubbed...
Name: one.diff
Type: text/x-patch
Size: 807 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20201006/4cc24037/attachment.bin>