History log of /llvm-project/clang/lib/Frontend/CompilerInvocation.cpp (Results 801 – 825 of 1971)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 8076c57f 05-Dec-2018 Vitaly Buka <vitalybuka@google.com>

[asan] Add clang flag -fsanitize-address-use-odr-indicator

Reviewers: eugenis, m.ostapenko, ygribov

Subscribers: hiraditya, llvm-commits

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

llv

[asan] Add clang flag -fsanitize-address-use-odr-indicator

Reviewers: eugenis, m.ostapenko, ygribov

Subscribers: hiraditya, llvm-commits

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

llvm-svn: 348327

show more ...


# 0a6b5b65 04-Dec-2018 Erich Keane <erich.keane@intel.com>

PTH-- Remove feature entirely-

When debugging a boost build with a modified
version of Clang, I discovered that the PTH implementation
stores TokenKind in 8 bits. However, we currently have 368
Toke

PTH-- Remove feature entirely-

When debugging a boost build with a modified
version of Clang, I discovered that the PTH implementation
stores TokenKind in 8 bits. However, we currently have 368
TokenKinds.

The result is that the value gets truncated and the wrong token
gets picked up when including PTH files. It seems that this will
go wrong every time someone uses a token that uses the 9th bit.

Upon asking on IRC, it was brought up that this was a highly
experimental features that was considered a failure. I discovered
via googling that BoostBuild (mostly Boost.Math) is the only user of
this
feature, using the CC1 flag directly. I believe that this can be
transferred over to normal PCH with minimal effort:
https://github.com/boostorg/build/issues/367

Based on advice on IRC and research showing that this is a nearly
completely unused feature, this patch removes it entirely.

Note: I considered leaving the build-flags in place and making them
emit an error/warning, however since I've basically identified and
warned the only user, it seemed better to just remove them.

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

Change-Id: If32744275ef1f585357bd6c1c813d96973c4d8d9
llvm-svn: 348266

show more ...


# 821b38f5 04-Dec-2018 Petr Hosek <phosek@chromium.org>

[Sema] Provide -fvisibility-global-new-delete-hidden option

When the global new and delete operators aren't declared, Clang
provides and implicit declaration, but this declaration currently
always u

[Sema] Provide -fvisibility-global-new-delete-hidden option

When the global new and delete operators aren't declared, Clang
provides and implicit declaration, but this declaration currently
always uses the default visibility. This is a problem when the
C++ library itself is being built with non-default visibility because
the implicit declaration will force the new and delete operators to
have the default visibility unlike the rest of the library.

The existing workaround is to use assembly to enforce the visiblity:
https://fuchsia.googlesource.com/zircon/+/master/system/ulib/zxcpp/new.cpp#108
but that solution is not always available, e.g. in the case of of
libFuzzer which is using an internal version of libc++ that's also built
with -fvisibility=hidden where the existing behavior is causing issues.

This change introduces a new option -fvisibility-global-new-delete-hidden
which makes the implicit declaration of the global new and delete
operators hidden.

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

llvm-svn: 348234

show more ...


# dbc99416 03-Dec-2018 Ilya Biryukov <ibiryukov@google.com>

[Analyzer] Actually check for -model-path being a directory

The original patch (r348038) clearly contained a typo and checked
for '-ctu-dir' twice.

llvm-svn: 348125


# d1a4b06c 30-Nov-2018 Kristof Umann <dkszelethus@gmail.com>

[analyzer] Emit an error for invalid -analyzer-config inputs

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

llvm-svn: 348038


# 549f9cd4 30-Nov-2018 Kristof Umann <dkszelethus@gmail.com>

[analyzer] Evaluate all non-checker config options before analysis

In earlier patches regarding AnalyzerOptions, a lot of effort went into
gathering all config options, and changing the interface so

[analyzer] Evaluate all non-checker config options before analysis

In earlier patches regarding AnalyzerOptions, a lot of effort went into
gathering all config options, and changing the interface so that potential
misuse can be eliminited.

