https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #21 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 23 Mar 2016, manu at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 > > --- Comment #19 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #17) > > "caused" by r44789 which introduced this path (initially with error || > > to_file == NULL) with a description of just > > > > (add_line_map): Return pointer to const. When passed NULL to_file > > with LC_LEAVE, use the obvious values for the return point so the > > caller doesn't have to figure them out. > > > > I will test the change. > > I'm not sure what this change ends up creating in the line-table. You may end > up creating just a different kind of invalid line-table. If it creates a > LC_LEAVE or a LC_RENAME with to_file==NULL or to_line==0, that seems broken in > just a different way. A LC_RENAME with to_file=="Unified_cpp_js_src35.ii" and > to_line==2 would be ok (just useless, because we are basically creating a new > map to say: we are at the same file at the same line as before). It depends on what the line directive was parsed with. > Also, it may work for this case, since we are returning to the main file and > the main file info was ok. I'm not sure what will happen when there are > several > included files (that is, the other branch that can set error == true). We parse the thing as LC_RENAME, so I think we're fine and any further bug would be in the callers. That said, I'd like to see motivating testcases for the error || as it seemingly was introduced as an unrelated change that may seemed to make sense (but certainly "obvious values" as the ChangeLog claims is only valid for the NULL to_file case, not for the error case as seen here).
