Re: [PATCH] Fix PR68067

2015-11-30 Thread Richard Biener
On Fri, 27 Nov 2015, Alan Lawrence wrote: > On 27/11/15 15:07, Alan Lawrence wrote: > > On 23/11/15 09:43, Richard Biener wrote: > > > On Fri, 20 Nov 2015, Alan Lawrence wrote: > > > > > > > ...the asserts > > > > you suggested in > > > >

Re: [PATCH] Fix PR68067

2015-11-30 Thread Jeff Law
On 11/30/2015 01:42 AM, Richard Biener wrote: Yeah. I've pondered with clearing the hashmap after each pass (and hope no IPA pass would redirect edges). Or even more aggressive, clear the hashmap as well when we do set_cfun (). Maybe you can try that? And no, I don't think any pass expects

Re: [PATCH] Fix PR68067

2015-11-27 Thread Alan Lawrence
On 27/11/15 15:07, Alan Lawrence wrote: On 23/11/15 09:43, Richard Biener wrote: On Fri, 20 Nov 2015, Alan Lawrence wrote: ...the asserts you suggested in (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D68117#c27)... >> So I have to ask, how sure are you that those assertions are(/should

Re: [PATCH] Fix PR68067

2015-11-27 Thread Alan Lawrence
On 23/11/15 09:43, Richard Biener wrote: On Fri, 20 Nov 2015, Alan Lawrence wrote: ...the asserts you suggested in (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D68117#c27)... >> So I have to ask, how sure are you that those assertions are(/should be!) "correct"? :) Ideally they should be

Re: [PATCH] Fix PR68067

2015-11-23 Thread Richard Biener
On Fri, 20 Nov 2015, Alan Lawrence wrote: > On 6 November 2015 at 10:39, Richard Biener wrote: > >> ../spec2000/benchspec/CINT2000/254.gap/src/polynom.c:358:11: error: > >> location > >> references block not in block tree > >> l1_279 = PHI <1(28), l1_299(33)> > > > > ^^^ > >

Re: [PATCH] Fix PR68067

2015-11-20 Thread Alan Lawrence
On 6 November 2015 at 10:39, Richard Biener wrote: >> ../spec2000/benchspec/CINT2000/254.gap/src/polynom.c:358:11: error: location >> references block not in block tree >> l1_279 = PHI <1(28), l1_299(33)> > > ^^^ > > this is the error to look at! It means that the GC heap will

Re: [PATCH] Fix PR68067

2015-11-06 Thread Alan Lawrence
On 28/10/15 13:38, Richard Biener wrote: Applied as follows. Bootstrapped / tested on x86_64-unknown-linux-gnu. Richard. 2015-10-28 Richard Biener * fold-const.c (negate_expr_p): Adjust the division case to properly avoid introducing undefined overflow.

Re: [PATCH] Fix PR68067

2015-11-06 Thread Richard Biener
On Fri, 6 Nov 2015, Alan Lawrence wrote: > On 28/10/15 13:38, Richard Biener wrote: > > > > Applied as follows. > > > > Bootstrapped / tested on x86_64-unknown-linux-gnu. > > > > Richard. > > > > 2015-10-28 Richard Biener > > > > * fold-const.c (negate_expr_p):

Re: [PATCH] Fix PR68067

2015-11-06 Thread Richard Biener
On Fri, 6 Nov 2015, Alan Lawrence wrote: > On 06/11/15 10:39, Richard Biener wrote: > > > ../spec2000/benchspec/CINT2000/254.gap/src/polynom.c:358:11: error: > > > location > > > references block not in block tree > > > l1_279 = PHI <1(28), l1_299(33)> > > > > ^^^ > > > > this is the error to

Re: [PATCH] Fix PR68067

2015-11-06 Thread Alan Lawrence
On 06/11/15 10:39, Richard Biener wrote: ../spec2000/benchspec/CINT2000/254.gap/src/polynom.c:358:11: error: location references block not in block tree l1_279 = PHI <1(28), l1_299(33)> ^^^ this is the error to look at! It means that the GC heap will be corrupted quite easily. Thanks, I'll

Re: [PATCH] Fix PR68067

2015-11-06 Thread Jeff Law
On 11/06/2015 05:26 AM, Richard Biener wrote: On Fri, 6 Nov 2015, Alan Lawrence wrote: On 06/11/15 10:39, Richard Biener wrote: ../spec2000/benchspec/CINT2000/254.gap/src/polynom.c:358:11: error: location references block not in block tree l1_279 = PHI <1(28), l1_299(33)> ^^^ this is the

Re: [PATCH] Fix PR68067

2015-10-28 Thread Richard Biener
On Tue, 27 Oct 2015, Richard Biener wrote: > On Tue, 27 Oct 2015, Richard Biener wrote: > > > > > The following patch adjusts negate_expr_p to account for the fact > > that we can't generally change a - (b - c) to (c - b) + a because > > -INF - 0 is ok while 0 - -INF not. Similarly for a - (b

[PATCH] Fix PR68067

2015-10-27 Thread Richard Biener
The following patch adjusts negate_expr_p to account for the fact that we can't generally change a - (b - c) to (c - b) + a because -INF - 0 is ok while 0 - -INF not. Similarly for a - (b + c). While creating testcases I noticed that MULT_EXPR handling is bogus as well as with -INF/2 * 2 neither

Re: [PATCH] Fix PR68067

2015-10-27 Thread Richard Biener
On Tue, 27 Oct 2015, Richard Biener wrote: > > The following patch adjusts negate_expr_p to account for the fact > that we can't generally change a - (b - c) to (c - b) + a because > -INF - 0 is ok while 0 - -INF not. Similarly for a - (b + c). > While creating testcases I noticed that