Re: can_throw_internal affected by inlining?

[Jan Hubicka <hubicka at ucw dot cz>]

> I'm committing the following test case that displays the bug.  It does 
> in fact pass with mainline, and does in fact fail with gcc 4.4.0.
> 
> I spent two days trying to come up with some cleaner way to fix this bug 
> than the inlinable flag you pass around, but to no avail.  The only 
> thing better I could think of is some global flag (or state variable) 
> that indicates whether or not inlining is complete.  At least then we 
> would not have to pass around that flag.  But I wouldn't want to 
> introduce yet another boolean state variable; I'd much prefer all of the 
> existing state variables we have be consolidated, and I can't justify 
> spending the time on that just now.

There is cfun->after_inlinng that says you this info on per-function
basis.
I will run the tests on C++ benchmarks this weekend whether simply
assuming all calls to be possibly inlined throws before this flag is set
is producing noticeable degradation in memuse/compile time.

Honza
> 
> >Well, we can either teach inlinable_call_p to handle your new indirect
> >calls as "for sure uninlinable"
> 
> This is the approach I'll take.  I've already hacked on an extra bit in 
> the gimple call subcode to indicate whether an indirect call is nothrow; 
> I might as well add another bit to say an indirect call is noinline.

Yep, it seems sort of resonable too.

Honza