Summary:
- If a parameter is used, nonnull checking needs function prototype to
retrieve the corresponding parameter's attributes. However, at the
prototype substitution phase when a template is being instantiated,
expression may be created and checked without a fully specialized
prototype. Under such a scenario, skip nonnull checking on that
argument.
Reviewers: rjmccall, tra, yaxunl
Subscribers: javed.absar, kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59900
llvm-svn: 357236
This fixes a false positive on the following, where st is configured to have
different sizes based on some preprocessor logic:
if (sizeof(buf) == sizeof(*st))
memcpy(&buf, st, sizeof(*st));
llvm-svn: 357041
Bail-out of CheckArrayAccess when the types of the base expression before
and after eventual casts are dependent. We will get another chance to check
for array bounds during instantiation. Fixes PR41087.
Differential Revision: https://reviews.llvm.org/D59776
Reviewed By: efriedma
llvm-svn: 356957
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
This patch includes the necessary code for converting between a fixed point type and integer.
This also includes constant expression evaluation for conversions with these types.
Differential Revision: https://reviews.llvm.org/D56900
llvm-svn: 355462
...instead of just comparing rank. Also, fix a bad warning about
_Float16, since its declared out of order in BuiltinTypes.def,
meaning comparing rank using BuiltinType::getKind() is incorrect.
Differential revision: https://reviews.llvm.org/D58254
llvm-svn: 354190
We were warning on valid ObjC property reference exprs, and passing
in the wrong arguments to DiagnoseFloatingImpCast (leading to a badly
worded diagnostic).
rdar://47644670
Differential revision: https://reviews.llvm.org/D58145
llvm-svn: 354074
Summary:
This makes it consistent with `memcmp` and `__builtin_bcmp`.
Also see the discussion in https://reviews.llvm.org/D56593.
Reviewers: jyknight
Subscribers: kristina, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58120
llvm-svn: 354023
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
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
As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for
isPodLike<std::pair<...>> did not match the expectation of
std::is_trivially_copyable which makes the memcpy optimization invalid.
This patch renames the llvm::isPodLike trait into llvm::is_trivially_copyable.
Unfortunately std::is_trivially_copyable is not portable across compiler / STL
versions. So a portable version is provided too.
Note that the following specialization were invalid:
std::pair<T0, T1>
llvm::Optional<T>
Tests have been added to assert that former specialization are respected by the
standard usage of llvm::is_trivially_copyable, and that when a decent version
of std::is_trivially_copyable is available, llvm::is_trivially_copyable is
compared to std::is_trivially_copyable.
As of this patch, llvm::Optional is no longer considered trivially copyable,
even if T is. This is to be fixed in a later patch, as it has impact on a
long-running bug (see r347004)
Note that GCC warns about this UB, but this got silented by https://reviews.llvm.org/D50296.
Differential Revision: https://reviews.llvm.org/D54472
llvm-svn: 351701
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
This patch includes logic for constant expression evaluation of fixed point additions.
Differential Revision: https://reviews.llvm.org/D55868
llvm-svn: 351593
Summary: In the [expr.sub] p1, we can read that for a given E1[E2], E1 is sequenced before E2.
Patch by Mateusz Janek.
Reviewers: rsmith, Rakete1111
Reviewed By: rsmith, Rakete1111
Subscribers: riccibruno, lebedev.ri, Rakete1111, hiraditya, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D50766
llvm-svn: 350874
When the type of the base expression after IgnoreParenCasts is incomplete,
it is still possible to diagnose an array access which precedes the array
bounds.
This is a follow-up on D55862 which added an early return when the type of
the base expression after IgnoreParenCasts was incomplete.
Differential Revision: https://reviews.llvm.org/D56050
Reviewed By: efriedma
llvm-svn: 350622
When checking that the array access is not out-of-bounds in CheckArrayAccess
it is possible that the type of the base expression after IgnoreParenCasts is
incomplete, even though the type of the base expression before IgnoreParenCasts
is complete. In this case we have no information about whether the array access
is out-of-bounds and we should just bail-out instead. This fixes PR39746 which
was caused by trying to obtain the size of an incomplete type.
Differential Revision: https://reviews.llvm.org/D55862
Reviewed By: efriedma
llvm-svn: 349811
Only explicitly look through integer and floating-point promotion where the result type is actually a promotion, which is not always the case for bit-fields in C.
Patch by Bevin Hansson.
llvm-svn: 349497
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
Only explicitly look through integer and floating-point promotion where the result type is actually a promotion, which is not always the case for bit-fields in C.
llvm-svn: 348889
We would issue a false-positive diagnostic for parameters in function declarations shadowing fields; we now only issue the diagnostic on a function definition instead.
llvm-svn: 348400
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
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
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
Summary:
Prior to this patch, OpenCL code such as the following would attempt to create
a BranchInst with a non-bool argument:
if (enqueue_kernel(get_default_queue(), 0, nd, ^(void){})) /* ... */
This patch is a follow up on a similar issue with pipe builtin
operations. See commit r280800 and https://bugs.llvm.org/show_bug.cgi?id=30219.
This change, while being conservative on non-builtin functions,
should set the type of expressions invoking builtins to the
proper type, instead of defaulting to `bool` and requiring
manual overrides in Sema::CheckBuiltinFunctionCall.
In addition to tests for enqueue_kernel, the tests are extended to
check other OpenCL builtins.
Reviewers: Anastasia, spatel, rsmith
Reviewed By: Anastasia
Subscribers: kristina, cfe-commits, svenvh
Differential Revision: https://reviews.llvm.org/D52879
llvm-svn: 347658
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
Summary:
GCC already catches these situations so we should handle it too.
GCC warns in C++ mode only (does anybody know why?). I think it is useful in C mode too.
Reviewers: rsmith, erichkeane, aaron.ballman, efriedma, xbolva00
Reviewed By: xbolva00
Subscribers: efriedma, craig.topper, scanon, cfe-commits
Differential Revision: https://reviews.llvm.org/D52835
llvm-svn: 346865
This patch fixes a minimum divider for offset in intrinsics
msa_[st/ld]_[b/h/w/d], when value is known in compile time.
Differential revision: https://reviews.llvm.org/D54038
llvm-svn: 346302
A mask type is a 1 to 8-byte string that follows the "mask." annotation
in the format string. This enables obfuscating data in the event the
provided privacy level isn't enabled.
rdar://problem/36756282
llvm-svn: 346211
The size of an os_log buffer is known at any stage of compilation, so making it
a constant expression means that the common idiom of declaring a buffer for it
won't result in a VLA. That allows the compiler to skip saving and restoring
the stack pointer around such buffers.
This also moves the OSLog and other FormatString helpers from
libclangAnalysis to libclangAST to avoid a circular dependency.
llvm-svn: 345971
We haven't supported compiling ObjC1 for a long time (and never will again), so
there isn't any reason to keep these separate. This patch replaces
LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC.
Differential revision: https://reviews.llvm.org/D53547
llvm-svn: 345637
Summary:
- Add `UETT_PreferredAlignOf` to account for the difference between `__alignof` and `alignof`
- `AlignOfType` now returns ABI alignment instead of preferred alignment iff clang-abi-compat > 7, and one uses _Alignof or alignof
Patch by Nicole Mazzuca!
Differential Revision: https://reviews.llvm.org/D53207
llvm-svn: 345419
Constructing a global std::map requires clang to generate a linear
amount of code to construct the initializer list if the elements are not
constexpr-constructible. std::vector is not constexpr-constructible, so
this code pattern was generating large amounts of code.
Also, because of PR38829, LLVM is pathologically slow on large basic
blocks, and this causes slow compilation. This works around the bug and
reduces code size.
SemaChecking.cpp -debug-info-kind=limited:
time objsize
before: 1m45.023s 9.8M
after: 0m25.205s 6.9M
So, a 42% obj size reduction and 3.2x speedup.
llvm-svn: 345329
Add a warning if a parameter with a named address space is passed
to a to_addr builtin.
For example:
int i;
to_private(&i); // generate warning as conversion from private to private is redundant.
Patch by Alistair Davies.
Differential Revision: https://reviews.llvm.org/D51411
llvm-svn: 342638
unsigned long long builtin_unpack_vector_int128 (vector int128_t, int);
vector int128_t builtin_pack_vector_int128 (unsigned long long, unsigned long long);
Builtins should behave the same way as in GCC.
Patch By: wuzish (Zixuan Wu)
Differential Revision: https://reviews.llvm.org/D52074
llvm-svn: 342614
Summary:
_Atomic and __sync_* operations are implicitly sequentially-consistent. Some
codebases want to force explicit usage of memory order instead. This warning
allows them to know where implicit sequentially-consistent memory order is used.
The warning isn't on by default because _Atomic was purposefully designed to
have seq_cst as the default: the idea was that it's the right thing to use most
of the time. This warning allows developers who disagree to enforce explicit
usage instead.
A follow-up patch will take care of C++'s std::atomic. It'll be different enough
from this patch that I think it should be separate: for C++ the atomic
operations all have a memory order parameter (or two), but it's defaulted. I
believe this warning should trigger when the default is used, but not when
seq_cst is used explicitly (or implicitly as the failure order for cmpxchg).
<rdar://problem/28172966>
Reviewers: rjmccall
Subscribers: dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D51084
llvm-svn: 341860
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
This adds the following intrinsics:
_kshiftli_mask8
_kshiftli_mask16
_kshiftli_mask32
_kshiftli_mask64
_kshiftri_mask8
_kshiftri_mask16
_kshiftri_mask32
_kshiftri_mask64
llvm-svn: 341234
Summary:
C++11 onwards specs the non-member functions atomic_load and atomic_load_explicit as taking the atomic<T> by const (potentially volatile) pointer. C11, in its infinite wisdom, decided to drop the const, and C17 will fix this with DR459 (the current draft forgot to fix B.16, but that’s not the normative part).
clang’s lib/Headers/stdatomic.h implements these as #define to the __c11_* equivalent, which are builtins with custom typecheck. Fix the typecheck.
D47613 takes care of the libc++ side.
Discussion: http://lists.llvm.org/pipermail/cfe-dev/2018-May/058129.html
<rdar://problem/27426936>
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D47618
llvm-svn: 338743
This diagnoses calls to memset that have the second and third arguments
transposed, for example:
memset(buf, sizeof(buf), 0);
This is done by checking if the third argument is a literal 0, or if the second
is a sizeof expression (and the third isn't). The first check is also done for
calls to bzero.
Differential revision: https://reviews.llvm.org/D49112
llvm-svn: 337470
The '%tu'/'%td' as formatting specifiers have been used to print out the
NSInteger/NSUInteger values for a long time. Typically their ABI matches, but that's
not the case on watchOS. The ABI difference boils down to the following:
- Regular 32-bit darwin targets (like armv7) use 'ptrdiff_t' of type 'int',
which matches 'NSInteger'.
- WatchOS arm target (armv7k) uses 'ptrdiff_t' of type 'long', which doesn't
match 'NSInteger' of type 'int'.
Because of this ABI difference these specifiers trigger -Wformat warnings only
for watchOS builds, which is really inconvenient for cross-platform code.
This patch avoids this -Wformat warning for '%tu'/'%td' and NS[U]Integer only,
and instead uses the new -Wformat-pedantic warning that JF introduced in
https://reviews.llvm.org/D47290. This is acceptable because Darwin guarantees that,
despite the watchOS ABI differences, sizeof(ptrdiff_t) == sizeof(NS[U]Integer),
and alignof(ptrdiff_t) == alignof(NS[U]Integer) so the warning is therefore noisy
for pedantic reasons.
I'll update public documentation to ensure that this behaviour is properly
communicated.
rdar://41739204
Differential Revision: https://reviews.llvm.org/D48852
llvm-svn: 336396
If a function has multiple format_arg attributes, clang only considers
the first it finds (because AttributeLists are in reverse order, not
necessarily the textually first) and ignores all others.
Loop over all FormatArgAttr to print warnings for all declared
format_arg attributes.
For instance, libintl's ngettext (select plural or singular version of
format string) has two __format_arg__ attributes.
Differential Revision: https://reviews.llvm.org/D48734
llvm-svn: 336239
Summary:
Pick D42933 back up, and make NSInteger/NSUInteger with %zu/%zi specifiers on Darwin warn only in pedantic mode. The default -Wformat recently started warning for the following code because of the added support for analysis for the '%zi' specifier.
NSInteger i = NSIntegerMax;
NSLog(@"max NSInteger = %zi", i);
The problem is that on armv7 %zi is 'long', and NSInteger is typedefed to 'int' in Foundation. We should avoid this warning as it's inconvenient to our users: it's target specific (happens only on armv7 and not arm64), and breaks their existing code. We should also silence the warning for the '%zu' specifier to ensure consistency. This is acceptable because Darwin guarantees that, despite the unfortunate choice of typedef, sizeof(size_t) == sizeof(NS[U]Integer), the warning is therefore noisy for pedantic reasons. Once this is in I'll update public documentation.
Related discussion on cfe-dev:
http://lists.llvm.org/pipermail/cfe-dev/2018-May/058050.html
<rdar://36874921&40501559>
Reviewers: ahatanak, vsapsai, alexshap, aaron.ballman, javed.absar, jfb, rjmccall
Subscribers: kristof.beyls, aheejin, cfe-commits
Differential Revision: https://reviews.llvm.org/D47290
llvm-svn: 335393
dead code.
This is important for C++ templates that essentially compute the valid
input in a way that is constant and will cause all the invalid cases to
be dead code that is deleted. Code in the wild actually does this and
GCC also accepts these kinds of patterns so it is important to support
it.
To make this work, we provide a non-error path to diagnose these issues,
and use a default-error warning instead. This keeps the relatively
strict handling but prevents nastiness like SFINAE on these errors. It
also allows us to safely use the system to diagnose this only when it
occurs at runtime (in emitted code).
Entertainingly, this required fixing the syntax in various other ways
for the x86 test because we never bothered to diagnose that the returns
were invalid.
Since debugging these compile failures was super confusing, I've also
improved the diagnostic to actually say what the value was. Most of the
checks I've made ignore this to simplify maintenance, but I've checked
it in a few places to make sure the diagnsotic is working.
Depends on D48462. Without that, we might actually crash some part of
the compiler after bypassing the error here.
Thanks to Richard, Ben Kramer, and especially Craig Topper for all the
help here.
Differential Revision: https://reviews.llvm.org/D48464
llvm-svn: 335309
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
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
The previous names took the shift amount in bits to match gcc and required a multiply by 8 in the header. This creates a misleading error message when we check the range of the immediate to the builtin since the allowed range also got multiplied by 8.
This commit changes the builtins to use a byte shift amount to match the underlying instruction and the Intel intrinsic.
Fixes the remaining issue from PR37795.
llvm-svn: 334773
Summary:
This fixes the ranges for the vcvth family of FP16 intrinsics in the clang front end. Previously it was accepting incorrect ranges
-Changed builtin range checking in SemaChecking
-added tests SemaCheck changes - included in their own file since no similar one exists
-modified existing tests to reflect new ranges
Reviewers: SjoerdMeijer, javed.absar
Reviewed By: SjoerdMeijer
Subscribers: kristof.beyls, cfe-commits
Differential Revision: https://reviews.llvm.org/D47592
llvm-svn: 334489
I'm looking into making the select builtins require avx512f, avx512bw, or avx512vl since masking operations generally require those features.
The extract builtins are funny because the 512-bit versions return a 128 or 256 bit vector with masking even when avx512vl is not supported.
llvm-svn: 334330
These builtins are all handled by CGBuiltin.cpp so it doesn't much matter what the immediate type is, but int matches the intrinsic spec.
llvm-svn: 334310
Test changes are due to differences in how we generate undef elements now. We also changed the types used for extractf128_si256/insertf128_si256 to match the signature of the builtin that previously existed which this patch resurrects. This also matches gcc.
llvm-svn: 334261
Adds support for these intrinsics, which are ARM and ARM64 only:
_interlockedbittestandreset_acq
_interlockedbittestandreset_rel
_interlockedbittestandreset_nf
_interlockedbittestandset_acq
_interlockedbittestandset_rel
_interlockedbittestandset_nf
Refactor the bittest intrinsic handling to decompose each intrinsic into
its action, its width, and its atomicity.
llvm-svn: 334239
We still emit shufflevector instructions we just do it from CGBuiltin.cpp now. This ensures the intrinsics that use this are only available on CPUs that support the feature.
I also added range checking to the immediate, but only checked it is 8 bits or smaller. We should maybe be stricter since we never use all 8 bits, but gcc doesn't seem to do that.
llvm-svn: 334237
We still lower them to native shuffle IR, but we do it in CGBuiltin.cpp now. This allows us to check the target feature and ensure the immediate fits in 8 bits.
This also improves our -O0 codegen slightly because we're able to see the zeroinitializer in the shuffle. It looks like it got lost behind a store+load previously.
llvm-svn: 334208
Summary:
We recently switch to using a selects in the intrinsics header files for FMA instructions. But the 512-bit versions support flavors with rounding mode which must be an Integer Constant Expression. This has forced those intrinsics to be implemented as macros. As it stands now the mask and mask3 intrinsics evaluate one of their macro arguments twice. If that argument itself is another intrinsic macro, we can end up over expanding macros. Or if its something we can CSE later it would show up multiple times when it shouldn't.
I tried adding __extension__ around the macro and making it an expression statement and declaring a local variable. But whatever name you choose for the local variable can never be used as the name of an input to the macro in user code. If that happens you would end up with the same name on the LHS and RHS of an assignment after expansion. We might be safe if we use __ in front of the variable names because those names are reserved and user code shouldn't use that, but I wasn't sure I wanted to make that claim.
The other option which I've chosen here, is to add back _mask, _maskz, and _mask3 flavors of the builtin which we will expand in CGBuiltin.cpp to replicate the argument as needed and insert any fneg needed on the third operand to make a subtract. The _maskz isn't truly necessary if we have an unmasked version or if we use the masked version with a -1 mask and wrap a select around it. But I've chosen to make things more uniform.
I separated out the scalar builtin handling to avoid too many things going on in EmitX86FMAExpr. It was different enough due to the extract and insert that the minor duplication of the CreateCall was probably worth it.
Reviewers: tkrupa, RKSimon, spatel, GBuella
Reviewed By: tkrupa
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D47724
llvm-svn: 334159
Previously we were just using extended vector operations in the header file.
This unfortunately allowed non-constant indices to be used with the intrinsics. This is incompatible with gcc, icc, and MSVC. It also introduces a different performance characteristic because non-constant index gets lowered to a vector store and an element sized load.
By adding the builtins we can check for the index to be a constant and ensure its in range of the vector element count.
User code still has the option to use extended vector operations themselves if they need non-constant indexing.
llvm-svn: 334057
This patch replaces all packed (and scalar without rounding
mode) fused intrinsics with fmadd/fmaddsub variations.
Then fmadd/fmaddsub are lowered to native IR.
Patch by tkrupa
Reviewers: craig.topper, sroland, spatel, RKSimon
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D47444
llvm-svn: 333555
Handling of the third parameter was only checking for *_n and not for the C11 variant, which means that cmpxchg of a 'desired' 0 value was erroneously warning. Handle C11 properly, and add extgensive tests for this as well as NULL pointers in a bunch of places.
Fixes r333246 from D47229.
llvm-svn: 333290
Summary:
As a companion to libc++ patch https://reviews.llvm.org/D47225, mark builtin atomic non-member functions which accept pointers as nonnull.
The atomic non-member functions accept pointers to std::atomic / std::atomic_flag as well as to the non-atomic value. These are all dereferenced unconditionally when lowered, and therefore will fault if null. It's a tiny gotcha for new users, especially when they pass in NULL as expected value (instead of passing a pointer to a NULL value).
<rdar://problem/18473124>
Reviewers: arphaman
Subscribers: aheejin, cfe-commits
Differential Revision: https://reviews.llvm.org/D47229
llvm-svn: 333246
Like other conversion warnings, allow float overflow warnings to be disabled
in known dead paths of template instantiation. This often occurs when a
template template type is a numeric type and the template will check the
range of the numeric type before performing the conversion.
llvm-svn: 332310
These intrinsics work exactly as all other atomic_fetch_* intrinsics and allow to create *atomicrmw* with ordering.
Updated the clang-extensions document.
Differential Revision: https://reviews.llvm.org/D46386
llvm-svn: 332193
This is similar to the LLVM change https://reviews.llvm.org/D46290.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46320
llvm-svn: 331834
As Eli brought up here: https://reviews.llvm.org/D46535
I'd previously messed up this fix by missing conversions
that are just slightly outside the range. This patch fixes
this by no longer ignoring the return value of
convertToInteger. Additionally, one of the error messages
wasn't very sensical (mentioning out of range value, when it
really was not), so it was cleaned up as well.
llvm-svn: 331812
As identified and briefly discussed here:
https://bugs.llvm.org/show_bug.cgi?id=37305
Converting a floating point number to an integer type when
the integral part is out of the range of the integer type is
undefined behavior in C. Additionally, CodeGen emits an undef
in this situation.
HOWEVER, we've been giving a warning that says that the value is
changed. This patch corrects the warning to list that it is actually
undefined behavior.
Differential Revision: https://reviews.llvm.org/D46535
llvm-svn: 331673
FunctionProtoType.
We previously re-evaluated the expression each time we wanted to know whether
the type is noexcept or not. We now evaluate the expression exactly once.
This is not quite "no functional change": it fixes a crasher bug during AST
deserialization where we would try to evaluate the noexcept specification in a
situation where we have not deserialized sufficient portions of the AST to
permit such evaluation.
llvm-svn: 331428
When a '>>' token is split into two '>' tokens (in C++11 onwards), or (as an
extension) when we do the same for other tokens starting with a '>', we can't
just use a location pointing to the first '>' as the location of the split
token, because that would result in our miscomputing the length and spelling
for the token. As a consequence, for example, a refactoring replacing 'A<X>'
with something else would sometimes replace one character too many, and
similarly diagnostics highlighting a template-id source range would highlight
one character too many.
Fix this by creating an expansion range covering the first character of the
'>>' token, whose spelling is '>'. For this to work, we generalize the
expansion range of a macro FileID to be either a token range (the common case)
or a character range (used in this new case).
llvm-svn: 331155
These builtins can't be handled by the backend on 64-bit targets. So error up front instead of throwing an isel error.
Fixes PR37225
Differential Revision: https://reviews.llvm.org/D46132
llvm-svn: 330987
Issue a warning when non-trivial C structs are copied or initialized by
calls to memset, bzero, memcpy, or memmove.
rdar://problem/36124208
Differential Revision: https://reviews.llvm.org/D45310
llvm-svn: 330202
The current support of the feature produces only 2 lines in report:
-Some general Code Generation Time;
-Total time of Backend Consumer actions.
This patch extends Clang time report with new lines related to Preprocessor, Include Filea Search, Parsing, etc.
Differential Revision: https://reviews.llvm.org/D43578
llvm-svn: 329684
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:
archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
llvm-svn: 329399
The diagnostic system for Clang can already handle many AST nodes. Instead
of converting them to strings first, just hand the AST node directly to
the diagnostic system and let it handle the output. Minor changes in some
diagnostic output.
llvm-svn: 328688
Summary:
Libc++'s default allocator uses `__builtin_operator_new` and `__builtin_operator_delete` in order to allow the calls to new/delete to be ellided. However, libc++ now needs to support over-aligned types in the default allocator. In order to support this without disabling the existing optimization Clang needs to support calling the aligned new overloads from the builtins.
See llvm.org/PR22634 for more information about the libc++ bug.
This patch changes `__builtin_operator_new`/`__builtin_operator_delete` to call any usual `operator new`/`operator delete` function. It does this by performing overload resolution with the arguments passed to the builtin to determine which allocation function to call. If the selected function is not a usual allocation function a diagnostic is issued.
One open issue is if the `align_val_t` overloads should be considered "usual" when `LangOpts::AlignedAllocation` is disabled.
In order to allow libc++ to detect this new behavior the value for `__has_builtin(__builtin_operator_new)` has been updated to `201802`.
Reviewers: rsmith, majnemer, aaron.ballman, erik.pilkington, bogner, ahatanak
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43047
llvm-svn: 328134
The patch fixes a number of bugs related to parameter indexing in
attributes:
* Parameter indices in some attributes (argument_with_type_tag,
pointer_with_type_tag, nonnull, ownership_takes, ownership_holds,
and ownership_returns) are specified in source as one-origin
including any C++ implicit this parameter, were stored as
zero-origin excluding any this parameter, and were erroneously
printing (-ast-print) and confusingly dumping (-ast-dump) as the
stored values.
* For alloc_size, the C++ implicit this parameter was not subtracted
correctly in Sema, leading to assert failures or to silent failures
of __builtin_object_size to compute a value.
* For argument_with_type_tag, pointer_with_type_tag, and
ownership_returns, the C++ implicit this parameter was not added
back to parameter indices in some diagnostics.
This patch fixes the above bugs and aims to prevent similar bugs in
the future by introducing careful mechanisms for handling parameter
indices in attributes. ParamIdx stores a parameter index and is
designed to hide the stored encoding while providing accessors that
require each use (such as printing) to make explicit the encoding that
is needed. Attribute declarations declare parameter index arguments
as [Variadic]ParamIdxArgument, which are exposed as ParamIdx[*]. This
patch rewrites all attribute arguments that are processed by
checkFunctionOrMethodParameterIndex in SemaDeclAttr.cpp to be declared
as [Variadic]ParamIdxArgument. The only exception is xray_log_args's
argument, which is encoded as a count not an index.
Differential Revision: https://reviews.llvm.org/D43248
llvm-svn: 326602
So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and
`dyn_cast`s for fun. This is a portion of what it found for clang; I
plan to do similar cleanups in LLVM and other subprojects when I find
time.
Because of the volume of changes, I explicitly avoided making any change
that wasn't highly local and obviously correct to me (e.g. we still have
a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading
is a thing and the cast<Bar> did actually change the type -- just up the
class hierarchy).
I also tried to leave the types we were cast<>ing to somewhere nearby,
in cases where it wasn't locally obvious what we were dealing with
before.
llvm-svn: 326416
The code for going up the macro arg expansion is duplicated in many
places (and we need it for the analyzer as well, so I did not want to
duplicate it two more times).
This patch is an NFC, so the semantics should remain the same.
Differential Revision: https://reviews.llvm.org/D42458
llvm-svn: 324780
typeof expressions
This commit looks through typeof type at the original expression when diagnosing
-Wsign-compare to avoid an unfriendly diagnostic.
rdar://36588828
Differential Revision: https://reviews.llvm.org/D42561
llvm-svn: 324514
The 'trivial_abi' attribute can be applied to a C++ class, struct, or
union. It makes special functions of the annotated class (the destructor
and copy/move constructors) to be trivial for the purpose of calls and,
as a result, enables the annotated class or containing classes to be
passed or returned using the C ABI for the underlying type.
When a type that is considered trivial for the purpose of calls despite
having a non-trivial destructor (which happens only when the class type
or one of its subobjects is a 'trivial_abi' class) is passed to a
function, the callee is responsible for destroying the object.
For more background, see the discussions that took place on the mailing
list:
http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.htmlhttp://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043
rdar://problem/35204524
Differential Revision: https://reviews.llvm.org/D41039
llvm-svn: 324269
The constant is already reduced to 8-bits by the time we get here and the checks were just ensuring that it was 8 bits. Thus I don't think there's anyway for them to fail.
llvm-svn: 322244
Adding the new enumerator forced a bunch more changes into this patch than I
would have liked. The -Wtautological-compare warning was extended to properly
check the new comparison operator, clang-format needed updating because it uses
precedence levels as weights for determining where to break lines (and several
operators increased their precedence levels with this change), thread-safety
analysis needed changes to build its own IL properly for the new operator.
All "real" semantic checking for this operator has been deferred to a future
patch. For now, we use the relational comparison rules and arbitrarily give
the builtin form of the operator a return type of 'void'.
llvm-svn: 320707
and fold together into a single function.
In so doing, fix a handful of remaining bugs where we would report false
positives or false negatives if we promote a signed value to an unsigned type
for the comparison.
This re-commits r320122 and r320124, minus two changes:
* Comparisons between a constant and a non-constant expression of enumeration
type never warn, not even if the constant is out of range. We should be
warning about the creation of such a constant, not about its use.
* We do not use more precise bit-widths for comparisons against bit-fields.
The more precise diagnostics probably are the right thing, but we should
consider moving them under their own warning flag.
Other than the refactoring, this patch should only change the behavior for the
buggy cases (where the warnings didn't take into account that promotion from
signed to unsigned can leave a range of inaccessible values in the middle of
the promoted type).
llvm-svn: 320211
> Unify implementation of our two different flavours of -Wtautological-compare.
>
> In so doing, fix a handful of remaining bugs where we would report false
> positives or false negatives if we promote a signed value to an unsigned type
> for the comparison.
This caused a new warning in Chromium:
../../base/trace_event/trace_log.cc:1545:29: error: comparison of constant 64
with expression of type 'unsigned int' is always true
[-Werror,-Wtautological-constant-out-of-range-compare]
DCHECK(handle.event_index < TraceBufferChunk::kTraceBufferChunkSize);
~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The 'unsigned int' is really a 6-bit bitfield, which is why it's always
less than 64.
I thought we didn't use to warn (with out-of-range-compare) when comparing
against the boundaries of a type?
llvm-svn: 320162
This broke Chromium:
../../base/trace_event/trace_log.cc:1545:29: error: comparison of constant 64
with expression of type 'unsigned int' is always true
[-Werror,-Wtautological-constant-out-of-range-compare]
DCHECK(handle.event_index < TraceBufferChunk::kTraceBufferChunkSize);
~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The 'unsigned int' is really a 6-bit bitfield, which is why it's always
less than 63.
Did this use to fall under the "in-range" case before? I thought we
didn't use to warn when comparing against the boundaries of a type.
llvm-svn: 320133
In so doing, fix a handful of remaining bugs where we would report false
positives or false negatives if we promote a signed value to an unsigned type
for the comparison.
llvm-svn: 320122
This is a follow up of r302131, in which we forgot to add SemaChecking
tests. Adding these tests revealed two problems which have been fixed:
- added missing intrinsic __qdbl,
- properly range checking ssat16 and usat16.
Differential Revision: https://reviews.llvm.org/D40888
llvm-svn: 320019
This is a fix for PR35509 in which we crash because we attempt to compute the
alignment of an incomplete type.
Differential Revision: https://reviews.llvm.org/D40895
llvm-svn: 320017
codepath plus the new "minimum / maximum value of type" diagnostic to get the
same effect.
Move the warning for an in-range but tautological comparison of a constant (0
or 1) against a bool out of -Wtautological-constant-out-of-range-compare into
the more-appropriate -Wtautological-constant-compare.
llvm-svn: 319942
An enumeration with a fixed underlying type can have any value in its
underlying type, not just those spanned by the values of its enumerators.
llvm-svn: 319875
It seems this somehow made -Wempty-body fire in some macro cases where
it didn't before, e.g.
../../third_party/ffmpeg/libavcodec/bitstream.c(169,5): error: if statement has empty body [-Werror,-Wempty-body]
ff_dlog(NULL, "new table index=%d size=%d\n", table_index, table_size);
^
../../third_party/ffmpeg\libavutil/internal.h(276,80): note: expanded from macro 'ff_dlog'
# define ff_dlog(ctx, ...) do { if (0) av_log(ctx, AV_LOG_DEBUG, __VA_ARGS__); } while (0)
^
../../third_party/ffmpeg/libavcodec/bitstream.c(169,5): note: put the
semicolon on a separate line to silence this warning
Reverting until this can be figured out.
> Do not show it when `if` or `else` come from macros.
> E.g.,
>
> #define USED(A) if (A); else
> #define SOME_IF(A) if (A)
>
> void test() {
> // No warnings are shown in those cases now.
> USED(0);
> SOME_IF(0);
> }
>
> Patch by Ilya Biryukov!
>
> Differential Revision: https://reviews.llvm.org/D40185
llvm-svn: 318665
Do not show it when `if` or `else` come from macros.
E.g.,
#define USED(A) if (A); else
#define SOME_IF(A) if (A)
void test() {
// No warnings are shown in those cases now.
USED(0);
SOME_IF(0);
}
Patch by Ilya Biryukov!
Differential Revision: https://reviews.llvm.org/D40185
llvm-svn: 318556
Summary:
As Mattias Eriksson has reported in PR35009, in C, for enums, the underlying type should
be used when checking for the tautological comparison, unlike C++, where the enumerator
values define the value range. So if not in CPlusPlus mode, use the enum underlying type.
Also, i have discovered a problem (a crash) when evaluating tautological-ness of the following comparison:
```
enum A { A_a = 0 };
if (a < 0) // expected-warning {{comparison of unsigned enum expression < 0 is always false}}
return 0;
```
This affects both the C and C++, but after the first fix, only C++ code was affected.
That was also fixed, while preserving (i think?) the proper diagnostic output.
And while there, attempt to enhance the test coverage.
Yes, some tests got moved around, sorry about that :)
Fixes PR35009
Reviewers: aaron.ballman, rsmith, rjmccall
Reviewed By: aaron.ballman
Subscribers: Rakete1111, efriedma, materi, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D39122
llvm-svn: 316268
Use the new helper methods to get the underlying type for NSUInteger,
NSInteger types. This avoids spreading the knowledge of the underlying
types in various sites. For non-LLP64 targets, this has no change.
llvm-svn: 316013
The first attempt, rL315614 was reverted because one libcxx
test broke, and i did not know at the time how to deal with it.
Summary:
Currently, clang only diagnoses completely out-of-range comparisons (e.g. `char` and constant `300`),
and comparisons of unsigned and `0`. But gcc also does diagnose the comparisons with the
`std::numeric_limits<>::max()` / `std::numeric_limits<>::min()` so to speak
Finally Fixes https://bugs.llvm.org/show_bug.cgi?id=34147
Continuation of https://reviews.llvm.org/D37565
Reviewers: rjmccall, rsmith, aaron.ballman
Reviewed By: rsmith
Subscribers: rtrieu, jroelofs, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D38101
llvm-svn: 315875
Summary:
Convert clang::LangAS to a strongly typed enum
Currently both clang AST address spaces and target specific address spaces
are represented as unsigned which can lead to subtle errors if the wrong
type is passed. It is especially confusing in the CodeGen files as it is
not possible to see what kind of address space should be passed to a
function without looking at the implementation.
I originally made this change for our LLVM fork for the CHERI architecture
where we make extensive use of address spaces to differentiate between
capabilities and pointers. When merging the upstream changes I usually
run into some test failures or runtime crashes because the wrong kind of
address space is passed to a function. By converting the LangAS enum to a
C++11 we can catch these errors at compile time. Additionally, it is now
obvious from the function signature which kind of address space it expects.
I found the following errors while writing this patch:
- ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address
space to TargetInfo::getPointer{Width,Align}()
- TypePrinter::printAttributedAfter() prints the numeric value of the
clang AST address space instead of the target address space.
However, this code is not used so I kept the current behaviour
- initializeForBlockHeader() in CGBlocks.cpp was passing
LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}()
- CodeGenFunction::EmitBlockLiteral() was passing a AST address space to
TargetInfo::getPointerWidth()
- CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space
to Qualifiers::addAddressSpace()
- CGOpenMPRuntimeNVPTX::getParameterAddress() was using
llvm::Type::getPointerTo() with a AST address space
- clang_getAddressSpace() returns either a LangAS or a target address
space. As this is exposed to C I have kept the current behaviour and
added a comment stating that it is probably not correct.
Other than this the patch should not cause any functional changes.
Reviewers: yaxunl, pcc, bader
Reviewed By: yaxunl, bader
Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits
Differential Revision: https://reviews.llvm.org/D38816
llvm-svn: 315871
Currently Clang uses default address space (0) to represent private address space for OpenCL
in AST. There are two issues with this:
Multiple address spaces including private address space cannot be diagnosed.
There is no mangling for default address space. For example, if private int* is emitted as
i32 addrspace(5)* in IR. It is supposed to be mangled as PUAS5i but it is mangled as
Pi instead.
This patch attempts to represent OpenCL private address space explicitly in AST. It adds
a new enum LangAS::opencl_private and adds it to the variable types which are implicitly
private:
automatic variables without address space qualifier
function parameter
pointee type without address space qualifier (OpenCL 1.2 and below)
Differential Revision: https://reviews.llvm.org/D35082
llvm-svn: 315668
Summary:
Currently, clang only diagnoses completely out-of-range comparisons (e.g. `char` and constant `300`),
and comparisons of unsigned and `0`. But gcc also does diagnose the comparisons with the
`std::numeric_limits<>::max()` / `std::numeric_limits<>::min()` so to speak
Finally Fixes https://bugs.llvm.org/show_bug.cgi?id=34147
Continuation of https://reviews.llvm.org/D37565
Reviewers: rjmccall, rsmith, aaron.ballman
Reviewed By: rsmith
Subscribers: rtrieu, jroelofs, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D38101
llvm-svn: 315614
This function is used to perform semantic analysis on Microsoft style
`__va_start`. Rename it to make this more explicit. `__va_start` is
marked as `ALL_MS_LANGUAGES`, and requires Microsoft compatibility.
Other GNU targets will use `__builtin_va_start` instead. NFC.
Addresses post-commit review comments from David Majnemer.
llvm-svn: 314241
The `__va_start` intrinsic for Windows ARM does not account for const
correctness when performing a check. All local qualifiers are ignored
when validating the invocation. This was exposed by building the swift
stdlib against the Windows 10586 SDK for ARM. Simply expand out the
check for the two parameters and ignore the qualifiers for the check.
llvm-svn: 314226
For the triple thumbv7-apple-ios8.0.0 ssize_t is long and size_t is unsigned long,
while NSInteger is int and NSUinteger is unsigned int. Following
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/Strings/Articles/formatSpecifiers.html
Clang catches it and insert a cast to long, for example
printf("%zd", getNSInteger())
will be replaced with
printf("%zd", (long)getNSInteger())
but since the underlying type of ssize_t is long the specifier "%zd" is not getting replaced.
This diff changes this behavior to enable replacing the specifier "%zd" with the correct one.
Differential revision: https://reviews.llvm.org/D38159
Test plan: make check-all
llvm-svn: 314011
As reported here: https://bugs.llvm.org/show_bug.cgi?id=34692
A non-defined enum with a backing type was always defaulting to
being treated as a signed type. IN the case where it IS defined,
the signed-ness of the actual items is used.
This patch uses the underlying type's signed-ness in the non-defined
case to test signed-comparision.
Differential Revision: https://reviews.llvm.org/D38145
llvm-svn: 313907
As Aaron Ballman has pointed out, that is not really correct.
So the key problem there is the invalidity of the testcase.
Revert r313747, and rework testcase in such a way, so these
details (platform-specific default enum sigdness) are
accounted for.
Also, add a C++-specific testcase.
llvm-svn: 313756
Hopefully fixes test-clang-msc-x64-on-i686-linux-RA build.
The underlying problem is that the enum is signed there.
Yet still, it is invalid for it to contain negative values,
so the comparison is always tautological in this case.
No differential, but related to https://reviews.llvm.org/D37629
llvm-svn: 313747
Recommit. Original commit was reverted because buildbots broke.
The error was only reproducible in the build with assertions.
The problem was that the diagnostic expected true/false as
bool, while it was provided as string "true"/"false".
Summary:
As requested by Sam McCall:
> Enums (not new I guess). Typical case: if (enum < 0 || enum > MAX)
> The warning strongly suggests that the enum < 0 check has no effect
> (for enums with nonnegative ranges).
> Clang doesn't seem to optimize such checks out though, and they seem
> likely to catch bugs in some cases. Yes, only if there's UB elsewhere,
> but I assume not optimizing out these checks indicates a deliberate
> decision to stay somewhat compatible with a technically-incorrect
> mental model.
> If this is the case, should we move these to a
> -Wtautological-compare-enum subcategory?
Reviewers: rjmccall, rsmith, aaron.ballman, sammccall, bkramer, djasper
Reviewed By: aaron.ballman
Subscribers: jroelofs, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D37629
llvm-svn: 313745
Summary:
As requested by Sam McCall:
> Enums (not new I guess). Typical case: if (enum < 0 || enum > MAX)
> The warning strongly suggests that the enum < 0 check has no effect
> (for enums with nonnegative ranges).
> Clang doesn't seem to optimize such checks out though, and they seem
> likely to catch bugs in some cases. Yes, only if there's UB elsewhere,
> but I assume not optimizing out these checks indicates a deliberate
> decision to stay somewhat compatible with a technically-incorrect
> mental model.
> If this is the case, should we move these to a
> -Wtautological-compare-enum subcategory?
Reviewers: rjmccall, rsmith, aaron.ballman, sammccall, bkramer, djasper
Reviewed By: aaron.ballman
Subscribers: jroelofs, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D37629
llvm-svn: 313677
Summary:
This is a first half(?) of a fix for the following bug:
https://bugs.llvm.org/show_bug.cgi?id=34147 (gcc -Wtype-limits)
GCC's -Wtype-limits does warn on comparison of unsigned value
with signed zero (as in, with 0), but clang only warns if the
zero is unsigned (i.e. 0U).
Also, be careful not to double-warn, or falsely warn on
comparison of signed/fp variable and signed 0.
Yes, all these testcases are needed.
Testing: $ ninja check-clang-sema check-clang-semacxx
Also, no new warnings for clang stage-2 build.
Reviewers: rjmccall, rsmith, aaron.ballman
Reviewed By: rjmccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D37565
llvm-svn: 312750
This patch adds support for __builtin_cpu_is. I've tried to match the strings supported to the latest version of gcc.
Differential Revision: https://reviews.llvm.org/D35449
llvm-svn: 310657
Converting a _Complex type to a real one simply discards the imaginary part.
This can easily lead to loss of information so for safety (and GCC
compatibility) this patch disallows that when the conversion would be implicit.
The one exception is bool, which actually compares both real and imaginary
parts and so is safe.
llvm-svn: 310427
OpenCL 2.0 atomic builtin functions have a scope argument which is ideally
represented as synchronization scope argument in LLVM atomic instructions.
Clang supports translating Clang atomic builtin functions to LLVM atomic
instructions. However it currently does not support synchronization scope
of LLVM atomic instructions. Without this, users have to use LLVM assembly
code to implement OpenCL atomic builtin functions.
This patch adds OpenCL 2.0 atomic builtin functions as Clang builtin
functions, which supports generating LLVM atomic instructions with
synchronization scope operand.
Currently only constant memory scope argument is supported. Support of
non-constant memory scope argument will be added later.
Differential Revision: https://reviews.llvm.org/D28691
llvm-svn: 310082
Move builtins from the x86 specific scope into the global
scope. Their use is still limited to x86_64 and aarch64 though.
This allows wine on aarch64 to properly handle variadic functions.
Differential Revision: https://reviews.llvm.org/D34475
llvm-svn: 308218
This patch series adds support for the IBM z14 processor. This part includes:
- Basic support for the new processor and its features.
- Support for low-level builtins mapped to new LLVM intrinsics.
Support for the -fzvector extension to vector float and the new
high-level vector intrinsics is provided by separate patches.
llvm-svn: 308197
Also add testcases for a bunch of expression forms that cause our evaluator to
crash. See PR33140 and PR32864 for crashes that this was causing.
This reverts r305287, which reverted r305239, which reverted r301742. The
previous revert claimed that buildbots were broken, but did not add any
testcases and the buildbots have lost all memory of what was wrong here.
Changes to test/OpenMP are not reverted; another change has triggered those
tests to change their output in the same way that r301742 did.
llvm-svn: 306346
Summary:
First, getCurFunction looks through blocks and lambdas, which is wrong.
Inside a lambda, va_start should refer to the lambda call operator
prototype. This fixes PR32737.
Second, we shouldn't use any of the getCur* methods, because they look
through contexts that we don't want to look through (EnumDecl,
CapturedStmtDecl). We can use CurContext directly as the calling
context.
Finally, this code assumed that CallExprs would never appear outside of
code contexts (block, function, obj-c method), which is wrong. Struct
member initializers are an easy way to create and parse exprs in a
non-code context.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D32761
llvm-svn: 302188
Combine the logic doing the ms_abi/sysv_abi checks into one function so
that each check and its logical opposite are near each other. Now we
don't need two Sema entry points for MS va_start and regular va_start.
Refactor the code that checks if the va_start caller is a function,
block, or obj-c method. We do this in three places, and they are all
buggy for variadic lambdas (PR32737). After this change, I have one
place to apply the functional fix.
NFC
llvm-svn: 301968
CheckForIntOverflow used to implement a whitelist of top-level expressions to
send to the constant expression evaluator, which handled many more expressions
than the CheckForIntOverflow whitelist did.
llvm-svn: 301742
A boxed expression evaluates its subexpr and then calls an objc method to transform it into another value with pointer type. The objc method can never be constexpr and therefore this expression can never be evaluated. Fixes a miscompile boxing expressions with side-effects.
Also make ObjCBoxedExpr handling a normal part of the expression evaluator instead of being the only case besides full-expression where we check for integer overflow.
llvm-svn: 301721
Check unqualified type for ndrange argument in device_side_enqueue so
device_side_enqueue accept const and volatile qualified ndranges.
Differential Revision: https://reviews.llvm.org/D31458
Patch by Dmitry Borisenkov!
llvm-svn: 300988
The Result variable is unused both in Sema::CheckARMBuiltinFunctionCall
and Sema::CheckAArch64BuiltinFunctionCall, remove it.
Patch by Wei-Ren Chen!
Reviewers: craig.topper, rnk
Reviewed By: rnk
Subscribers: aemerson, cfe-commits, rengolin
Differential Revision: https://reviews.llvm.org/D32014
llvm-svn: 300572
Our _MM_HINT_T0/T1 constant values are 3/2 which matches gcc, but not icc or Intel documentation. Interestingly gcc had this same bug on their implementation of the gather/scatter builtins at one point too.
Fixes PR32411.
llvm-svn: 299233
Reasoning behind this change was allowing the function to accept all values
from range [-128, 255] since all of them can be encoded in an 8bit wide
value.
This differs from the prior state where only range [-128, 127] was accepted,
where values were assumed to be signed, whereas now the actual
interpretation of the immediate is deferred to the consumer as required.
Patch by Stefan Maksimovic.
Differential Revision: https://reviews.llvm.org/D31082
llvm-svn: 299229
This adds -Wbitfield-enum-conversion, which warns on implicit
conversions that happen on bitfield assignment that change the value of
some enumerators.
Values of enum type typically take on a very small range of values, so
they are frequently stored in bitfields. Unfortunately, there is no
convenient way to calculate the minimum number of bits necessary to
store all possible values at compile time, so users usually hard code a
bitwidth that works today and widen it as necessary to pass basic
testing and validation. This is very error-prone, and leads to stale
widths as enums grow. This warning aims to catch such bugs.
This would have found two real bugs in clang and two instances of
questionable code. See r297680 and r297654 for the full description of
the issues.
This warning is currently disabled by default while we investigate its
usefulness outside of LLVM.
The major cause of false positives with this warning is this kind of
enum:
enum E { W, X, Y, Z, SENTINEL_LAST };
The last enumerator is an invalid value used to validate inputs or size
an array. Depending on the prevalance of this style of enum across a
codebase, this warning may be more or less feasible to deploy. It also
has trouble on sentinel values such as ~0U.
Reviewers: rsmith, rtrieu, thakis
Reviewed By: thakis
Subscribers: hfinkel, voskresensky.vladimir, sashab, cfe-commits
Differential Revision: https://reviews.llvm.org/D30923
llvm-svn: 297761
The only valid values for scale immediate of scatter/gather builtins are 1, 2, 4, or 8. This patch enforces this in the frontend otherwise we generate invalid instruction encodings in the backend.
Differential Revision: https://reviews.llvm.org/D30875
llvm-svn: 297642
Given that we have already explicitly stated in the qualifier that the
expression is __unaligned, it makes little sense to diagnose that the address
of the packed member may not be aligned.
Differential Revision: https://reviews.llvm.org/D30884
llvm-svn: 297620
Removes immediate range checks for these instructions, since they have GPR
rt as their input operand.
Patch by Stefan Maksimovic.
Differential Revision: https://reviews.llvm.org/D30693
llvm-svn: 297485
instantiation.
In preparation for converting the template stack to a more general context
stack (so we can include context notes for other kinds of context).
llvm-svn: 295686
Removed ndrange_t as Clang builtin type and added
as a struct type in the OpenCL header.
Use type name to do the Sema checking in enqueue_kernel
and modify IR generation accordingly.
Review: D28058
Patch by Dmitry Borisenkov!
llvm-svn: 295311
This patch changes how we handle argument-dependent `diagnose_if`
attributes. In particular, we now check them in the same place that we
check for things like passing NULL to Nonnull args, etc. This is
basically better in every way than how we were handling them before. :)
This fixes PR31638, PR31639, and PR31640.
Differential Revision: https://reviews.llvm.org/D28889
llvm-svn: 293360
* In C++, never create a FunctionNoProtoType for a builtin (fixes C++1z
crasher from r289754).
* Fix type of __sync_synchronize to be a no-parameter function rather than a
varargs function. This matches GCC.
* Fix type of vfprintf to match its actual type. We gave it a wrong type due
to PR4290 (apparently autoconf generates invalid code and expects compilers
to choke it down or it miscompiles the program; the relevant error in clang
was downgraded to a warning in r122744 to fix other occurrences of this
autoconf brokenness, so we don't need this workaround any more).
* Turn off vararg argument checking for __noop, since it's not *really* a
varargs function. Alternatively we could add custom type checking for it
and synthesize parameter types matching the actual arguments in each call,
but that seemed like overkill.
llvm-svn: 290146
The function SemaBuiltinFPClassification removed superfluous float to double
casts, this was changed to also remove float to float casts but this isn't
valid in all cases, for example when doing an rvaluetolvalue cast. Added a
check to only remove if this was a conventional floating cast.
Added additional tests into SemaOpenCL/extensions to cover these cases
llvm-svn: 289650
This change makes sure single-precision floating point types are used if the
cl_fp64 extension is not supported by the target.
Also removed the check to see whether the OpenCL version is >= 1.2, as this has
been incorporated into the extension setting code.
Differential Revision: https://reviews.llvm.org/D24235
llvm-svn: 289544
- Rename CheckMinZero to CheckMaxUnsignedZero to reflect its actual purpose.
- Remove unused parameters from CheckAbsoluteValueFunction and
CheckMaxUnsignedZero functions.
- Refactor the function name check so both functions can use the same one.
llvm-svn: 288756
New default warning that triggers when an unsigned zero is used in a call to
std::max. For unsigned values, zero is the minimum value, so any call to
std::max is always equal to the other value. A common pattern was to take
the max of zero and the difference of two unsigned values, not taking into
account that unsigned values wrap around below zero. This warning also emits
a note with a fixit hint to remove the zero and call to std::max.
llvm-svn: 288732
declared variables.
Teach Sema to check the aligned attribute attached to variable
declarations so that it doesn't issue spurious warnings.
rdar://problem/26517471
Differential revision: https://reviews.llvm.org/D21099
llvm-svn: 288267
This commit teaches clang that is has to emit a warning when NULL is passed
as the 'expected' pointer parameter into an atomic compare exchange call.
rdar://18926650
Differential Revision: https://reviews.llvm.org/D26978
llvm-svn: 287776
Summary:
This is a simple sema check patch for arguments of `__builtin_arm_rsr` and the related builtins, which currently do not allow special registers with indexes >7.
Some of the possible register name formats these builtins accept are:
```
{c}p<coprocessor>:<op1>:c<CRn>:c<CRm>:<op2>
```
```
o0:op1:CRn:CRm:op2
```
where `op1` / `op2` are integers in the range [0, 7] and `CRn` / `CRm` are integers in the range [0, 15].
The current sema check does not allow `CRn` > 7 and accepts `op2` up to 15.
Reviewers: LukeCheeseman, rengolin
Subscribers: asl, aemerson, rengolin, cfe-commits
Differential Revision: https://reviews.llvm.org/D26464
llvm-svn: 287378
Summary:
Add a warning when assigning enums to bitfields without an explicit
unsigned underlying type. This is to prevent problems with MSVC
compatibility, since the Microsoft ABI defaults to storing enums with a
signed type, causing inconsistencies with saving to/reading from
bitfields.
Also disabled the warning in the dr0xx.cpp test which throws the error,
and added a test for the warning.
The warning can be disabled with -Wno-signed-enum-bitfield.
Patch by Sasha Bermeister!
Reviewers: rnk, aaron.ballman
Subscribers: mehdi_amini, aaron.ballman, cfe-commits, thakis, dcheng
Differential Revision: https://reviews.llvm.org/D24289
llvm-svn: 287177
Make handling integer parameters more flexible:
- For the number of events argument allow to pass larger
integers than 32 bits as soon as compiler can prove that
the range fits in 32 bits. If not, the diagnostic will be given.
- Change type of the arguments specifying the sizes of
the corresponding block arguments to be size_t.
Review: https://reviews.llvm.org/D26509
llvm-svn: 286849
- Accept NULL pointer as a valid parameter value for clk_event.
- Generate clk_event_t arguments of internal
__enqueue_kernel_XXX function as pointers in generic address space.
Review: https://reviews.llvm.org/D26507
llvm-svn: 286836
Unfortunately, the backend currently doesn't fold masks into the instructions correctly when they come from these shufflevectors. I'll work on that in a future commit.
llvm-svn: 285667
The second argument to __builtin_alloca_with_align is supposed to be in
bits, not bytes. Using alignof there would be indicative of a bug.
llvm-svn: 285609
__builtin_alloca always uses __BIGGEST_ALIGNMENT__ for the alignment of
the allocation. __builtin_alloca_with_align allows the programmer to
specify the alignment of the allocation.
This fixes PR30658.
llvm-svn: 285544
Unfortunately, the backend currently doesn't fold masks into the instructions correctly when they come from these shufflevectors. I'll work on that in a future commit.
llvm-svn: 285540
This reverts commit r285007 and reapply r284990, with a fix for the
opencl test that I broke. Original commit message follows:
These new builtins support a mechanism for logging OS events, using a
printf-like format string to specify the layout of data in a buffer.
The _buffer_size version of the builtin can be used to determine the size
of the buffer to allocate to hold the data, and then __builtin_os_log_format
can write data into that buffer. This implements format checking to report
mismatches between the format string and the data arguments. Most of this
code was written by Chris Willmore.
Differential Revision: https://reviews.llvm.org/D25888
llvm-svn: 285019
These new builtins support a mechanism for logging OS events, using a
printf-like format string to specify the layout of data in a buffer.
The _buffer_size version of the builtin can be used to determine the size
of the buffer to allocate to hold the data, and then __builtin_os_log_format
can write data into that buffer. This implements format checking to report
mismatches between the format string and the data arguments. Most of this
code was written by Chris Willmore.
Differential Revision: https://reviews.llvm.org/D25888
llvm-svn: 284990
This commit improves the '-Wformat' warnings by ensuring that the formatting
checker can see through Objective-C message sends when we are calling an
Objective-C method with an appropriate format_arg attribute.
rdar://23622446
Differential Revision: https://reviews.llvm.org/D25820
llvm-svn: 284961
This patch teaches clang to range check immediates for MIPS MSA instrinsics.
This checking is done strictly in comparison to some existing GCC
implementations. E.g. msa_andvi_b(var, 257) does not result in andvi $wX, 1.
Similarily msa_ldi_b takes a range of -128 to 127.
As part of this effort, correct the existing MSA test as it has both illegal
types and immediates.
Reviewers: vkalintiris
Differential Revision: https://reviews.llvm.org/D25017
llvm-svn: 284620
This reverts commit r283802. It introduces temporarily static
initializers, because StringRef ctor isn't (yet) constexpr for
string literals.
I plan to get there this week, but apparently GCC is so terrible
with these static initializer right now (10 min+ extra codegen
time was reported) that I'll hold on to this patch till the
constexpr one is ready, and land these at the same time.
llvm-svn: 283920
This commit improves the packed member warning by showing the name of the
anonymous structure/union when it was defined within a typedef declaration.
rdar://28498901
Differential Revision: https://reviews.llvm.org/D25106
llvm-svn: 283304
Summary:
This lets people link against LLVM and their own version of the UTF
library.
I determined this only affects llvm, clang, lld, and lldb by running
$ git grep -wl 'UTF[0-9]\+\|\bConvertUTF\bisLegalUTF\|getNumBytesFor' | cut -f 1 -d '/' | sort | uniq
clang
lld
lldb
llvm
Tested with
ninja lldb
ninja check-clang check-llvm check-lld
(ninja check-lldb doesn't complete for me with or without this patch.)
Reviewers: rnk
Subscribers: klimek, beanz, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D24996
llvm-svn: 282822
The backend can't encode all possible values of the argument and will fail isel. Checking in the frontend presents a friendlier experience to the user.
I started with builtins that can only take _MM_CUR_DIRECTION or _MM_NO_EXC. More builtins coming in the future.
llvm-svn: 282228
Summary:
The diagnostic did not handle ~ well. An expression such as ~0 is often used when 'all ones' is needed.
Differential Revision: https://reviews.llvm.org/D24232
llvm-svn: 282156
Summary:
Offset was doubled in size, but the assignment was missing. We just need
to reassign to the original variable in this case to fix it.
Reviewers: cfe-commits, echristo
Subscribers: meikeb
Differential Revision: https://reviews.llvm.org/D24648
llvm-svn: 281706
Summary:
The warning for a format string not being a string literal and therefore
being potentially insecure is overly strict for indices into string
literals. This fix checks if the index into the string literal is
precomputable. If that's the case it will check if the suffix of that
string literal is a valid format string string literal. It will still
issue the aforementioned warning for out of range indices into the
string literal.
Patch by Meike Baumgärtner (meikeb)
Reviewers: rsmith
Subscribers: srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D24584
llvm-svn: 281686
The underlying type for an enumeration in C is either char, signed int, or unsigned int. In the case the underlying type is chosen to be char (such as when passing -fshort-enums or using __attribute__((packed)) on the enum declaration), the enumeration can result in undefined behavior. However, when the underlying type is signed int or unsigned int (or long long as an extension), there is no undefined behavior because the types are compatible. This patch silences diagnostics for the latter while retaining the diagnostics for the former.
This patch addresses PR29140.
llvm-svn: 281632
Summary: This reverts r281527 because I messed up the attribution.
Reviewers: srhines
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24579
llvm-svn: 281530
Summary:
The warning for a format string not being a sting literal and therefore
being potentially insecure is overly strict for indecies into sting
literals. This fix checks if the index into the string literal is
precomputable. If thats the case it will check if the suffix of that
sting literal is a valid format string string literal. It will still
issue the aforementioned warning for out of range indecies into the
string literal.
Reviewers: rsmith
Subscribers: srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D23820
llvm-svn: 281527
Taking the address of a packed member is dangerous since the reduced
alignment of the pointee is lost. This can lead to memory alignment
faults in some architectures if the pointer value is dereferenced.
This change adds a new warning to clang emitted when taking the address
of a packed member. A packed member is either a field/data member
declared as attribute((packed)) or belonging to a struct/class
declared as such. The associated flag is -Waddress-of-packed-member.
Conversions (either implicit or via a valid casting) to pointer types
with lower or equal alignment requirements (e.g. void* or char*)
will silence the warning.
Differential Revision: https://reviews.llvm.org/D20561
llvm-svn: 278483
Follow-up from r278264 after Joerg's feedback.
Since bzero is not standard, be more strict: also check if the first
argument is a pointer, which harden the check for when it does not come
originally from a builtin.
llvm-svn: 278379
Reapply r277787. For memset (and others) we can get diagnostics like:
struct stat { int x; };
void foo(struct stat *stamps) {
bzero(stamps, sizeof(stamps));
memset(stamps, 0, sizeof(stamps));
}
t.c:7:28: warning: 'memset' call operates on objects of type 'struct stat' while the size is based on a different type 'struct stat *' [-Wsizeof-pointer-memaccess]
memset(stamps, 0, sizeof(stamps));
~~~~~~ ^~~~~~
t.c:7:28: note: did you mean to dereference the argument to 'sizeof' (and multiply it by the number of elements)?
memset(stamps, 0, sizeof(stamps));
^~~~~~
This patch implements the same class of warnings for bzero.
Differential Revision: https://reviews.llvm.org/D22525
rdar://problem/18963514
llvm-svn: 278264
If the return type is a pointer and the function returns the reference to a
pointer, don't warn since only the value is returned, not the reference.
If a reference function parameter appears in the reference chain, don't warn
since binding happens at the caller scope, so addresses returned are not
to local stack. This includes default arguments as well.
llvm-svn: 277889
For builtin logical operators, there is a well-defined ordering of argument
evaluation. For overloaded operator of the same type, there is no argument
evaluation order, similar to other function calls. When both are present,
uninstantiated templates with an operator&& is treated as an unresolved
function call. Unresolved function calls are treated as normal function calls,
and may result in false positives when the builtin logical operator is used.
Have the unsequenced checker ignore dependent expressions to avoid this
false positive. The check also happens in template instantiations to catch
when the overloaded operator is used.
llvm-svn: 277866
Silence the -Wbitfield-constant-conversion warning for when -1 or other
negative values are assigned to unsigned bitfields, provided that the bitfield
is wider than the minimum number of bits needed to encode the negative value.
llvm-svn: 277796
For memset (and others) we can get diagnostics like:
struct stat { int x; };
void foo(struct stat *stamps) {
bzero(stamps, sizeof(stamps));
memset(stamps, 0, sizeof(stamps));
}
t.c:7:28: warning: 'memset' call operates on objects of type 'struct stat' while the size is based on a different type 'struct stat *' [-Wsizeof-pointer-memaccess]
memset(stamps, 0, sizeof(stamps));
~~~~~~ ^~~~~~
t.c:7:28: note: did you mean to dereference the argument to 'sizeof' (and multiply it by the number of elements)?
memset(stamps, 0, sizeof(stamps));
^~~~~~
This patch implements the same class of warnings for bzero.
Differential Revision: https://reviews.llvm.org/D22525
rdar://problem/18963514
llvm-svn: 277787
In atomic builtins, we assumed that the LValue conversion on the first
argument would succeed. So, we would crash given code like:
```
void ovl(char);
void ovl(int);
__atomic_store_n(ovl, 0, 0);
```
This patch makes us not assume that said conversion is successful. :)
llvm-svn: 276232
This patch implements PR#22821.
Taking the address of a packed member is dangerous since the reduced
alignment of the pointee is lost. This can lead to memory alignment
faults in some architectures if the pointer value is dereferenced.
This change adds a new warning to clang emitted when taking the address
of a packed member. A packed member is either a field/data member
declared as attribute((packed)) or belonging to a struct/class
declared as such. The associated flag is -Waddress-of-packed-member.
Conversions (either implicit or via a valid casting) to pointer types
with lower or equal alignment requirements (e.g. void* or char*)
silence the warning.
This change also adds a new error diagnostic when the user attempts to
bind a reference to a packed member, regardless of the alignment.
Differential Revision: https://reviews.llvm.org/D20561
llvm-svn: 275417
- Added new Builtins: enqueue_kernel, get_kernel_work_group_size
and get_kernel_preferred_work_group_size_multiple.
These Builtins use custom check to diagnose parameters of the passed Blocks
i. e. variable number of 'local void*' type params, and check different
overloads specified in Table 6.31 of OpenCL v2.0.
- IR is generated as an internal library call for each OpenCL Builtin,
reusing ObjC Block implementation.
Review: http://reviews.llvm.org/D20249
llvm-svn: 274540
Currently we only have OpenCL 2.0 Builtins i.e. pipes or address space conversions.
They have to be added only in the version 2.0 compilation mode to make the identifiers
available for use in the other versions.
Review: http://reviews.llvm.org/D20249
llvm-svn: 274509
OpenCL builtin functions to_{global|local|private} accepts argument of pointer type to arbitrary pointee type, and return a pointer to the same pointee type in different addr space, i.e.
global gentype *to_global(gentype *p);
It is not desirable to declare it as
global void *to_global(void *);
in opencl header file since it misses diagnostics.
This patch implements these builtin functions as Clang builtin functions. In the builtin def file they are defined to have signature void*(void*). When handling call expressions, their declarations are re-written to have correct parameter type and return type corresponding to the call argument.
In codegen call to addr void *to_addr(void*) is generated with addrcasts or bitcasts to facilitate implementation in builtin library.
Differential Revision: http://reviews.llvm.org/D19932
llvm-svn: 270261
I couldn't find any documentation that this form existed either. Nor is there documentation for one of the remaining two forms, but there is a testcase that uses it.
llvm-svn: 269879
Remove the floating point to bool conversion warnings. Some of these
conversions will be caught by -Wliteral-conversion and -Wfloat-conversion
llvm-svn: 267234
Restructure the implict floating point to integer conversions so that
interesting sub-groups are under different flags. Breakdown of warnings:
No warning:
Exact conversions from floating point to integer:
int x = 10.0;
int x = 1e10;
-Wliteral-conversion - Floating point literal to integer with rounding:
int x = 5.5;
int x = -3.4;
-Wfloat-conversion - All conversions not covered by the above two:
int x = GetFloat();
int x = 5.5 + 3.5;
-Wfloat-zero-conversion - The expression converted has a non-zero floating
point value that gets converted to a zero integer value, excluded the cases
falling under -Wliteral-conversion. Subset of -Wfloat-conversion.
int x = 1.0 / 2.0;
-Wfloat-overflow-conversion - The floating point value is outside the range
of the integer type, exluding cases from -Wliteral conversion. Subset of
-Wfloat-conversion.
char x = 500;
char x = -1000;
-Wfloat-bool-conversion - Any conversion of a floating point type to bool.
Subset of -Wfloat-conversion.
if (GetFloat()) {}
bool x = 5.0;
-Wfloat-bool-constant-conversion - Conversion of a compile time evaluatable
floating point value to bool. Subset of -Wfloat-bool-conversion.
bool x = 1.0;
bool x = 4.0 / 20.0;
Also add EvaluateAsFloat to Sema, which is similar to EvaluateAsInt, but for
floating point values.
llvm-svn: 267054
Craig Topper