History log of /llvm-project/clang/lib/Frontend/CompilerInvocation.cpp (Results 851 – 875 of 1971)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 7b274544 08-Aug-2018 Petr Hosek <phosek@chromium.org>

[ADT] Normalize empty triple components

LLVM triple normalization is handling "unknown" and empty components
differently; for example given "x86_64-unknown-linux-gnu" and
"x86_64-linux-gnu" which sh

[ADT] Normalize empty triple components

LLVM triple normalization is handling "unknown" and empty components
differently; for example given "x86_64-unknown-linux-gnu" and
"x86_64-linux-gnu" which should be equivalent, triple normalization
returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's
config.sub returns "x86_64-unknown-linux-gnu" for both
"x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the
triple normalization to behave the same way, replacing empty triple
components with "unknown".

This addresses PR37129.

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

llvm-svn: 339294

show more ...


Revision tags: llvmorg-7.0.0-rc1
# 77403dee 26-Jul-2018 Alexey Bataev <a.bataev@hotmail.com>

[OPENMP] Force OpenMP 4.5 when compiling for offloading.

If the user requested compilation for OpenMP with the offloading
support, force the version of the OpenMP standard to 4.5 by default.

llvm-s

[OPENMP] Force OpenMP 4.5 when compiling for offloading.

If the user requested compilation for OpenMP with the offloading
support, force the version of the OpenMP standard to 4.5 by default.

llvm-svn: 338032

show more ...


# e1bfbc58 21-Jul-2018 Yaxun Liu <Yaxun.Liu@amd.com>

[HIP] Support -fcuda-flush-denormals-to-zero for amdgcn

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

llvm-svn: 337639


# 99337e24 20-Jul-2018 Fangrui Song <maskray@google.com>

Change \t to spaces

llvm-svn: 337530


# da08f6ac 19-Jul-2018 Manoj Gupta <manojgupta@google.com>

[clang]: Add support for "-fno-delete-null-pointer-checks"

Summary:
Support for this option is needed for building Linux kernel.
This is a very frequently requested feature by kernel developers.

Mo

[clang]: Add support for "-fno-delete-null-pointer-checks"

Summary:
Support for this option is needed for building Linux kernel.
This is a very frequently requested feature by kernel developers.

More details : https://lkml.org/lkml/2018/4/4/601

GCC option description for -fdelete-null-pointer-checks:
This Assume that programs cannot safely dereference null pointers,
and that no code or data element resides at address zero.

-fno-delete-null-pointer-checks is the inverse of this implying that
null pointer dereferencing is not undefined.

This feature is implemented in as the function attribute
"null-pointer-is-valid"="true".
This CL only adds the attribute on the function.
It also strips "nonnull" attributes from function arguments but
keeps the related warnings unchanged.

Corresponding LLVM change rL336613 already updated the
optimizations to not treat null pointer dereferencing
as undefined if the attribute is present.

Reviewers: t.p.northover, efriedma, jyknight, chandlerc, rnk, srhines, void, george.burgess.iv

Reviewed By: jyknight

Subscribers: drinkcat, xbolva00, cfe-commits

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

llvm-svn: 337433

show more ...


# 14b468ba 18-Jul-2018 Peter Collingbourne <peter@pcc.me.uk>

Re-land r337333, "Teach Clang to emit address-significance tables.",
which was reverted in r337336.

The problem that required a revert was fixed in r337338.

Also added a missing "REQUIRES: x86-regi

Re-land r337333, "Teach Clang to emit address-significance tables.",
which was reverted in r337336.

The problem that required a revert was fixed in r337338.

Also added a missing "REQUIRES: x86-registered-target" to one of
the tests.

Original commit message:
> Teach Clang to emit address-significance tables.
>
> By default, we emit an address-significance table on all ELF
> targets when the integrated assembler is enabled. The emission of an
> address-significance table can be controlled with the -faddrsig and
> -fno-addrsig flags.
>
> Differential Revision: https://reviews.llvm.org/D48155

llvm-svn: 337339

show more ...


# 35c6996b 17-Jul-2018 Peter Collingbourne <peter@pcc.me.uk>

Revert r337333, "Teach Clang to emit address-significance tables."

Causing multiple failures on sanitizer bots due to TLS symbol errors,
e.g.

/usr/bin/ld: __msan_origin_tls: TLS definition in /home

Revert r337333, "Teach Clang to emit address-significance tables."

Causing multiple failures on sanitizer bots due to TLS symbol errors,
e.g.

/usr/bin/ld: __msan_origin_tls: TLS definition in /home/buildbots/ppc64be-clang-test/clang-ppc64be/stage1/lib/clang/7.0.0/lib/linux/libclang_rt.msan-powerpc64.a(msan.cc.o) section .tbss.__msan_origin_tls mismatches non-TLS reference in /tmp/lit_tmp_0a71tA/mallinfo-3ca75e.o

