Skip to content

[driver] merge clang driver changes to master branch #2

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 384 commits into from
Feb 1, 2018
Merged

[driver] merge clang driver changes to master branch #2

merged 384 commits into from
Feb 1, 2018

Conversation

schweitzpgi
Copy link

includes a large number of changes from llvmmirror to clang (moves closer to tip)

petrhosek and others added 30 commits January 11, 2018 06:42
@petrhosek
Reland "[Driver] Update default sanitizer blacklist location"
bd990c3 
This is related to moving the sanitizer blacklists to share/
subdirectory.

Differential Revision: https://reviews.llvm.org/D41706

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322258 91177308-0d34-0410-b5e6-96231b3b80d8
@petrhosek
Revert "[Driver] Update default sanitizer blacklist location"
43db181 
This reverts commit r322258: broke the dfsan build.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322260 91177308-0d34-0410-b5e6-96231b3b80d8
@labath
[Lex] Use WritableMemoryBuffer in ScratchBuffer.cpp
998ea35 
This avoids the need to const_cast the buffer contents to write to it.

NFCI.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322268 91177308-0d34-0410-b5e6-96231b3b80d8
@asb
[RISCV] Add the RISCV target and compiler driver
febf5cb 
As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver 
support (RV64 to follow).

Differential Revision: https://reviews.llvm.org/D39963


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322276 91177308-0d34-0410-b5e6-96231b3b80d8
@asb
[Driver][RISCV] Fix r322276 by adding missing dummy crtbegin.o files …
fa79ef6 
…to test input

The dummy crtbegin.o files were left out in r322276 (as they were ignored by 
svn add of test/Driver/Inputs/multilib_riscv_linux_sdk) and are necessary for 
the driver test to work.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322277 91177308-0d34-0410-b5e6-96231b3b80d8
@svenvh
[OpenCL] Reorder the CLK_sRGBx/sRGBA defines, NFC
a28cfce 
Swap them so that all channel order defines are ordered according to
their values.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322278 91177308-0d34-0410-b5e6-96231b3b80d8
@asb
[Driver][RISCV] Fix r322276 for Windows (path separator issue)
f92bbd5 
We were seeing test failures of riscv32-toolchain.c on windows due to the \ 
path separator being used for the linker. Add {{/|\\\\}} pattern (made 
horrible due to escaping), just like introduced in r214931.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322286 91177308-0d34-0410-b5e6-96231b3b80d8
@asb
[Driver][RISCV] Another Windows file separator fix for riscv32-toolch…
f0382ad 
…ain.c test

I've checking the failure log, this _should_ be the last one. Sorry for not 
spotting this additional case first time round.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322294 91177308-0d34-0410-b5e6-96231b3b80d8
@zygoloid
Handle scoped_lockable objects being returned by value in C++17.
568cb88 
In C++17, guaranteed copy elision means that there isn't necessarily a
constructor call when a local variable is initialized by a function call that
returns a scoped_lockable by value. In order to model the effects of
initializing a local variable with a function call returning a scoped_lockable,
pretend that the move constructor was invoked within the caller at the point of
return.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322316 91177308-0d34-0410-b5e6-96231b3b80d8
@espindola
Make internal/private GVs implicitly dso_local.
ffd83ec 
While updating clang tests for having clang set dso_local I noticed
that:

- There are *a lot* of tests to update.
- Many of the updates are redundant.

They are redundant because a GV is "obviously dso_local". This patch
starts formalizing that a bit by requiring that internal and private
GVs be dso_local too. Since they all are, we don't have to print
dso_local to the textual representation, making it a bit more compact
and easier to read.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322318 91177308-0d34-0410-b5e6-96231b3b80d8
@sbc100
[WebAssembly] Remove -allow-undefined-file wasm.syms from linker args
0420193 
See: WebAssembly/tool-conventions#35

Differential Revision: https://reviews.llvm.org/D41923

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322321 91177308-0d34-0410-b5e6-96231b3b80d8
@EricWF
Add __reference_binds_to_temporary trait for checking safe referenc…
902a1d1 
…e initialization.

Summary:
The STL types `std::pair` and `std::tuple` can both store reference types. However their constructors cannot adequately check if the initialization of reference types is safe.  For example:

```
std::tuple<std::tuple<int> const&> t = 42;
// The stored reference is already dangling.
```

Libc++ has a best effort attempts in tuple to diagnose this, but they're not able to handle all valid cases (If I'm not mistaken). For example initialization of a reference from the result of a class's conversion operator.  Libc++ would benefit from having a builtin traits which can provide a much better implementation.

This patch introduce the `__reference_binds_to_temporary(T, U)` trait  that determines whether a reference of type `T` bound to an expression of type `U` would bind to a materialized temporary object.

Note that the trait simply returns false if `T` is not a reference type instead of reporting it as an error.

```
static_assert(__is_constructible(int const&, long));
static_assert(__reference_binds_to_temporary(int const&, long));
```


Reviewers: majnemer, rsmith

Reviewed By: rsmith

Subscribers: compnerd, cfe-commits

Differential Revision: https://reviews.llvm.org/D29930

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322334 91177308-0d34-0410-b5e6-96231b3b80d8
@topperc
[Docs] Fix typo in toolchain documentation
b4b2f3a 
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322347 91177308-0d34-0410-b5e6-96231b3b80d8
@Weverything
[ODRHash] Don't hash friend functions.
780143b 
In certain combinations of templated classes and friend functions, the body
of friend functions does not get propagated along with function signature.
Exclude friend functions for hashing to avoid this case.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322350 91177308-0d34-0410-b5e6-96231b3b80d8
@sam-mccall
[CodeComplete] Add an option to omit results from the preamble.
3ee4cc4 
Summary:
Enumerating the contents of a namespace or global scope will omit any
decls that aren't already loaded, instead of deserializing them from the
PCH.

This allows a fast hybrid code completion where symbols from headers are
provided by an external index. (Sema already exposes the information
needed to do a reasonabl job of filtering them).
Clangd plans to implement this hybrid.

This option is just a hint - callers still need to postfilter results if
they want to *avoid* completing decls outside the main file.

Reviewers: bkramer, ilya-biryukov

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D41989

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322371 91177308-0d34-0410-b5e6-96231b3b80d8
@sbc100
[WebAssembly] Support -stdlib=libc++ switch
ad3d09b 
Referenced implementation from Fuchsia and Darwin Toolchain.
Still only support CST_Libcxx.  Now checks that the argument
is really '-stdlib=libc++', and display error.

Also, now will pass -lc++ and -lc++abi to the linker.

Patch by Patrick Cheng!

Differential Revision: https://reviews.llvm.org/D41937

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322382 91177308-0d34-0410-b5e6-96231b3b80d8
@vsapsai
[Lex] Avoid out-of-bounds dereference in LexAngledStringLiteral.
95cd7fb 
Fix makes the loop in LexAngledStringLiteral more like the loops in
LexStringLiteral, LexCharConstant. When we skip a character after
backslash, we need to check if we reached the end of the file instead of
reading the next character unconditionally.

