History log of /llvm-project/clang/lib/Frontend/CompilerInvocation.cpp (Results 451 – 475 of 1971)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 5834996f 18-Nov-2020 Ben Barham <ben_barham@apple.com>

[Frontend] Add flag to allow PCM generation despite compiler errors

As with precompiled headers, it's useful for indexers to be able to
continue through compiler errors in dependent modules.

Resolv

[Frontend] Add flag to allow PCM generation despite compiler errors

As with precompiled headers, it's useful for indexers to be able to
continue through compiler errors in dependent modules.

Resolves rdar://69816264

Reviewed By: akyrtzi

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

show more ...


# 3f4b5893 16-Nov-2020 Yaxun (Sam) Liu <yaxun.liu@amd.com>

[AMDGPU] Add option -munsafe-fp-atomics

Add an option -munsafe-fp-atomics for AMDGPU target.

When enabled, clang adds function attribute "amdgpu-unsafe-fp-atomics"
to any functions for amdgpu targe

[AMDGPU] Add option -munsafe-fp-atomics

Add an option -munsafe-fp-atomics for AMDGPU target.

When enabled, clang adds function attribute "amdgpu-unsafe-fp-atomics"
to any functions for amdgpu target. This allows amdgpu backend to use
unsafe fp atomic instructions in these functions.

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

show more ...


# 2f3055c5 13-Nov-2020 Jan Svoboda <git@jansvoboda.dev>

[clang][cli] Add support for options with two flags for controlling the same field.

This enables automatically parsing and generating CC1 arguments for options where two flags control the same field

[clang][cli] Add support for options with two flags for controlling the same field.

This enables automatically parsing and generating CC1 arguments for options where two flags control the same field, e.g. -fexperimental-new-pass-manager and -fno-experimental new pass manager.

Reviewed By: Bigcheese, dexonsmith

Original patch by Daniel Grumberg.

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

show more ...


# 6861d938 14-Nov-2020 Roman Lebedev <lebedev.ri@gmail.com>

Revert "clang-misexpect: Profile Guided Validation of Performance Annotations in LLVM"

See discussion in https://bugs.llvm.org/show_bug.cgi?id=45073 / https://reviews.llvm.org/D66324#2334485
the imp

Revert "clang-misexpect: Profile Guided Validation of Performance Annotations in LLVM"

See discussion in https://bugs.llvm.org/show_bug.cgi?id=45073 / https://reviews.llvm.org/D66324#2334485
the implementation is known-broken for certain inputs,
the bugreport was up for a significant amount of timer,
and there has been no activity to address it.
Therefore, just completely rip out all of misexpect handling.

I suspect, fixing it requires redesigning the internals of MD_misexpect.
Should anyone commit to fixing the implementation problem,
starting from clean slate may be better anyways.

This reverts commit 7bdad08429411e7d0ecd58cd696b1efe3cff309e,
and some of it's follow-ups, that don't stand on their own.

show more ...


# d2d59d2b 11-Nov-2020 Jan Svoboda <jan_svoboda@apple.com>

Reland [clang][cli] Port ObjCMTAction to new option parsing system

Merge existing marhsalling info kinds and add some primitives to
express flag options that contribute to a bitfield.

Depends on D8

Reland [clang][cli] Port ObjCMTAction to new option parsing system

Merge existing marhsalling info kinds and add some primitives to
express flag options that contribute to a bitfield.

Depends on D82574

Original patch by Daniel Grumberg.

Reviewed By: Bigcheese

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

show more ...


# ac523d2d 12-Nov-2020 Kevin P. Neal <kevin.neal@sas.com>

[FPEnv][Clang][Driver] Use MarshallingInfoFlag for -fexperimental-strict-floating-point

As of D80952 we are disabling strict floating point on all hosts except
those that are explicitly listed as su

[FPEnv][Clang][Driver] Use MarshallingInfoFlag for -fexperimental-strict-floating-point

As of D80952 we are disabling strict floating point on all hosts except
those that are explicitly listed as supported. Use of strict floating point
on other hosts requires use of the -fexperimental-strict-floating-point
flag. This is to avoid bugs like "https://bugs.llvm.org/show_bug.cgi?id=45329"
(which has an incorrect link in the previous review).

In the review for D80952 I was asked to mark the -fexperimental option as
a MarshallingInfoFlag. This patch does exactly that.

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

show more ...


# 4e9af3d4 06-Nov-2020 Duncan P. N. Exon Smith <dexonsmith@apple.com>

Frontend: Skip namespace around createVFSFromCompilerInvocation definition, NFC

Qualify definitions with `clang::` rather than opening/closing a namespace.

Differential Revision: https://reviews.ll

Frontend: Skip namespace around createVFSFromCompilerInvocation definition, NFC