llvm-svn: 337336

show more ...


# 27242c04 17-Jul-2018 Peter Collingbourne <peter@pcc.me.uk>

Teach Clang to emit address-significance tables.

By default, we emit an address-significance table on all ELF
targets when the integrated assembler is enabled. The emission of an
address-significanc

Teach Clang to emit address-significance tables.

By default, we emit an address-significance table on all ELF
targets when the integrated assembler is enabled. The emission of an
address-significance table can be controlled with the -faddrsig and
-fno-addrsig flags.

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

llvm-svn: 337333

show more ...


# 33f3e630 17-Jul-2018 Jacob Bandes-Storch <jacob@bandes-stor.ch>

[Driver] Add -fno-digraphs

Summary: Add a flag `-fno-digraphs` to disable digraphs in the lexer, similar to `-fno-operator-names` which disables alternative names for C++ operators.

Reviewers: rsmi

[Driver] Add -fno-digraphs

Summary: Add a flag `-fno-digraphs` to disable digraphs in the lexer, similar to `-fno-operator-names` which disables alternative names for C++ operators.

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: rsmith, cfe-commits

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

llvm-svn: 337232

show more ...


# 76675de1 05-Jul-2018 Erich Keane <erich.keane@intel.com>

[clang-cl, PCH] Implement support for MS-style PCH through headers

Implement support for MS-style PCH through headers.

This enables support for /Yc and /Yu where the through header is either
on the

[clang-cl, PCH] Implement support for MS-style PCH through headers

Implement support for MS-style PCH through headers.

This enables support for /Yc and /Yu where the through header is either
on the command line or included in the source. It replaces the current
support the requires the header also be specified with /FI.

This change adds a -cc1 option -pch-through-header that is used to either
start or stop compilation during PCH create or use.

When creating a PCH, the compilation ends after compilation of the through
header.

When using a PCH, tokens are skipped until after the through header is seen.

Patch By: mikerice
Differential Revision: https://reviews.llvm.org/D46652

llvm-svn: 336379

show more ...


# 6e16c60f 29-Jun-2018 Leonard Chan <leonardchan@google.com>

[Fixed Point Arithmetic] Rename `-fsame-fbits` flag

