Hi,
On Mon, 20 Jun 2011, Richard Guenther wrote:
> > of the specifications; rather, we should consider whether there is a
> > situation where a user could reasonably expect NULL + 0 to be valid.
> > In the example by Richard,
> >
> > int __attribute__((noinline)) foo (void *p, int i)
> > {
> >
On Mon, Jun 20, 2011 at 2:25 PM, Zdenek Dvorak wrote:
>> > I don't think we should move this kind of undefinedness from C to
>> > the GIMPLE semantics. What do other languages allow that
>> > we have to support (what did K&R C specify?).
>>
>> I don't think there is a formal specification of K&R
> > I don't think we should move this kind of undefinedness from C to
> > the GIMPLE semantics. What do other languages allow that
> > we have to support (what did K&R C specify?).
>
> I don't think there is a formal specification of K&R C, just the (somewhat
> informal) book. On topic of pointe
> I don't think we should move this kind of undefinedness from C to
> the GIMPLE semantics. What do other languages allow that
> we have to support (what did K&R C specify?).
I don't think there is a formal specification of K&R C, just the (somewhat
informal) book. On topic of pointer arithmetic
2011/6/17 Jeff Law :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/17/11 08:12, Zdenek Dvorak wrote:
>
if we do, we definitely should not -- the only point of such a
construction is
to bypass the pointer arithmetics restrictions,
>>>
>>> Ok, we don't. Where does the C
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/17/11 08:12, Zdenek Dvorak wrote:
>>> if we do, we definitely should not -- the only point of such a construction
>>> is
>>> to bypass the pointer arithmetics restrictions,
>>
>> Ok, we don't. Where does the C standard say that NULL + 0 is und
Hi,
> >> >> > Index: tree-vrp.c
> >> >> > ===
> >> >> > --- tree-vrp.c (revision 173703)
> >> >> > +++ tree-vrp.c (working copy)
> >> >> > @@ -2273,7 +2273,12 @@ extract_range_from_binary_expr (value_ra
> >> >> > {
> >> >> >
2011/6/17 Zdenek Dvorak :
> Hi,
>
>> >> > Index: tree-vrp.c
>> >> > ===
>> >> > --- tree-vrp.c (revision 173703)
>> >> > +++ tree-vrp.c (working copy)
>> >> > @@ -2273,7 +2273,12 @@ extract_range_from_binary_expr (value_ra
>> >> >
Hi,
> >> > Index: tree-vrp.c
> >> > ===
> >> > --- tree-vrp.c (revision 173703)
> >> > +++ tree-vrp.c (working copy)
> >> > @@ -2273,7 +2273,12 @@ extract_range_from_binary_expr (value_ra
> >> > {
> >> > /* For point
2011/6/17 Zdenek Dvorak :
>> >> Interesting. I'd never thought about the generation/use angle to prove
>> >> a pointer was non-null. ISTM we could use that same logic to infer that
>> >> more pointers are non-null in extract_range_from_binary_expr.
>> >>
>> >> Interested in tackling that improvem
> >> Interesting. I'd never thought about the generation/use angle to prove
> >> a pointer was non-null. ISTM we could use that same logic to infer that
> >> more pointers are non-null in extract_range_from_binary_expr.
> >>
> >> Interested in tackling that improvement, obviously as an independen
On Fri, Jun 17, 2011 at 12:40 PM, Tom de Vries wrote:
> On 06/17/2011 12:01 AM, Jeff Law wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 06/16/11 00:39, Tom de Vries wrote:
>>> Hi,
>>>
>>> Consider the following example.
>>>
>>> extern unsigned int foo (int*) __attribute__((pur
On 06/17/2011 12:01 AM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/16/11 00:39, Tom de Vries wrote:
>> Hi,
>>
>> Consider the following example.
>>
>> extern unsigned int foo (int*) __attribute__((pure));
>> unsigned int
>> tr (int array[], int n)
>> {
>> unsigne
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/16/11 00:39, Tom de Vries wrote:
> Hi,
>
> Consider the following example.
>
> extern unsigned int foo (int*) __attribute__((pure));
> unsigned int
> tr (int array[], int n)
> {
> unsigned int i;
> unsigned int sum = 0;
> for (i = 0; i <
On 06/16/2011 05:42 PM, Zdenek Dvorak wrote:
diff -u gcc/tree-ssa-loop-niter.c (working copy) gcc/tree-ssa-loop-niter.c
(working copy)
--- gcc/tree-ssa-loop-niter.c (working copy)
+++ gcc/tree-ssa-loop-niter.c (working copy)
@@ -2875,6 +2875,16 @@
low = lower_bound
> >> diff -u gcc/tree-ssa-loop-niter.c (working copy) gcc/tree-ssa-loop-niter.c
> >> (working copy)
> >> --- gcc/tree-ssa-loop-niter.c (working copy)
> >> +++ gcc/tree-ssa-loop-niter.c (working copy)
> >> @@ -2875,6 +2875,16 @@
> >> low = lower_bound_in_type (type, type);
> >> high = upper_b
On Thu, Jun 16, 2011 at 5:24 PM, Zdenek Dvorak wrote:
> Hi,
>
>> diff -u gcc/tree-ssa-loop-niter.c (working copy) gcc/tree-ssa-loop-niter.c
>> (working copy)
>> --- gcc/tree-ssa-loop-niter.c (working copy)
>> +++ gcc/tree-ssa-loop-niter.c (working copy)
>> @@ -2875,6 +2875,16 @@
>> low = lower
Hi,
> diff -u gcc/tree-ssa-loop-niter.c (working copy) gcc/tree-ssa-loop-niter.c
> (working copy)
> --- gcc/tree-ssa-loop-niter.c (working copy)
> +++ gcc/tree-ssa-loop-niter.c (working copy)
> @@ -2875,6 +2875,16 @@
>low = lower_bound_in_type (type, type);
>high = upper_bound_in_type (ty
On 06/16/2011 09:24 AM, Zdenek Dvorak wrote:
> Hi,
>
>> Consider the following example.
>>
>> extern unsigned int foo (int*) __attribute__((pure));
>> unsigned int
>> tr (int array[], int n)
>> {
>> unsigned int i;
>> unsigned int sum = 0;
>> for (i = 0; i < n; i++)
>> sum += foo (&array
Hi,
> Consider the following example.
>
> extern unsigned int foo (int*) __attribute__((pure));
> unsigned int
> tr (int array[], int n)
> {
> unsigned int i;
> unsigned int sum = 0;
> for (i = 0; i < n; i++)
> sum += foo (&array[i]);
> return sum;
> }
>
> For 32-bit pointers, the an
On 06/16/2011 08:39 AM, Tom de Vries wrote:
> I will sent the adapted test cases in a separate email.
Update 2 test cases to be more strict, and more like the original example.
Thanks,
- Tom
2011-06-15 Tom de Vries
PR target/45098
* gcc.target/arm/ivopts-3.c: Update test.
Hi,
Consider the following example.
extern unsigned int foo (int*) __attribute__((pure));
unsigned int
tr (int array[], int n)
{
unsigned int i;
unsigned int sum = 0;
for (i = 0; i < n; i++)
sum += foo (&array[i]);
return sum;
}
For 32-bit pointers, the analysis in infer_loop_bounds_
22 matches
Mail list logo
