On Mon, 2023-07-31 at 13:46 +0200, Benjamin Priour wrote:
> Hi Dave,
>
> On Fri, Jul 21, 2023 at 10:10 PM David Malcolm <[email protected]>
> wrote:
[...snip...]
> >
> > I see that we have test coverage for:
> > noexcept-new.C: -fno-exceptions with new vs nothrow-new
> > whereas:
> > new-2.C has (implicitly) -fexceptions with new
> >
> > It seems that of the four combinations for:
> > - exceptions enabled or disabled
> > and:
> > - throwing versus non-throwing new
> > this is covering three of the cases but is missing the case of
> > nothrow-
> > new when exceptions are enabled.
> > Presumably new-2.C should gain test coverage for this case. Or am
> > I
> > missing something here? Am I right in thinking that it's possible
> > for
> > the user to use nothrow new when exceptions are enabled to get a
> > new
> > that can fail and return nullptr? Or is that not possible?
> >
> >
> Thanks a lot for spotting that, the new test pointed out an issue
> with the
> detection of nothrow.
> It has been fixed and now both test cases behave similarly.
> However, this highlighted a faulty test case I had written.
>
> int* y = new(std::nothrow) int();
> int z = *y + 2; /* { dg-warning "dereference of NULL 'y'" } */
> /* { dg-warning "use of uninitialized value '\\*y'" "" { xfail *-*-*
> } .-1
> } */ // (#) should be a bogus
> delete y;
>
> The test labelled (#) is wrong and should be a bogus instead.
Am I right in thinking that by this you mean that with the patch, the
analyzer complains about "use of uninitialized value '*y'" ? (which
would be an incorrect warning)
> If "y" is null then the allocation failed and dereferencing "y" will
> cause
> a segfault, not a "use-of-uninitialized-value".
> Thus we should stick to 'dereference of NULL 'y'" only.
> If "y" is non-null then the allocation succeeded and "*y" is
> initialized
> since we are calling a default initialization with the empty
> parenthesis.
I *think* it's possible to have the region_model have y pointing to a
heap_allocated_region of sizeof(int) size that's been initialized, but
still have the malloc state machine part of the program_state say that
the pointer is maybe-null.
What does the gimple look like and what does the program_state look
like after the assignment to y?
>
> This led me to consider having "null-dereference" supersedes
> "use-of-uninitialized-value", but
> new PR 110830 made me reexamine it.
>
> I believe fixing PR 110830 is thus required before submitting this
> patch,
> or we would have some extra irrelevant warnings.
How bad would the problem be? PR 110830 looks a little involved, so is
there a way to get the current patch in without dragging that extra
complexity in?
[...snip...]
Thanks
Dave