- Rename the `-fsame-fbits` flag to `-fpadding-on-unsigned-fixed-point`
- Move the flag from a driver option to a cc1 option
- Rename the `SameFBi

[Fixed Point Arithmetic] Rename `-fsame-fbits` flag

- Rename the `-fsame-fbits` flag to `-fpadding-on-unsigned-fixed-point`
- Move the flag from a driver option to a cc1 option
- Rename the `SameFBits` member in TargetInfo to `PaddingOnUnsignedFixedPoint`
- Updated descriptions

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

llvm-svn: 335993

show more ...


# 08c5a7b8 25-Jun-2018 Hans Wennborg <hans@hanshq.net>

[clang-cl] Don't emit dllexport inline functions etc. from pch files (PR37801)

With MSVC, PCH files are created along with an object file that needs to
be linked into the final library or executable

[clang-cl] Don't emit dllexport inline functions etc. from pch files (PR37801)

With MSVC, PCH files are created along with an object file that needs to
be linked into the final library or executable. That object file
contains the code generated when building the headers. In particular, it
will include definitions of inline dllexport functions, and because they
are emitted in this object file, other files using the PCH do not need
to emit them. See the bug for an example.

This patch makes clang-cl match MSVC's behaviour in this regard, causing
significant compile-time savings when building dlls using precompiled
headers.

For example, in a 64-bit optimized shared library build of Chromium with
PCH, it reduces the binary size and compile time of
stroke_opacity_custom.obj from 9315564 bytes to 3659629 bytes and 14.6
to 6.63 s. The wall-clock time of building blink_core.dll goes from
38m41s to 22m33s. ("user" time goes from 1979m to 1142m).

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

llvm-svn: 335466

show more ...


# 7609cb83 22-Jun-2018 Tobias Edler von Koch <tobias@codeaurora.org>

Re-land "[LTO] Enable module summary emission by default for regular LTO"

Since we are now producing a summary also for regular LTO builds, we
need to run the NameAnonGlobals pass in those cases as

Re-land "[LTO] Enable module summary emission by default for regular LTO"

Since we are now producing a summary also for regular LTO builds, we
need to run the NameAnonGlobals pass in those cases as well (the
summary cannot handle anonymous globals).

See https://reviews.llvm.org/D34156 for details on the original change.

This reverts commit 6c9ee4a4a438a8059aacc809b2dd57128fccd6b3.

llvm-svn: 335385

show more ...


# e597a2cf 21-Jun-2018 Tobias Edler von Koch <tobias@codeaurora.org>

Revert "[LTO] Enable module summary emission by default for regular LTO"

This is breaking a couple of buildbots. We need to run the
NameAnonGlobal pass for regular LTO now as well (since we're produ

Revert "[LTO] Enable module summary emission by default for regular LTO"

This is breaking a couple of buildbots. We need to run the
NameAnonGlobal pass for regular LTO now as well (since we're producing a
summary). I'll post a separate patch for review to make this happen and
then re-commit.

This reverts commit c0759b7b1f4a81ff9021b952aa38a222d5fa4dfd.

llvm-svn: 335291

show more ...


# 9a8be606 21-Jun-2018 Tobias Edler von Koch <tobias@codeaurora.org>

[LTO] Enable module summary emission by default for regular LTO

Summary:
With D33921, we gained the ability to have module summaries in regular
LTO modules without triggering ThinLTO compilation. Mo

[LTO] Enable module summary emission by default for regular LTO

Summary:
With D33921, we gained the ability to have module summaries in regular
LTO modules without triggering ThinLTO compilation. Module summaries in
regular LTO allow garbage collection (dead stripping) before LTO
compilation and thus open up additional optimization opportunities.

This patch enables summary emission in regular LTO for all targets
except ld64-based ones (which use the legacy LTO API).

Reviewers: pcc, tejohnson, mehdi_amini

Subscribers: inglorion, eraman, cfe-commits

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

llvm-svn: 335284

show more ...


# db01c3ad 20-Jun-2018 Leonard Chan <leonardchan@google.com>

[Fixed Point Arithmetic] Fixed Point Precision Bits and Fixed Point Literals

This diff includes the logic for setting the precision bits for each primary fixed point type in the target info and logi

[Fixed Point Arithmetic] Fixed Point Precision Bits and Fixed Point Literals

This diff includes the logic for setting the precision bits for each primary fixed point type in the target info and logic for initializing a fixed point literal.

Fixed point literals are declared using the suffixes

```
hr: short _Fract
uhr: unsigned short _Fract
r: _Fract
ur: unsigned _Fract
lr: long _Fract
ulr: unsigned long _Fract
hk: short _Accum
uhk: unsigned short _Accum
k: _Accum
uk: unsigned _Accum
```
Errors are also thrown for illegal literal values

```
unsigned short _Accum u_short_accum = 256.0uhk; // expected-error{{the integral part of this literal is too large for this unsigned _Accum type}}
```

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

llvm-svn: 335148

show more ...


Revision tags: llvmorg-6.0.1, llvmorg-6.0.1-rc3
# e368de36 13-Jun-2018 Piotr Padlewski <piotr.padlewski@gmail.com>

Add -fforce-emit-vtables

Summary:
In many cases we can't devirtualize
because definition of vtable is not present. Most of the
time it is caused by inline virtual function not beeing
emitted. Fo

Add -fforce-emit-vtables

Summary:
In many cases we can't devirtualize
because definition of vtable is not present. Most of the
time it is caused by inline virtual function not beeing
emitted. Forcing emitting of vtable adds a reference of these
inline virtual functions.
Note that GCC was always doing it.

Reviewers: rjmccall, rsmith, amharc, kuhar

Subscribers: llvm-commits, cfe-commits

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

Co-authored-by: Krzysztof Pszeniczny <krzysztof.pszeniczny@gmail.com>
llvm-svn: 334600

show more ...


# d8c6290b 11-Jun-2018 Pavel Labath <labath@google.com>

Move VersionTuple from clang/Basic to llvm/Support

Summary:
This kind of functionality is useful to other project apart from clang.
LLDB works with version numbers a lot, but it does not have a conv

Move VersionTuple from clang/Basic to llvm/Support

Summary:
This kind of functionality is useful to other project apart from clang.
LLDB works with version numbers a lot, but it does not have a convenient
abstraction for this. Moving this class to a lower level library allows
it to be freely used within LLDB.

Since this class is used in a lot of places in clang, and it used to be
in the clang namespace, it seemed appropriate to add it to the list of
adopted classes in LLVM.h to avoid prefixing all uses with "llvm::".

Also, I didn't find any tests specific for this class, so I wrote a
couple of quick ones for the more interesting bits of functionality.

Reviewers: zturner, erik.pilkington

Subscribers: mgorny, cfe-commits, llvm-commits

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

llvm-svn: 334399

show more ...


# d8d15473 07-Jun-2018 Shoaib Meenai <smeenai@fb.com>

[Frontend] Disallow non-MSVC exception models for windows-msvc targets

The windows-msvc target is used for MSVC ABI compatibility, including
the exceptions model. It doesn't make sense to pair a win

[Frontend] Disallow non-MSVC exception models for windows-msvc targets

The windows-msvc target is used for MSVC ABI compatibility, including
the exceptions model. It doesn't make sense to pair a windows-msvc
target with a non-MSVC exception model. This would previously cause an
assertion failure; explicitly error out for it in the frontend instead.
This also allows us to reduce the matrix of target/exception models a
bit (see the modified tests), and we can possibly simplify some of the
personality code in a follow-up.

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

llvm-svn: 334243

show more ...


# f921d854 04-Jun-2018 Leonard Chan <leonardchan@google.com>

This diff includes changes for supporting the following types.

// Primary fixed point types
signed short _Accum s_short_accum;
signed _Accum s_accum;
signed long _Accum s_long_accum;
unsigned short

This diff includes changes for supporting the following types.

// Primary fixed point types
signed short _Accum s_short_accum;
signed _Accum s_accum;
signed long _Accum s_long_accum;
unsigned short _Accum u_short_accum;
unsigned _Accum u_accum;
unsigned long _Accum u_long_accum;

// Aliased fixed point types
short _Accum short_accum;
_Accum accum;
long _Accum long_accum;
This diff only allows for declaration of the fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. The saturated versions of these types and the equivalent _Fract types will also be added in future patches.

The tests included are for asserting that we can declare these types.

Fixed the test that was failing by not checking for dso_local on some
targets.

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

llvm-svn: 333923

show more ...


Revision tags: llvmorg-6.0.1-rc2
# 0d485dbb 02-Jun-2018 Leonard Chan <leonardchan@google.com>

Revert "This diff includes changes for supporting the following types."

This reverts commit r333814, which fails for a test checking the bit
width on ubuntu.

llvm-svn: 333815


# db55d833 02-Jun-2018 Leonard Chan <leonardchan@google.com>

This diff includes changes for supporting the following types.

```

