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 needs to
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 type,
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 2.
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 usual
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.
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 = last_9 != 0B;
x_12 =
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 to fold
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
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
.original:
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);
...
}
During
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: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 value.
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. I see what you mean
13 matches
Mail list logo
