Re: [patch] Fix wrong code for boolean negation in condition at -O

2019-03-23 Thread Eric Botcazou
> Umm, did you look at ssa_name_has_boolean_range? Isn't the problem that > Ada's BOOLEAN_TYPE has a wider range than [0..1] and thus this is the > wrong bit of code: > > /* Boolean types always have a range [0..1]. */ > if (TREE_CODE (TREE_TYPE (op)) == BOOLEAN_TYPE) > return true;

Re: [patch] Fix wrong code for boolean negation in condition at -O

2019-03-19 Thread Jeff Law
On 2/25/19 2:07 AM, Eric Botcazou wrote: > Hi, > > this is a regression present on the mainline and 8 branch, introduced by the > new code in edge_info::derive_equivalences dealing with BIT_AND_EXPR for SSA > names with boolean range: > > /* If either operand has a boolean range,

Re: [patch] Fix wrong code for boolean negation in condition at -O

2019-03-01 Thread Eric Botcazou
> The BIT_AND_EXPR case is clearly correct for all possible values. The code > says that if the result of BIT_AND_EXPR is known to be a non-zero constant, > and one or both of the BIT_AND_EXPR arguments have known value ranges [0,1] > (or boolean or precision 1, not talking about those now), then

Re: [patch] Fix wrong code for boolean negation in condition at -O

2019-02-28 Thread Jakub Jelinek
On Fri, Mar 01, 2019 at 12:19:36AM +0100, Eric Botcazou wrote: > > I know Eric has committed a tweak here, but I view this magic handling as > > something meant for boolean types only (if it is correct at all and the > > right fix wouldn't be avoid the BIT_NOT_EXPR for the prec > 1 booleans, I > >

Re: [patch] Fix wrong code for boolean negation in condition at -O

2019-02-28 Thread Eric Botcazou
> I know Eric has committed a tweak here, but I view this magic handling as > something meant for boolean types only (if it is correct at all and the > right fix wouldn't be avoid the BIT_NOT_EXPR for the prec > 1 booleans, I > believe the expansion of BIT_NOT_EXPR doesn't have any special case

Re: [patch] Fix wrong code for boolean negation in condition at -O

2019-02-28 Thread Jakub Jelinek
On Mon, Feb 25, 2019 at 10:07:10AM +0100, Eric Botcazou wrote: > 2019-02-25 Eric Botcazou > > * tree-ssa-dom.c (edge_info::derive_equivalences) : Fix > and move around comment. > : Likewise. > : Add specific handling for boolean types. This broke the following

Re: [patch] Fix wrong code for boolean negation in condition at -O

2019-02-28 Thread Eric Botcazou
> > Given the new code for BIT_AND_EXPR in edge_info::derive_equivalences for > > boolean types, I think that the same special treatment must be added for > > boolean types in the BIT_NOT_EXPR case to preserve the 0-or-1-value > > invariant. > > > > Bootstrapped/regtested on x86_64-suse-linux, OK

Re: [patch] Fix wrong code for boolean negation in condition at -O

2019-02-26 Thread Richard Biener
On Mon, Feb 25, 2019 at 10:09 AM Eric Botcazou wrote: > > Hi, > > this is a regression present on the mainline and 8 branch, introduced by the > new code in edge_info::derive_equivalences dealing with BIT_AND_EXPR for SSA > names with boolean range: > > /* If either operand has a

[patch] Fix wrong code for boolean negation in condition at -O

2019-02-25 Thread Eric Botcazou
Hi, this is a regression present on the mainline and 8 branch, introduced by the new code in edge_info::derive_equivalences dealing with BIT_AND_EXPR for SSA names with boolean range: /* If either operand has a boolean range, then we know its value must be one,