On Wed, May 06, 2009 at 03:42:47PM -0700, Ian Lance Taylor wrote:
> Stelian Pop writes:
>
> There is something strange in your trees. Why did it convert the
> pointers to "long int"? Why did it not simply convert them to "int"?
> The fact that they are going to be assigned to a "long int" vari
Stelian Pop writes:
>> I took a quick look at a similar case for x86, and the key step seems to
>> be a call to ptr_difference_const. It converts the difference of two
>> ADDR_EXPRs to a constant.
>
> in my case ptr_difference_const doesn't get called at all, because
> the operands are no longer
On Wed, May 06, 2009 at 01:23:57PM -0700, Ian Lance Taylor wrote:
> Stelian Pop writes:
>
> > I did spent a few hours looking but haven't had much luck.
> >
> > I tried tracing this one:
> >> > 6 long i = s.f-&s.b;
> > and noticed that the pointers gets casted to 'long' (so they become integers
Stelian Pop writes:
> I did spent a few hours looking but haven't had much luck.
>
> I tried tracing this one:
>> >6 long i = s.f-&s.b;
> and noticed that the pointers gets casted to 'long' (so they become integers
> and no longer pointers) before the actual substraction is made.
>
> Of cours
On Wed, May 06, 2009 at 12:19:55PM -0700, Ian Lance Taylor wrote:
> Stelian Pop writes:
>
> > on TARGET_8W and TARGET_16:
> > 920928-1.c:
> > 1 struct{int c;}v;
> > 2 static long i=((char*)&(v.c)-(char*)&v)
> > 930326-1.c:
> > 1 struct
> > 2 {
> > 3 char a, b, f[3];
> >
Stelian Pop writes:
> on TARGET_8W and TARGET_16:
> 920928-1.c:
> 1 struct{int c;}v;
> 2 static long i=((char*)&(v.c)-(char*)&v)
> 930326-1.c:
> 1 struct
> 2 {
> 3 char a, b, f[3];
> 4 } s;
> 5
> 6 long i = s.f-&s.b;
> labels-3.c:
>9 int f
