The attribute informs the compiler that the annotated pointer parameter
of a function cannot escape and enables IRGen to attach attribute
'nocapture' to parameters that are annotated with the attribute. That is
the only optimization that currently takes advantage of 'noescape', but
there are other optimizations that will be added later that improves
IRGen for ObjC blocks.
rdar://problem/19886775
Differential Revision: https://reviews.llvm.org/D32520
llvm-svn: 313720
The recently behavior in the code that these tests were meant to be checking will be ammended as soon as a suitable change can be properly reviewed.
llvm-svn: 313684
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:
According to C99 6.3.2.1p1, structs and unions with nested
const-qualified fields (that is, const-qualified fields
declared at some recursive level of the aggregate) are not
modifiable lvalues. However, Clang permits assignments of
these lvalues.
With this patch, we both prohibit the assignment of records
with const-qualified fields and emit a best-effort diagnostic.
This fixes https://bugs.llvm.org/show_bug.cgi?id=31796 .
Committing on behalf of bevinh (Bevin Hansson).
Reviewers: rtrieu, rsmith, bjope
Reviewed By: bjope
Subscribers: Ka-Ka, rogfer01, bjope, fhahn, cfe-commits
Differential Revision: https://reviews.llvm.org/D37254
llvm-svn: 313628
This fixes PR28903 by avoiding access check for inner enum constant. We
are performing access check because one enum constant references another
and because enum is defined in CXXRecordDecl. But access check doesn't
work because FindDeclaringClass doesn't expect more than one EnumDecl
and because inner enum has access AS_none due to not being an immediate
child of a record.
The change detects an enum is defined in wrong place and allows to skip
parsing its body. Access check is skipped together with body parsing.
There was no crash in C, added test case to cover the new error.
rdar://problem/28530809
Reviewers: rnk, doug.gregor, rsmith
Reviewed By: doug.gregor
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D37089
llvm-svn: 313386
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 makes -Wunreachable-code work for programs containing SEH (except for
__finally, which is still missing for now).
__try is modeled like try (but simpler since it can only have a single __except
or __finally), __except is fairly similar to catch (but simpler, since it can't
contain declarations). __leave is implemented similarly to break / continue.
Use the existing addTryDispatchBlock infrastructure (which
FindUnreachableCode() in ReachableCode.cpp uses via cfg->try_blocks_begin()) to
mark things in the __except blocks as reachable.
Re-use TryTerminatedBlock. This means we add EH edges from calls to the __try
block, but not from all other statements. While this is incomplete, it matches
LLVM's SEH codegen support. Also, in practice, BuildOpts.AddEHEdges is always
false in practice from what I can tell, so we never even insert the call EH
edges either.
https://reviews.llvm.org/D36914
llvm-svn: 311561
This reverts commit rL310403, which caused spurious warnings in libc++,
because it didn't properly handle templated scoped lockable types.
llvm-svn: 310698
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
Such implicitly declared functions behave as if the enclosing block
contained the declaration extern int name() (C90, 6.3.3.2 Function calls),
thus their names should have block scope (C90, 6.1.2.1 Scope of identifiers).
This patch fixes https://bugs.llvm.org/show_bug.cgi?id=33224
Differential Revision: https://reviews.llvm.org/D33676
llvm-svn: 310616
Add warnings in cases where an implicit `this` argument is expected to
attributes because either `this` doesn't exist because the attribute is
on a free function, or because `this` is on a type that doesn't have a
corresponding capability/lockable/scoped_lockable attribute.
Reviewers: delesley, aaron.ballman
Differential Revision: https://reviews.llvm.org/D36237
llvm-svn: 310403
Delete the test that was broken by rL309725, and add it back in a
follow up commit. Also, improve the tests a bit.
Reviewers: delesley, aaron.ballman
Differential Revision: https://reviews.llvm.org/D36237
llvm-svn: 310402
An ABI change was introduced in r254596 that modified structure layouts when the 'packed' attribute was used on one-byte bitfields. Since the PS4 target needs to maintain backwards compatibility for all structure layouts, this change reintroduces the old behavior for PS4 targets only. It also introduces PS4 specific cases to the relevant test.
Patch by Matthew Voss.
llvm-svn: 310388
r282968 introduced a regression due to the lack of proper testing.
Re-add lax conversion support between non ext vectors for compound
assignments and add a test for that.
rdar://problem/28639467
llvm-svn: 309722
'#pragma pack (pop)' and suspicious uses of '#pragma pack' in included files
The second recommit (r309106) was reverted because the "non-default #pragma
pack value chages the alignment of struct or union members in the included file"
warning proved to be too aggressive for external projects like Chromium
(https://bugs.chromium.org/p/chromium/issues/detail?id=749197). This recommit
makes the problematic warning a non-default one, and gives it the
-Wpragma-pack-suspicious-include warning option.
The first recommit (r308441) caused a "non-default #pragma pack value might
change the alignment of struct or union members in the included file" warning
in LLVM itself. This recommit tweaks the added warning to avoid warnings for
#includes that don't have any records that are affected by the non-default
alignment. This tweak avoids the previously emitted warning in LLVM.
Original message:
This commit adds a new -Wpragma-pack warning. It warns in the following cases:
- When a translation unit is missing terminating #pragma pack (pop) directives.
- When entering an included file if the current alignment value as determined
by '#pragma pack' directives is different from the default alignment value.
- When leaving an included file that changed the state of the current alignment
value.
rdar://10184173
Differential Revision: https://reviews.llvm.org/D35484
llvm-svn: 309386
The warning fires on non-suspicious code in Chromium. Reverting until a
solution is figured out.
> Recommit r308327 2nd time: Add a warning for missing
> '#pragma pack (pop)' and suspicious uses of '#pragma pack' in included files
>
> The first recommit (r308441) caused a "non-default #pragma pack value might
> change the alignment of struct or union members in the included file" warning
> in LLVM itself. This recommit tweaks the added warning to avoid warnings for
> #includes that don't have any records that are affected by the non-default
> alignment. This tweak avoids the previously emitted warning in LLVM.
>
> Original message:
>
> This commit adds a new -Wpragma-pack warning. It warns in the following cases:
>
> - When a translation unit is missing terminating #pragma pack (pop) directives.
> - When entering an included file if the current alignment value as determined
> by '#pragma pack' directives is different from the default alignment value.
> - When leaving an included file that changed the state of the current alignment
> value.
>
> rdar://10184173
>
> Differential Revision: https://reviews.llvm.org/D35484
llvm-svn: 309186
'#pragma pack (pop)' and suspicious uses of '#pragma pack' in included files
The first recommit (r308441) caused a "non-default #pragma pack value might
change the alignment of struct or union members in the included file" warning
in LLVM itself. This recommit tweaks the added warning to avoid warnings for
#includes that don't have any records that are affected by the non-default
alignment. This tweak avoids the previously emitted warning in LLVM.
Original message:
This commit adds a new -Wpragma-pack warning. It warns in the following cases:
- When a translation unit is missing terminating #pragma pack (pop) directives.
- When entering an included file if the current alignment value as determined
by '#pragma pack' directives is different from the default alignment value.
- When leaving an included file that changed the state of the current alignment
value.
rdar://10184173
Differential Revision: https://reviews.llvm.org/D35484
llvm-svn: 309106
MIPS gcc supports `long_call/far/near` attributes only, but other
targets have the `short_call` attribut, so let's support it for MIPS
for consistency.
llvm-svn: 308719
This patch adds support for the `long_call`, `far`, and `near` attributes
for MIPS targets. The `long_call` and `far` attributes are synonyms. All
these attributes override `-mlong-calls` / `-mno-long-calls` command
line options for particular function.
Differential revision: https://reviews.llvm.org/D35479
llvm-svn: 308667
This diff addresses FIXMEs in lib/Analysis/ScanfFormatString.cpp
for the case of ssize_t format specifier and adds tests.
In particular, this change enables Clang to emit a warning
on incorrect using of "%zd"/"%zn".
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D35652
llvm-svn: 308662
This seems to have broken the sanitizer-x86_64-linux buildbot. Reverting until
it's fixed, especially since this landed just before the 5.0 branch.
> This commit adds a new -Wpragma-pack warning. It warns in the following cases:
>
> - When a translation unit is missing terminating #pragma pack (pop) directives.
> - When entering an included file if the current alignment value as determined
> by '#pragma pack' directives is different from the default alignment value.
> - When leaving an included file that changed the state of the current alignment
> value.
>
> rdar://10184173
>
> Differential Revision: https://reviews.llvm.org/D35484
llvm-svn: 308455
and suspicious uses of '#pragma pack' in included files
This commit adds a new -Wpragma-pack warning. It warns in the following cases:
- When a translation unit is missing terminating #pragma pack (pop) directives.
- When entering an included file if the current alignment value as determined
by '#pragma pack' directives is different from the default alignment value.
- When leaving an included file that changed the state of the current alignment
value.
rdar://10184173
Differential Revision: https://reviews.llvm.org/D35484
llvm-svn: 308441
of '#pragma pack' in included files
This commit adds a new -Wpragma-pack warning. It warns in the following cases:
- When a translation unit is missing terminating #pragma pack (pop) directives.
- When entering an included file if the current alignment value as determined
by '#pragma pack' directives is different from the default alignment value.
- When leaving an included file that changed the state of the current alignment
value.
rdar://10184173
Differential Revision: https://reviews.llvm.org/D35484
llvm-svn: 308327
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 extends the -fzvector language feature to enable the new
"vector float" data type when compiling at -march=z14. This matches
the updated extension definition implemented by other compilers for
the platform, which is indicated to applications by pre-defining
__VEC__ to 10302 (instead of 10301).
llvm-svn: 308198
Summary:
This way, the behavior of that warning flag
more closely resembles that of GCC.
Do note that there is at least one false-negative (see FIXME in tests).
Fixes PR4802.
Testing:
```
ninja check-clang-sema check-clang-semacxx
```
Reviewers: dblaikie, majnemer, rnk
Reviewed By: dblaikie, rnk
Subscribers: mclow.lists, cfe-commits, alexfh, rnk
Differential Revision: https://reviews.llvm.org/D33102
llvm-svn: 307045
This patch extends the `overloadable` attribute to allow for one
function with a given name to not be marked with the `overloadable`
attribute. The overload without the `overloadable` attribute will not
have its name mangled.
So, the following code is now legal:
void foo(void) __attribute__((overloadable));
void foo(int);
void foo(float) __attribute__((overloadable));
In addition, this patch fixes a bug where we'd accept code with
`__attribute__((overloadable))` inconsistently applied. In other words,
we used to accept:
void foo(void);
void foo(void) __attribute__((overloadable));
But we will do this no longer, since it defeats the original purpose of
requiring `__attribute__((overloadable))` on all redeclarations of a
function.
This breakage seems to not be an issue in practice, since the only code
I could find that had this pattern often looked like:
void foo(void);
void foo(void) __attribute__((overloadable)) __asm__("foo");
void foo(int) __attribute__((overloadable));
...Which can now be simplified by simply removing the asm label and
overloadable attribute from the redeclaration of `void foo(void);`
Differential Revision: https://reviews.llvm.org/D32332
llvm-svn: 306467
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:
Before this change, we couldn't capture the `this` pointer that's
implicitly the first argument of class member functions. There are some
interesting things we can do with capturing even just this single
argument for zero-argument member functions.
Reviewers: rnk, pelikan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D34052
llvm-svn: 305544
Summary:
This way, the behavior of that warning flag
more closely resembles that of GCC.
Do note that there is at least one false-negative (see FIXME in tests).
Fixes PR4802.
Testing:
```
ninja check-clang-sema check-clang-semacxx
```
Reviewers: dblaikie, majnemer, rnk
Reviewed By: dblaikie, rnk
Subscribers: cfe-commits, alexfh, rnk
Differential Revision: https://reviews.llvm.org/D33102
llvm-svn: 305147
This test was silently failing since a long time because it failed to include
stdlib.h (as it's running in a freestanding environment). However, because we
used just not clang_cc1 instead of the verify mode, this regression was never
noticed and the test was just always passing.
This adds -ffreestanding to the invocation, so that tmmintrin.h doesn't
indirectly include mm_malloc.h, which in turns includes the unavailable stdlib.h.
We also run now in the -verify mode to prevent that we silently regress again.
I've also updated the test to no longer check the return value of _mm_alignr_epi8
as this is also causing it to fail (and it's not really the job of this test to
test this).
Patch by Raphael Isemann (D34022)
llvm-svn: 305089
Bitwise complement applied to vector of floats described with
attribute `ext_vector_type` is not diagnosed as error. Attempt to
compile such construct causes assertion violation in Instruction.cpp.
With this change the complement is treated similar to the case of
vector type described with attribute `vector_size`.
Differential Revision: https://reviews.llvm.org/D33732
llvm-svn: 304963
This patch provides a means to specify section-names for global variables,
functions and static variables, using #pragma directives.
This feature is only defined to work sensibly for ELF targets.
One can specify section names as:
#pragma clang section bss="myBSS" data="myData" rodata="myRodata" text="myText"
One can "unspecify" a section name with empty string e.g.
#pragma clang section bss="" data="" text="" rodata=""
Reviewers: Roger Ferrer, Jonathan Roelofs, Reid Kleckner
Differential Revision: https://reviews.llvm.org/D33412
llvm-svn: 304705
Print "this block declaration is not a prototype" for non-prototype
declarations of blocks instead of "this function declaration ...".
rdar://problem/32461723
Differential Revision: https://reviews.llvm.org/D33739
llvm-svn: 304507
A recent change requires opencl triple environment for compiling OpenCL
program, which causes regressions in libclc.
This patch fixes that. Instead of deducing language based on triple
environment, it checks LangOptions.
Differential Revision: https://reviews.llvm.org/D33445
llvm-svn: 303644
This patch adds support for the `micromips` and `nomicromips` attributes
for MIPS targets.
Differential revision: https://reviews.llvm.org/D33363
llvm-svn: 303546
Alloca always returns a pointer in alloca address space, which may
be different from the type defined by the language. For example,
in C++ the auto variables are in the default address space. Therefore
cast alloca to the expected address space when necessary.
Differential Revision: https://reviews.llvm.org/D32248
llvm-svn: 303370
This patch teaches clang to perform implicit scalar to vector conversions
when one of the operands of a binary vector expression is a scalar which
can be converted to the element type of the vector without truncation
following GCC's implementation.
If the (constant) scalar is can be casted safely, it is implicitly casted to the
vector elements type and splatted to produce a vector of the same type.
Contributions from: Petar Jovanovic
Reviewers: bruno, vkalintiris
Differential Revision: https://reviews.llvm.org/D25866
llvm-svn: 302935
Diagnostics related to redefinition errors that point to the same header
file do not provide much information that helps users fixing the issue.
- In the modules context, it usually happens because of non modular
includes.
- When modules aren't involved it might happen because of the lack of
header guards.
Enhance diagnostics in these scenarios.
Differential Revision: https://reviews.llvm.org/D28832
rdar://problem/31669175
llvm-svn: 302765
We were sometimes doing a function->pointer conversion in
Sema::CheckPlaceholderExpr, which isn't the job of CheckPlaceholderExpr.
So, when we saw typeof(OverloadedFunctionName), where
OverloadedFunctionName referenced a name with only one function that
could have its address taken, we'd give back a function pointer type
instead of a function type. This is incorrect.
I kept the logic for doing the function pointer conversion in
resolveAndFixAddressOfOnlyViableOverloadCandidate because it was more
consistent with existing ResolveAndFix* methods.
llvm-svn: 302506
In C typos in arguments in a call of an overloadable function lead
to a failure of construction of CallExpr and following recovery does
not handle created delayed typos. This causes an assertion fail in
Sema::~Sema since Sema::DelayedTypos remains not empty.
The patch fixes that behavior by handling a call with arguments
having dependant types in the way that C++ does.
Differential Revision: https://reviews.llvm.org/D31764
Patch by Dmitry Borisenkov!
llvm-svn: 302435
Summary:
When the function is compiled with soft-float or on CPU with no FPU, we
don't need to diagnose for a call from an ISR to a regular function.
Reviewers: jroelofs, eli.friedman
Reviewed By: jroelofs
Subscribers: aemerson, rengolin, javed.absar, cfe-commits
Differential Revision: https://reviews.llvm.org/D32918
llvm-svn: 302274
This patch adds a fix-it for the -Wunguarded-availability warning. This fix-it
is similar to the Swift one: it suggests that you wrap the statement in an
`if (@available)` check. The produced fixits are indented (just like the Swift
ones) to make them look nice in Xcode's fix-it preview.
rdar://31680358
Differential Revision: https://reviews.llvm.org/D32424
llvm-svn: 302253
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
The fix is that ExprEvaluatorBase::VisitInitListExpr should handle transparent exprs instead of exprs with one element. Fixing that uncovers one testcase failure because the AST for "constexpr _Complex float test2 = {1};" is wrong (the _Complex prvalue should not be const-qualified), and a number of test failures in test/OpenMP where the captured stmt contains an InitListExpr that is in syntactic form.
llvm-svn: 301891
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
function/block pointer properties
The commit r300981 allowed @param/@return commands for function/block
pointer property declarations. This meant that -Wdocumentation started warning
about @return that was used to document properties whose function/block type
returned void. However, prior to that commit, we allowed @return for all
property declarations, because it can be used to document the value that's
returned by the property getter. This commit restores the previous behaviour:
now the @return command can be used to document all properties without warnings.
rdar://24978538
llvm-svn: 301402
loc
Prior to this commit -Wdocumentation crashed when checking the @returns command
for declarations whose function/block pointer type included an attribute like
_Nullable.
rdar://31818195
llvm-svn: 301400
that have a function/block pointer type
This commit improves the -Wdocumentation warning by making sure that @param and
@returns commands won't trigger warnings when used for fields, variables,
or properties whose type is a function/block pointer type. The
function/block pointer type must be specified directly with the declaration,
and when a typedef is used the warning is still emitted.
In the future we might also want to handle the std::function type as well.
rdar://24978538
llvm-svn: 300981
Summary:
Libc++ currently implements the `ATOMIC_<TYPE>_LOCK_FREE` macros using the `__GCC_ATOMIC_<TYPE>_LOCK_FREE` macros. However these are not available when MSVC compatibility is enabled even though C11 `_Atomic` is. This prevents libc++ from correctly implementing `ATOMIC_<TYPE>_LOCK_FREE`.
This patch adds an alternative spelling `__CLANG_ATOMIC_<TYPE>_LOCK_FREE` that is enabled with `-fms-compatibility`.
Reviewers: rsmith, aaron.ballman, majnemer, zturner, compnerd, jfb, rnk
Reviewed By: rsmith
Subscribers: BillyONeal, smeenai, jfb, cfe-commits, dschuff
Differential Revision: https://reviews.llvm.org/D32265
llvm-svn: 300914
Prior to this commit the external_source_symbol attribute wasn't supported by
#pragma clang attribute for the following two reasons:
- The Named attribute subject hasn't been supported by TableGen.
- There was no way to specify a subject match rule for #pragma clang attribute
that could operate on a set of attribute subjects (e.g. the ones that derive
from NamedDecl).
This commit fixes the two issues and thus adds external_source_symbol support to
#pragma clang attribute.
rdar://31169028
Differential Revision: https://reviews.llvm.org/D32176
llvm-svn: 300712
This is a recommit of r300539 that was reverted in r300543 due to test failures.
The original commit message is displayed below:
The new '#pragma clang attribute' directive can be used to apply attributes to
multiple declarations. An attribute must satisfy the following conditions to
be supported by the pragma:
- It must have a subject list that's defined in the TableGen file.
- It must be documented.
- It must not be late parsed.
- It must have a GNU/C++11 spelling.
Differential Revision: https://reviews.llvm.org/D30009
llvm-svn: 300556
The new '#pragma clang attribute' directive can be used to apply attributes to
multiple declarations. An attribute must satisfy the following conditions to
be supported by the pragma:
- It must have a subject list that's defined in the TableGen file.
- It must be documented.
- It must not be late parsed.
- It must have a GNU/C++11 spelling.
Differential Revision: https://reviews.llvm.org/D30009
llvm-svn: 300539
For OpenCL, the private address space qualifier is 0 in AST. Before this change, 0 address space qualifier
is always mapped to target address space 0. As now target private address space is specified by
alloca address space in data layout, address space qualifier 0 needs to be mapped to alloca addr space specified by the data layout.
This change has no impact on targets whose alloca addr space is 0.
With contributions from Matt Arsenault, Tony Tye and Wen-Heng (Jack) Chung
Differential Revision: https://reviews.llvm.org/D31404
llvm-svn: 299965
Akira Hatanaka