Qualify definitions with `clang::` rather than opening/closing a namespace.

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

show more ...


# f917356f 11-Nov-2020 Mehdi Amini <joker.eph@gmail.com>

Revert "[clang][cli] Port ObjCMTAction to new option parsing system"

This reverts commit 09248a5d25bb1c9f357247fa3da8fbe4470e9c67.

Some builds are broken. I suspect a `static constexpr` in a class

Revert "[clang][cli] Port ObjCMTAction to new option parsing system"

This reverts commit 09248a5d25bb1c9f357247fa3da8fbe4470e9c67.

Some builds are broken. I suspect a `static constexpr` in a class missing a
definition out of class (required pre-c++17).

show more ...


# 624bced7 11-Nov-2020 Elvina Yakubova <elvina.yakubova@huawei.com>

[OpenCL] Make Clang recognize -cl-std=1.0 as a value argument

This patch makes Clang recognize -cl-std=1.0 as a value argument,
before only -std=cl1.0 has to be used instead.

Fixes https://bugs.llv

[OpenCL] Make Clang recognize -cl-std=1.0 as a value argument

This patch makes Clang recognize -cl-std=1.0 as a value argument,
before only -std=cl1.0 has to be used instead.

Fixes https://bugs.llvm.org/show_bug.cgi?id=47981

Reviewed By: Anastasia

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

show more ...


# 09248a5d 11-Nov-2020 Jan Svoboda <jan_svoboda@apple.com>

[clang][cli] Port ObjCMTAction to new option parsing system

Merge existing marhsalling info kinds and add some primitives to
express flag options that contribute to a bitfield.

Depends on D82574

R

[clang][cli] Port ObjCMTAction to new option parsing system

Merge existing marhsalling info kinds and add some primitives to
express flag options that contribute to a bitfield.

Depends on D82574

Reviewed By: Bigcheese

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

show more ...


# 58c586e7 10-Nov-2020 Alexandre Rames <arames@apple.com>

Allow searching for prebuilt implicit modules.

This reverts commit c67656b994c87224e0b33e2c4b09093986a5cfa6, and addresses the
build issue.


# dbfa69c5 09-Nov-2020 Jan Svoboda <jan_svoboda@apple.com>

Port some floating point options to new option marshalling infrastructure

This ports a number of OpenCL and fast-math flags for floating point
over to the new marshalling infrastructure.

As part of

Port some floating point options to new option marshalling infrastructure

This ports a number of OpenCL and fast-math flags for floating point
over to the new marshalling infrastructure.

As part of this, `Opt{In,Out}FFlag` were enhanced to allow other flags to
imply them, via `DefaultAnyOf<>`. For example:
```
defm signed_zeros : OptOutFFlag<"signed-zeros", ...,
"LangOpts->NoSignedZero",
DefaultAnyOf<[cl_no_signed_zeros, menable_unsafe_fp_math]>>;
```
defines `-fsigned-zeros` (`false`) and `-fno-signed-zeros` (`true`)
linked to the keypath `LangOpts->NoSignedZero`, defaulting to `false`,
but set to `true` implicitly if one of `-cl-no-signed-zeros` or
`-menable-unsafe-fp-math` is on.

Note that the initial patch was written Daniel Grumberg.

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

show more ...


# c67656b9 06-Nov-2020 Stella Stamenova <stilis@microsoft.com>

Revert "Allow searching for prebuilt implicit modules."

This reverts commit 71e108cd86e70b06c5fa3a63689dcb3555c3d13f.

This change caused a build failure on Windows:
http://lab.llvm.org:8011/#/build

Revert "Allow searching for prebuilt implicit modules."

This reverts commit 71e108cd86e70b06c5fa3a63689dcb3555c3d13f.

This change caused a build failure on Windows:
http://lab.llvm.org:8011/#/builders/83/builds/570

show more ...


# 71e108cd 05-Nov-2020 Alexandre Rames <arames@apple.com>

Allow searching for prebuilt implicit modules.

The behavior is controlled by the `-fprebuilt-implicit-modules` option, and
allows searching for implicit modules in the prebuilt module cache paths.

Allow searching for prebuilt implicit modules.

The behavior is controlled by the `-fprebuilt-implicit-modules` option, and
allows searching for implicit modules in the prebuilt module cache paths.

The current command-line options for prebuilt modules do not allow to easily
maintain and use multiple versions of modules. Both the producer and users of
prebuilt modules are required to know the relationships between compilation
options and module file paths. Using a particular version of a prebuilt module
requires passing a particular option on the command line (e.g.
`-fmodule-file=[<name>=]<file>` or `-fprebuilt-module-path=<directory>`).

