| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Summary:
Changed EABIVersion type from string to llvm::EABI.
It seems it was just a typo and this is intended implementation.
Differential Revision: https://reviews.llvm.org/D34595
llvm-svn: 306953
|
|
Summary:
Un-revert https://reviews.llvm.org/D34868, but with a slight tweak to the
documentation to fix an error -- I had used the wrong syntax for a link.
llvm-svn: 306948
|
|
Summary:
The commit caused a documentation breakage.
llvm-svn: 306946
|
|
Summary:
Depends on https://reviews.llvm.org/D34867.
Add a Clang frontend option to enable optimization remark hotness
thresholds, which were added to LLVM in https://reviews.llvm.org/D34867.
This prevents diagnostics that do not meet a minimum hotness
threshold from being output. When generating optimization remarks for large
codebases with a ton of cold code paths, this option can be used
to limit the optimization remark output at a reasonable size.
Discussion of this change can be read here:
http://lists.llvm.org/pipermail/llvm-dev/2017-June/114377.html
Reviewers: anemet, davidxl, hfinkel
Reviewed By: anemet
Subscribers: fhahn, cfe-commits
Differential Revision: https://reviews.llvm.org/D34868
llvm-svn: 306945
|
|
basic block vectorizer. This vectorizer has had no known users for many,
many years and is completely surpassed by the normal
'-fvectorize-slp'-controlled SLP vectorizer in LLVM.
Hal proposed this back in 2014 to no objections:
http://lists.llvm.org/pipermail/llvm-dev/2014-November/079091.html
While this patch completely removes the flag, Joerg is working on
a patch that will add it back in a way that warns users and ignores the
flag in a clear and well factored way (so that we can keep doing this
going forward).
Differential Revision: https://reviews.llvm.org/D34846
llvm-svn: 306786
|
|
Differential Revision: https://reviews.llvm.org/D34790
llvm-svn: 306757
|
|
a c++17 aligned allocation/deallocation function that is unavailable in
the standard library on Apple platforms.
The aligned functions are implemented only in the following versions or
later versions of the OSes, so clang issues diagnostics if the deployment
target being targeted is older than these:
macosx: 10.13
ios: 11.0
tvos: 11.0
watchos: 4.0
The diagnostics are issued whenever the aligned functions are selected
except when the selected function has a definition in the same file.
If there is a user-defined function available somewhere else, option
-Wno-aligned-allocation-unavailable can be used to silence the
diagnostics.
rdar://problem/32664169
Differential Revision: https://reviews.llvm.org/D34574
llvm-svn: 306722
|
|
Summary: Device offloading requires the specification of an additional flag containing the triple of the //other// architecture the code is being compiled on if such an architecture exists. If compiling for the host, the auxiliary triple flag will contain the triple describing the device and vice versa.
Reviewers: arpith-jacob, sfantao, caomhin, carlo.bertolli, ABataev, Hahnfeld, jlebar, hfinkel, tstellar
Reviewed By: Hahnfeld
Subscribers: rengolin, cfe-commits
Differential Revision: https://reviews.llvm.org/D29339
llvm-svn: 306689
|
|
Restore the `-gz` option to the driver with some minor tweaks to handle
the additional case for `-Wa,--compress-debug-sections`.
This intends to make the compression of the debug information
controllable from the driver. The following is the behaviour:
-gz enable compression (ambiguous for format, will default to zlib-gnu)
-gz=none disable compression
-gz=zlib-gnu enable compression (deprecated GNU style zlib compression)
-gz=zlib enable compression (zlib based compression)
Although -Wa,-compress-debug-sections works, it should be discouraged
when using the driver to invoke the assembler. However, we permit the
assembler to accept the GNU as style argument --compress-debug-sections
to maintain compatibility.
Note, -gz/-gz= does *NOT* imply -g. That is, you need to additionally
specific -g for debug information to be generated.
llvm-svn: 306115
|
|
Summary:
Prior to this change, using `-fdiagnostics-show-hotness` with a sampling
profile specified via `-fprofile-sample-use=` would result in the Clang
frontend emitting a warning: "argument '-fdiagnostics-show-hotness' requires
profile-guided optimization information". Of course, a sampling profile
*is* profile-guided optimization information, so the warning is misleading.
Furthermore, despite the warning, hotness was displayed based on the data in
the sampling profile.
Prevent the warning from being emitted when a sampling profile is used, and
add a test that verifies this.
Reviewers: anemet, davidxl
Reviewed By: davidxl
Subscribers: danielcdh, cfe-commits
Differential Revision: https://reviews.llvm.org/D34082
llvm-svn: 306079
|
|
for preprocessing
r300667 added support for editor placeholder to Clang. That commit didn’t take
into account that users who use Clang for preprocessing only (-E) will get the
"editor placeholder in source file" error when preprocessing their source
(PR33394). This commit ensures that Clang doesn't lex editor placeholders when
running a preprocessor only action.
rdar://32718000
Differential Revision: https://reviews.llvm.org/D34256
llvm-svn: 305576
|
|
Summary:
It seems -flto must be either "thin" or "full". I think the use of
containValue is just a typo.
Reviewers: ruiu, tejohnson
Subscribers: mehdi_amini, inglorion
Differential Revision: https://reviews.llvm.org/D34055
llvm-svn: 305392
|
|
cc1as does not currently access the "--" version of this flag. At the
very least this needs to be fixed and proper test cases need to be
added.
Simple reproducer:
clang -Wa,--compress-debug-sections /tmp/test.cc
Result:
error: unknown argument: '--compress-debug-sections'
llvm-svn: 305182
|
|
These options control the behaviour of the compression of debug info
sections on ELF targets. Our behaviour slightly diverges from the
behaviour of GCC. `-gz` maps to the `-compress-debug-sections` rather
than `-compress-debug-sections=zlib` or
`-compress-debug-sections=zlib-gnu`. This small divergence allows us to
be compatible across versions of binutils (=zlib support was introduced
in 2.26, while earlier versions only support =zlib-gnu). This also
allows users to not have to worry about the version of the assembler
they may be using if they are not using the IAS. Previously, users
would have had to go through the internal option
`-compress-debug-sectionss` and pass that through to the assembler,
which is no longer needed.
llvm-svn: 305165
|
|
If specified, when preprocessing, the contents of imported .pcm files will be
included in preprocessed output. The resulting preprocessed file can then be
compiled standalone without the module sources or .pcm files.
llvm-svn: 305116
|
|
This is tied with the LLVM side of the change to expose the debug
information compression types to clang. We now track the compression
type as an enumeration rather than a boolean. We still use the same
value (GNU) that we did previously. This is in preparation to support
passing down the compression type and switch it based on the command
line.
llvm-svn: 305039
|
|
-fsanitize-coverage=inline-8bit-counters. Experimental so far, not documenting yet. Reapplying revisions 304630, 304631, 304632, 304673, see PR33308
llvm-svn: 305026
|
|
-fsanitize-coverage=inline-8bit-counters. Experimental so far, not documenting yet. (clang part)"
This reverts commit r304631, as it broke ARM/AArch64 bots for 2 days.
llvm-svn: 304697
|
|
-fsanitize-coverage=inline-8bit-counters. Experimental so far, not documenting yet. (clang part)
llvm-svn: 304631
|
|
This patch makes it an error to have a mismatch between the enabled
sanitizers in a CU, and in any module being imported into the CU. Only
mismatches between non-modular sanitizers are treated as errors.
This patch also includes non-modular sanitizers in module hashes, in
order to ensure module rebuilds occur when -fsanitize=X is toggled on
and off for non-modular sanitizers, and to cut down on module rebuilds
when the option is toggled for modular sanitizers.
This fixes a longstanding issue with implicit modules and sanitizers,
which Duncan originally diagnosed.
When building with implicit modules it's possible to hit a scenario
where modules are built without -fsanitize=address, and are subsequently
imported into CUs with -fsanitize=address enabled. This causes strange
failures at runtime. The case Duncan found affects libcxx, since its
vector implementation behaves differently when ASan is enabled.
Implicit module builds should "just work" when -fsanitize=X is toggled
on and off across multiple compiler invocations, which is what this
patch does.
Differential Revision: https://reviews.llvm.org/D32724
llvm-svn: 304463
|
|
Ignore default CC flags that don't make sense for the target arch. This
is consistent with MSVC.
Addresses part of PR33237
llvm-svn: 304305
|
|
Amongst other, this will help LTO to correctly handle/honor files
compiled with O0, helping debugging failures.
It also seems in line with how we handle other options, like how
-fnoinline adds the appropriate attribute as well.
Differential Revision: https://reviews.llvm.org/D28404
llvm-svn: 304127
|
|
llvm-svn: 303882
|
|
There's a Microsoft header in the Windows SDK which won't
compile with clang because it uses an operator name (and)
as a field name. This patch allows that file to compile by
setting the option which disables operator names.
The header which doesn't compile <Query.h> C:/Program Files (x86)/
Windows Kits/10/include/10.0.14393.0/um\Query.h:259:40:
error: expected member name or ';' after declaration specifiers
/* [case()] */ NODERESTRICTION or;
~~~~~~~~~~~~~~~ ^
1 error generated.
Contributed for Melanie Blower
Differential Revision:https://reviews.llvm.org/D33505
llvm-svn: 303798
|
|
Reviewers: bkramer, krasimir, arphaman, akyrtzi
Reviewed By: bkramer
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33397
llvm-svn: 303630
|
|
When a diagnostic includes a highlighted range spanning multiple lines, clang
now supports printing out multiple lines of context if necessary to show the
highlighted ranges. This is not yet exposed in the driver, but can be enabled
by "-Xclang -fcaret-diagnostics-max-lines -Xclang N".
This is experimental until we can find out whether it works well in practice,
and if so, what a good default for the maximum number of lines is.
llvm-svn: 303589
|
|
This feature is subtly broken when the linker is gold 2.26 or
earlier. See the following bug for details:
https://sourceware.org/bugzilla/show_bug.cgi?id=19002
Since the decision needs to be made at compilation time, we can not
test the linker version. The flag is off by default on ELF targets,
and on otherwise.
llvm-svn: 302591
|
|
hidden -mllvm flag. clang part.
llvm-svn: 302320
|
|
This reverts commit because it broke
sanitizer-x86_64-linux-autoconf bot and
clang-ppc64be-linux-multistage bot.
llvm-svn: 302000
|
|
-isysroot is the flag which set the system root directory.
This bug report https://bugs.llvm.org//show_bug.cgi?id=11503
shows that -isysroot is not handled at all on Unix, so fixed this bug.
After this diff, I could get this result https://pastebin.com/TeCmn9mj .
Differential Revision: https://reviews.llvm.org/D31495
llvm-svn: 301998
|
|
action to the general FrontendAction infrastructure.
This permits applying -E, -ast-dump, -fsyntax-only, and so on to a module map
compilation. (The -E form is not currently especially useful yet as there's no
good way to take the output and use it to actually build a module.)
In order to support this, -cc1 now accepts -x <lang>-module-map in all cases
where it accepts -x <lang> for a language we can parse (not ir/ast). And for
uniformity, we also accept -x <lang>-header for all such languages (we used
to reject for cuda and renderscript), and -x <lang>-cpp-output for all such
languages (we used to reject for c, cl, and renderscript).
(None of these new alternatives are accepted by the driver yet, so no
user-visible changes.)
llvm-svn: 301610
|
|
Don't list deprecated -std= values (c++0x etc). Only produce one line of output
per standard, even if we know it by multiple names.
In passing, add missing -std=gnu++03 alias (supported by GCC), and add new
spelling '-std=cl1.0' for OpenCL 1.0 for consistency with the other values,
with the same meaning as the preexisting '-std=cl'.
llvm-svn: 301507
|
|
llvm-svn: 301500
|
|
We already prohibited this in most cases (in r130710), but had some bugs in our
enforcement of this rule. Specifically, this prevents the following
combinations:
* -x c -std=clN.M, which would previously effectively act as if -x cl were
used, despite the input being a C source file. (-x cl -std=cNN continues
to be disallowed.)
* -x c++ -std=cuda, which would previously select C++98 + CUDA, despite that
not being a C++ standard. (-x cuda -std=c++NN is still permitted, and
selects CUDA with the given C++ standard as its base language.
-x cuda -std=cuda is still supported with the meaning of CUDA + C++98.)
* -x renderscript -std=c++NN, which would previously form a hybrid "C++ with
RenderScript extensions" language. We could support such a thing, but
shouldn't do so by accident.
llvm-svn: 301497
|
|
distinct kind of input.
No functionality change intended.
llvm-svn: 301442
|
|
using metadata
Since Split DWARF needs to name the actual .dwo file that is generated,
it can't be known at the time the llvm::Module is produced as it may be
merged with other Modules before the object is generated and that object
may be generated with any name.
By passing the Split DWARF file name when LLVM is producing object code
the .dwo file name in the object file can match correctly.
The support for Split DWARF for implicit modules remains the same -
using metadata to store the dwo name and dwo id so that potentially
multiple skeleton CUs referring to different dwo files can be generated
from one llvm::Module.
llvm-svn: 301063
|
|
This commit teaches Clang to recognize editor placeholders that are produced
when an IDE like Xcode inserts a code-completion result that includes a
placeholder. Now when the lexer sees a placeholder token, it emits an
'editor placeholder in source file' error and creates an identifier token
that represents the placeholder. The parser/sema can now recognize the
placeholders and can suppress the diagnostics related to the placeholders. This
ensures that live issues in an IDE like Xcode won't get spurious diagnostics
related to placeholders.
This commit also adds a new compiler option named '-fallow-editor-placeholders'
that silences the 'editor placeholder in source file' error. This is useful
for an IDE like Xcode as we don't want to display those errors in live issues.
rdar://31581400
Differential Revision: https://reviews.llvm.org/D32081
llvm-svn: 300667
|
|
The driver needs to know whether it's building a module interface or
implementation unit because it affects which outputs it produces and how it
builds the command pipeline. But the frontend doesn't need to know and should
not care: all it needs to know is what action it is being asked to perform on
the input.
(This is in preparation for permitting -emit-obj to be used on a module
interface unit to produce object code without going via a "full" PCM file.)
llvm-svn: 300611
|
|
Remove the restriction where this is only valid with C++
rdar://problem/29055656
Differential Revision: https://reviews.llvm.org/D31781
llvm-svn: 300108
|
|
This allows using and testing these two features separately. (noteably,
debug info is, so far as I know, always a win (basically). But function
modular codegen is currently a loss for highly optimized code - where
most of the linkonce_odr definitions are optimized away, so providing
weak_odr definitions is only overhead)
llvm-svn: 300104
|
|
This isn't need anymore and modules options -fbuild-session-file and
-fmodules-validate-once-per-build-session already provide a sane
mechanism to validate the system headers.
rdar://problem/19767523
llvm-svn: 300027
|
|
Summary: Preserve vec3 type with CodeGen option.
Reviewers: Anastasia, bruno
Reviewed By: Anastasia
Subscribers: bruno, ahatanak, cfe-commits
Differential Revision: https://reviews.llvm.org/D30810
llvm-svn: 299445
|
|
This is handled in a similar way we handle invalid -mcode-model.
PR: 31840
llvm-svn: 299315
|
|
Summary:
The refactoring introduced a regression in the flag processing for
-fxray-instruction-threshold which causes it to not get passed properly.
This change should restore the previous behaviour.
Reviewers: rnk, pelikan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31491
llvm-svn: 299126
|
|
Summary:
The -fxray-always-instrument= and -fxray-never-instrument= flags take
filenames that are used to imbue the XRay instrumentation attributes
using a whitelist mechanism (similar to the sanitizer special cases
list). We use the same syntax and semantics as the sanitizer blacklists
files in the implementation.
As implemented, we respect the attributes that are already defined in
the source file (i.e. those that have the
[[clang::xray_{always,never}_instrument]] attributes) before applying
the always/never instrument lists.
Reviewers: rsmith, chandlerc
Subscribers: jfb, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30388
llvm-svn: 299041
|
|
FPContractModeKind is the codegen option flag which is already ternary (off,
on, fast). This makes it universally the type for the contractable info
across the front-end:
* In FPOptions (i.e. in the Sema + in the expression nodes).
* In LangOpts::DefaultFPContractMode which is the option that initializes
FPOptions in the Sema.
Another way to look at this change is that before fp-contractable on/off were
the only states handled to the front-end:
* For "on", FMA folding was performed by the front-end
* For "fast", we simply forwarded the flag to TargetOptions to handle it in
LLVM
Now off/on/fast are all exposed because for fast we will generate
fast-math-flags during CodeGen.
This is toward moving fp-contraction=fast from an LLVM TargetOption to a
FastMathFlag in order to fix PR25721.
---
This is a recommit of r299027 with an adjustment to the test
CodeGenCUDA/fp-contract.cu. The test assumed that even
though -ffp-contract=on is passed FE-based folding of FMA won't happen.
This is obviously wrong since the user is asking for this explicitly with the
option. CUDA is different that -ffp-contract=fast is on by default.
The test used to "work" because contract=fast and contract=on were maintained
separately and we didn't fold in the FE because contract=fast was on due to
the target-default. This patch consolidates the contract=on/fast/off state
into a ternary state hence the change in behavior.
---
Differential Revision: https://reviews.llvm.org/D31167
llvm-svn: 299033
|
|
This reverts commit r299027.
It's causing a test failure in clang's CodeGenCUDE/fp-contract.cu
llvm-svn: 299029
|
|
FPContractModeKind is the codegen option flag which is already ternary (off,
on, fast). This makes it universally the type for the contractable info
across the front-end:
* In FPOptions (i.e. in the Sema + in the expression nodes).
* In LangOpts::DefaultFPContractMode which is the option that initializes
FPOptions in the Sema.
Another way to look at this change is that before fp-contractable on/off were
the only states handled to the front-end:
* For "on", FMA folding was performed by the front-end
* For "fast", we simply forwarded the flag to TargetOptions to handle it in
LLVM
Now off/on/fast are all exposed because for fast we will generate
fast-math-flags during CodeGen.
This is toward moving fp-contraction=fast from an LLVM TargetOption to a
FastMathFlag in order to fix PR25721.
Differential Revision: https://reviews.llvm.org/D31167
llvm-svn: 299027
|
|
Summary: Enable cl_mad_enamle and cl_no_signed_zeros options when user turns on cl_unsafe_math_optimizations or cl_fast_relaxed_math options.
Reviewers: Anastasia, cfe-commits
Reviewed By: Anastasia
Subscribers: bader, yaxunl
Differential Revision: https://reviews.llvm.org/D31324
llvm-svn: 298838
|
|
The flag CXXOperatorNames was overwritten unconditionally
after being set for OpenCL.
There seems to be no necessity to set it, so removing the line.
llvm-svn: 298709
|
