[cfe-commits] implicit sign/bitwidth conversions during array indexing?

[Ted Kremenek]

On Nov 17, 2008, at 9:54 AM, Eli Friedman wrote:

> On Mon, Nov 17, 2008 at 9:49 AM, Ted Kremenek <kremenek at apple.com>  
> wrote:
>> My question is whether or not Sema should insert an implicit cast  
>> here from
>> long long to int?  It seems strange that there is an implicit cast  
>> from
>> short to int but not from long long to int.
>
> Actually, if I recall correctly, there isn't an implicit cast either
> way for the case of array subscripting.

Hi Eli,

I think too much of the original thread got lost.  Your right that  
there is no implicit cast for array subscripting.  We do insert  
implicit casts for pointer arithmetic.  For example:

void f(int *p) {
   short i = 0;
   long long k = 0;

   int x;
   x = *(p + i);   // implicit cast for 'i' from short to int
   x += *(p + k); // no implicit cast for 'k' from long long to int

   return x;
}

The standard says that E1[E2] is the same as *(E1 + E2), so I was  
curious why there was no implicit cast from long long to int when  
doing pointer arithmetic.  I also think that we should probably have  
an implicit cast when performing array indexing, but that's a separate  
matter from my original question.

>
> The issue with inserting an implicit cast from long long to int is
> that conceptually, it isn't there!  The fact that we truncate long
> long to i32 in CodeGen is really just an artifact of the
> implementation on 32-bit machines.


Regardless of Codegen, conceptually the types are changing.  Even for  
the following code we insert an implicit cast from 'long' to 'int'  
even on a 32-bit machine:

   long x = 0;
   int y = x;

Obviously, in the case of a 64-bit machine the implicit cast becomes  
even more valuable since it implies a truncation during CodeGen.

For the array indexing (or rather pointer arithmetic), is it not the  
case that the 'long long' is being converted (always) to an integer  
with the same width as a pointer?  Moreover, the sign of the integer  
type is changing.  This seems like something that should be  
semantically captured in the ASTs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20081117/e948af5c/attachment.html>