However the compiler already knows how to distinguish and automatically locate
implicit modules. Hence this proposal to introduce the
`-fprebuilt-implicit-modules` option. When set, it enables searching for
implicit modules in the prebuilt module paths (specified via
`-fprebuilt-module-path`). To not modify existing behavior, this search takes
place after the standard search for prebuilt modules. If not

Here is a workflow illustrating how both the producer and consumer of prebuilt
modules would need to know what versions of prebuilt modules are available and
where they are located.

clang -cc1 -x c modulemap -fmodules -emit-module -fmodule-name=foo -fmodules-cache-path=prebuilt_modules_v1 <config 1 options>
clang -cc1 -x c modulemap -fmodules -emit-module -fmodule-name=foo -fmodules-cache-path=prebuilt_modules_v2 <config 2 options>
clang -cc1 -x c modulemap -fmodules -emit-module -fmodule-name=foo -fmodules-cache-path=prebuilt_modules_v3 <config 3 options>

clang -cc1 -x c use.c -fmodules fmodule-map-file=modulemap -fprebuilt-module-path=prebuilt_modules_v1 <config 1 options>
clang -cc1 -x c use.c -fmodules fmodule-map-file=modulemap <non-prebuilt config options>

With prebuilt implicit modules, the producer can generate prebuilt modules as
usual, all in the same output directory. The same mechanisms as for implicit
modules take care of incorporating hashes in the path to distinguish between
module versions.

Note that we do not specify the output module filename, so `-o` implicit modules are generated in the cache path `prebuilt_modules`.

clang -cc1 -x c modulemap -fmodules -emit-module -fmodule-name=foo -fmodules-cache-path=prebuilt_modules <config 1 options>
clang -cc1 -x c modulemap -fmodules -emit-module -fmodule-name=foo -fmodules-cache-path=prebuilt_modules <config 2 options>
clang -cc1 -x c modulemap -fmodules -emit-module -fmodule-name=foo -fmodules-cache-path=prebuilt_modules <config 3 options>

The user can now simply enable prebuilt implicit modules and point to the
prebuilt modules cache. No need to "parse" command-line options to decide
what prebuilt modules (paths) to use.

clang -cc1 -x c use.c -fmodules fmodule-map-file=modulemap -fprebuilt-module-path=prebuilt_modules -fprebuilt-implicit-modules <config 1 options>
clang -cc1 -x c use.c -fmodules fmodule-map-file=modulemap -fprebuilt-module-path=prebuilt_modules -fprebuilt-implicit-modules <non-prebuilt config options>

This is for example particularly useful in a use-case where compilation is
expensive, and the configurations expected to be used are predictable, but not
controlled by the producer of prebuilt modules. Modules for the set of
predictable configurations can be prebuilt, and using them does not require
"parsing" the configuration (command-line options).

Reviewed By: Bigcheese

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

show more ...


# ae9231ca 02-Nov-2020 Ben Dunbobbin <Ben.Dunbobbin@sony.com>

Reland - [Clang] Add the ability to map DLL storage class to visibility

415f7ee883 had LIT test failures on any build where the clang executable
was not called "clang". I have adjusted the LIT CHECK

Reland - [Clang] Add the ability to map DLL storage class to visibility

415f7ee883 had LIT test failures on any build where the clang executable
was not called "clang". I have adjusted the LIT CHECKs to remove the
binary name to fix this.

Original commit message:

For PlayStation we offer source code compatibility with
Microsoft's dllimport/export annotations; however, our file
format is based on ELF.

To support this we translate from DLL storage class to ELF
visibility at the end of codegen in Clang.

