On Fri, Jan 10, 2025 at 3:27 PM Qing Zhao <qing.z...@oracle.com> wrote:
>
>
>
> > On Jan 10, 2025, at 03:00, Richard Biener <richard.guent...@gmail.com> 
> > wrote:
> >
> > On Thu, Jan 9, 2025 at 9:39 PM Qing Zhao <qing.z...@oracle.com> wrote:
> >>
> >>
> >>
> >>> On Jan 9, 2025, at 14:10, Jeff Law <jeffreya...@gmail.com> wrote:
> >>>
> >>>
> >>>
> >>> On 1/9/25 10:48 AM, Qing Zhao wrote:
> >>>
> >>>>>
> >>>>> I think Jeff's patch is not reasonable since it boils down to not 
> >>>>> diagnose
> >>>>> -Warray-bounds but instead remove those stmts.
> >>>> If these stmts are dead-code that are generated by compiler optimization 
> >>>> (NOT from source code),
> >>>> removing them before diagnosis is correct. (To avoid false positive 
> >>>> warnings).
> >>> But I don't think we generally know if the problematic statements came 
> >>> from user code or were generated by the compiler.
> >>
> >> To help the compiler catches real problems in the source code and avoid 
> >> false positive warnings introduced by the compiler transformation, we 
> >> might need to add flags in the IR to distinguish this?
> >
> > Well, the issue is the problematic statements _are_ in user code, just
> > -Warray-bounds is too stupid to
> > look at SCEV for indices and instead relies on weaker value-ranges.
>
> A little confused here: are you saying that the testing case of PR92539 has 
> __conditional__ UB in the source code level?
> If so, could you please clarify this a little bit more? (From my 
> understanding of the source code, I didn’t see
> UB in the source code, do I miss anything obvious?)

static bool eat(char const*& first, char const* last)
{
    if (first != last && ischar(*first)) {
        ++first;
        return true;
    }
    return false;
}

static bool eat_two(char const*& first, char const* last)
{
    auto save = first;
    if (eat(first, last) && eat(first, last))
        return true;

The ++first is the conditional UB stmt for the 2nd eat().  It's
conditional on the first eat() returning true and first != last.

The compiler now needs to prove that these conditions
are enough that UB never happens at runtime.  uninit
analysis for example would diagnose if it cannot prove that
while -Warray-bounds simply always diagnoses regardless
of how the conditions are but it requires "obvious" UB.

Richard.

>
> thanks.
>
> Qing
> >
> > It's a problem we're never going to fully solve.  Some of the
> > testcases show missed optimizations
> > which we can work on.  Some show we diagnose IL we later are able to
> > optimize away, some
> > simply show that users are not always happy with how we decide on
> > suppressing a diagnostic.
> >
> > For the case at hand we should be able to optimize it fully.
> >
> > But optimizing based on UB is always going to be to interact with
> > diagnosing UB, so we have
> > to be careful.  Our "late" diagnostics are most problematic here and
> > I'd argue moving those
> > earlier is the first thing we should try.
> >
> > Richard.
> >
> >>
> >> Qing
> >>>
> >>> Jeff
>
>

Reply via email to