Up until this point, AnalyzerOptions only evaluated an option when it was
querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions
would store an Optional field for it that would be None up until somewhere in
the code until the flag's getter function is called.

However, now that we're confident that we've gathered all configs, we can
evaluate off of them before analysis, so we can emit a error on invalid input
even if that prticular flag will not matter in that particular run of the
analyzer. Another very big benefit of this is that debug.ConfigDumper will now
show the value of all configs every single time.

Also, almost all options related class have a similar interface, so uniformity
is also a benefit.

The implementation for errors on invalid input will be commited shorty.

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

llvm-svn: 348031

show more ...


# 55fcb4e9 29-Nov-2018 Adrian Prantl <aprantl@apple.com>

[-gmodules] Honor -fdebug-prefix-map in the debug info inside PCMs.

This patch passes -fdebug-prefix-map (a feature for renaming source
paths in the debug info) through to the per-module codegen opt

[-gmodules] Honor -fdebug-prefix-map in the debug info inside PCMs.

This patch passes -fdebug-prefix-map (a feature for renaming source
paths in the debug info) through to the per-module codegen options and
adds the debug prefix map to the module hash.

<rdar://problem/46045865>

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

llvm-svn: 347926

show more ...


# 000fbab0 26-Nov-2018 Sam Parker <sam.parker@arm.com>

[NFC] Replace magic numbers with CodeGenOpt enums

Use enum values from llvm/Support/CodeGen.h for the optimisation
levels in CompilerInvocation.

llvm-svn: 347577


# f4bf671a 17-Nov-2018 Calixte Denizet <cdenizet@mozilla.com>

