Date: Tue, 13 Apr 2021 21:08:36 +0100
On Tue, 13 Apr 2021 at 20:22, Jon Chesterfield <
jonathanchesterfield_at_[hidden]> wrote:
> On Tue, Apr 13, 2021 at 7:39 PM Peter Sewell <Peter.Sewell_at_[hidden]>
> wrote:
>
>> - all other cases (i.e., those that are neither representation-byte
>> accesses, padding-byte accesses, or partially initialised struct member
>> accesses) of reading uninitialised variables can be regarded as programmer
>> errors
>>
>
> A case I believe is missing from the enumeration involves reading off the
> end of an array, from uninitialised memory, when processing an array in
> chunks of multiple elements at a time. Popular with code using vector
> intrinsics. Copying an uninitialised value, doing arithmetic to it, then
> flushing it back to the source is quicker than explicit loop epilogues.
>
True. We have previously thought about that case, but it's intertwined
also with the provenance and effective type semantics, so perhaps better to
defer for now.
thanks,
Peter
jonathanchesterfield_at_[hidden]> wrote:
> On Tue, Apr 13, 2021 at 7:39 PM Peter Sewell <Peter.Sewell_at_[hidden]>
> wrote:
>
>> - all other cases (i.e., those that are neither representation-byte
>> accesses, padding-byte accesses, or partially initialised struct member
>> accesses) of reading uninitialised variables can be regarded as programmer
>> errors
>>
>
> A case I believe is missing from the enumeration involves reading off the
> end of an array, from uninitialised memory, when processing an array in
> chunks of multiple elements at a time. Popular with code using vector
> intrinsics. Copying an uninitialised value, doing arithmetic to it, then
> flushing it back to the source is quicker than explicit loop epilogues.
>
True. We have previously thought about that case, but it's intertwined
also with the provenance and effective type semantics, so perhaps better to
defer for now.
thanks,
Peter
Received on 2021-04-13 15:08:50