Summary:
Previously Clang incorrectly ignored the expression of a void `co_return`. This patch addresses that bug.
I'm not quite sure if I got the code-gen right, but this patch is at least a start.
Reviewers: rsmith, GorNishanov
Reviewed By: rsmith, GorNishanov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D36070
llvm-svn: 309545
Summary:
Previously Clang was not considering operator declarations that occur at function scope. This is incorrect according to [over.match.oper]p3
> The set of non-member candidates is the result of the unqualified lookup of operator@ in the context of the expression according to the usual rules for name lookup in unqualified function calls.
This patch changes operator name lookup to consider block scope declarations.
This patch fixes PR27027.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D35297
llvm-svn: 309530
MS ignores the keyword "short" when used after a jc/jz instruction, LLVM ought to do the same.
llvm: D35892
Differential Revision: https://reviews.llvm.org/D35893
llvm-svn: 309510
Allows the incorporation of legit (x86) Control Regs within inline asm stataements
Differential Revision: https://reviews.llvm.org/D35903
llvm-svn: 309508
This led to crashes as the line number cache would report a bogus line number
for a line of code, and we'd try to find a nonexistent column within the line
when printing diagnostics.
llvm-svn: 309503
Clang specifies a max type alignment of 16 bytes on darwin targets (annoyingly in the driver not via cc1), meaning that the builtin nontemporal stores don't correctly align the loads/stores to 32 or 64 bytes when required, resulting in lowering to temporal unaligned loads/stores.
This patch casts the vectors to explicitly aligned types prior to the load/store to ensure that the require alignment is respected.
Differential Revision: https://reviews.llvm.org/D35996
llvm-svn: 309488
On some targets, passing zero to the clz() or ctz() builtins has undefined
behavior. I ran into this issue while debugging UB in __hash_table from libcxx:
the bug I was seeing manifested itself differently under -O0 vs -Os, due to a
UB call to clz() (see: libcxx/r304617).
This patch introduces a check which can detect UB calls to builtins.
llvm.org/PR26979
Differential Revision: https://reviews.llvm.org/D34590
llvm-svn: 309459
Summary: Thoes files are used to build Android toolchain. D32816 makes it possible to build runtimes for targets.
Reviewers: beanz, srhines
Reviewed By: srhines
Subscribers: pirama, jroelofs, srhines, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33561
llvm-svn: 309407
By creating this target other projects that depend on clang-generated headers (like LLDB) will no longer be order-dependent on Clang being processed by CMake first.
Also, by creating a dummy of this target in ClangConfig.cmake, projects that can build against out-of-tree clang can freely depend on the target without needing to have conditionals for if clang is in-tree or out-of-tree.
llvm-svn: 309390
'#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
Clang specifies a max type alignment of 16 bytes on darwin targets, meaning that the builtin nontemporal stores don't correctly align the loads/stores to 32 or 64 bytes when required, resulting in lowering to temporal unaligned loads/stores.
llvm-svn: 309382
Summary:
Allow merging short case labels when they actually end with a comment
(like a comment after the ``break``) and when followed by switch-level
comments (e.g. aligned with next case):
switch(a) {
case 0: break; // comment at end of case
case 1: return value;
// comment related to next case
// comment related to next case
case 2:
}
Reviewers: krasimir, djasper
Reviewed By: krasimir
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D35557
llvm-svn: 309370
Summary:
The current code would return an incorrect value when a preprocessor
directive is present immediately after the opening brace: this causes
the nanespace end comment fixer to break in some places, for exemple it
would not add the comment in this case:
namespace a {
#define FOO
}
Fixing the computation is simple enough, but it was breaking a feature,
as it would cause comments to be added also when the namespace
declaration was dependant on conditional compilation.
To fix this, a hash of the current preprocessor stack/branches is
computed at the beginning of parseBlock(), so that we explicitely do not
store the OpeningLineIndex when the beginning and end of the block are
not in the same preprocessor conditions.
Tthe hash is computed based on the line, but this could propbably be
improved by using the actual condition, so that clang-format would be
able to match multiple identical #ifdef blocks.
Reviewers: krasimir, djasper
Reviewed By: krasimir
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D35483
llvm-svn: 309369
The EHABI definition was being inlined into the users even when EHABI
was not in use. Adjust the condition to ensure that the right version
is defined.
llvm-svn: 309327
This tests the ARM64 specific constants added in SVN r309081,
similar to the one added in r277928 for armintr.h.
Differential Revision: https://reviews.llvm.org/D35934
llvm-svn: 309314
r303175 made changes to have __cxa_allocate_exception return a 16-byte
aligned pointer, so it's no longer necessary to specify a lower
alignment (8-bytes) for exception objects on Darwin.
rdar://problem/32363695
llvm-svn: 309308
When an omp for loop is canceled the constructed objects are being destructed
twice.
It looks like the desired code is:
{
Obj o;
If (cancelled) branch-through-cleanups to cancel.exit.
}
[cleanups]
cancel.exit:
__kmpc_for_static_fini
br cancel.cont (*)
cancel.cont:
__kmpc_barrier
return
The problem seems to be the branch to cancel.cont is currently also going
through the cleanups calling them again. This change just does a direct branch
instead.
Patch By: michael.p.rice@intel.com
Differential Revision: https://reviews.llvm.org/D35854
llvm-svn: 309288
Summary: The new PM needs to invoke add-discriminator pass when building with -fdebug-info-for-profiling.
Reviewers: chandlerc, davidxl
Reviewed By: chandlerc
Subscribers: sanjoy, cfe-commits
Differential Revision: https://reviews.llvm.org/D35746
llvm-svn: 309282
The ARM Runtime ABI document (IHI0043) defines the AEABI floating point
helper functions in 4.1.2 The floating-point helper functions. These
functions always use the base PCS (soft-fp). However helper functions
defined outside of this document such as the complex-number multiply and
divide helpers are not covered by this requirement and should use
hard-float PCS if the target is hard-float as both compiler-rt and libgcc
for a hard-float sysroot implement these functions with a hard-float PCS.
All of the floating point helper functions that are explicitly soft float
are expanded in the llvm ARM backend. This change makes clang not force the
BuiltinCC to AAPCS for AAPCS_VFP. With this change the ARM compiler-rt
tests involving _Complex pass with both hard-fp and soft-fp targets.
Differential Revision: https://reviews.llvm.org/D35538
llvm-svn: 309257
This just adds the CPU to a list of commands passed to GAS when not using the
integrated assembler.
Differential Revision: https://reviews.llvm.org/D33820
llvm-svn: 309256
Ensure that we define the `_Unwind_Control_Block` structure used on ARM
EHABI targets. This is needed for building libc++abi with the unwind.h
from the resource dir. A minor fallout of this is that we needed to
create a typedef for _Unwind_Exception to work across ARM EHABI and
non-EHABI targets. The structure definitions here are based originally
on the documentation from ARM under the "Exception Handling ABI for the
ARM® Architecture" Section 7.2. They are then adjusted to more closely
reflect the definition in libunwind from LLVM. Those changes are
compatible in layout but permit easier use in libc++abi and help
maintain compatibility between libunwind and the compiler provided
definition.
llvm-svn: 309226
The initializer for a static local variable cannot be hot, because it runs at
most once per program. That's not quite the same thing as having a low branch
probability, but under the assumption that the function is invoked many times,
modeling this as a branch probability seems reasonable.
For TLS variables, the situation is less clear, since the initialization side
of the branch can run multiple times in a program execution, but we still
expect initialization to be rare relative to non-initialization uses. It would
seem worthwhile to add a PGO counter along this path to make this estimation
more accurate in future.
For globals with guarded initialization, we don't yet apply any branch weights.
Due to our use of COMDATs, the guard will be reached exactly once per DSO, but
we have no idea how many DSOs will define the variable.
llvm-svn: 309195
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
Eric Liu