[Clang] Add options -fprofile-filter-files and -fprofile-exclude-files to filter the files to instrument with gcov (after revert https://reviews.llvm.org/rL346659)

Summary:
the previous patch (https

[Clang] Add options -fprofile-filter-files and -fprofile-exclude-files to filter the files to instrument with gcov (after revert https://reviews.llvm.org/rL346659)

Summary:
the previous patch (https://reviews.llvm.org/rC346642) has been reverted because of test failure under windows.
So this patch fix the test cfe/trunk/test/CodeGen/code-coverage-filter.c.

Reviewers: marco-c

Reviewed By: marco-c

Subscribers: cfe-commits, sylvestre.ledru

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

llvm-svn: 347144

show more ...


# 9941da41 17-Nov-2018 David Blaikie <dblaikie@gmail.com>

Sink BuryPointer from Clang into LLVM for reuse there

llvm-svn: 347141


# 75557716 16-Nov-2018 Reid Kleckner <rnk@google.com>

[codeview] Expose -gcodeview-ghash for global type hashing

Summary:
Experience has shown that the functionality is useful. It makes linking
optimized clang with debug info for me a lot faster, 20s t

[codeview] Expose -gcodeview-ghash for global type hashing

Summary:
Experience has shown that the functionality is useful. It makes linking
optimized clang with debug info for me a lot faster, 20s to 13s. The
type merging phase of PDB writing goes from 10s to 3s.

This removes the LLVM cl::opt and replaces it with a metadata flag.

After this change, users can do the following to use ghash:
- add -gcodeview-ghash to compiler flags
- replace /DEBUG with /DEBUG:GHASH in linker flags

Reviewers: zturner, hans, thakis, takuto.ikuta

Subscribers: aprantl, hiraditya, JDevlieghere, llvm-commits

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

llvm-svn: 347072

show more ...


# 28ddb91d 14-Nov-2018 Richard Smith <richard-llvm@metafoo.co.uk>

[c++20] Implement P0482R6: enable -fchar8_t by default in C++20 mode.

This unfortunately results in a substantial breaking change when
switching to C++20, but it's not yet clear what / how much we s

[c++20] Implement P0482R6: enable -fchar8_t by default in C++20 mode.

This unfortunately results in a substantial breaking change when
switching to C++20, but it's not yet clear what / how much we should
do about that. We may want to add a compatibility conversion from
u8 string literals to const char*, similar to how C++98 provided a
compatibility conversion from string literals to non-const char*,
but that's not handled by this patch.

The feature can be disabled in C++20 mode with -fno-char8_t.

llvm-svn: 346892

show more ...


# 91829eef 14-Nov-2018 George Rimar <grimar@accesssoftek.com>

[Clang] - Add '-gsplit-dwarf[=split,=single]' version for '-gsplit-dwarf' option.

The DWARF5 specification says(Appendix F.1):

"The sections that do not require relocation, however, can be
written

[Clang] - Add '-gsplit-dwarf[=split,=single]' version for '-gsplit-dwarf' option.

The DWARF5 specification says(Appendix F.1):

"The sections that do not require relocation, however, can be
written to the relocatable object (.o) file but ignored by the
linker or they can be written to a separate DWARF object (.dwo)
file that need not be accessed by the linker."

The first part describes a single file split DWARF feature and there
is no way to trigger this behavior atm.
Fortunately, no many changes are required to keep *.dwo sections
in a .o, the patch does that.

Differential revision: https://reviews.llvm.org/D52296

llvm-svn: 346837

show more ...


# 27692de9 13-Nov-2018 David Blaikie <dblaikie@gmail.com>

DebugInfo: Add a driver flag for DWARF debug_ranges base address specifier use.

Summary:
This saves a lot of relocations in optimized object files (at the cost
of some cost/increase in linked execut

DebugInfo: Add a driver flag for DWARF debug_ranges base address specifier use.

Summary:
This saves a lot of relocations in optimized object files (at the cost
of some cost/increase in linked executable bytes), but gold's 32 bit
gdb-index support has a bug (
https://sourceware.org/bugzilla/show_bug.cgi?id=21894 ) so we can't
switch to this unconditionally. (& even if it weren't for that bug, one
might argue that some users would want to optimize in one direction or
the other - prioritizing object size or linked executable size)

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

llvm-svn: 346789

show more ...


# 186d5bd8 12-Nov-2018 Calixte Denizet <cdenizet@mozilla.com>

Revert rL346644, rL346642: the added test test/CodeGen/code-coverage-filter.c is failing under windows

llvm-svn: 346659


# cedcc73d 12-Nov-2018 Calixte Denizet <cdenizet@mozilla.com>

[Clang] Add options -fprofile-filter-files and -fprofile-exclude-files to filter the files to instrument with gcov

Summary:
These options are taking regex separated by colons to filter files.
- if b

[Clang] Add options -fprofile-filter-files and -fprofile-exclude-files to filter the files to instrument with gcov

Summary:
These options are taking regex separated by colons to filter files.
- if both are empty then all files are instrumented
- if -fprofile-filter-files is empty then all the filenames matching any of the regex from exclude are not instrumented
- if -fprofile-exclude-files is empty then all the filenames matching any of the regex from filter are instrumented
- if both aren't empty then all the filenames which match any of the regex in filter and which don't match all the regex in filter are instrumented
- this patch is a follow-up of https://reviews.llvm.org/D52033

Reviewers: marco-c, vsk

Reviewed By: marco-c, vsk

Subscribers: cfe-commits, sylvestre.ledru

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

llvm-svn: 346642

show more ...


# 302c6435 03-Nov-2018 Takuto Ikuta <takuto.ikuta@gmail.com>

Add /Zc:DllexportInlines option to clang-cl

Summary:
This CL adds /Zc:DllexportInlines flag to clang-cl.
When Zc:DllexportInlines- is specified, inline class member function is not exported if the f

Add /Zc:DllexportInlines option to clang-cl

Summary:
This CL adds /Zc:DllexportInlines flag to clang-cl.
When Zc:DllexportInlines- is specified, inline class member function is not exported if the function does not have local static variables.

By not exporting inline function, code for those functions are not generated and that reduces both compile time and obj size. Also this flag does not import inline functions from dllimported class if the function does not have local static variables.

On my 24C48T windows10 machine, build performance of chrome target in chromium repository is like below.
These stats are come with 'target_cpu="x86" enable_nacl = false is_component_build=true dcheck_always_on=true` build config and applied
* https://chromium-review.googlesource.com/c/chromium/src/+/1212379
* https://chromium-review.googlesource.com/c/v8/v8/+/1186017

Below stats were taken with this patch applied on https://github.com/llvm-project/llvm-project-20170507/commit/a05115cd4c57ff76b0f529e38118765b58ed7f2e

| config | build time | speedup | build dir size |
| with patch, PCH on, debug | 1h10m0s | x1.13 | 35.6GB |
| without patch, PCH on, debug | 1h19m17s | | 49.0GB |
| with patch, PCH off, debug | 1h15m45s | x1.16 | 33.7GB |
| without patch, PCH off, debug | 1h28m10s | | 52.3GB |
| with patch, PCH on, release | 1h13m13s | x1.22 | 26.2GB |
| without patch, PCH on, release | 1h29m57s | | 37.5GB |
| with patch, PCH off, release | 1h23m38s | x1.32 | 23.7GB |
| without patch, PCH off, release | 1h50m50s | | 38.7GB |

This patch reduced obj size and the number of exported symbols largely, that improved link time too.
e.g. link time stats of blink_core.dll become like below
| | cold disk cache | warm disk cache |
| with patch, PCH on, debug | 71s | 30s |
| without patch, PCH on, debug | 111s | 48s |

This patch's implementation is based on Nico Weber's patch. I modified to support static local variable, added tests and took stats.

Bug: https://bugs.llvm.org/show_bug.cgi?id=33628

Reviewers: hans, thakis, rnk, javed.absar

Reviewed By: hans

Subscribers: kristof.beyls, smeenai, dschuff, probinson, cfe-commits, eraman

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

llvm-svn: 346069

show more ...


Revision tags: llvmorg-7.0.1-rc2
# 0eb50083 02-Nov-2018 Filipe Cabecinhas <me@filcab.net>

Change -fsanitize-address-poison-class-member-array-new-cookie to -fsanitize-address-poison-custom-array-cookie

Handle it in the driver and propagate it to cc1

Reviewers: rjmccall, kcc, rsmith

Sub

Change -fsanitize-address-poison-class-member-array-new-cookie to -fsanitize-address-poison-custom-array-cookie

Handle it in the driver and propagate it to cc1

Reviewers: rjmccall, kcc, rsmith

Subscribers: cfe-commits

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

llvm-svn: 346001

show more ...


# f1f351c9 02-Nov-2018 Kristof Umann <dkszelethus@gmail.com>

[analyzer] New flag to print all -analyzer-config options

A new -cc1 flag is avaible for the said purpose: -analyzer-config-help

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

llvm-svn: 34

[analyzer] New flag to print all -analyzer-config options

A new -cc1 flag is avaible for the said purpose: -analyzer-config-help

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

llvm-svn: 345989

show more ...


# e4090180 02-Nov-2018 Alexey Bataev <a.bataev@hotmail.com>

[OPENMP][NVPTX]Improve emission of the globalized variables for
target/teams/distribute regions.

Target/teams/distribute regions exist for all the time the kernel is
executed. Thus, if the variable

[OPENMP][NVPTX]Improve emission of the globalized variables for
target/teams/distribute regions.

Target/teams/distribute regions exist for all the time the kernel is
executed. Thus, if the variable is declared in their context and then
escape it, we can allocate global memory statically instead of
allocating it dynamically.
Patch captures all the globalized variables in target/teams/distribute
contexts, merges them into the records, one per each target region.
Those records are then joined into the union, one per compilation unit
(to save the global memory). Those units are organized into
2 x dimensional arrays, where the first dimension is
the number of blocks per SM and the second one is the number of SMs.
Runtime functions manage this global memory space between the executing
teams.

llvm-svn: 345978

show more ...


Revision tags: llvmorg-7.0.1-rc1
# 4dc0b1ac 01-Nov-2018 Reid Kleckner <rnk@google.com>

Fix clang -Wimplicit-fallthrough warnings across llvm, NFC

This patch should not introduce any behavior changes. It consists of
mostly one of two changes:
1. Replacing fall through comments with the

Fix clang -Wimplicit-fallthrough warnings across llvm, NFC

This patch should not introduce any behavior changes. It consists of
mostly one of two changes:
1. Replacing fall through comments with the LLVM_FALLTHROUGH macro
2. Inserting 'break' before falling through into a case block consisting
of only 'break'.

We were already using this warning with GCC, but its warning behaves
slightly differently. In this patch, the following differences are
relevant:
1. GCC recognizes comments that say "fall through" as annotations, clang
doesn't
2. GCC doesn't warn on "case N: foo(); default: break;", clang does
3. GCC doesn't warn when the case contains a switch, but falls through
the outer case.

I will enable the warning separately in a follow-up patch so that it can
be cleanly reverted if necessary.

Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu

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

llvm-svn: 345882

show more ...


# fa98390b 30-Oct-2018 Erik Pilkington <erik.pilkington@gmail.com>

NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)

We haven't supported compiling ObjC1 for a long time (and never will again), so
there isn't any reason to keep these separat

NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)

We haven't supported compiling ObjC1 for a long time (and never will again), so
there isn't any reason to keep these separate. This patch replaces
LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC.

Differential revision: https://reviews.llvm.org/D53547

llvm-svn: 345637

show more ...


# f239a44a 26-Oct-2018 Volodymyr Sapsai <vsapsai@apple.com>

[VFS] Add property 'fallthrough' that controls fallback to real file system.

Default property value 'true' preserves current behavior. Value 'false' can be
used to create VFS "root", file system tha

[VFS] Add property 'fallthrough' that controls fallback to real file system.

Default property value 'true' preserves current behavior. Value 'false' can be
used to create VFS "root", file system that gives better control over which
files compiler can use during compilation as there are no unpredictable
accesses to real file system.

Non-fallthrough use case changes how we treat multiple VFS overlay
files. Instead of all of them being at the same level just above a real
file system, now they are nested and subsequent overlays can refer to
files in previous overlays.

Change is done both in LLVM and Clang, corresponding LLVM commit is r345431.

rdar://problem/39465552

Reviewers: bruno, benlangmuir

Reviewed By: bruno

Subscribers: dexonsmith, cfe-commits, hiraditya

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

llvm-svn: 345432

show more ...


# 6822bd79 26-Oct-2018 Richard Smith <richard-llvm@metafoo.co.uk>

PR26547: alignof should return ABI alignment, not preferred alignment

Summary:
- Add `UETT_PreferredAlignOf` to account for the difference between `__alignof` and `alignof`
- `AlignOfType` now retur

PR26547: alignof should return ABI alignment, not preferred alignment

Summary:
- Add `UETT_PreferredAlignOf` to account for the difference between `__alignof` and `alignof`
- `AlignOfType` now returns ABI alignment instead of preferred alignment iff clang-abi-compat > 7, and one uses _Alignof or alignof

Patch by Nicole Mazzuca!

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

llvm-svn: 345419

show more ...


# a8a24aa0 25-Oct-2018 Luke Cheeseman <luke.cheeseman@arm.com>

[AArch64] Branch Protection and Return Address Signing B Key Support

- Add support for -mbranch-protection=<type>[+<type>]* where
- <type> ::= [standard, none, bti, pac-ret[+b-key,+leaf]*]
- The p

[AArch64] Branch Protection and Return Address Signing B Key Support

- Add support for -mbranch-protection=<type>[+<type>]* where
- <type> ::= [standard, none, bti, pac-ret[+b-key,+leaf]*]
- The protection emits relevant function attributes
- sign-return-address=<scope>
- sign-return-address-key=<key>
- branch-protection

llvm-svn: 345273

show more ...


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