Richard Sandiford
Thu Jul 5 07:18:00 GMT 2007

Alexandre Oliva <> writes:
> On Jul  4, 2007, David Edelsohn <> wrote:
>>>>>>> Alexandre Oliva writes:
> Alexandre> It's as mechanical as the change you proposed, except that yours
> Alexandre> potentially loses information that would enable someone to recover 
> Alexandre> !BEFORE_RELOAD_P() out of the expanded version of no_new_pseudos.
>> 	Except that no_new_pseudos was not used consistently.
> I'm not sure what you mean by "consistently", but regardless, how
> could any argument possibly make it better to replace it with
>   (reload_in_progress || reload_completed)
> rather than
> such that anyone willing to clean things up from this point on may
> have to use complex grep patters to account for ongoing line breaks,
> reformatting and any other boolean transformations, just because it
> had to be expanded right away rather than retained as a macro?
> What I'm proposing is just that, instead of
>   s/no_new_pseudos/(reload_in_progress || reload_completed)/g
> we use
>   s/no_new_pseudos/!BEFORE_RELOAD_P ()/
> or at least keep no_new_pseudos as a macro that can be easily grepped
> for and doesn't break line length limits in current sources.
> I'm not asking for any actual cleanups to be reverted, just that we
> don't make it even harder to further clean it up.  If taking out one
> of these three variables is good, taking out another of them is going
> to be better, right?  Making it harder (or, more accurately, uglier)
> to do so isn't helping.

For the record, Alex puts my point of view perfectly here too.
I gather from the follow-ups that there's resistance to
s/no_new_pseudos/!BEFORE_RELOAD_P ()/ -- with BEFORE_RELOAD_P
defined as "reload_in_progress || reload_completed" until Alex's
follow-on change is implemented -- but I don't understand why.


More information about the Gcc mailing list