On Thu, Jun 28, 2018 at 5:39 AM, Paolo Carlini <paolo.carl...@oracle.com> wrote: > Hi, > > On 28/06/2018 03:22, David Malcolm wrote: >> >> [snip] >>> >>> If I'm following you right, the idea is that gcc should complain >>> because two different things in the user's source code contradict >>> each >>> other. >>> >>> In such circumstances, I think we ought to try to print *both* >>> locations, so that we're showing, rather than just telling. >> >> Or to put in another way, if two things in the user's source contradict >> each other, we should show the user both. The user is going to have to >> decide to delete one (or both) of them, and we don't know which one, >> but at least by showing both it helps him/her take their next action. > > Sure, makes sense. Thus the below uses rich_location the way you explained. > I also added 2 specific testcases and extended a bit another one to exercise > a bit more min_location..Of course the patch doesn't add max_location > anymore, I suspect we are not going to find uses for a max anytime soon, > because we really want rich_location with multiple ranges in all those > cases...
> if ((type_quals & TYPE_QUAL_VOLATILE) > - && (loc == UNKNOWN_LOCATION || locations[ds_volatile] < loc)) > + && (loc == UNKNOWN_LOCATION > + || linemap_location_before_p (line_table, > + locations[ds_volatile], loc))) > loc = locations[ds_volatile]; > if ((type_quals & TYPE_QUAL_RESTRICT) > - && (loc == UNKNOWN_LOCATION || locations[ds_restrict] < loc)) > + && (loc == UNKNOWN_LOCATION > + || linemap_location_before_p (line_table, > + locations[ds_restrict], loc))) > loc = locations[ds_restrict]; Why not use min_location here? Jason
