This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree profiling branch] folding constant in cond expr ( for versioned node)

On May 31, 2005 10:48 AM, Razya Ladelsky <> wrote:
> The problem was when compiling a function in cp/mangle.c, where the formal 
> was substituted 
> with a constant (similar to what inlining does), in a conditional expr.
> This produced a failure of not proper gimple code.

I still don't see how it can possibly create non-GIMPLE code, but I believe
Honza said the problem is that some passes don't expect constants in the
COND_EXPR_COND of a GIMPLE conditional branch.  IMHO that is a real bug, but
I have no problem with patches like yours to sweep it under the carpet again
because this folding is probably useful for other reasons as well.

> After consulting with Honza, it seems that this fix is the proper one for 
> the moment, 
> as it is what the inliner does in these cases.


> I  encountered this problem when bootstrapping.
> However, after the latest mainline merge, bootstrapping passes without 
> this fix.
> Maybe the fix is not necessary at the moment, but I still think it should 
> be there.
> What do you think?

I believe it is not a fix, but it is still necessary.  I gather you're saying
you don't have a test case for this anymore.  Too bad :-(  Perhaps you can
try to construct one.

I also reiterate you should add a comment to explain why you fold COND_EXPRs
there.  It may be obvious to us now, but not for someone not reading this
discussion but reading your code two, three years from now.  It is not obvious
just from the code why you'd want to fold conditionals there.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]