On Sun, May 29, 2005 at 08:53:55AM -0400, Paul Schlie wrote:
> Only because I perceived it to be necessary to most ideally/optimally
> preserve the value-range result of a comparison expression. As it was
> unclear if a comparison expression were defined as having an 'int' vs.
> 'bool' result typ
> From: Diego Novillo <[EMAIL PROTECTED]>
>> On Sat, May 28, 2005 at 12:09:51PM -0400, Paul Schlie wrote:
>> - Yes thanks; but my point was that the result of comparison should remain
>> '_Bool' not 'int', and be properly promoted to likely 'char' not 'int'. As
>> for VRP to be most useful it n
On Sat, May 28, 2005 at 12:09:51PM -0400, Paul Schlie wrote:
> - Yes thanks; but my point was that the result of comparison should remain
> '_Bool' not 'int', and be properly promoted to likely 'char' not 'int'. As
> for VRP to be most useful it needs to know the minimal precision required.
>
> From: Diego Novillo <[EMAIL PROTECTED]>
>> On Sat, May 28, 2005 at 01:02:49AM -0400, Paul Schlie wrote:
>> Especially for the purpose of VRP, why wouldn't it be most ideally
>> appropriate to define the result of a comparison to be a _Bool, as it's
>> constrained to the range of 0:1; and by "usua
On Sat, May 28, 2005 at 01:02:49AM -0400, Paul Schlie wrote:
> Especially for the purpose of VRP, why wouldn't it be most ideally
> appropriate to define the result of a comparison to be a _Bool, as it's
>
Read my original message. (_Bool)1 + (_Bool)1 is folded to 0. I
needed it to be folded to
>> On Fri, May 27, 2005 at 02:45:14PM -0400, Andrew Pinski wrote:
>>> re:
>>> char *foo(char *p, char *q) {
>>> int x = (p !=0) + (q != 0);
>>> ...
>>> }
>>
>> Are you sure, the NE_EXPR does not have a type of INTEGER_TYPE?
>> This sounds like a missing fold_convert somewhere.
>>
> Ah, yes
On Fri, May 27, 2005 at 02:45:14PM -0400, Andrew Pinski wrote:
> Are you sure, the NE_EXPR does not have a type of INTEGER_TYPE?
> This sounds like a missing fold_convert somewhere.
>
Ah, yes. I see what you mean now. The comparison was of type
int but the evaluation was generating a _Bool valu
>
> On Fri, May 27, 2005 at 02:32:46PM -0400, Andrew Pinski wrote:
> > >
> > > This is happening in gcc.dg/tree-ssa/20040121-1.c. The test
> > > specifically tests that (p!=0) + (q!=0) should be computed as
> > > int:
> > >
> > > char *foo(char *p, char *q) {
> > > int x = (p !=0) + (q != 0
On Fri, May 27, 2005 at 02:32:46PM -0400, Andrew Pinski wrote:
> >
> > This is happening in gcc.dg/tree-ssa/20040121-1.c. The test
> > specifically tests that (p!=0) + (q!=0) should be computed as
> > int:
> >
> > char *foo(char *p, char *q) {
> > int x = (p !=0) + (q != 0);
> > ...
> >
>
> This is happening in gcc.dg/tree-ssa/20040121-1.c. The test
> specifically tests that (p!=0) + (q!=0) should be computed as
> int:
>
> char *foo(char *p, char *q) {
> int x = (p !=0) + (q != 0);
> ...
> }
>
> During VRP, we get this IL
>
> D.1294_10 = first_8 != 0B;
> D.1295_11
On Fri, May 27, 2005 at 02:23:02PM -0400, Ian Lance Taylor wrote:
> The program is legal C. The _Bool values should be promoted to int
> before doing the addition.
>
OK, thanks.
> I guess that type cast is being lost somewhere.
>
It doesn't seem to be ever emitted. There are no casts in
.origi
On May 27, 2005, at 11:05 AM, Diego Novillo wrote:
This is happening in gcc.dg/tree-ssa/20040121-1.c. The test
specifically tests that (p!=0) + (q!=0) should be computed as
int:
char *foo(char *p, char *q) {
int x = (p !=0) + (q != 0);
...
}
Is this program legal C?
!= is defined
Diego Novillo <[EMAIL PROTECTED]> writes:
> This is happening in gcc.dg/tree-ssa/20040121-1.c. The test
> specifically tests that (p!=0) + (q!=0) should be computed as
> int:
>
> char *foo(char *p, char *q) {
> int x = (p !=0) + (q != 0);
> ...
> }
>
...
> When we call int_const_binop
13 matches
Mail list logo
