Move tests that have C/C++ sources into the appropriate directory. This
allows them to be selected for testing based on whether llvm-gcc is
present or not.
llvm-svn: 39963
According to the spec (C++ 5p6[expr]), we need to adjust "T&" to
"T" before further analysis. We do this via the "implicit cast"
thingy.
llvm-svn: 39953
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
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
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
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
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
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
Evan Cheng