This is the mail archive of the gcc-bugs@gcc.gnu.org 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]

[Bug tree-optimization/34648] [4.3 Regression] ICE in find_or_generate_expression



------- Comment #9 from rguenther at suse dot de  2008-01-16 21:18 -------
Subject: Re:  [4.3 Regression] ICE in
 find_or_generate_expression

On Wed, 16 Jan 2008, amacleod at redhat dot com wrote:

> ------- Comment #8 from amacleod at redhat dot com  2008-01-16 20:53 -------
> Created an attachment (id=14951)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14951&action=view)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14951&action=view)
> proposed patch for sccvn
> 
> I did some analysis, and then verified with dberlin that I was on the right
> track.

Thanks!

> The root of the problem is a disconnect between SCCVN and PRE.
> 
> The function bar() is a function call which is a constant. SCCVN therefore puts
> it in the tables as a value which can be regenerated by calling bar().
> 
> PRE in turn looks at the call and notes that it can throw an exception, and
> says that it is therefore *not* an expression which can be regenerated.
> 
> Things then fail in find_or_generate_expression() because the expression is in
> the table, but PRE is unable to regenerate it.
> 
> In order to fix the problem, we need to make SCCVN and PRE agree whether a
> constant function which can throw is an expression which can be regenerated.
> 
> My initial take on that it is not, because the throw could result in some side
> effects.
> 
> The decl for bar() is
> 
>    extern const unsigned short int **bar (void) __attribute__ ((const));
> 
> The other question is 'is that really a throwable function?'

A const function does not throw.  From the docs:

"..., and have no effects except the return value."

likewise pure functions do not throw.

> tree_could_throw_p() currently returns TRUE for bar().  This problem could also
> be fixed by bar() not being a throwable expression. I'm assuming this is well
> defined, and currently correct. 

Yes it is.  I think adjusting tree_could_throw_p() is the correct
thing to do.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34648


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