| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
documentation for -fconstexpr-steps.
llvm-svn: 336747
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 331644
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As suggested in the post-commit thread for rL331056, we should match these
clang options with the established vocabulary of the corresponding sanitizer
option. Also, the use of 'strict' is well-known for these kinds of knobs,
and we can improve the descriptive text in the docs.
So this intends to match the logic of D46135 but only change the words.
Matching LLVM commit to match this spelling of the attribute to follow shortly.
Differential Revision: https://reviews.llvm.org/D46236
llvm-svn: 331209
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As discussed in the post-commit thread for:
rL330437 ( http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180423/545906.html )
We need a way to opt-out of a float-to-int-to-float cast optimization because too much
existing code relies on the platform-specific undefined result of those casts when the
float-to-int overflows.
The LLVM changes associated with adding this function attribute are here:
rL330947
rL330950
rL330951
Also as suggested, I changed the LLVM doc to mention the specific sanitizer flag that
catches this problem:
rL330958
Differential Revision: https://reviews.llvm.org/D46135
llvm-svn: 331041
|
|
|
|
| |
llvm-svn: 329052
|
|
|
|
|
|
|
|
|
|
|
| |
attribute for AMDGPU (CLANG)
- Remove use of the opencl and amdopencl environment member of the target triple for the AMDGPU target.
- Use a function attribute to communicate to the AMDGPU backend.
Differential Revision: https://reviews.llvm.org/D43735
llvm-svn: 328347
|
|
|
|
|
|
| |
Remove mention of -std=c94 (it is spelled iso9899:1994, not c94) and add mention of -std=c17 and -std=gnu17.
llvm-svn: 327264
|
|
|
|
| |
llvm-svn: 326438
|
|
|
|
| |
llvm-svn: 326434
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently, assertion-disabled Clang builds emit value names when generating LLVM IR. This is controlled by the `NDEBUG` macro, and is not easily overridable. In order to get IR output containing names from a release build of Clang, the user must manually construct the CC1 invocation w/o the `-discard-value-names` option. This is less than ideal.
For example, Godbolt uses a release build of Clang, and so when asked to emit LLVM IR the result lacks names, making it harder to read. Manually invoking CC1 on Compiler Explorer is not feasible.
This patch adds the driver options `-fdiscard-value-names` and `-fno-discard-value-names` which allow the user to override the default behavior. If neither is specified, the old behavior remains.
Reviewers: erichkeane, aaron.ballman, lebedev.ri
Reviewed By: aaron.ballman
Subscribers: bogner, cfe-commits
Differential Revision: https://reviews.llvm.org/D42887
llvm-svn: 324498
|
|
|
|
| |
llvm-svn: 323902
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Use monospace for option flags in the PCH section, instead of the
italics that were being used previously.
I believe these used to be links, for which single backticks would
have been appropriate, but since they were un-link-ified in
https://reviews.llvm.org/rL275560, I believe monospace is now more
appropriate, and so two backticks are needed.
Test Plan:
Build the `docs-clang-html` target and confirm the options are rendered
using monospace font.
Reviewers: sepavloff, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42005
llvm-svn: 322447
|
|
|
|
| |
llvm-svn: 321705
|
|
|
|
| |
llvm-svn: 321623
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang is inherently a cross compiler and can generate code for any target
enabled during build. It however requires to specify many parameters in the
invocation, which could be hardcoded during configuration process in the
case of single-target compiler. The purpose of configuration files is to
make specifying clang arguments easier.
A configuration file is a collection of driver options, which are inserted
into command line before other options specified in the clang invocation.
It groups related options together and allows specifying them in simpler,
more flexible and less error prone way than just listing the options
somewhere in build scripts. Configuration file may be thought as a "macro"
that names an option set and is expanded when the driver is called.
Use of configuration files is described in `UserManual.rst`.
Differential Revision: https://reviews.llvm.org/D24933
llvm-svn: 321621
|
|
|
|
|
|
| |
Need to check targets in tests more carefully.
llvm-svn: 321588
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang is inherently a cross compiler and can generate code for any target
enabled during build. It however requires to specify many parameters in the
invocation, which could be hardcoded during configuration process in the
case of single-target compiler. The purpose of configuration files is to
make specifying clang arguments easier.
A configuration file is a collection of driver options, which are inserted
into command line before other options specified in the clang invocation.
It groups related options together and allows specifying them in simpler,
more flexible and less error prone way than just listing the options
somewhere in build scripts. Configuration file may be thought as a "macro"
that names an option set and is expanded when the driver is called.
Use of configuration files is described in `UserManual.rst`.
Differential Revision: https://reviews.llvm.org/D24933
llvm-svn: 321587
|
|
|
|
| |
llvm-svn: 321562
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change allows generalizing pointers in type signatures used for
cfi-icall by enabling the -fsanitize-cfi-icall-generalize-pointers flag.
This works by 1) emitting an additional generalized type signature
metadata node for functions and 2) llvm.type.test()ing for the
generalized type for translation units with the flag specified.
This flag is incompatible with -fsanitize-cfi-cross-dso because it would
require emitting twice as many type hashes which would increase artifact
size.
Reviewers: pcc, eugenis
Reviewed By: pcc
Subscribers: kcc
Differential Revision: https://reviews.llvm.org/D39358
llvm-svn: 317044
|
|
|
|
| |
llvm-svn: 314061
|
|
|
|
| |
llvm-svn: 311854
|
|
|
|
| |
llvm-svn: 308427
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: The Clang option was previously not included in the User's Manual.
Reviewers: anemet, davidxl, hfinkel
Reviewed By: hfinkel
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D34928
llvm-svn: 307193
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One way to currently test the reproducers is to setup
"FORCE_CLANG_DIAGNOSTICS_CRASH=1" before invoking clang. This simulates
a crash and produces the same contents needed by the reproducers. The
reproducers are specially useful when triaging Modules issues, not only
on crashes, but also for reproducing misleading warnings, errors, etc.
Add a '-gen-reproducer' driver option to clang (or any similar name) and
give users a flag option.
Note that clang already has a -fno-crash-diagnostics, which disables the
crash reproducers. I've decided not to propose "-fcrash-diagnostics"
since it doesn't convey the ideia of reproduction despite a crash.
rdar://problem/24114619
Differential Revision: https://reviews.llvm.org/D27604
llvm-svn: 300109
|
|
|
|
| |
llvm-svn: 295433
|
|
|
|
|
|
|
|
|
| |
Added description of a new feature that allows to specify
vendor extension in flexible way using compiler pragma instead
of modifying source code directly (committed in clang@r289979).
Review: D29829
llvm-svn: 295313
|
|
|
|
|
|
|
|
|
|
|
| |
preprocessor macros.
Added "-fdebug-macro" flag (and "-fno-debug-macro" flag) to enable (and to disable) emitting macro debug info.
Added CC1 "-debug-info-macro" flag that enables emitting macro debug info.
Differential Revision: https://reviews.llvm.org/D16135
llvm-svn: 294637
|
|
|
|
|
|
| |
NFC.
llvm-svn: 293877
|
|
|
|
| |
llvm-svn: 292265
|
|
|
|
| |
llvm-svn: 292115
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add missing flag to UsersManual
It would be good to merge it to 4.0 branch.
Reviewers: hans
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28727
llvm-svn: 292112
|
|
|
|
| |
llvm-svn: 292015
|
|
|
|
|
|
|
|
|
|
| |
This time, make ignored options, such as /utf-8, show up as well if they
have help text.
Also, since we're now exposing -fdelayed-template-parsing, add help text
to the -fno version so that shows up as well.
llvm-svn: 291798
|
|
|
|
| |
llvm-svn: 291783
|
|
|
|
|
|
|
| |
Updated index and UsersManual with OpenCL description.
Review: https://reviews.llvm.org/D28080
llvm-svn: 291780
|
|
|
|
|
|
|
|
|
|
| |
This was accidentally removed in r260506, even though we only support
non-allocatable global register variables. The general (allocatable) case
is explicitly not supported.
Differential Revision: https://reviews.llvm.org/D27473
llvm-svn: 289455
|
|
|
|
|
|
| |
including Clang.
llvm-svn: 285341
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original commit message:
Add -fdiagnostics-show-hotness
Summary:
I've recently added the ability for optimization remarks to include the
hotness of the corresponding code region. This uses PGO and allows
filtering of the optimization remarks by relevance. The idea was first
discussed here:
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334
The general goal is to produce a YAML file with the remarks. Then, an
external tool could dynamically filter these by hotness and perhaps by
other things.
That said it makes sense to also expose this at the more basic level
where we just include the hotness info with each optimization remark.
For example, in D22694, the clang flag was pretty useful to measure the
overhead of the additional analyses required to include hotness.
(Without the flag we don't even run the analyses.)
For the record, Hal has already expressed support for the idea of this
patch on IRC.
Differential Revision: https://reviews.llvm.org/D23284
llvm-svn: 281293
|
|
|
|
|
|
|
|
| |
This reverts commit r281276.
Many bots are failing.
llvm-svn: 281279
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I've recently added the ability for optimization remarks to include the
hotness of the corresponding code region. This uses PGO and allows
filtering of the optimization remarks by relevance. The idea was first
discussed here:
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334
The general goal is to produce a YAML file with the remarks. Then, an
external tool could dynamically filter these by hotness and perhaps by
other things.
That said it makes sense to also expose this at the more basic level
where we just include the hotness info with each optimization remark.
For example, in D22694, the clang flag was pretty useful to measure the
overhead of the additional analyses required to include hotness.
(Without the flag we don't even run the analyses.)
For the record, Hal has already expressed support for the idea of this
patch on IRC.
Differential Revision: https://reviews.llvm.org/D23284
llvm-svn: 281276
|
|
|
|
|
|
|
|
| |
remark flags. For now I'm checking in a copy of the built documentation, but we
can replace this with a placeholder (as we do for the attributes reference
documentation) once we enable building this server-side.
llvm-svn: 281192
|
|
|
|
|
|
|
|
|
|
| |
to CC1, which are translated to function attributes and can e.g. be mapped on
build attributes FP_exceptions and FP_denormal. Setting these build attributes
allows better selection of floating point libraries.
Differential Revision: https://reviews.llvm.org/D23840
llvm-svn: 280064
|
|
|
|
| |
llvm-svn: 278710
|
|
|
|
| |
llvm-svn: 276891
|
|
|
|
|
|
|
| |
This patch enables raw profile merging for this option which is the
new intended behavior.
llvm-svn: 276484
|