llvm-svn: 64727

llvm-svn: 64725

possible future "data loss" warnings, and b) makes it intensely
obvious to the user what the impl of these functions do in a
ambiguity error.

llvm-svn: 64724

llvm-svn: 64723

Now no candidates are printed because the 'notes' are in a system header. :(

#include <tgmath-sofar.h>
 double foo2(short *x) {
  return acos(x);
}

t.c:10:10: error: no matching function for call to '__tg_acos'; candidates are:
  return acos(x);
         ^~~~
1 diagnostic generated.

llvm-svn: 64722

all the integer types other than char/short to avoid overload ambiguities.

llvm-svn: 64721

produces really horrible diagnostics when overload ambiguities
happen:

t.c:10:10: error: call to '__tg_acos' is ambiguous; candidates are:
  return acos(x);
         ^~~~
In file included from t.c:1:
/Users/sabre/llvm/Debug/Headers/tgmath-sofar.h:49:1: note: candidate function
__TG_RC_1(x, acos, cacos)
^
/Users/sabre/llvm/Debug/Headers/tgmath-sofar.h:49:1: note: candidate function
__TG_RC_1(x, acos, cacos)
^
/Users/sabre/llvm/Debug/Headers/tgmath-sofar.h:49:1: note: candidate function
__TG_RC_1(x, acos, cacos)
^
/Users/sabre/llvm/Debug/Headers/tgmath-sofar.h:49:1: note: candidate function
__TG_RC_1(x, acos, cacos)
^
/Users/sabre/llvm/Debug/Headers/tgmath-sofar.h:49:1: note: candidate function
__TG_RC_1(x, acos, cacos)
^
/Users/sabre/llvm/Debug/Headers/tgmath-sofar.h:49:1: note: candidate function
__TG_RC_1(x, acos, cacos)
^

A possible fix is to just not use macros for this, which I'll probably go for,
but it would be nice to emit the type at the call, so we know what we asked for!

llvm-svn: 64720

instance in Sema be a pimpl.

llvm-svn: 64718

CXXRecordDecl that is used to represent class template
specializations. These are canonical declarations that can refer to
either an actual class template specialization in the code, e.g.,

  template<> class vector<bool> { };

or to a template instantiation. However, neither of these features is
actually implemented yet, so really we're just using (and uniqing) the
declarations to make sure that, e.g., A<int> is a different type from
A<float>. Note that we carefully distinguish between what the user
wrote in the source code (e.g., "A<FLOAT>") and the semantic entity it
represents (e.g., "A<float, int>"); the former is in the sugared Type,
the latter is an actual Decl.

llvm-svn: 64716

llvm-svn: 64712

llvm-svn: 64711

makes -emit-html do nice things for code like:

#define FOO(X) y

int FOO(4
);

highlighting the FOO instance as well as the ) on the next line properly.

llvm-svn: 64710

llvm-svn: 64701

llvm-svn: 64700

llvm-svn: 64692

nonfragile abi.

llvm-svn: 64690

 - Define pow[lf]?, sqrt[lf]? as builtins.

 - Add -fmath-errno option which binds to LangOptions.MathErrno

 - Add new builtin flag Builtin::Context::isConstWithoutErrno for
   functions which can be marked as const if errno isn't respected for
   math functions. Sema automatically marks these functions as const
   when they are defined, if MathErrno=0.

 - IRgen uses const attribute on sqrt and pow library functions to
   decide if it can use the llvm intrinsic.

llvm-svn: 64689

Doug: please verify that it is expected that LastIdx can be less that
NumInits. And perhaps add a comment so that Chris doesn't break your
code. :)

llvm-svn: 64688

extensions). This caught a couple bugs in our test suite :)

llvm-svn: 64686

llvm-svn: 64684

emit two volatile loads for:
typedef __attribute__(( ext_vector_type(4) )) float float4;

float test(volatile float4 *P) {
  return P->x+P->y;
}

llvm-svn: 64683

llvm-svn: 64681

llvm-svn: 64680

We now pass all the deprecation tests in the objc.dg suite.

llvm-svn: 64679

llvm-svn: 64676

 - Fix test case to not only have negative tests.

llvm-svn: 64674

llvm-svn: 64673

llvm-svn: 64672

llvm-svn: 64671

llvm-svn: 64670

dubious, but at least mark it as an invalid decl.

llvm-svn: 64668

llvm-svn: 64667

prototype, synthesize ParmVarDecls for prototype-less FunctionDecl.

llvm-svn: 64666

llvm-svn: 64660

whose declaration was declared as deprecated.

llvm-svn: 64658

the same.

llvm-svn: 64657

interface for ivars before assuming that this is an unresolved
function name.

Fixes <rdar://problem/6590445>.

llvm-svn: 64653

llvm-svn: 64652

llvm-svn: 64651

llvm-svn: 64650