On 12/6/18 1:32 PM, Jakub Jelinek wrote:
>> For -fno-delete-null-pointer-checks ISTM
>> we should indicate "we don't know anything about the result" of such an
>> operation.
>
> There are cases where we still know something. The largest valid object
> that can be supported is half of the
On Thu, Dec 06, 2018 at 01:08:34PM -0700, Jeff Law wrote:
> > I hope we can still say that pointer wrapping even with
> > -fno-delete-null-pointer-checks is UB, so this patch differentiates between
> > positive offsets (in ssizetype), negative offsets (in ssizetype) and zero
> > offsets and
On 12/5/18 11:45 PM, Jakub Jelinek wrote:
> Hi!
>
> If we consider -fno-delete-null-pointer-checks as a way to support e.g. AVR
> and other targets which can validly place objects at NULL rather than a way
> to workaround UBs in code, I believe the following testcase must pass if
> there is e.g.
On Thu, 6 Dec 2018, Jakub Jelinek wrote:
> On Thu, Dec 06, 2018 at 10:05:15AM +0100, Richard Biener wrote:
> > Note I wonder if with -fwrapv-pointer NULL automatically becomes a
> > valid address? Or is only wrapping around half of the address
> > space UB?
>
> Hadn't thought about
On Thu, Dec 06, 2018 at 10:05:15AM +0100, Richard Biener wrote:
> Note I wonder if with -fwrapv-pointer NULL automatically becomes a
> valid address? Or is only wrapping around half of the address
> space UB?
Hadn't thought about -fwrapv-pointer, I guess we (especially with
On Thu, 6 Dec 2018, Jakub Jelinek wrote:
> Hi!
>
> If we consider -fno-delete-null-pointer-checks as a way to support e.g. AVR
> and other targets which can validly place objects at NULL rather than a way
> to workaround UBs in code, I believe the following testcase must pass if
> there is e.g.
Hi!
If we consider -fno-delete-null-pointer-checks as a way to support e.g. AVR
and other targets which can validly place objects at NULL rather than a way
to workaround UBs in code, I believe the following testcase must pass if
there is e.g.
char a[32]; // And this object ends up at
