summaryrefslogtreecommitdiffstats
path: root/clang/test/Sema/builtins.c
Commit message (Collapse)AuthorAgeFilesLines
* [Builtins] Implement __builtin_is_constant_evaluated for use in C++2aEric Fiselier2019-04-241-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements `__builtin_is_constant_evaluated` as specifier by [P0595R2](https://wg21.link/p0595r2). It is built on the back of Bill Wendling's work for `__builtin_constant_p()`. More tests to come, but early feedback is appreciated. I plan to implement warnings for common mis-usages like those belowe in a following patch: ``` void foo(int x) { if constexpr (std::is_constant_evaluated())) { // condition is always `true`. Should use plain `if` instead. foo_constexpr(x); } else { foo_runtime(x); } } ``` Reviewers: rsmith, MaskRay, bruno, void Reviewed By: rsmith Subscribers: dexonsmith, zoecarver, fdeazeve, kristina, cfe-commits Differential Revision: https://reviews.llvm.org/D55500 llvm-svn: 359067
* [Sema] Add some compile time _FORTIFY_SOURCE diagnosticsErik Pilkington2019-03-181-5/+5
| | | | | | | | | | | | | | | | | | | | | | | These diagnose overflowing calls to subset of fortifiable functions. Some functions, like sprintf or strcpy aren't supported right not, but we should probably support these in the future. We previously supported this kind of functionality with -Wbuiltin-memcpy-chk-size, but that diagnostic doesn't work with _FORTIFY implementations that use wrapper functions. Also unlike that diagnostic, we emit these warnings regardless of whether _FORTIFY_SOURCE is actually enabled, which is nice for programs that don't enable the runtime checks. Why not just use diagnose_if, like Bionic does? We can get better diagnostics in the compiler (i.e. mention the sizes), and we have the potential to diagnose sprintf and strcpy which is impossible with diagnose_if (at least, in languages that don't support C++14 constexpr). This approach also saves standard libraries from having to add diagnose_if. rdar://48006655 Differential revision: https://reviews.llvm.org/D58797 llvm-svn: 356397
* [Clang] Add __builtin_launderEric Fiselier2018-12-141-0/+18
| | | | | | | | | | | | | | | | | Summary: This patch adds `__builtin_launder`, which is required to implement `std::launder`. Additionally GCC provides `__builtin_launder`, so thing brings Clang in-line with GCC. I'm not exactly sure what magic `__builtin_launder` requires, but based on previous discussions this patch applies a `@llvm.invariant.group.barrier`. As noted in previous discussions, this may not be enough to correctly handle vtables. Reviewers: rnk, majnemer, rsmith Reviewed By: rsmith Subscribers: kristina, Romain-Geissler-1A, erichkeane, amharc, jroelofs, cfe-commits, Prazek Differential Revision: https://reviews.llvm.org/D40218 llvm-svn: 349195
* Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""Fangrui Song2018-11-301-0/+9
| | | | | | | | | It seems the two failing tests can be simply fixed after r348037 Fix 3 cases in Analysis/builtin-functions.cpp Delete the bad CodeGen/builtin-constant-p.c for now llvm-svn: 348053
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Fangrui Song2018-11-301-9/+0
| | | | | | | | | | Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp while we are investigating why the following snippet fails: extern char extern_var; struct { int a; } a = {__builtin_constant_p(extern_var)}; llvm-svn: 348039
* Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-281-0/+9
| | | | | | | This was reverted in r347656 due to me thinking it caused a miscompile of Chromium. Turns out it was the Chromium code that was broken. llvm-svn: 347756
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-271-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused a miscompile in Chrome (see crbug.com/908372) that's illustrated by this small reduction: static bool f(int *a, int *b) { return !__builtin_constant_p(b - a) || (!(b - a)); } int arr[] = {1,2,3}; bool g() { return f(arr, arr + 3); } $ clang -O2 -S -emit-llvm a.cc -o - g() should return true, but after r347417 it became false for some reason. This also reverts the follow-up commits. r347417: > Re-Reinstate 347294 with a fix for the failures. > > Don't try to emit a scalar expression for a non-scalar argument to > __builtin_constant_p(). > > Third time's a charm! r347446: > The result of is.constant() is unsigned. r347480: > A __builtin_constant_p() returns 0 with a function type. r347512: > isEvaluatable() implies a constant context. > > Assume that we're in a constant context if we're asking if the expression can > be compiled into a constant initializer. This fixes the issue where a > __builtin_constant_p() in a compound literal was diagnosed as not being > constant, even though it's always possible to convert the builtin into a > constant. r347531: > A "constexpr" is evaluated in a constant context. Make sure this is reflected > if a __builtin_constant_p() is a part of a constexpr. llvm-svn: 347656
* Re-Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-211-0/+9
| | | | | | | | | Don't try to emit a scalar expression for a non-scalar argument to __builtin_constant_p(). Third time's a charm! llvm-svn: 347417
* Revert r347364 again, the fix was incomplete.Nico Weber2018-11-211-9/+0
| | | | llvm-svn: 347389
* Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-201-0/+9
| | | | | | | EvaluateAsInt() is sometimes called in a constant context. When that's the case, we need to specify it as so. llvm-svn: 347364
* Revert 347294, it turned many bots on lab.llvm.org:8011/console red.Nico Weber2018-11-201-9/+0
| | | | llvm-svn: 347314
* Use is.constant intrinsic for __builtin_constant_pBill Wendling2018-11-201-0/+9
| | | | | | | | | | | | | | | | Summary: A __builtin_constant_p may end up with a constant after inlining. Use the is.constant intrinsic if it's a variable that's in a context where it may resolve to a constant, e.g., an argument to a function after inlining. Reviewers: rsmith, shafik Subscribers: jfb, kristina, cfe-commits, nickdesaulniers, jyknight Differential Revision: https://reviews.llvm.org/D54355 llvm-svn: 347294
* [Sema] Clean up some __builtin_*_chk diagnosticsErik Pilkington2018-09-061-4/+15
| | | | | | | | | | | Namely, print the likely macro name when it's used, and include the actual computed sizes in the diagnostic message, which are sometimes not obvious. rdar://43909200 Differential revision: https://reviews.llvm.org/D51697 llvm-svn: 341566
* Implement semantic checking for __builtin_signbit.Aaron Ballman2018-06-191-0/+23
| | | | | | r242675 changed the signature for the signbit builtin but did not introduce proper semantic checking to ensure the arguments are as-expected. This patch groups the signbit builtin along with the other fp classification builtins. Fixes PR28172. llvm-svn: 335050
* Reverting due to line ending changes; will reapply after addressing that.Aaron Ballman2018-06-191-223/+200
| | | | llvm-svn: 335049
* Implement semantic checking for __builtin_signbit.Aaron Ballman2018-06-191-200/+223
| | | | | | r242675 changed the signature for the signbit builtin but did not introduce proper semantic checking to ensure the arguments are as-expected. This patch groups the signbit builtin along with the other fp classification builtins. Fixes PR28172. llvm-svn: 335048
* Disallow pointers to const in __sync_fetch_and_xxx.Aaron Ballman2018-05-051-0/+5
| | | | | | | | | | | | Diagnoses code like: void f(const int *ptr) { __sync_fetch_and_add(ptr, 1); } which matches the behavior of GCC and ICC. llvm-svn: 331598
* Add __sync_fetch_and_nand (again)Hal Finkel2014-10-021-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to GCC 4.4, __sync_fetch_and_nand was implemented as: { tmp = *ptr; *ptr = ~tmp & value; return tmp; } but this was changed in GCC 4.4 to be: { tmp = *ptr; *ptr = ~(tmp & value); return tmp; } in response to this change, support for sync_fetch_and_nand (and sync_nand_and_fetch) was removed in r99522 in order to avoid miscompiling code depending on the old semantics. However, at this point: 1. Many years have passed, and the amount of code relying on the old semantics is likely smaller. 2. Through the work of many contributors, all LLVM backends have been updated such that "atomicrmw nand" provides the newer GCC 4.4+ semantics (this process was complete July of 2014 (added to the release notes in r212635). 3. The lack of this intrinsic is now a needless impediment to porting codes from GCC to Clang (I've now seen several examples of this). It is true, however, that we still set GNUC_MINOR to 2 (corresponding to GCC 4.2). To compensate for this, and to address the original concern regarding code relying on the old semantics, I've added a warning that specifically details the fact that the semantics have changed and that we provide the newer semantics. Fixes PR8842. llvm-svn: 218905
* Patch to check at compile time for overflow whenFariborz Jahanian2014-09-181-2/+23
| | | | | | | | __builtin___memcpy_chk and similar builtins are being used. Patch by Jacques Fortier (with added clang tests). rdar://11076881 llvm-svn: 218063
* patch to add missing warning on sizeof wrong parameterFariborz Jahanian2014-09-121-5/+25
| | | | | | | | for __builtin___strlcpy_chk/__builtin___strlcat_chk. Patch by Jacques Fortier with monir change by me and addition of test. rdar://18259539 llvm-svn: 217700
* Add __builtin_operator_new and __builtin_operator_delete, which act like callsRichard Smith2014-06-031-0/+5
| | | | | | | to the normal non-placement ::operator new and ::operator delete, but allow optimizations like new-expressions and delete-expressions do. llvm-svn: 210137
* Only provide MS builtins when -fms-extensions is onReid Kleckner2013-11-131-0/+6
| | | | | | | | | | | We already have builtins that are only available in GNU mode, so this mirrors that. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D2128 llvm-svn: 194615
* Refactor all diagnosing of TypoCorrections through a common function, inRichard Smith2013-08-171-1/+1
| | | | | | | preparation for teaching this function how to diagnose a correction that includes importing a module. llvm-svn: 188602
* Add tests to check recent changes to some builtins.Bill Wendling2012-12-181-0/+15
| | | | llvm-svn: 170458
* Tweak wording and add diagnostic groups to misc diagnostics.Eli Friedman2012-11-021-1/+1
| | | | llvm-svn: 167274
* Avoid multiple atomic builtin declaration.Abramo Bagnara2012-09-221-0/+14
| | | | llvm-svn: 164454
* Add -Wstring-plus-int, which warns on "str" + int and int + "str".Nico Weber2012-03-021-1/+1
| | | | | | | | It doesn't warn if the integer is known at compile time and within the bounds of the string. Discussion: http://comments.gmane.org/gmane.comp.compilers.clang.scm/47203 llvm-svn: 151943
* Modify how the -verify flag works. Currently, the verification string andRichard Trieu2011-12-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | diagnostic message are compared. If either is a substring of the other, then no error is given. This gives rise to an unexpected case: // expect-error{{candidate function has different number of parameters}} will match the following error messages from Clang: candidate function has different number of parameters (expected 1 but has 2) candidate function has different number of parameters It will also match these other error messages: candidate function function has different number of parameters number of parameters This patch will change so that the verification string must be a substring of the diagnostic message before accepting. Also, all the failing tests from this change have been corrected. Some stats from this cleanup: 87 - removed extra spaces around verification strings 70 - wording updates to diagnostics 40 - extra leading or trailing characters (typos, unmatched parens or quotes) 35 - diagnostic level was included (error:, warning:, or note:) 18 - flag name put in the warning (-Wprotocol) llvm-svn: 146619
* Replace the implementation of __builtin_constant_p (which was based on the GCCRichard Smith2011-12-091-0/+60
| | | | | | | | | | | | | | | | | | | | | | | | documentation) with one based on what GCC's __builtin_constant_p is actually intended to do (discovered by asking a friendly GCC developer). In particular, an expression which folds to a pointer is now only considered to be a "constant" by this builtin if it refers to the first character in a string literal. This fixes a rather subtle wrong-code issue when building with glibc. Given: const char cs[4] = "abcd"; int f(const char *p) { return strncmp(p, cs, 4); } ... the macro magic for strncmp produces a (potentially crashing) call to strlen(cs), because it expands to an expression starting with: __builtin_constant_p(cs) && strlen(cs) < 4 ? /* ... */ Under the secret true meaning of __builtin_constant_p, this is guaranteed to be safe! llvm-svn: 146236
* Suggest typo corrections for implicit function declarations.Hans Wennborg2011-12-061-2/+2
| | | | | | | A mistyped function call becomes an inmplicit function declaration in C. Suggest typo correction when one can be found. llvm-svn: 145930
* Remove warning for null characters in CFString literals. Clang handles them ↵Ted Kremenek2011-03-151-1/+1
| | | | | | | | just fine, and GCC 4.2 doesn't warn here either. We added this warning back in 2007 when we were comparing against GCC 4.0. llvm-svn: 127704
* zap trailing whitespaceGabor Greif2010-10-151-5/+5
| | | | llvm-svn: 116572
* fix PR7885, rejecting invalid uses of __builtin_constant_p.Chris Lattner2010-10-121-0/+7
| | | | llvm-svn: 116317
* Have Sema check for validity of CGString literalFariborz Jahanian2010-09-071-1/+1
| | | | | | instead of asserting in IRGen. Fixes radar 8390459. llvm-svn: 113253
* Implement __builtin_printf, __builtin_fprintf. Fixes <rdar://problem/8336581>.Douglas Gregor2010-08-251-0/+5
| | | | llvm-svn: 112049
* Make the pointer arguments to the __sync_* builtins pointers toDouglas Gregor2010-07-281-0/+6
| | | | | | volatile-qualified types. Fixes <rdar://problem/8228293>. llvm-svn: 109618
* Mark __builtin_eh_return as noreturn. Patch by Dimitry Andric.Benjamin Kramer2010-07-261-0/+4
| | | | llvm-svn: 109452
* Improve the representation of the atomic builtins in a few ways. First, we makeChandler Carruth2010-07-181-0/+5
| | | | | | | | | | | | | | | their call expressions synthetically have the "deduced" types based on their first argument. We only insert conversions in the AST for arguments whose values require conversion to match the value type expected. This keeps PR7600 closed by maintaining the return type, but avoids assertions due to unexpected implicit casts making the type unsigned (test case added from Daniel). The magic is moved into the codegen for the atomic builtin which inserts the casts as needed at the IR level to raise the type to an integer suitable for the LLVM intrinsic. This shouldn't cause any real change in functionality, but now we can make the builtin be more truly polymorphic. llvm-svn: 108638
* Fix PR7600, and correctly convert the result of an atomic builtin to theChandler Carruth2010-07-091-1/+4
| | | | | | | | | expected value type. This is necessary as the builtin is internally represented as only operating on integral types. Also, add a FIXME to add support for floating point value types. llvm-svn: 108002
* Remove the argument number from the constant integer diagnostic.Eric Christopher2010-04-191-1/+1
| | | | | | Update all of the testcases accordingly. llvm-svn: 101795
* Consolidate most of the integer constant expression builtin requirementEric Christopher2010-04-171-1/+1
| | | | | | | | checking into a single function and use that throughout. Remove some now unnecessary diagnostics and update tests with now more accurate diagnostics. llvm-svn: 101610
* testcase for previous patch!Chris Lattner2009-12-301-4/+5
| | | | llvm-svn: 92317
* 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
* Provide a custom diagnostic when code tries to use an unknown builtinDouglas Gregor2009-09-281-0/+4
| | | | llvm-svn: 83014
* builtin_trap should be noreturn, this fixes PR5062, patch byChris Lattner2009-09-261-0/+5
| | | | | | Roman Divacky! llvm-svn: 82876
* implement support for __builtin_eh_return_data_regno on x86-32 and x86-64.Chris Lattner2009-09-231-0/+10
| | | | | | This implements PR5034 and rdar://6836445. llvm-svn: 82614
* Implement __builtin_unreachable(), a GCC 4.5 extension.Chris Lattner2009-09-211-0/+11
| | | | llvm-svn: 82433
* Prep for new warning.Mike Stump2009-07-221-1/+1
| | | | llvm-svn: 76709
* Test changes to account for removed builtins.Eli Friedman2009-06-061-9/+0
| | | | llvm-svn: 73004
* Fix the atomics sema code to convert operands to the argument typesChris Lattner2009-05-081-1/+1
| | | | | | | | | of the underlying _N builtin, not the the type of the pointee of the actual type. This ensures that atomics involving pointers end up using the correct integer type when they are resolved, avoiding aborts in codegen. llvm-svn: 71218
OpenPOWER on IntegriCloud