Yeah, at least for the unittest I provided, the coverage info will be wrong without the patch.
Thanks, Dehao On Thu, Nov 15, 2012 at 10:30 AM, Xinliang David Li <davi...@google.com> wrote: > I probably made too general statement in this topic. However for the > PRE case, I believe the choice of not using UNKNOWN location is still > better. > > thanks, > > David > > On Thu, Nov 15, 2012 at 9:23 AM, Eric Botcazou <ebotca...@adacore.com> wrote: >>> The randomness here means that if we set UNKNOWN_LOCATION to insn, it >>> can get source location anywhere. Even with some small code layout >>> changes, the location for that insn could change. I would hope that in >>> the future, we add an assertion when emitting instruction to enforce >>> that INSN_LOCATION is never UNKNOWN_LOCATION. So when generate new >>> instructions/stmts, if we can surely know where it is coming from, it >>> is fine. Otherwise, instead of using UNKNOWN_LOCATION, we will set its >>> location to where it is inserted. How does that sound? >> >> Still the same problem: you cannot make that a general rule, since you don't >> know the coverage status of the instruction just above the insertion point. >> If a later optimization moves the new statements around, you may well end up >> with wrong coverage info. >> >> -- >> Eric Botcazou
