llvm-svn: 39927

llvm-svn: 39925

llvm-svn: 39907

accurate diagnostics.  For test/Lexer/comments.c we now emit:

int x = 000000080;  /* expected-error {{invalid digit}} */
               ^
constants.c:7:4: error: invalid digit '8' in octal constant
00080;             /* expected-error {{invalid digit}} */
   ^


The last line is due to an escaped newline.  The full line looks like:

int y = 0000\
00080;             /* expected-error {{invalid digit}} */


Previously, we emitted:
constants.c:4:9: error: invalid digit '8' in octal constant
int x = 000000080;  /* expected-error {{invalid digit}} */
        ^
constants.c:6:9: error: invalid digit '8' in octal constant
int y = 0000\
        ^

which isn't too bad, but the new way is better for the user,
regardless of whether there is an escaped newline or not.

All the other lexer-related diagnostics should switch over 
to using AdvanceToTokenCharacter where appropriate.  Help
wanted :).

This implements test/Lexer/constants.c.

llvm-svn: 39906

specifying the start of a token and a logical (phase 3) character number,
returns a sloc representing the input character corresponding to it.

llvm-svn: 39905

llvm-svn: 39904

llvm-svn: 39903

codegen to compile:

int test(int *A, int *B) {
  return A-B;
}

into:

_test:
        movl 4(%esp), %eax
        subl 8(%esp), %eax
        sarl $2, %eax
        ret

instead of:

_test:
        movl 4(%esp), %eax
        subl 8(%esp), %eax
        movl %eax, %ecx
        sarl $31, %ecx
        shrl $30, %ecx
        addl %ecx, %eax
        sarl $2, %eax
        ret

llvm-svn: 39902

llvm-svn: 39901

llvm-svn: 39900

llvm-svn: 39899

llvm-svn: 39898

llvm-svn: 39897

information in the common case.  On this invalid code:

typedef float float4 __attribute__((vector_size(16)));
typedef int int4 __attribute__((vector_size(16)));
void test(float4 a, int4 *result, int i) {
    result[i] = a;
}

we now generate:
  t.c:5:15: error: incompatible types assigning 'float4' to 'int4'
instead of:
  t.c:5:15: error: incompatible types assigning 'float4' to 'int  __attribute__((vector_size(16)))'

This implements test/Sema/typedef-retain.c

llvm-svn: 39892

ParseArraySubscriptExpr.  Notably, the new code doesn't have to think about 
canonical types at all.

llvm-svn: 39891

the actual vectortype or pointertype when they return success.

llvm-svn: 39890

llvm-svn: 39889

the result type of the expr node.

Implement isIntegerConstantExpr for ImplicitCastExpr nodes the same
was as for CastExpr nodes.

Implement proper sign/zero extension as well as truncation and noop
conversion in the i-c-e evaluator.  This allows us to correctly
handle i-c-e's like these:

char array[1024/(sizeof (long))];
int x['\xBb' == (char) 187 ? 1: -1];

this implements test/Sema/i-c-e2.c

llvm-svn: 39888

not all builtin types have size and alignment equal to pointers :)

llvm-svn: 39887

llvm-svn: 39886

llvm-svn: 39884

llvm-svn: 39868

virtual->physical mapping explicitly.

llvm-svn: 39867

This is the final step/commit for implementing exlicit implicit casts. Unlike the 
previous two checkins, which involved lot's of tedious refactoring, this checkin is nice and clean:-)

- Hacked UsualUnaryConversions, UsualArithmeticConversions, and DefaultFunctionArrayConversion
to create the AST node (using a helper function promoteExprToType).
- Added a setType method to Expr.
- Changed Expr::isIntegerConstantExpr to allow for the new node.

llvm-svn: 39866

llvm-svn: 39865

This doesn't significantly improve carbon.h, but it does speed up
INPUTS/macro_pounder_obj.c by 48%

llvm-svn: 39864

which makes it multithread clean.

llvm-svn: 39863

explicitly new'd array.  The array never mutates once created, so a vector
is overkill.

llvm-svn: 39862

This speeds up parsing carbon.h by 3.3% by avoiding some malloc traffic for 
small macros.

llvm-svn: 39861

llvm-svn: 39860

code more obvious.

llvm-svn: 39859

llvm-svn: 39858

llvm-svn: 39853

compute type alignment.  This info is needed for struct layout.

llvm-svn: 39850

vars.  Approach suggested by Keith.

llvm-svn: 39849

llvm-svn: 39848

llvm-svn: 39847

llvm-svn: 39846

llvm-svn: 39842

llvm-svn: 39841