// Primary fixed point types
signed short _Accum s_short_accum;
signed _Accum s_accum;
signed long _Accum s_long_accum;
unsigned s

This diff includes changes for supporting the following types.

```

// Primary fixed point types
signed short _Accum s_short_accum;
signed _Accum s_accum;
signed long _Accum s_long_accum;
unsigned short _Accum u_short_accum;
unsigned _Accum u_accum;
unsigned long _Accum u_long_accum;

// Aliased fixed point types
short _Accum short_accum;
_Accum accum;
long _Accum long_accum;

```

This diff only allows for declaration of the fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. The saturated versions of these types and the equivalent `_Fract` types will also be added in future patches.

The tests included are for asserting that we can declare these types.

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

llvm-svn: 333814

show more ...


# 16ed8dd8 31-May-2018 Aaron Ballman <aaron@aaronballman.com>

Add a new driver mode to dump compiler feature and extension options.

Add the ability to dump compiler option-related information to a JSON file via the -compiler-options-dump option. Specifically,

Add a new driver mode to dump compiler feature and extension options.

Add the ability to dump compiler option-related information to a JSON file via the -compiler-options-dump option. Specifically, it dumps the features/extensions lists -- however, this output could be extended to other information should it be useful. In order to support features and extensions, I moved them into a .def file so that we could build the various lists we care about from them without a significant increase in maintenance burden.

llvm-svn: 333653

show more ...


# 54d13b40 30-May-2018 Peter Collingbourne <peter@pcc.me.uk>

Sema: Add a flag for rejecting member pointers with incomplete base types.

Codebases that need to be compatible with the Microsoft ABI can pass
this flag to avoid issues caused by the lack of a fixe

Sema: Add a flag for rejecting member pointers with incomplete base types.

Codebases that need to be compatible with the Microsoft ABI can pass
this flag to avoid issues caused by the lack of a fixed ABI for
incomplete member pointers.

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

llvm-svn: 333498

show more ...


# f92ca01e 25-May-2018 Petr Hosek <phosek@chromium.org>

[Support] Avoid normalization in sys::getDefaultTargetTriple

The return value of sys::getDefaultTargetTriple, which is derived from
-DLLVM_DEFAULT_TRIPLE, is used to construct tool names, default ta

[Support] Avoid normalization in sys::getDefaultTargetTriple

The return value of sys::getDefaultTargetTriple, which is derived from
-DLLVM_DEFAULT_TRIPLE, is used to construct tool names, default target,
and in the future also to control the search path directly; as such it
should be used textually, without interpretation by LLVM.

Normalization of this value may lead to unexpected results, for example
if we configure LLVM with -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-linux-gnu,
normalization will transform that value to x86_64--linux-gnu. Driver will
use that value to search for tools prefixed with x86_64--linux-gnu- which
may be confusing. This is also inconsistent with the behavior of the
--target flag which is taken as-is without any normalization and overrides
the value of LLVM_DEFAULT_TARGET_TRIPLE.

Users of sys::getDefaultTargetTriple already perform their own
normalization as needed, so this change shouldn't impact existing logic.

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

llvm-svn: 333307

show more ...


1...<<31323334353637383940>>...79