Discovered by OSS-Fuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3832

rdar://problem/35572754

Reviewers: arphaman, kcc, rsmith, dexonsmith

Reviewed By: rsmith, dexonsmith

Subscribers: cfe-commits, rsmith, dexonsmith

Differential Revision: https://reviews.llvm.org/D41423


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322390 91177308-0d34-0410-b5e6-96231b3b80d8
@alexey-bataev
[OPENMP] Replace calls of getAssociatedStmt().
a65cfe0 
getAssociatedStmt() returns the outermost captured statement for the
OpenMP directive. It may return incorrect region in case of combined
constructs. Reworked the code to reduce the number of calls of
getAssociatedStmt() and used getInnermostCapturedStmt() and
getCapturedStmt() functions instead.
In case of firstprivate variables it may lead to an extra allocas
generation for private copies even if the variable is passed by value
into outlined function and could be used directly as private copy.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322393 91177308-0d34-0410-b5e6-96231b3b80d8
@asb
Refactor handling of signext/zeroext in ABIArgInfo
1a586d3 
As @rjmccall suggested in D40023, we can get rid of 
ABIInfo::shouldSignExtUnsignedType (used to handle cases like the Mips calling 
convention where 32-bit integers are always sign extended regardless of the 
sign of the type) by adding a SignExt field to ABIArgInfo. In the common case, 
this new field is set automatically by ABIArgInfo::getExtend based on the sign 
of the type. For targets that want greater control, they can use 
ABIArgInfo::getSignExtend or ABIArgInfo::getZeroExtend when necessary. This 
change also cleans up logic in CGCall.cpp.

There is no functional change intended in this patch, and all tests pass 
unchanged. As noted in D40023, Mips might want to sign-extend unsigned 32-bit 
integer return types. A future patch might modify 
MipsABIInfo::classifyReturnType to use MipsABIInfo::extendType.

Differential Revision: https://reviews.llvm.org/D41999


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322396 91177308-0d34-0410-b5e6-96231b3b80d8
@Weverything
Disable test for Windows to fix Windows buildbots.
6d538af 
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322405 91177308-0d34-0410-b5e6-96231b3b80d8
@rjmccall
Allocate and access NormalCleanupDest with the natural alignment of i32.
3fb45fc 
This alignment can be less than 4 on certain embedded targets, which may
not even be able to deal with 4-byte alignment on the stack.

Patch by Jacob Young!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322406 91177308-0d34-0410-b5e6-96231b3b80d8
@haoNoQ
[analyzer] Don't flag strcpy of string literals into sufficiently lar…
bdecb5f 
…ge buffers.

In the security package, we have a simple syntactic check that warns about
strcpy() being insecure, due to potential buffer overflows.

Suppress that check's warning in the trivial situation when the source is an
immediate null-terminated string literal and the target is an immediate
sufficiently large buffer.

Patch by András Leitereg!

Differential Revision: https://reviews.llvm.org/D41384


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322410 91177308-0d34-0410-b5e6-96231b3b80d8
@pogo59
[DWARFv5] Have -gdwarf-5 generate MD5 checksums
baf72be 
Differential Revision: https://reviews.llvm.org/D42011

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322413 91177308-0d34-0410-b5e6-96231b3b80d8
@zygoloid
When rebuilding an InitListExpr, don't give it a type.
124ae53 
InitListExprs without types (well, with type 'void') represent not-yet-analyzed
initializer lists; InitListExpr with types fool Sema into thinking they don't
need further analysis in some cases (particularly C++17 copy omission).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322414 91177308-0d34-0410-b5e6-96231b3b80d8
@dyung
Fix test on Windows that was added in r322382.
200c1f8 
The test was using "%clang++" which on Windows became "clang.exe++". Use %clangxx instead.

Reviewed by Paul Robinson



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322417 91177308-0d34-0410-b5e6-96231b3b80d8
@Weverything
Try to suppress Windows testing again.
dc9d0e2 
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322420 91177308-0d34-0410-b5e6-96231b3b80d8
@echristo
Remove unused addIfPresent function.
019ab6b 
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322427 91177308-0d34-0410-b5e6-96231b3b80d8
@zygoloid
DR126: partially implement the const-correct rules for exception hand…
a3e65d2 
…ler matching.

While here, fix up the myriad other ways in which Sema's two "can this handler
catch that exception?" implementations get things wrong and unify them.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322431 91177308-0d34-0410-b5e6-96231b3b80d8
@asb
Fix test/Driver/riscv32-toolchain.c for builds setting CLANG_DEFAULT_…
f5335dc 
…LINKER

Petr Hosek reported an external buildbot was failing on riscv32-toolchain.c, 
seemingly as it set CLANG_DEFAULT_LINKER to lld. Address this by explicitly 
setting -fuse-ld=ld in the tests.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322435 91177308-0d34-0410-b5e6-96231b3b80d8
@jkorous-apple
[Sema] Fix crash for type-dependent base classes
58416cd 
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322438 91177308-0d34-0410-b5e6-96231b3b80d8
George Karpenkov and others added 17 commits January 29, 2018 21:45
[analyzer] Use stable filenames in analyzer testing infrastructure
44c0f4c 
Makes finding the right file in test results easier.

Differential Revision: https://reviews.llvm.org/D42445

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@323697 91177308-0d34-0410-b5e6-96231b3b80d8
@EricWF
[coroutines] Fix application of NRVO to Coroutine "Gro" or return obj…
82aa86f 
…ect.

Summary:
Fix NRVO for Gro variable.

Previously, we only marked the GRO declaration as an NRVO variable
when its QualType and the function return's QualType matched exactly
(using operator==). However, this was incorrect for two reasons:

1. We were marking non-class types, such as ints, as being NRVO variables.

