On Thu, Oct 19, 2017 at 2:47 PM, Richard Earnshaw (lists) <richard.earns...@arm.com> wrote: > On 19/10/17 09:14, Richard Biener wrote: >> On Wed, Oct 18, 2017 at 6:59 PM, Egeyar Bagcioglu >> <egeyar.bagcio...@oracle.com> wrote: >>> Hello, >>> >>> Test case "guality.exp=nrv-1.c" fails on aarch64. Optimizations reorder the >>> instructions and cause the value of a variable to be checked before its >>> first assignment. The following patch is moving the >>> break point to the end of the function. Therefore, it ensures that the break >>> point is reached after the assignment instruction is executed. >>> >>> Please review the patch and apply if legitimate. >> >> guality testcases are mostly user-experience tests but they are indeed >> prone to the usual jumpiness. As a user we'd expect a breakpoint >> on this line to trigger only if previous stmts have been committed. >> > > If all the side effects of the later expression occur before any of the > side effects of the earlier one then this would never happen. > > You might be able to concoct dwarf expressions that gave the appearance > of the expression having been evaluated, but memory dumping would almost > certainly reveal that memory hadn't really been updated at that point. > >> I guess Alex work on stmt frontiers will fix this instance? > > Don't stmt frontiers just enable you to identify exactly one stopping > point with each statement, so that you don't keep repeatedly stepping to > the same line?
I thought they made sure the point it comes up with is at least somewhat correlated with the intended point in the excution flow? If we're allowed to move all those notes to the beginning of the function with just keeping their order I would miss the point of having them at all. But I don't remember anything "invalidating" such notes in the patch so maybe this is indeed what they are... :/ Richard. > R. > >> >> Richard. >> >>> Egeyar >>> > >
