http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094
--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> 2013-01-24 19:30:54 UTC --- "manu at gcc dot gnu.org" <gcc-bugzi...@gcc.gnu.org> wrote: > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094 > >--- Comment #9 from Manuel López-Ibáñez <manu at gcc dot gnu.org> >2013-01-24 18:39:18 UTC --- >> During original gimplification, I can understand the OR_HERE (aka >> input_location) part there, or in passes that maintain >input_location. > >I thought gimplification happens after each whole function is read, how >is >input_location correct in that case? Moreover, how do optimization >passes try >to mantain input_location accurate? Input_location should only be used from parsing. Other places reuse the variable and those happen to eventually pick up stale values, such as gimplification. We should Arrange for different globals to be used there and privatize input_location. In the meantime assert that input_location is unknown when Entering or leaving passes. > >> force_gimple_operand* should temporarily set input_location to >UNKNOWN_LOCATION >> and restore it back from a saved copy before returning. > >My fear is that this is basically delaying the inevitable, which is >getting rid >of input_location. At some moment, the saving/restoring of >input_location in >random points will start conflicting in unexpected ways and the whole >thing >will be unfixable without breaking something else.