2. We failed to  handle cases where the canonical types were the same, but the actual `QualType` objects were different. For example, if  one was represented by a typedef. (Example: https://godbolt.org/g/3UFgsL)

This patch fixes these bugs by marking the Gro variable as supporting NRVO only
when `BuildReturnStmt` marks the Gro variable as a coroutine candidate.






Reviewers: rsmith, GorNishanov, nicholas

Reviewed By: GorNishanov

Subscribers: majnemer, cfe-commits

Differential Revision: https://reviews.llvm.org/D42343

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@323712 91177308-0d34-0410-b5e6-96231b3b80d8
@Artem-B
[CUDA] Added partial support for CUDA-9.1
ccacb5d 
Clang can use CUDA-9.1 now, though new APIs (are not implemented yet.

The major change is that headers in CUDA-9.1 went through substantial
changes that started in CUDA-9.0 which required substantial changes
in the cuda compatibility headers provided by clang.

There are two major issues:
* CUDA SDK no longer provides declarations for libdevice functions.
* A lot of device-side functions have become nvcc's builtins and
  CUDA headers no longer contain their implementations.

This patch changes the way CUDA headers are handled if we compile
with CUDA 9.x. Both 9.0 and 9.1 are affected.

* Clang provides its own declarations of libdevice functions.
* For CUDA-9.x clang now provides implementation of device-side
  'standard library' functions using libdevice.

This patch should not affect compilation with CUDA-8. There may be
some observable differences for CUDA-9.0, though they are not expected
to affect functionality.

Tested: CUDA test-suite tests for all supported combinations of:
        CUDA: 7.0,7.5,8.0,9.0,9.1
        GPU: sm_20, sm_35, sm_60, sm_70

Differential Revision: https://reviews.llvm.org/D42513

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@323713 91177308-0d34-0410-b5e6-96231b3b80d8
@EricWF
Revert "[coroutines] Fix application of NRVO to Coroutine "Gro" or re…
facfffc 
…turn object."

This reverts commit r323712. It's causing some test failures on certain machines.
Not sure why, will investigate.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@323717 91177308-0d34-0410-b5e6-96231b3b80d8
@ahatanaka
Revert "CodeGen: annotate ObjC ARC functions with ABI constraints"
6a5184a 
This reverts commit r294872.

Although this patch is correct, it caused the objc_autoreleaseRValue/objc_retainAutoreleasedReturnValue

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@323814 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] Extend SuppressInlineDefensiveChecksVisitor to all macros,…
ac466c9 
… including non-function-like ones

No reason to treat function-like macros differently here.

Tracked in rdar://29907377

Differential Revision: https://reviews.llvm.org/D42444

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@323827 91177308-0d34-0410-b5e6-96231b3b80d8
@hahnjo
[CUDA] Detect installation in PATH
c0ae038 
If the CUDA toolkit is not installed to its default locations
in /usr/local/cuda, the user is forced to specify --cuda-path.
This is tedious and the driver can be smarter if well-known tools
(like ptxas) can already be found in the PATH environment variable.

Add option --cuda-path-ignore-env if the user wants to ignore
set environment variables. Also use it in the tests to make sure
the driver always finds the same CUDA installation, regardless
of the user's environment.

Differential Revision: https://reviews.llvm.org/D42642

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@323848 91177308-0d34-0410-b5e6-96231b3b80d8
@krasimirgg
[clang-format] Adds space around braces in text protos
e400706 
Summary:
This patch modifies the text proto Google style to add spaces around braces.

I investigated using something different than Cpp11BracedListStyle, but it turns out it's what we want and also the java and js styles also depend on that.

Reviewers: djasper

Reviewed By: djasper

Subscribers: klimek, cfe-commits

Differential Revision: https://reviews.llvm.org/D42685

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@323860 91177308-0d34-0410-b5e6-96231b3b80d8
@jroelofs
Fix typo. NFC
02e8730 
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@323864 91177308-0d34-0410-b5e6-96231b3b80d8
@dfukalov
[AMDGPU] Add ds_fadd, ds_fmin, ds_fmax builtins functions
251524e 
Reviewed by arsenm

Differential Revision: https://reviews.llvm.org/D42578

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@323890 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "Revert rC322769: [RISCV] Propagate -mabi and -march values to…
717663c 
… GNU assembler."

Summary: Bringing back the code change and simplified test cases to test 32/64 bit targets.

Reviewers: asb, yroux, inouehrs, mgrang

Reviewed By: yroux, inouehrs

Subscribers: cfe-commits, rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal, niosHD

Differential Revision: https://reviews.llvm.org/D42666

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@323894 91177308-0d34-0410-b5e6-96231b3b80d8
@dfukalov
Revert "[AMDGPU] Add ds_fadd, ds_fmin, ds_fmax builtins functions"
8605c2b 
This reverts https://reviews.llvm.org/rL323890

This reverts commit 251524e.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@323896 91177308-0d34-0410-b5e6-96231b3b80d8
@sbc100
[WebAssembly] Don't pass -ffunction-section/-fdata-sections
317550f 
llvm currently forces both of these to true to passing them
is redundant.

Differential Revision: https://reviews.llvm.org/D37831

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@323897 91177308-0d34-0410-b5e6-96231b3b80d8
@echristo
Clarify that optimization levels -O2 and above are recommended for us…
15c4170 
…e of PGO.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@323902 91177308-0d34-0410-b5e6-96231b3b80d8
@mzeren-vmw
[clang-format] Align preprocessor comments with #
5762b18 
Summary:
r312125, which introduced preprocessor indentation, shipped with a known
issue where "indentation of comments immediately before indented
preprocessor lines is toggled on each run". For example these two forms
toggle:

  #ifndef HEADER_H
  #define HEADER_H
  #if 1
  // comment
  #   define A 0
  #endif
  #endif

  #ifndef HEADER_H
  #define HEADER_H
  #if 1
     // comment
  #   define A 0
  #endif
  #endif

This happens because we check vertical alignment against the '#' yet
indent to the level of the 'define'. This patch resolves this issue by
aligning against the '#'.

Reviewers: krasimir, klimek, djasper

Reviewed By: krasimir

Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42408

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@323904 91177308-0d34-0410-b5e6-96231b3b80d8
@hyp
[PR32482] Fix bitfield layout for -mms-bitfield and pragma pack
253065e 
The patch ensures that a new storage unit is created when the new bitfield's
size is wider than the available bits.

rdar://36343145

Differential Revision: https://reviews.llvm.org/D42660


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@323921 91177308-0d34-0410-b5e6-96231b3b80d8
@schweitzpgi
Merge branch 'master' of github.com:llvm-mirror/clang
1aa077b
@sscalpone sscalpone merged commit c5995a2 into flang-compiler:master Feb 1, 2018
schweitzpgi pushed a commit to schweitzpgi/obsolete-flang-driver that referenced this pull request Feb 14, 2018
@zmodem
Merging r323155:
9c57ee8 
------------------------------------------------------------------------
r323155 | chandlerc | 2018-01-22 23:05:25 +0100 (Mon, 22 Jan 2018) | 133 lines

Introduce the "retpoline" x86 mitigation technique for variant flang-compiler#2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre..

Summary:
First, we need to explain the core of the vulnerability. Note that this
is a very incomplete description, please see the Project Zero blog post
for details:
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html

The basis for branch target injection is to direct speculative execution
of the processor to some "gadget" of executable code by poisoning the
prediction of indirect branches with the address of that gadget. The
gadget in turn contains an operation that provides a side channel for
reading data. Most commonly, this will look like a load of secret data
followed by a branch on the loaded value and then a load of some
predictable cache line. The attacker then uses timing of the processors
cache to determine which direction the branch took *in the speculative
execution*, and in turn what one bit of the loaded value was. Due to the
nature of these timing side channels and the branch predictor on Intel
processors, this allows an attacker to leak data only accessible to
a privileged domain (like the kernel) back into an unprivileged domain.

The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In many
cases, the compiler can simply use directed conditional branches and
a small search tree. LLVM already has support for lowering switches in
this way and the first step of this patch is to disable jump-table
lowering of switches and introduce a pass to rewrite explicit indirectbr
sequences into a switch over integers.

However, there is no fully general alternative to indirect calls. We
introduce a new construct we call a "retpoline" to implement indirect
calls in a non-speculatable way. It can be thought of loosely as
a trampoline for indirect calls which uses the RET instruction on x86.
Further, we arrange for a specific call->ret sequence which ensures the
processor predicts the return to go to a controlled, known location. The
retpoline then "smashes" the return address pushed onto the stack by the
call with the desired target of the original indirect call. The result
is a predicted return to the next instruction after a call (which can be
used to trap speculative execution within an infinite loop) and an
actual indirect branch to an arbitrary address.

On 64-bit x86 ABIs, this is especially easily done in the compiler by
using a guaranteed scratch register to pass the target into this device.
For 32-bit ABIs there isn't a guaranteed scratch register and so several
different retpoline variants are introduced to use a scratch register if
one is available in the calling convention and to otherwise use direct
stack push/pop sequences to pass the target address.

This "retpoline" mitigation is fully described in the following blog
post: https://support.google.com/faqs/answer/7625886

We also support a target feature that disables emission of the retpoline
thunk by the compiler to allow for custom thunks if users want them.
These are particularly useful in environments like kernels that
routinely do hot-patching on boot and want to hot-patch their thunk to
different code sequences. They can write this custom thunk and use
`-mretpoline-external-thunk` *in addition* to `-mretpoline`. In this
case, on x86-64 thu thunk names must be:
```
  __llvm_external_retpoline_r11
```
or on 32-bit:
```
  __llvm_external_retpoline_eax
  __llvm_external_retpoline_ecx
  __llvm_external_retpoline_edx
  __llvm_external_retpoline_push
```
And the target of the retpoline is passed in the named register, or in
the case of the `push` suffix on the top of the stack via a `pushl`
instruction.

There is one other important source of indirect branches in x86 ELF
binaries: the PLT. These patches also include support for LLD to
generate PLT entries that perform a retpoline-style indirection.

The only other indirect branches remaining that we are aware of are from
precompiled runtimes (such as crt0.o and similar). The ones we have
found are not really attackable, and so we have not focused on them
here, but eventually these runtimes should also be replicated for
retpoline-ed configurations for completeness.

For kernels or other freestanding or fully static executables, the
compiler switch `-mretpoline` is sufficient to fully mitigate this
particular attack. For dynamic executables, you must compile *all*
libraries with `-mretpoline` and additionally link the dynamic
executable and all shared libraries with LLD and pass `-z retpolineplt`
(or use similar functionality from some other linker). We strongly
recommend also using `-z now` as non-lazy binding allows the
retpoline-mitigated PLT to be substantially smaller.

When manually apply similar transformations to `-mretpoline` to the
Linux kernel we observed very small performance hits to applications
running typical workloads, and relatively minor hits (approximately 2%)
even for extremely syscall-heavy applications. This is largely due to
the small number of indirect branches that occur in performance
sensitive paths of the kernel.

When using these patches on statically linked applications, especially
C++ applications, you should expect to see a much more dramatic
performance hit. For microbenchmarks that are switch, indirect-, or
virtual-call heavy we have seen overheads ranging from 10% to 50%.

However, real-world workloads exhibit substantially lower performance
impact. Notably, techniques such as PGO and ThinLTO dramatically reduce
the impact of hot indirect calls (by speculatively promoting them to
direct calls) and allow optimized search trees to be used to lower
switches. If you need to deploy these techniques in C++ applications, we
*strongly* recommend that you ensure all hot call targets are statically
linked (avoiding PLT indirection) and use both PGO and ThinLTO. Well
tuned servers using all of these techniques saw 5% - 10% overhead from
the use of retpoline.

We will add detailed documentation covering these components in
subsequent patches, but wanted to make the core functionality available
as soon as possible. Happy for more code review, but we'd really like to
get these patches landed and backported ASAP for obvious reasons. We're
planning to backport this to both 6.0 and 5.0 release streams and get
a 5.0 release with just this cherry picked ASAP for distros and vendors.

This patch is the work of a number of people over the past month: Eric, Reid,
Rui, and myself. I'm mailing it out as a single commit due to the time
sensitive nature of landing this and the need to backport it. Huge thanks to
everyone who helped out here, and everyone at Intel who helped out in
discussions about how to craft this. Also, credit goes to Paul Turner (at
Google, but not an LLVM contributor) for much of the underlying retpoline
design.

Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer

Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits

Differential Revision: https://reviews.llvm.org/D41723
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_60@324068 91177308-0d34-0410-b5e6-96231b3b80d8
schweitzpgi pushed a commit to schweitzpgi/obsolete-flang-driver that referenced this pull request Feb 28, 2018
[analyzer] Logging test quickfix flang-compiler#2.
6d40150 
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@326229 91177308-0d34-0410-b5e6-96231b3b80d8
schweitzpgi pushed a commit to schweitzpgi/obsolete-flang-driver that referenced this pull request Mar 8, 2018
@rnk
Merging r323155:
334f080 
------------------------------------------------------------------------
r323155 | chandlerc | 2018-01-22 14:05:25 -0800 (Mon, 22 Jan 2018) | 133 lines

Introduce the "retpoline" x86 mitigation technique for variant flang-compiler#2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre..

Summary:
First, we need to explain the core of the vulnerability. Note that this
is a very incomplete description, please see the Project Zero blog post
for details:
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html

The basis for branch target injection is to direct speculative execution
of the processor to some "gadget" of executable code by poisoning the
prediction of indirect branches with the address of that gadget. The
gadget in turn contains an operation that provides a side channel for
reading data. Most commonly, this will look like a load of secret data
followed by a branch on the loaded value and then a load of some
predictable cache line. The attacker then uses timing of the processors
cache to determine which direction the branch took *in the speculative
execution*, and in turn what one bit of the loaded value was. Due to the
nature of these timing side channels and the branch predictor on Intel
processors, this allows an attacker to leak data only accessible to
a privileged domain (like the kernel) back into an unprivileged domain.

The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In many
cases, the compiler can simply use directed conditional branches and
a small search tree. LLVM already has support for lowering switches in
this way and the first step of this patch is to disable jump-table
lowering of switches and introduce a pass to rewrite explicit indirectbr
sequences into a switch over integers.

However, there is no fully general alternative to indirect calls. We
introduce a new construct we call a "retpoline" to implement indirect
calls in a non-speculatable way. It can be thought of loosely as
a trampoline for indirect calls which uses the RET instruction on x86.
Further, we arrange for a specific call->ret sequence which ensures the
processor predicts the return to go to a controlled, known location. The
retpoline then "smashes" the return address pushed onto the stack by the
call with the desired target of the original indirect call. The result
is a predicted return to the next instruction after a call (which can be
used to trap speculative execution within an infinite loop) and an
actual indirect branch to an arbitrary address.

On 64-bit x86 ABIs, this is especially easily done in the compiler by
using a guaranteed scratch register to pass the target into this device.
For 32-bit ABIs there isn't a guaranteed scratch register and so several
different retpoline variants are introduced to use a scratch register if
one is available in the calling convention and to otherwise use direct
stack push/pop sequences to pass the target address.

This "retpoline" mitigation is fully described in the following blog
post: https://support.google.com/faqs/answer/7625886

We also support a target feature that disables emission of the retpoline
thunk by the compiler to allow for custom thunks if users want them.
These are particularly useful in environments like kernels that
routinely do hot-patching on boot and want to hot-patch their thunk to
different code sequences. They can write this custom thunk and use
`-mretpoline-external-thunk` *in addition* to `-mretpoline`. In this
case, on x86-64 thu thunk names must be:
```
  __llvm_external_retpoline_r11
```
or on 32-bit:
```
  __llvm_external_retpoline_eax
  __llvm_external_retpoline_ecx
  __llvm_external_retpoline_edx
  __llvm_external_retpoline_push
```
And the target of the retpoline is passed in the named register, or in
the case of the `push` suffix on the top of the stack via a `pushl`
instruction.

There is one other important source of indirect branches in x86 ELF
binaries: the PLT. These patches also include support for LLD to
generate PLT entries that perform a retpoline-style indirection.

The only other indirect branches remaining that we are aware of are from
precompiled runtimes (such as crt0.o and similar). The ones we have
found are not really attackable, and so we have not focused on them
here, but eventually these runtimes should also be replicated for
retpoline-ed configurations for completeness.

For kernels or other freestanding or fully static executables, the
compiler switch `-mretpoline` is sufficient to fully mitigate this
particular attack. For dynamic executables, you must compile *all*
libraries with `-mretpoline` and additionally link the dynamic
executable and all shared libraries with LLD and pass `-z retpolineplt`
(or use similar functionality from some other linker). We strongly
recommend also using `-z now` as non-lazy binding allows the
retpoline-mitigated PLT to be substantially smaller.

When manually apply similar transformations to `-mretpoline` to the
Linux kernel we observed very small performance hits to applications
running typical workloads, and relatively minor hits (approximately 2%)
even for extremely syscall-heavy applications. This is largely due to
the small number of indirect branches that occur in performance
sensitive paths of the kernel.

When using these patches on statically linked applications, especially
C++ applications, you should expect to see a much more dramatic
performance hit. For microbenchmarks that are switch, indirect-, or
virtual-call heavy we have seen overheads ranging from 10% to 50%.

However, real-world workloads exhibit substantially lower performance
impact. Notably, techniques such as PGO and ThinLTO dramatically reduce
the impact of hot indirect calls (by speculatively promoting them to
direct calls) and allow optimized search trees to be used to lower
switches. If you need to deploy these techniques in C++ applications, we
*strongly* recommend that you ensure all hot call targets are statically
linked (avoiding PLT indirection) and use both PGO and ThinLTO. Well
tuned servers using all of these techniques saw 5% - 10% overhead from
the use of retpoline.

We will add detailed documentation covering these components in
subsequent patches, but wanted to make the core functionality available
as soon as possible. Happy for more code review, but we'd really like to
get these patches landed and backported ASAP for obvious reasons. We're
planning to backport this to both 6.0 and 5.0 release streams and get
a 5.0 release with just this cherry picked ASAP for distros and vendors.

This patch is the work of a number of people over the past month: Eric, Reid,
Rui, and myself. I'm mailing it out as a single commit due to the time
sensitive nature of landing this and the need to backport it. Huge thanks to
everyone who helped out here, and everyone at Intel who helped out in
discussions about how to craft this. Also, credit goes to Paul Turner (at
Google, but not an LLVM contributor) for much of the underlying retpoline
design.

Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer

Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits

Differential Revision: https://reviews.llvm.org/D41723
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_50@324012 91177308-0d34-0410-b5e6-96231b3b80d8
schweitzpgi pushed a commit to schweitzpgi/obsolete-flang-driver that referenced this pull request Aug 10, 2018
@jfbastien
Auto var init test fix flang-compiler#2
c629b8b 
It turns out that the AVX bots have different alignment for their vectors, and my test mistakenly assumed a particular vector alignent on the stack. Instead, capture the alignment and test for it in subsequent operations.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@339093 91177308-0d34-0410-b5e6-96231b3b80d8
schweitzpgi pushed a commit to schweitzpgi/obsolete-flang-driver that referenced this pull request Sep 7, 2018
[analyzer] [NFC] Split up RetainSummaryManager from RetainCountChecke…
3025b83 
…r - try flang-compiler#2

Turns out it can't be removed from the analyzer since it relies on CallEvent.

Moving to staticAnalyzer/core

Differential Revision: https://reviews.llvm.org/D51023

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@340247 91177308-0d34-0410-b5e6-96231b3b80d8
schweitzpgi pushed a commit to schweitzpgi/obsolete-flang-driver that referenced this pull request Dec 18, 2018
@LebedevRI
[clang][CodeGen] Implicit Conversion Sanitizer: discover the world of…
d8a18b8 
… CompoundAssign operators

Summary:
As reported by @regehr (thanks!) on twitter (https://twitter.com/johnregehr/status/1057681496255815686),
we (me) has completely forgot about the binary assignment operator.
In AST, it isn't represented as separate `ImplicitCastExpr`'s,
but as a single `CompoundAssignOperator`, that does all the casts internally.
Which means, out of these two, only the first one is diagnosed:
```
auto foo() {
    unsigned char c = 255;
    c = c + 1;
    return c;
}
auto bar() {
    unsigned char c = 255;
    c += 1;
    return c;
}
```
https://godbolt.org/z/JNyVc4

This patch does handle the `CompoundAssignOperator`:
```
int main() {
  unsigned char c = 255;
  c += 1;
  return c;
}
```
```
$ ./bin/clang -g -fsanitize=integer /tmp/test.c && ./a.out
/tmp/test.c:3:5: runtime error: implicit conversion from type 'int' of value 256 (32-bit, signed) to type 'unsigned char' changed the value to 0 (8-bit, unsigned)
    #0 0x2392b8 in main /tmp/test.c:3:5
    flang-compiler#1 0x7fec4a612b16 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x22b16)
    flang-compiler#2 0x214029 in _start (/build/llvm-build-GCC-release/a.out+0x214029)
```

However, the pre/post increment/decrement is still not handled.

Reviewers: rsmith, regehr, vsk, rjmccall, #sanitizers

Reviewed By: rjmccall

Subscribers: mclow.lists, cfe-commits, regehr

Tags: #clang, #sanitizers

Differential Revision: https://reviews.llvm.org/D53949

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@347258 91177308-0d34-0410-b5e6-96231b3b80d8
schweitzpgi pushed a commit to schweitzpgi/obsolete-flang-driver that referenced this pull request Mar 27, 2019
@hctim
Rollback of rL355585.
fbb9516 
Introduces memory leak in FunctionTest.GetPointerAlignment that breaks sanitizer buildbots:

```
=================================================================
==2453==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 128 byte(s) in 1 object(s) allocated from:
    #0 0x610428 in operator new(unsigned long) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:105
    flang-compiler#1 0x16936bc in llvm::User::operator new(unsigned long) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/lib/IR/User.cpp:151:19
    flang-compiler#2 0x7c3fe9 in Create /b/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/IR/Function.h:144:12
    flang-compiler#3 0x7c3fe9 in (anonymous namespace)::FunctionTest_GetPointerAlignment_Test::TestBody() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/unittests/IR/FunctionTest.cpp:136
    flang-compiler#4 0x1a836a0 in HandleExceptionsInMethodIfSupported<testing::Test, void> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc
    flang-compiler#5 0x1a836a0 in testing::Test::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2474
    flang-compiler#6 0x1a85c55 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11
    flang-compiler#7 0x1a870d0 in testing::TestCase::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28
    flang-compiler#8 0x1aa5b84 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43
    flang-compiler#9 0x1aa4d30 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc
    flang-compiler#10 0x1aa4d30 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4257
    flang-compiler#11 0x1a6b656 in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46
    flang-compiler#12 0x1a6b656 in main /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50
    flang-compiler#13 0x7f5af37a22e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)

Indirect leak of 40 byte(s) in 1 object(s) allocated from:
    #0 0x610428 in operator new(unsigned long) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:105
    flang-compiler#1 0x151be6b in make_unique<llvm::ValueSymbolTable> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/ADT/STLExtras.h:1349:29
    flang-compiler#2 0x151be6b in llvm::Function::Function(llvm::FunctionType*, llvm::GlobalValue::LinkageTypes, unsigned int, llvm::Twine const&, llvm::Module*) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/lib/IR/Function.cpp:241
    flang-compiler#3 0x7c4006 in Create /b/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/IR/Function.h:144:16
    flang-compiler#4 0x7c4006 in (anonymous namespace)::FunctionTest_GetPointerAlignment_Test::TestBody() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/unittests/IR/FunctionTest.cpp:136
    flang-compiler#5 0x1a836a0 in HandleExceptionsInMethodIfSupported<testing::Test, void> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc
    flang-compiler#6 0x1a836a0 in testing::Test::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2474
    flang-compiler#7 0x1a85c55 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11
    flang-compiler#8 0x1a870d0 in testing::TestCase::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28
    flang-compiler#9 0x1aa5b84 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43
    flang-compiler#10 0x1aa4d30 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc
    flang-compiler#11 0x1aa4d30 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4257
    flang-compiler#12 0x1a6b656 in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46
    flang-compiler#13 0x1a6b656 in main /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50
    flang-compiler#14 0x7f5af37a22e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)

SUMMARY: AddressSanitizer: 168 byte(s) leaked in 2 allocation(s).
```

See http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/11358/steps/check-llvm%20asan/logs/stdio for more information.

Also introduces use-of-uninitialized-value in ConstantsTest.FoldGlobalVariablePtr:
```
==7070==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x14e703c in User /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/User.h:79:5
    flang-compiler#1 0x14e703c in Constant /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/Constant.h:44
    flang-compiler#2 0x14e703c in llvm::GlobalValue::GlobalValue(llvm::Type*, llvm::Value::ValueTy, llvm::Use*, unsigned int, llvm::GlobalValue::LinkageTypes, llvm::Twine const&, unsigned int) /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/GlobalValue.h:78
    flang-compiler#3 0x14e5467 in GlobalObject /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/GlobalObject.h:34:9
    flang-compiler#4 0x14e5467 in llvm::GlobalVariable::GlobalVariable(llvm::Type*, bool, llvm::GlobalValue::LinkageTypes, llvm::Constant*, llvm::Twine const&, llvm::GlobalValue::ThreadLocalMode, unsigned int, bool) /b/sanitizer-x86_64-linux-fast/build/llvm/lib/IR/Globals.cpp:314
    flang-compiler#5 0x6938f1 in llvm::(anonymous namespace)::ConstantsTest_FoldGlobalVariablePtr_Test::TestBody() /b/sanitizer-x86_64-linux-fast/build/llvm/unittests/IR/ConstantsTest.cpp:565:18
    flang-compiler#6 0x1a240a1 in HandleExceptionsInMethodIfSupported<testing::Test, void> /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc
    flang-compiler#7 0x1a240a1 in testing::Test::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2474
    flang-compiler#8 0x1a26d26 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11
    flang-compiler#9 0x1a2815f in testing::TestCase::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28
    flang-compiler#10 0x1a43de8 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43
    flang-compiler#11 0x1a42c47 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc
    flang-compiler#12 0x1a42c47 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:4257
    flang-compiler#13 0x1a0dfba in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46
    flang-compiler#14 0x1a0dfba in main /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50
    flang-compiler#15 0x7f2081c412e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
    flang-compiler#16 0x4dff49 in _start (/b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/unittests/IR/IRTests+0x4dff49)

SUMMARY: MemorySanitizer: use-of-uninitialized-value /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/User.h:79:5 in User
```

See http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/30222/steps/check-llvm%20msan/logs/stdio for more information.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@355616 91177308-0d34-0410-b5e6-96231b3b80d8
schweitzpgi pushed a commit to schweitzpgi/obsolete-flang-driver that referenced this pull request Apr 22, 2019
@alexfh
Remove a useless assertion in clang-check.
18ac76c 
The assertion prevents it from applying fixes when used along with compilation
databases with relative paths. Added a test that demonstrates the assertion
failure.

An example of the assertion:
input.cpp:11:14: error: expected ';' after top level declarator
typedef int T
             ^
             ;
input.cpp:11:14: note: FIX-IT applied suggested code changes
clang-check: clang/tools/clang-check/ClangCheck.cpp:94: virtual std::string (anonymous namespace)::FixItOptions::RewriteFilename(const std::string &, int &): Assertion `llvm::sys::path::is_absolute(filename) && "clang-fixit expects absolute paths only."' failed.
  #0 llvm::sys::PrintStackTrace(llvm::raw_ostream&) llvm/lib/Support/Unix/Signals.inc:494:13
  flang-compiler#1 llvm::sys::RunSignalHandlers() llvm/lib/Support/Signals.cpp:69:18
  flang-compiler#2 SignalHandler(int) llvm/lib/Support/Unix/Signals.inc:357:1
  flang-compiler#3 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x110c0)
  flang-compiler#4 raise (/lib/x86_64-linux-gnu/libc.so.6+0x32fcf)
  flang-compiler#5 abort (/lib/x86_64-linux-gnu/libc.so.6+0x343fa)
  flang-compiler#6 (/lib/x86_64-linux-gnu/libc.so.6+0x2be37)
  flang-compiler#7 (/lib/x86_64-linux-gnu/libc.so.6+0x2bee2)
  flang-compiler#8 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag)
  flang-compiler#9 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char*>(char*, char*, std::__false_type)
 flang-compiler#10 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*)
 flang-compiler#11 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
 flang-compiler#12 (anonymous namespace)::FixItOptions::RewriteFilename(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int&) clang/tools/clang-check/ClangCheck.cpp:101:0
 flang-compiler#13 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_data() const
 flang-compiler#14 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_is_local() const
 flang-compiler#15 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose()
 flang-compiler#16 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
 flang-compiler#17 clang::FixItRewriter::WriteFixedFiles(std::vector<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >*) clang/lib/Frontend/Rewrite/FixItRewriter.cpp:98:0
 flang-compiler#18 std::__shared_ptr<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2>::get() const
 flang-compiler#19 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::_M_get() const
 flang-compiler#20 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::operator->() const
 flang-compiler#21 clang::CompilerInstance::getFrontendOpts() clang/include/clang/Frontend/CompilerInstance.h:290:0
 flang-compiler#22 clang::FrontendAction::EndSourceFile() clang/lib/Frontend/FrontendAction.cpp:966:0
 flang-compiler#23 __gnu_cxx::__normal_iterator<clang::FrontendInputFile*, std::vector<clang::FrontendInputFile, std::allocator<clang::FrontendInputFile> > >::operator++()
 flang-compiler#24 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) clang/lib/Frontend/CompilerInstance.cpp:943:0
 flang-compiler#25 clang::tooling::FrontendActionFactory::runInvocation(std::shared_ptr<clang::CompilerInvocation>, clang::FileManager*, std::shared_ptr<clang::PCHContainerOperations>, clang::DiagnosticConsumer*) clang/lib/Tooling/Tooling.cpp:369:33
 flang-compiler#26 clang::tooling::ToolInvocation::runInvocation(char const*, clang::driver::Compilation*, std::shared_ptr<clang::CompilerInvocation>, std::shared_ptr<clang::PCHContainerOperations>) clang/lib/Tooling/Tooling.cpp:344:18
 flang-compiler#27 clang::tooling::ToolInvocation::run() clang/lib/Tooling/Tooling.cpp:329:10
 flang-compiler#28 clang::tooling::ClangTool::run(clang::tooling::ToolAction*) clang/lib/Tooling/Tooling.cpp:518:11
 flang-compiler#29 main clang/tools/clang-check/ClangCheck.cpp:187:15

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@357915 91177308-0d34-0410-b5e6-96231b3b80d8
schweitzpgi pushed a commit to schweitzpgi/obsolete-flang-driver that referenced this pull request Apr 22, 2019
@RKSimon
Revert rL357915 from cfe/trunk: Remove a useless assertion in clang-c…
14e3e53 
…heck.

The assertion prevents it from applying fixes when used along with compilation
databases with relative paths. Added a test that demonstrates the assertion
failure.

An example of the assertion:
input.cpp:11:14: error: expected ';' after top level declarator
typedef int T
             ^
             ;
input.cpp:11:14: note: FIX-IT applied suggested code changes
clang-check: clang/tools/clang-check/ClangCheck.cpp:94: virtual std::string (anonymous namespace)::FixItOptions::RewriteFilename(const std::string &, int &): Assertion `llvm::sys::path::is_absolute(filename) && "clang-fixit expects absolute paths only."' failed.
  #0 llvm::sys::PrintStackTrace(llvm::raw_ostream&) llvm/lib/Support/Unix/Signals.inc:494:13
  flang-compiler#1 llvm::sys::RunSignalHandlers() llvm/lib/Support/Signals.cpp:69:18
  flang-compiler#2 SignalHandler(int) llvm/lib/Support/Unix/Signals.inc:357:1
  flang-compiler#3 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x110c0)
  flang-compiler#4 raise (/lib/x86_64-linux-gnu/libc.so.6+0x32fcf)
  flang-compiler#5 abort (/lib/x86_64-linux-gnu/libc.so.6+0x343fa)
  flang-compiler#6 (/lib/x86_64-linux-gnu/libc.so.6+0x2be37)
  flang-compiler#7 (/lib/x86_64-linux-gnu/libc.so.6+0x2bee2)
  flang-compiler#8 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag)
  flang-compiler#9 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char*>(char*, char*, std::__false_type)
 flang-compiler#10 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*)
 flang-compiler#11 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
 flang-compiler#12 (anonymous namespace)::FixItOptions::RewriteFilename(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int&) clang/tools/clang-check/ClangCheck.cpp:101:0
 flang-compiler#13 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_data() const
 flang-compiler#14 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_is_local() const
 flang-compiler#15 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose()
 flang-compiler#16 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
 flang-compiler#17 clang::FixItRewriter::WriteFixedFiles(std::vector<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >*) clang/lib/Frontend/Rewrite/FixItRewriter.cpp:98:0
 flang-compiler#18 std::__shared_ptr<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2>::get() const
 flang-compiler#19 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::_M_get() const
 flang-compiler#20 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::operator->() const
 flang-compiler#21 clang::CompilerInstance::getFrontendOpts() clang/include/clang/Frontend/CompilerInstance.h:290:0
 flang-compiler#22 clang::FrontendAction::EndSourceFile() clang/lib/Frontend/FrontendAction.cpp:966:0
 flang-compiler#23 __gnu_cxx::__normal_iterator<clang::FrontendInputFile*, std::vector<clang::FrontendInputFile, std::allocator<clang::FrontendInputFile> > >::operator++()
 flang-compiler#24 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) clang/lib/Frontend/CompilerInstance.cpp:943:0
 flang-compiler#25 clang::tooling::FrontendActionFactory::runInvocation(std::shared_ptr<clang::CompilerInvocation>, clang::FileManager*, std::shared_ptr<clang::PCHContainerOperations>, clang::DiagnosticConsumer*) clang/lib/Tooling/Tooling.cpp:369:33
 flang-compiler#26 clang::tooling::ToolInvocation::runInvocation(char const*, clang::driver::Compilation*, std::shared_ptr<clang::CompilerInvocation>, std::shared_ptr<clang::PCHContainerOperations>) clang/lib/Tooling/Tooling.cpp:344:18
 flang-compiler#27 clang::tooling::ToolInvocation::run() clang/lib/Tooling/Tooling.cpp:329:10
 flang-compiler#28 clang::tooling::ClangTool::run(clang::tooling::ToolAction*) clang/lib/Tooling/Tooling.cpp:518:11
 flang-compiler#29 main clang/tools/clang-check/ClangCheck.cpp:187:15
........
Breaks windows buildbots

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@357918 91177308-0d34-0410-b5e6-96231b3b80d8
schweitzpgi pushed a commit to schweitzpgi/obsolete-flang-driver that referenced this pull request Apr 22, 2019
@alexfh
Remove a useless assertion in clang-check.
f72b058 
Re-commit r357915 with a fix for windows.

The assertion prevents it from applying fixes when used along with compilation
databases with relative paths. Added a test that demonstrates the assertion
failure.

An example of the assertion:
input.cpp:11:14: error: expected ';' after top level declarator
typedef int T
             ^
             ;
input.cpp:11:14: note: FIX-IT applied suggested code changes
clang-check: clang/tools/clang-check/ClangCheck.cpp:94: virtual std::string (anonymous namespace)::FixItOptions::RewriteFilename(const std::string &, int &): Assertion `llvm::sys::path::is_absolute(filename) && "clang-fixit expects absolute paths only."' failed.
  #0 llvm::sys::PrintStackTrace(llvm::raw_ostream&) llvm/lib/Support/Unix/Signals.inc:494:13
  flang-compiler#1 llvm::sys::RunSignalHandlers() llvm/lib/Support/Signals.cpp:69:18
  flang-compiler#2 SignalHandler(int) llvm/lib/Support/Unix/Signals.inc:357:1
  flang-compiler#3 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x110c0)
  flang-compiler#4 raise (/lib/x86_64-linux-gnu/libc.so.6+0x32fcf)
  flang-compiler#5 abort (/lib/x86_64-linux-gnu/libc.so.6+0x343fa)
  flang-compiler#6 (/lib/x86_64-linux-gnu/libc.so.6+0x2be37)
  flang-compiler#7 (/lib/x86_64-linux-gnu/libc.so.6+0x2bee2)
  flang-compiler#8 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag)
  flang-compiler#9 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char*>(char*, char*, std::__false_type)
 flang-compiler#10 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*)
 flang-compiler#11 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
 flang-compiler#12 (anonymous namespace)::FixItOptions::RewriteFilename(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int&) clang/tools/clang-check/ClangCheck.cpp:101:0
 flang-compiler#13 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_data() const
 flang-compiler#14 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_is_local() const
 flang-compiler#15 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose()
 flang-compiler#16 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
 flang-compiler#17 clang::FixItRewriter::WriteFixedFiles(std::vector<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >*) clang/lib/Frontend/Rewrite/FixItRewriter.cpp:98:0
 flang-compiler#18 std::__shared_ptr<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2>::get() const
 flang-compiler#19 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::_M_get() const
 flang-compiler#20 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::operator->() const
 flang-compiler#21 clang::CompilerInstance::getFrontendOpts() clang/include/clang/Frontend/CompilerInstance.h:290:0
 flang-compiler#22 clang::FrontendAction::EndSourceFile() clang/lib/Frontend/FrontendAction.cpp:966:0
 flang-compiler#23 __gnu_cxx::__normal_iterator<clang::FrontendInputFile*, std::vector<clang::FrontendInputFile, std::allocator<clang::FrontendInputFile> > >::operator++()
 flang-compiler#24 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) clang/lib/Frontend/CompilerInstance.cpp:943:0
 flang-compiler#25 clang::tooling::FrontendActionFactory::runInvocation(std::shared_ptr<clang::CompilerInvocation>, clang::FileManager*, std::shared_ptr<clang::PCHContainerOperations>, clang::DiagnosticConsumer*) clang/lib/Tooling/Tooling.cpp:369:33
 flang-compiler#26 clang::tooling::ToolInvocation::runInvocation(char const*, clang::driver::Compilation*, std::shared_ptr<clang::CompilerInvocation>, std::shared_ptr<clang::PCHContainerOperations>) clang/lib/Tooling/Tooling.cpp:344:18
 flang-compiler#27 clang::tooling::ToolInvocation::run() clang/lib/Tooling/Tooling.cpp:329:10
 flang-compiler#28 clang::tooling::ClangTool::run(clang::tooling::ToolAction*) clang/lib/Tooling/Tooling.cpp:518:11
 flang-compiler#29 main clang/tools/clang-check/ClangCheck.cpp:187:15

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@357921 91177308-0d34-0410-b5e6-96231b3b80d8
schweitzpgi pushed a commit to schweitzpgi/obsolete-flang-driver that referenced this pull request May 13, 2019
@tstellar
lib/Header: Fix Visual Studio builds try flang-compiler#2
a0b7c9a 
Summary:
This is a follow up to r355253 and a better fix than the first attempt
which was r359257.

We can't install anything from ${CMAKE_CFG_INTDIR}, because this value
is only defined at build time, but we still must make sure to copy the
headers into ${CMAKE_CFG_INTDIR}/lib/clang/$VERSION/include, because the lit
tests look for headers there.  So for this fix we revert to the
old behavior of copying the headers to ${CMAKE_CFG_INTDIR}/lib/clang/$VERSION/include
during the build and then installing them from the source tree.

Reviewers: smeenai, vzakhari, phosek

Reviewed By: smeenai, vzakhari

Subscribers: mgorny, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D61220

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359654 91177308-0d34-0410-b5e6-96231b3b80d8
schweitzpgi pushed a commit to schweitzpgi/obsolete-flang-driver that referenced this pull request Aug 7, 2019
@Ralender
[clang] perform semantic checking in constant context
d999cf6 
Summary:
Since the addition of __builtin_is_constant_evaluated the result of an expression can change based on whether it is evaluated in constant context. a lot of semantic checking performs evaluations with out specifying context. which can lead to wrong diagnostics.
for example:
```
constexpr int i0 = (long long)__builtin_is_constant_evaluated() * (1ll << 33); //flang-compiler#1
constexpr int i1 = (long long)!__builtin_is_constant_evaluated() * (1ll << 33); //flang-compiler#2
```
before the patch, flang-compiler#2 was diagnosed incorrectly and flang-compiler#1 wasn't diagnosed.
after the patch flang-compiler#1 is diagnosed as it should and flang-compiler#2 isn't.

Changes:
 - add a flag to Sema to passe in constant context mode.
 - in SemaChecking.cpp calls to Expr::Evaluate* are now done in constant context when they should.
 - in SemaChecking.cpp diagnostics for UB are not checked for in constant context because an error will be emitted by the constant evaluator.
 - in SemaChecking.cpp diagnostics for construct that cannot appear in constant context are not checked for in constant context.
 - in SemaChecking.cpp diagnostics on constant expression are always emitted because constant expression are always evaluated.
 - semantic checking for initialization of constexpr variables is now done in constant context.
 - adapt test that were depending on warning changes.
 - add test.

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D62009

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@363488 91177308-0d34-0410-b5e6-96231b3b80d8
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.