summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGen/overloadable.c
Commit message (Collapse)AuthorAgeFilesLines
* Bring r325915 back.Rafael Espindola2018-02-231-3/+3
| | | | | | | | | | | | | | | The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
* Move CHECK right before the function it describes.George Burgess IV2016-09-071-1/+1
| | | | llvm-svn: 280852
* [Sema] Compare bad conversions in overload resolution.George Burgess IV2016-09-071-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | r280553 introduced an issue where we'd emit ambiguity errors for code like: ``` void foo(int *, int); void foo(unsigned int *, unsigned int); void callFoo() { unsigned int i; foo(&i, 0); // ambiguous: int->unsigned int is worse than int->int, // but unsigned int*->unsigned int* is better than // int*->int*. } ``` This patch fixes this issue by changing how we handle ill-formed (but valid) implicit conversions. Candidates with said conversions now always rank worse than candidates without them, and two candidates are considered to be equally bad if they both have these conversions for the same argument. Additionally, this fixes a case in C++11 where we'd complain about an ambiguity in a case like: ``` void f(char *, int); void f(const char *, unsigned); void g() { f("abc", 0); } ``` ...Since conversion to char* from a string literal is considered ill-formed in C++11 (and deprecated in C++03), but we accept it as an extension. llvm-svn: 280847
* [Sema] Relax overloading restrictions in C.George Burgess IV2016-09-021-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch allows us to perform incompatible pointer conversions when resolving overloads in C. So, the following code will no longer fail to compile (though it will still emit warnings, assuming the user hasn't opted out of them): ``` void foo(char *) __attribute__((overloadable)); void foo(int) __attribute__((overloadable)); void callFoo() { unsigned char bar[128]; foo(bar); // selects the char* overload. } ``` These conversions are ranked below all others, so: A. Any other viable conversion will win out B. If we had another incompatible pointer conversion in the example above (e.g. `void foo(int *)`), we would complain about an ambiguity. Differential Revision: https://reviews.llvm.org/D24113 llvm-svn: 280553
* [Sema] Allow implicit conversions of &overloaded_fn in C.George Burgess IV2016-03-231-0/+30
| | | | | | | | | | | | | | | | | | | | | | | Also includes a minor ``enable_if`` docs update. Currently, our address-of overload machinery will only allow implicit conversions of overloaded functions to void* in C. For example: ``` void f(int) __attribute__((overloadable)); void f(double) __attribute__((overloadable, enable_if(0, ""))); void *fp = f; // OK. This is C and the target is void*. void (*fp2)(void) = f; // Error. This is C, but the target isn't void*. ``` This patch makes the assignment of `fp2` select the `f(int)` overload, rather than emitting an error (N.B. you'll still get a warning about the `fp2` assignment if you use -Wincompatible-pointer-types). Differential Revision: http://reviews.llvm.org/D13704 llvm-svn: 264132
* AST: Implement mangling support for function types without a prototype.Peter Collingbourne2015-08-071-0/+3
| | | | | | | | | | Function types without prototypes can arise when mangling a function type within an overloadable function in C. We mangle these as the absence of any parameter types (not even an empty parameter list). Differential Revision: http://reviews.llvm.org/D11848 llvm-svn: 244374
* Remove the -cxx-abi command-line flag.Hans Wennborg2014-01-141-1/+3
| | | | | | | | | | | | | | | This makes the C++ ABI depend entirely on the target: MS ABI for -win32 triples, Itanium otherwise. It's no longer possible to do weird combinations. To be able to run a test with a specific ABI without constraining it to a specific triple, new substitutions are added to lit: %itanium_abi_triple and %ms_abi_triple can be used to get the current target triple adjusted to the desired ABI. For example, if the test suite is running with the i686-pc-win32 target, %itanium_abi_triple will expand to i686-pc-mingw32. Differential Revision: http://llvm-reviews.chandlerc.com/D2545 llvm-svn: 199250
* Update tests in preparation for using the MS ABI for Win32 targetsHans Wennborg2014-01-131-1/+1
| | | | | | | | | | In preparation for making the Win32 triple imply MS ABI mode, make all tests pass in this mode, or make them use the Itanium mode explicitly. Differential Revision: http://llvm-reviews.chandlerc.com/D2401 llvm-svn: 199130
* Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.Daniel Dunbar2009-12-151-1/+1
| | | | | | | | | - This is designed to make it obvious that %clang_cc1 is a "test variable" which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it can be useful to redefine what gets run as 'clang -cc1' (for example, to set a default target). llvm-svn: 91446
* Rename clang to clang-cc.Daniel Dunbar2009-03-241-1/+1
| | | | | | Tests and drivers updated, still need to shuffle dirs. llvm-svn: 67602
* Add mangling for variadic functions and conversion functionsDouglas Gregor2009-02-131-0/+2
| | | | llvm-svn: 64425
* Add basic support for C++ name mangling according to the Itanium C++Douglas Gregor2009-02-131-0/+24
ABI to the CodeGen library. Since C++ code-generation is so incomplete, we can't exercise much of this mangling code. However, a few smoke tests show that it's doing the same thing as GCC. When C++ codegen matures, we'll extend the ABI tester to verify name-mangling as well, and complete the implementation here. At this point, the major client of name mangling is in the uses of the new "overloadable" attribute in C, which allows overloading. Any "overloadable" function in C (or in an extern "C" block in C++) will be mangled the same way that the corresponding C++ function would be mangled. llvm-svn: 64413
OpenPOWER on IntegriCloud