This builtin has the same UI as __builtin_object_size, but has the
potential to be evaluated dynamically. It is meant to be used as a
drop-in replacement for libraries that use __builtin_object_size when
a dynamic checking mode is enabled. For instance,
__builtin_object_size fails to provide any extra checking in the
following function:
void f(size_t alloc) {
char* p = malloc(alloc);
strcpy(p, "foobar"); // expands to __builtin___strcpy_chk(p, "foobar", __builtin_object_size(p, 0))
}
This is an overflow if alloc < 7, but because LLVM can't fold the
object size intrinsic statically, it folds __builtin_object_size to
-1. With __builtin_dynamic_object_size, alloc is passed through to
__builtin___strcpy_chk.
rdar://32212419
Differential revision: https://reviews.llvm.org/D56760
llvm-svn: 352665
This is meant to be used with clang's __builtin_dynamic_object_size.
When 'true' is passed to this parameter, the intrinsic has the
potential to be folded into instructions that will be evaluated
at run time. When 'false', the objectsize intrinsic behaviour is
unchanged.
rdar://32212419
Differential revision: https://reviews.llvm.org/D56761
llvm-svn: 352664
Summary:
Was trying to understand how complicated it would be to write
a clang-tidy `openmp-exception-escape`-ish check once D57100 lands.
Just so it happens, all the data is already there,
it is just conveniently omitted from AST dump.
Reviewers: aaron.ballman, steveire, ABataev
Reviewed By: ABataev
Subscribers: ABataev, guansong, cfe-commits
Tags: #openmp, #clang
Differential Revision: https://reviews.llvm.org/D57452
llvm-svn: 352631
In 64 bit MSVC environment size_t is defined as unsigned long long.
In single source language like HIP, data layout should be consistent
in device and host compilation, therefore copy data layout controlling
fields from Aux target for AMDGPU target.
Differential Revision: https://reviews.llvm.org/D56318
llvm-svn: 352620
When creating the prototype of implicit assignment operators the
returned reference to the class should be qualified with the same
addr space as 'this' (i.e. __generic in OpenCL).
Differential Revision: https://reviews.llvm.org/D57101
llvm-svn: 352617
Summary:
We use the existing diag::note_locked_here to tell the user where we saw
the first locking.
Reviewers: aaron.ballman, delesley
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D56967
llvm-svn: 352549
We don't need to use the predetermined data-sharing attributes for the
loop counters if the user explicitly specified correct data-sharing
attributes for such variables.
llvm-svn: 352543
Re-enable format string warnings on printf.
The warnings are still incomplete. Apparently it is undefined to use a
vector specifier without a length modifier, which is not currently
warned on. Additionally, type warnings appear to not be working with
the hh modifier, and aren't warning on all of the special restrictions
from c99 printf.
llvm-svn: 352540
This reverts r348083. This was based on a misreading of the spec
for printf specifiers.
Also revert r343653, as without a subsequent patch, a correctly
specified format for a vector will incorrectly warn.
Fixes bug 40491.
llvm-svn: 352539
It is intended to disable _all_ warnings, even those upgraded to
errors via `-Werror=warningname` or `#pragma clang diagnostic error'
Fixes: https://llvm.org/PR38231
Differential Revision: https://reviews.llvm.org/D53199
llvm-svn: 352535
Track them for ISL/OS objects by default, and for NS/CF under a flag.
rdar://47536377
Differential Revision: https://reviews.llvm.org/D57356
llvm-svn: 352534
According to the report, better to keep the original strict compare
operation as the loop condition with unsigned loop counters to make the
loop countable. This allows further loop transformations.
llvm-svn: 352526
r352221 caused regressions in CUDA/HIP since device function may use _Float16 whereas host does not support it.
In this case host compilation should not diagnose usage of _Float16 in device functions or variables.
For now just do not diagnose _Float16 for CUDA/HIP. In the future we should have more precise check.
Differential Revision: https://reviews.llvm.org/D57369
llvm-svn: 352488
When a function takes the address of a field the analyzer will no longer
assume that the function will change other fields of the enclosing structs.
Differential Revision: https://reviews.llvm.org/D57230
llvm-svn: 352473
Summary:
When importing classes we may add a CXXMethodDecl more than once to a CXXRecordDecl when handling overrides. This patch will fix the cases we currently know about and handle the case where we are only dealing with declarations.
Differential Revision: https://reviews.llvm.org/D56936
llvm-svn: 352436
Introduce an option to request global visibility settings be applied to
declarations without a definition or an explicit visibility, rather than
the existing behavior of giving these default visibility. When the
visibility of all or most extern definitions are known this allows for
the same optimisations -fvisibility permits without updating source code
to annotate all declarations.
Differential Revision: https://reviews.llvm.org/D56868
llvm-svn: 352391
Summary:
Trying to use structure binding with a structure that doesn't implement
std::tuple_size, should unpack the data members. When the struct is a
template though, clang might hit an assertion (if the type has not been
completed before), because CXXRecordDecl::DefinitionData is nullptr.
This commit fixes the problem by completing the type while trying to
decompose the structured binding.
The ICE happens in real world code, for example, when trying to iterate
a protobuf generated map with a range-based for loop and structure
bindings (because google::protobuf::MapPair is a template and doesn't
support std::tuple_size).
Reported-by: nicholas.sun@nlsun.com
Patch by Daniele Di Proietto
Reviewers: #clang, rsmith
Reviewed By: #clang, rsmith
Subscribers: cpplearner, Rakete1111, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D56974
llvm-svn: 352323
This patch effectively fixes the almost decade old checker naming issue.
The solution is to assert when CheckerManager::getChecker is called on an
unregistered checker, and assert when CheckerManager::registerChecker is called
on a checker that is already registered.
Differential Revision: https://reviews.llvm.org/D55429
llvm-svn: 352292
Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
- StackAddrEscapeBase
- StackAddrEscapeBase
- CStringModeling
- DynamicMemoryModeling (base of the MallocChecker family)
- IteratorModeling (base of the IteratorChecker family)
- ValistBase
- SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
- NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker)
- IvarInvalidationModeling (base of IvarInvalidation checker family)
- RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Differential Revision: https://reviews.llvm.org/D54438
llvm-svn: 352287
The actual implementation of unix.API features a dual-checker: two checkers in
one, even though they don't even interact at all. Split them up, as this is a
problem for establishing dependencies.
I added no new code at all, just merely moved it around.
Since the plist files change (and that's a benefit!) this patch isn't NFC.
Differential Revision: https://reviews.llvm.org/D55425
llvm-svn: 352278
Summary:
The 512-bit cvt(u)qq2tops, cvt(u)qqtopd, and cvt(u)dqtops intrinsics all have the possibility of taking an explicit rounding mode argument. If the rounding mode is CUR_DIRECTION we'd like to emit a sitofp/uitofp instruction and a select like we do for 256-bit intrinsics.
For cvt(u)qqtopd and cvt(u)dqtops we do this when the form of the software intrinsics that doesn't take a rounding mode argument is used. This is done by using convertvector in the header with the select builtin. But if the explicit rounding mode form of the intrinsic is used and CUR_DIRECTION is passed, we don't do this. We shouldn't have this inconsistency.
For cvt(u)qqtops nothing is done because we can't use the select builtin in the header without avx512vl. So we need to use custom codegen for this.
Even when the rounding mode isn't CUR_DIRECTION we should also use select in IR for consistency. And it will remove another scalar integer mask from our intrinsics.
To accomplish all of these goals I've taken a slightly unusual approach. I've added two new X86 specific intrinsics for sitofp/uitofp with rounding. These intrinsics are variadic on the input and output type so we only need 2 instead of 6. This avoids the need for a switch to map them in CGBuiltin.cpp. We just need to check signed vs unsigned. I believe other targets also use variadic intrinsics like this.
So if the rounding mode is CUR_DIRECTION we'll use an sitofp/uitofp instruction. Otherwise we'll use one of the new intrinsics. After that we'll emit a select instruction if needed.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D56998
llvm-svn: 352267
Summary:
When mounting LLVM source into a windows container in read-only mode, certain tests fail. Ideally, we want all these tests to pass so that developers can mount the same source folder into multiple (windows) containers simultaneously, allowing them to build/test the same source code using various different configurations simultaneously.
**Fix**: I've found that when attempting to open a file for writing on windows, if you don't have the correct permissions (trying to open a file for writing in a read-only folder), you get [Access is denied](https://support.microsoft.com/en-us/help/2623670/access-denied-or-other-errors-when-you-access-or-work-with-files-and-f). In llvm, we map this error message to a linux based error, see: https://github.com/llvm-mirror/llvm/blob/master/lib/Support/ErrorHandling.cpp
This is why we see "Permission denied" in our output as opposed to the expected "No such file or directory", thus causing the tests to fail.
I've changed the test locally to instead point to the root drive so that they can successfully bypass the Access is denied error when LLVM is mounted in as a read-only directory. This way, the test operate exactly the same, but we can get around the windows-complications of what error to expect in a read-only directory.
Patch By: justice_adams
Reviewers: rsmith, zturner, MatzeB, stella.stamenova
Reviewed By: stella.stamenova
Subscribers: ormris, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D50563
llvm-svn: 352252
Fix a bug where we would compare array sizes with incompatible
element types, and look through explicit casts.
rdar://44800168
Differential revision: https://reviews.llvm.org/D57064
llvm-svn: 352239
Float16 support was disabled recently on many platforms, however that
commit still allowed literals of Float16 type to work. This commit
removes those based on the same logic as Float16 disable.
Change-Id: I72243048ae2db3dc47bd3d699843e3edf9c395ea
llvm-svn: 352229
As Discussed here:
http://lists.llvm.org/pipermail/llvm-dev/2019-January/129543.html
There are problems exposing the _Float16 type on architectures that
haven't defined the ABI/ISel for the type yet, so we're temporarily
disabling the type and making it opt-in.
Differential Revision: https://reviews.llvm.org/D57188
Change-Id: I5db7366dedf1deb9485adb8948b1deb7e612a736
llvm-svn: 352221
declaration in MSVCCompat mode
Microsoft compiler permits the use of 'static' storage specifier outside
of a class definition if it's on an out-of-line member function template
declaration.
This patch allows 'static' storage specifier on an out-of-line member
function template declaration with a warning in Clang (To be compatible
with Microsoft).
Intel C/C++ compiler allows the 'static' keyword with a warning in
Microsoft mode. GCC allows this with -fpermissive.
Patch By: Manna
Differential Revision: https://reviews.llvm.org/D56473
Change-Id: I97b2d9e9d57cecbcd545d17e2523142a85ca2702
llvm-svn: 352219
Add tests that arguments for enabling/disabling
sb and predres are correctly being or not passed
by the driver.
Differential Revision: https://reviews.llvm.org/D57060
llvm-svn: 352203
Relocatable code generation is meaningless on MSP430, as the platform is too small to use shared libraries.
Patch by Dmitry Mikushev!
Differential Revision: https://reviews.llvm.org/D56927
llvm-svn: 352181
ACLE specifies that return type for rsr and rsr64 is uint32_t and
uint64_t respectively. D56852 change the return type of rsr64 from
unsigned long to unsigned long long which at least on Linux doesn't
match uint64_t, but the test isn't strict enough to detect that
because compiler implicitly converts unsigned long long to uint64_t,
but it breaks other uses such as printf with PRIx64 type specifier.
This change makes the test stricter enforcing that the return type
of rsr and rsr64 builtins is what is actually specified in ACLE.
Differential Revision: https://reviews.llvm.org/D57210
llvm-svn: 352156
This reverts commit r351740: this broke on platforms where unsigned long
long isn't the same as uint64_t which is what ACLE specifies for the
return value of rsr64.
Differential Revision: https://reviews.llvm.org/D57209
llvm-svn: 352153
The /AI flag is for #using directives, which I don't think we support.
This is consistent with how the /I flag is handled by MSVC. Add a test
for it.
Differential Revision: https://reviews.llvm.org/D57189
llvm-svn: 352119
Erik Pilkington