llvm-svn: 39950

Convert UsualArithmeticConversions to return "void". Now that we synthesize ImplicitCastExpr's,
there is no compelling need to return the converted type. If both expression type's are arithmetic, then
both types will always be the same. If they aren't (for pointer/int types, say), then the
types will be different. The client is responsible for distinguishing...

llvm-svn: 39947

beyond the end of an alloca to make FastDSE faster and more aggressive.

llvm-svn: 39945

llvm-svn: 39944

Implement semantic analysis for the cast operator.

llvm-svn: 39943

Sigh .. fix copy & paste error.

llvm-svn: 39939

found by prepending a .
In build-for-llvm-top.sh, dereference variables for exansion.

llvm-svn: 39936

Remove the 2 QualType references to method UsualArithmeticConversions. Last week, I added these
to quickly fix a regression. Avoiding them entirely is a much cleaner solution. Clients of 
UsualArithmeticConversions should simply call getType() on the expression to get the
converted type. In practice, only a small number of routines care about this.

llvm-svn: 39934

This also avoids a fork bomb from the llvm-top/build script which
doesn't know how to handle cycles in the dependence graph.

llvm-svn: 39933

isPointerType and isVectorType to only look through a single level of typedef
when one is present.  For this invalid code:

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

we now get:

t.c:5:15: error: incompatible types assigning 'float4' to 'int4'
    result[i] = a;
    ~~~~~~~~~ ^ ~

instead of:

t.c:5:15: error: incompatible types assigning 'float4' to 'int  __attribute__((vector_size(16)))'
    result[i] = a;
    ~~~~~~~~~ ^ ~

The rest of the type predicates should be upgraded to do the same thing.

llvm-svn: 39932

llvm-svn: 39931

Change DefaultFunctionArrayConversions and UsualUnaryConversions to return void. The caller 
needs to query the expression for the type. Since both these functions guarantee the expression 
contains a valid type, removed old/vacuous asserts (from code calling both of these routines).

llvm-svn: 39930

dead stores on 400.perlbench.

llvm-svn: 39929

SemaExpr.cpp:561: warning: dereferencing type-punned pointer will break strict-aliasing rules

Patch by Benoit Boissinot!

llvm-svn: 39928

llvm-svn: 39927

llvm-svn: 39926

llvm-svn: 39925

llvm-gcc build to succeed. Without this change it fails in libstdc++
compilation. This causes no regressions in dejagnu tests. However, 
someone who knows this code better might want to review it.

llvm-svn: 39924

have an error, and refector out the code for binary operators into
ConstantFoldBinaryFP and use it for all binary floating-point operations
which may have an error. These functions still rely exclusively on errno
to detect errors though.

llvm-svn: 39923

which appears to be the intent.

llvm-svn: 39922

llvm-svn: 39921

where it's interpreted as a comment, not part of the syntax.

llvm-svn: 39920

llvm-svn: 39917

llvm-svn: 39916

llvm-svn: 39915

of the cyclic depndency between llvm and llvm-gcc-4-0.

llvm-svn: 39910

llvm-svn: 39909

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

llvm-svn: 39896

llvm-svn: 39895