| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Reverts llvm/llvm-project#147959
|
|
report_fatal_error is not a good way to report diagnostics to the users, so this switches to using actual diagnostic reporting mechanisms instead.
Fixes #147187
|
|
As reported in #138173, enabling `-ftime-report` adds pass timing info
to the stats file if `-stats-file` is specified. This was determined to
be WAI. However, if one intentionally wants to put timer information in
the stats file, using `-ftime-report` may lead to a lot of logspam (that
can't be removed by directing stderr to `/dev/null` as that would also
redirect compiler errors). To address this, this PR adds a flag
`-stats-file-timers` that adds timer data to the stats file without
outputting to stderr.
|
|
As we are now Sema-complete for OpenACC 3.4 (and thus have a conforming
implementation, in all modes), we can now set the _OPENACC macro
correctly.
Additionally, we remove the temporary 'override' functionality, which
was intended to allow people to experiment with this. We aren't having a
deprecation period as OpenACC support is still considered experimental.
|
|
(#148982)
This PR removes the command line parsing workaround introduced in
https://github.com/llvm/llvm-project/pull/146342 by moving
`LangOptions::ExceptionHandling` to `CodeGenOptions` that get parsed
even for IR input. Additionally, this improves layering, where the
codegen library now checks `CodeGenOptions` instead of `LangOptions` for
exception handling. (This got enabled by
https://github.com/llvm/llvm-project/pull/146422.)
|
|
Some `LangOptions` duplicate their `CodeGenOptions` counterparts. My
understanding is that this was done solely because some infrastructure
(like preprocessor initialization, serialization, module compatibility
checks, etc.) were only possible/convenient for `LangOptions`. This PR
implements the missing support for `CodeGenOptions`, which makes it
possible to remove some duplicate `LangOptions` fields and simplify the
logic. Motivated by https://github.com/llvm/llvm-project/pull/146342.
|
|
This PR introduces the use of pointer authentication to objective-c[++].
This includes:
* __ptrauth qualifier support for ivars
* protection of isa and super fields
* protection of SEL typed ivars
* protection of class_ro_t data
* protection of methodlist pointers and content
|
|
Alas reflection pushed p2719 out of C++26, so this PR changes the
diagnostics to reflect that for now type aware allocation is
functionally a clang extension.
|
|
Revert llvm/llvm-project#143520 for now since it’s causing issues for
people who are using symlinks and prefer to preserve the original path
(i.e. looks like we’ll have to make this configurable after all; I just
need to figure out how to pass `-no-canonical-prefixes` down through the
driver); I’m planning to refactor this a bit and reland it in a few
days.
|
|
(#146620)
This patch fixes an issue where Microsoft-specific layout attributes,
such as __declspec(empty_bases), were ignored during CUDA/HIP device
compilation on a Windows host. This caused a critical memory layout
mismatch between host and device objects, breaking libraries that rely
on these attributes for ABI compatibility.
The fix introduces a centralized hasMicrosoftRecordLayout() check within
the TargetInfo class. This check is aware of the auxiliary (host) target
and is set during TargetInfo::adjust if the host uses a Microsoft ABI.
The empty_bases, layout_version, and msvc::no_unique_address attributes
now use this centralized flag, ensuring device code respects them and
maintains layout consistency with the host.
Fixes: https://github.com/llvm/llvm-project/issues/146047
|
|
This can significantly shorten file paths to standard library headers,
e.g. on my system, `<ranges>` is currently printed as
```console
/usr/lib/gcc/x86_64-redhat-linux/15/../../../../include/c++/15/ranges
```
but with this change, we instead print
```console
/usr/include/c++/15/ranges
```
This is of course just a heuristic; there are paths that would get longer
as a result of this, so we use whichever path ends up being shorter.
@AaronBallman pointed out that this might be problematic for network
file systems since path resolution might take a while, so this is enabled
only for paths that are part of a local filesystem—though not on Windows
since there we noticed that the check itself is slow.
The file names are cached in `SourceManager`.
|
|
(#146910)
This is the `CodeGenOptions` counterpart to
https://github.com/llvm/llvm-project/pull/146766.
|
|
This removes the `{BENIGN,COMPATIBLE}{,_ENUM,_VALUE}_LANGOPT` X macros
controlling `LangOptions`. These are permutations of the base `LANGOPT`,
`ENUM_LANGOPT` and `VALUE_LANGOPT` X macros that also carry the
information of their effect on AST (and therefore module compatibility).
Their functionality is now implemented by passing `Benign`, `Compatible`
or `NotCompatible` argument to the base X macros and using C++17 `if
constexpr` in the clients to achieve the same codegen.
This PR solves this FIXME:
```
// FIXME: Clients should be able to more easily select whether they want
// different levels of compatibility versus how to handle different kinds
// of option.
```
The base X macros are preserved, since they are used in `LangOptions.h`
to generate different kinds of field and function declarations for
flags, values and enums, which can't be achieved with `if constexpr`.
The new syntax also forces developers to think about compatibility when
adding new language option, hopefully reducing the number of new options
that are affecting by default even though they are benign or compatible.
Note that the `BENIGN_` macros used to forward to their `COMPATIBLE_`
counterparts. I don't think this ever kicked in, since there are no
clients of the `.def` file that define `COMPATIBLE_` without also
defining `BENIGN_`. However, this might be something downstream forks
need to take care of by doing `if constexpr (CK::Compatibility ==
CK::Benign || CK::Compatibility == CK::Compatible)` in place of `#define
COMPATIBLE_`.
|
|
|
|
Summary:
This patch is mostly an NFC that renames the existing `-fopenmp-targets`
into `--offload-targets`. Doing this early to simplify a follow-up patch
that will hopefully allow this syntax to be used more generically over
the existing `--offload` syntax (which I think is mostly unmaintained
now.). Following in the well-trodden path of trying to pull language
specific offload options into generic ones, but right now this is still
just OpenMP specific.
|
|
The comment for `DiagnosticConsumer::BeginSourceFile()` states that
"diagnostics with source range information are required to only be
emitted in between BeginSourceFile() and EndSourceFile().". While
working on some upcoming changes to the static analyzer, we hit some
crashes when diagnostics were reported from the `EndOfMainFile` callback
in the preprocessor. This turned out to be because
`FrontEndAction::EndSourceFile()` notifies the diagnostic clients of the
end of the source file before it notifies the preprocessor. Thus, the
diagnostics from the preprocessor callback are reported when the
diagnostic client is no longer expecting any diagnostics.
The fix is to swap the order of the `EndSourceFile()` calls so that the
preprocessor is notified first.
I've added asserts to the `ClangTidyDiagnosticConsumer` to catch
unexpected diagnostics outside of a source file. Before swapping the
order of the calls as described above, this causes several failures in
the clang-tidy regression tests. With the swap, there are no failures in
`check-all`.
rdar://141230583
|
|
This is similar to -msve-vector-bits, but for streaming mode: it
constrains the legal values of "vscale", allowing optimizations based on
that constraint.
This also fixes conversions between SVE vectors and fixed-width vectors
in streaming functions with -msve-vector-bits and
-msve-streaming-vector-bits.
This rejects any use of arm_sve_vector_bits types in streaming
functions; if it becomes relevant, we could add
arm_sve_streaming_vector_bits types in the future.
This doesn't touch the __ARM_FEATURE_SVE_BITS define.
|
|
Fixes regression reported
https://github.com/llvm/llvm-project/pull/146342#issuecomment-3026600152
The test could probably be better. I'm not sure what special is
happening with the module
compile, but I can't seem to reproduce this with just a plain -cc1 run.
|
|
This will enable removal of a hack from the wasm backend
in a future change.
This feels unnecessarily clunky. I would assume something was
automatically parsing this and propagating it in the C++ case,
but I can't seem to find it. In particular it feels wrong that
I need to parse out the individual values, given they are listed
in the options.td file. We should also be parsing and forwarding
every flag that corresponds to something else in TargetOptions,
which requires auditing.
|
|
Co-authored-by: Kazu Hirata <kazu@google.com>
|
|
SourceLocation (#145711)
Introduce a type alias for the commonly used `std::pair<FileID,
unsigned>` to improve code readability, and make it easier for future
updates (64-bit source locations).
|
|
signature version (#144813)
This pr provides the ability to specify the root signature version as a
compiler option and to retain this in the root signature decl.
It also updates the methods to serialize the version when dumping the
declaration and to output the version when generating the metadata.
- Update `DXContainer.hI` to define the root signature versions
- Update `Options.td` and `LangOpts.h` to define the
`fdx-rootsignature-version` compiler option
- Update `Options.td` to provide an alias `force-rootsig-ver` in
clang-dxc
- Update `Decl.[h|cpp]` and `SeamHLSL.cpp` so that `RootSignatureDecl`
will retain its version type
- Updates `CGHLSLRuntime.cpp` to generate the extra metadata field
- Add tests to illustrate
Resolves https://github.com/llvm/llvm-project/issues/126557.
Note: this does not implement validation based on versioning.
https://github.com/llvm/llvm-project/issues/129940 is required to
retrieve the version and use it for validations.
|
|
The value was known already, but it was parsed as latest which is
incorrect because we are already doing clang 21.
|
|
This PR resubmits the changes from #136098, which was previously
reverted due to a build failure during the linking stage:
```
undefined reference to `llvm::DebugInfoCorrelate'
undefined reference to `llvm::ProfileCorrelate'
```
The root cause was that `llvm/lib/Frontend/Driver/CodeGenOptions.cpp`
references symbols from the `Instrumentation` component, but the
`LINK_COMPONENTS` in the `llvm/lib/Frontend/CMakeLists.txt` for
`LLVMFrontendDriver` did not include it. As a result, linking failed in
configurations where these components were not transitively linked.
### Fix:
This updated patch explicitly adds `Instrumentation` to
`LINK_COMPONENTS` in the relevant `llvm/lib/Frontend/CMakeLists.txt`
file to ensure the required symbols are properly resolved.
---------
Co-authored-by: ict-ql <168183727+ict-ql@users.noreply.github.com>
Co-authored-by: Chyaka <52224511+liliumshade@users.noreply.github.com>
Co-authored-by: Tarun Prabhu <tarunprabhu@gmail.com>
|
|
Static analysis flagged Input as a large object that would benefit from
being moved over being copied.
|
|
When passing `-save-temps` to clang, the generated preprocessed output
uses gnu line markers. This unexpectedly triggers gnu-line-marker
warnings when used with `-Weverything` or `-pedantic`. Even worse,
compilation fails if `-Werror` is used.
This change suppresses gnu-line-marker warnings when invoking clang with
input from a preprocessor job and the user has not otherwise explictly
specified `-Wgnu-line-marker` somewhere on the command line. Note that
this does apply to user provided preprocessed files.
fixes #63802
|
|
Static analysis flagged this since we could move MergedRanges since it
is a std::vector, a local and unused after that line. So there is a
potential saving.
|
|
(#142163)
We're planning on using the ASTPrinter in LLDB for AST dumping. But it
currently takes the output stream via `unique_ptr`. In LLDB we don't
have the output stream available in this form and instead it would be
convenient if we could just pass a reference to the stream.
This patch adds that overload.
|
|
These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
|
|
compiler" (#142159)
Reverts llvm/llvm-project#136098
|
|
(#136098)
This patch implements IR-based Profile-Guided Optimization support in
Flang through the following flags:
- `-fprofile-generate` for instrumentation-based profile generation
- `-fprofile-use=<dir>/file` for profile-guided optimization
Resolves #74216 (implements IR PGO support phase)
**Key changes:**
- Frontend flag handling aligned with Clang/GCC semantics
- Instrumentation hooks into LLVM PGO infrastructure
- LIT tests verifying:
- Instrumentation metadata generation
- Profile loading from specified path
- Branch weight attribution (IR checks)
**Tests:**
- Added gcc-flag-compatibility.f90 test module verifying:
- Flag parsing boundary conditions
- IR-level profile annotation consistency
- Profile input path normalization rules
- SPEC2006 benchmark results will be shared in comments
For details on LLVM's PGO framework, refer to [Clang PGO
Documentation](https://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization).
This implementation was developed by [XSCC Compiler
Team](https://github.com/orgs/OpenXiangShan/teams/xscc).
---------
Co-authored-by: ict-ql <168183727+ict-ql@users.noreply.github.com>
Co-authored-by: Tom Eccles <t@freedommail.info>
|
|
When the comment ends with a splice at EOF.
Fixes #141221
|
|
(#141131)
|
|
(#139584)"
This reverts commit e2a885537f11f8d9ced1c80c2c90069ab5adeb1d. Build failures were fixed right away and reverting the original commit without the fixes breaks the build again.
|
|
(#139584)"
This reverts commit 9e306ad4600c4d3392c194a8be88919ee758425c.
Multiple builtbot failures have been reported:
https://github.com/llvm/llvm-project/pull/139584
|
|
The `DiagnosticOptions` class is currently intrusively
reference-counted, which makes reasoning about its lifetime very
difficult in some cases. For example, `CompilerInvocation` owns the
`DiagnosticOptions` instance (wrapped in `llvm::IntrusiveRefCntPtr`) and
only exposes an accessor returning `DiagnosticOptions &`. One would
think this gives `CompilerInvocation` exclusive ownership of the object,
but that's not the case:
```c++
void shareOwnership(CompilerInvocation &CI) {
llvm::IntrusiveRefCntPtr<DiagnosticOptions> CoOwner = &CI.getDiagnosticOptions();
// ...
}
```
This is a perfectly valid pattern that is being actually used in the
codebase.
I would like to ensure the ownership of `DiagnosticOptions` by
`CompilerInvocation` is guaranteed to be exclusive. This can be
leveraged for a copy-on-write optimization later on. This PR changes
usages of `DiagnosticOptions` across `clang`, `clang-tools-extra` and
`lldb` to not be intrusively reference-counted.
|
|
This reverts commit 7a242387c950c7060143da6da0e6fb91f36bb458. Even after 175f8a44, the Modules/fmodules-validate-once-per-build-session.c test is not fixed on the clang-armv8-quick build bot. (Failure occurs on line 114.)
|
|
This reverts commit 18b885f66babff3a10451bc811ffc077d61ed8ee, effectively reapplying #139987. This commit fixes unit tests (for example ASTUnitTest.SaveLoadPreservesLangOptionsInPrintingPolicy) where the `ASTUnit::ModCache` pointer dereferenced within `ASTUnit::serialize()` was null. This commit makes sure each factory function does initialize `ASTUnit::ModCache`.
|
|
Since getLastArgValue returns StringRef, and the constructor of
SmallString accepts StringRef, we do not need to go through a
temporary instance of std::string.
|
|
|
|
Fixes #139375
Clang expects command line source locations to be provided using 1-based
indexing.
Currently, Clang does not reject zero as invalid argument for column or
line number, which can cause Clang to crash.
This commit extends validation in `ParsedSourceLocation::FromString` to
only accept (unsinged) non-zero integers.
|
|
Reverts llvm/llvm-project#138983
|
|
Timestamps are an implementation detail of the cross-process module
cache implementation. This PR hides it from the `ModuleCache` API, which
simplifies the in-process implementation.
|
|
There are checks in clang codebase that determine the type of source
file, associated with a given location - specifically, if it is an
ordonary file or comes from sources like command-line options or a
built-in definitions. These checks often rely on calls to
`getPresumedLoc`, which is relatively expensive. In certain cases, these
checks are combined, leading to repeated calculations of the costly
function negatively affecting compile time.
This change tries to optimize such checks. It must fix compile time
regression introduced in
https://github.com/llvm/llvm-project/pull/137306/.
---------
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
|
|
|
|
|
|
Force-validation of user headers was implemented in acb803e8 to deal
with files changing during build. The dependency scanner guarantees an
immutable file system during single build session, so the validation is
unnecessary. (We don't hit the disk too often due to the caching VFS,
but even avoiding going to the cache and deserializing the input files
makes sense.)
|
|
(#138234)
Move the Darwin framework search path logic from
InitHeaderSearch::AddDefaultIncludePaths to
DarwinClang::AddClangSystemIncludeArgs. Add a new -internal-iframework
cc1 argument to support the tool chain adding these paths.
Now that the tool chain is adding search paths via cc1 flag, they're
only added if they exist, so the Preprocessor/cuda-macos-includes.cu
test is no longer relevant.
Change Driver/driverkit-path.c and Driver/darwin-subframeworks.c to do
-### style testing similar to the darwin-header-search and
darwin-embedded-search-paths tests. Rename darwin-subframeworks.c to
darwin-framework-search-paths.c and have it test all framework search
paths, not just SubFrameworks.
Add a unit test to validate that the myriad of search path flags result
in the expected search path list.
Fixes https://github.com/llvm/llvm-project/issues/75638
|
|
replace '-mllvm -array-bounds-pseudofn' (#138577)
@fmayer introduced '-mllvm -array-bounds-pseudofn'
(https://github.com/llvm/llvm-project/pull/128977/) to make it easier to
see why crashes occurred, and to estimate with a profiler the cycles
spent on these array-bounds checks. This functionality could be usefully
generalized to other checks in future work.
This patch adds the plumbing for -fsanitize-annotate-debug-info, and
connects it to the existing array-bounds-pseudo-fn functionality i.e.,
-fsanitize-annotate-debug-info=array-bounds can be used as a replacement
for '-mllvm -array-bounds-pseudofn', though we do not yet delete the
latter.
Note: we replaced '-mllvm -array-bounds-pseudofn' in
clang/test/CodeGen/bounds-checking-debuginfo.c, because adding test
cases would modify the line numbers in the test assertions, and
therefore obscure that the test output is the same between '-mllvm
-array-bounds-pseudofn' and -fsanitize-annotate-debug-info=array-bounds.
|
|
The allocation interposition mode had a number of issues, which are
primarily addressed in the library component via
<https://github.com/ROCm/rocThrust/pull/543>. However, it is necessary
to interpose some additional symbols, which this patch does.
Furthermore, to implement this in a compatible way, we guard the new
implementation under a V1 macro, which is defined in addition to the
existing `__HIPSTDPAR_INTERPOSE_ALLOC__` one.
|