Other toolchains have used similar strategies (e.g. see the
documentation for this ARM toolchain:

https://developer.arm.com/documentation/dui0530/i/migrating-from-rvct-v3-1-to-rvct-v4-0/changes-to-symbol-visibility-between-rvct-v3-1-and-rvct-v4-0)

This patch adds the ability to perform this translation. Options
are provided to support customizing the mapping behaviour.

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

show more ...


# 5024d3aa 02-Nov-2020 Ben Dunbobbin <Ben.Dunbobbin@sony.com>

Revert "[Clang] Add the ability to map DLL storage class to visibility"

This reverts commit 415f7ee8836944942d8beb70e982e95a312866a7.

The added tests were failing on the build bots!


# 415f7ee8 02-Nov-2020 Ben Dunbobbin <Ben.Dunbobbin@sony.com>

[Clang] Add the ability to map DLL storage class to visibility

For PlayStation we offer source code compatibility with
Microsoft's dllimport/export annotations; however, our file
format is based on

[Clang] Add the ability to map DLL storage class to visibility

For PlayStation we offer source code compatibility with
Microsoft's dllimport/export annotations; however, our file
format is based on ELF.

To support this we translate from DLL storage class to ELF
visibility at the end of codegen in Clang.

Other toolchains have used similar strategies (e.g. see the
documentation for this ARM toolchain:

https://developer.arm.com/documentation/dui0530/i/migrating-from-rvct-v3-1-to-rvct-v4-0/changes-to-symbol-visibility-between-rvct-v3-1-and-rvct-v4-0)

This patch adds the ability to perform this translation. Options
are provided to support customizing the mapping behaviour.

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

show more ...


# 0949f96d 29-Sep-2020 Teresa Johnson <tejohnson@google.com>

[MemProf] Pass down memory profile name with optional path from clang

Similar to -fprofile-generate=, add -fmemory-profile= which takes a
directory path. This is passed down to LLVM via a new module

[MemProf] Pass down memory profile name with optional path from clang

Similar to -fprofile-generate=, add -fmemory-profile= which takes a
directory path. This is passed down to LLVM via a new module flag
metadata. LLVM in turn provides this name to the runtime via the new
__memprof_profile_filename variable.

Additionally, always pass a default filename (in $cwd if a directory
name is not specified vi the = form of the option). This is also
consistent with the behavior of the PGO instrumentation. Since the
memory profiles will generally be fairly large, it doesn't make sense to
dump them to stderr. Also, importantly, the memory profiles will
eventually be dumped in a compact binary format, which is another reason
why it does not make sense to send these to stderr by default.

Change the existing memprof tests to specify log_path=stderr when that
was being relied on.

Depends on D89086.

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

show more ...


# 13aee94b 29-Oct-2020 Mircea Trofin <mtrofin@google.com>

[ThinLTO] Fix empty .llvmcmd sections

When passing -lto-embed-bitcode=post-merge-pre-opt, we were getting
empty .llvmcmd sections. It turns out that is because the
CodeGenOptions::CmdArgs field was

[ThinLTO] Fix empty .llvmcmd sections

When passing -lto-embed-bitcode=post-merge-pre-opt, we were getting
empty .llvmcmd sections. It turns out that is because the
CodeGenOptions::CmdArgs field was only populated when clang saw
-fembed-bitcode={all|marker}.

This patch always populates the CodeGenOptions::CmdArgs. The overhead
of carrying through in memory in all cases is likely negligible in
the grand schema of things, and it keeps the using code simple.

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

show more ...


# 57cdc52c 22-Oct-2020 Venkataramanan Kumar <venkataramanan.kumar.llvm@gmail.com>

Initial support for vectorization using Libmvec (GLIBC vector math library)

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


# 7c3fea77 22-Oct-2020 Xiang1 Zhang <xiang1.zhang@intel.com>

[X86] Support customizing stack protector guard

Reviewed By: nickdesaulniers, MaskRay

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


# 2484e915 20-Oct-2020 Fangrui Song <i@maskray.me>

[Driver] Clean up -gz & --compress-debug-sections

* Make cc1 and cc1as --compress-debug-sections an alias for --compress-debug-sections=zlib
* Make -gz an alias for -gz=zlib

The new behavior is con

[Driver] Clean up -gz & --compress-debug-sections

* Make cc1 and cc1as --compress-debug-sections an alias for --compress-debug-sections=zlib
* Make -gz an alias for -gz=zlib

The new behavior is consistent with GCC when binutils>=2.26 is detected:
-gz is translated to --compress-debug-sections=zlib instead of --compress-debug-sections.

show more ...


# 545c687c 20-Oct-2020 Fangrui Song <i@maskray.me>

[gcov] Unify driver and CC1 option names for -ftest-coverage & -fprofile-arcs

No need to use -femit-coverage-notes and -femit-coverage-data.


# 0ab222e7 20-Oct-2020 Fangrui Song <i@maskray.me>

[gcov] Delete CC1 option -test-coverage

The name is unfortunate because it is similar to the driver option -ftest-coverage.
It turns out aside from one occurrence in a test, this option is not used.


# 774ab601 20-Oct-2020 Douglas Yung <douglas.yung@sony.com>

Add option to use older clang ABI behavior when passing certain union types as function arguments

Recently commit D78699 (commit 26cfb6e562f1), fixed clang's behavior with respect
to passing a union

Add option to use older clang ABI behavior when passing certain union types as function arguments

Recently commit D78699 (commit 26cfb6e562f1), fixed clang's behavior with respect
to passing a union type through a register to correctly follow the ABI. However,
this is an ABI breaking change with earlier versions of the clang compiler, so we
should add an -fclang-abi-compat option to address this. Additionally, the PS4 ABI
requires the older behavior, so that is added as well.

This change adds a Ver11 value to the ClangABI enum that when it is set (or the
target is the PS4 triple), we skip the ABI fix introduced in D78699.

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

show more ...


1...<<11121314151617181920>>...79