History log of /llvm-project/clang/lib/Frontend/CompilerInvocation.cpp (Results 251 – 275 of 1971)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# e1ed0218 21-Sep-2021 Arthur Eubanks <aeubanks@google.com>

[clang] Make -Rpass imply -Rpass=.*

Previously with -Rpass (and friends) we'd have remarks "enabled", but
without an actual regex.

As seen in the test change to line numbers, this can give us bette

[clang] Make -Rpass imply -Rpass=.*

Previously with -Rpass (and friends) we'd have remarks "enabled", but
without an actual regex.

As seen in the test change to line numbers, this can give us better
diagnostics by properly enabling NeedLocTracking with -Rpass.

Reviewed By: dblaikie

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

show more ...


# 29b44ca8 09-Sep-2021 Joseph Huber <jhuber6@vols.utk.edu>

[OpenMP] Add flag for setting debug in the offloading device

This patch introduces the flags `-fopenmp-target-debug` and
`-fopenmp-target-debug=` to set the value of a global in the device.
This wil

[OpenMP] Add flag for setting debug in the offloading device

This patch introduces the flags `-fopenmp-target-debug` and
`-fopenmp-target-debug=` to set the value of a global in the device.
This will be used to enable or disable debugging features statically in
the device runtime library.

Reviewed By: jdoerfert

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

show more ...


# 0a9d740c 08-Sep-2021 Usman Nadeem <mnadeem@quicinc.com>

[clang][Driver] Update/cleanup LTO logic to ensure that the last lto argument is honored

- Make flto an alias of flto=full.
- Make foffload-lto an alias of foffload-lto=full.
- Make flto_EQ_jobserve

[clang][Driver] Update/cleanup LTO logic to ensure that the last lto argument is honored

- Make flto an alias of flto=full.
- Make foffload-lto an alias of foffload-lto=full.
- Make flto_EQ_jobserver, flto_EQ_auto aliases of flto=full,
since they are being treated as full lto right now.
- Clean up the code for parseLTOMode and setLTOMode.
- Replace uses of OPT_flto with OPT_flto_EQ since they alias now.

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

Change-Id: I5d867db83a680434fba5c8d85c9a83135d3b81ee

show more ...


# 54612a03 08-Sep-2021 Usman Nadeem <mnadeem@quicinc.com>

Revert "[clang][Driver] Update/cleanup LTO logic to ensure that the last lto argument is honored"

This reverts commit d2d2e5ea480feb09dc0edeac2eb14310de74b372.


# d2d2e5ea 08-Sep-2021 Usman Nadeem <mnadeem@quicinc.com>

[clang][Driver] Update/cleanup LTO logic to ensure that the last lto argument is honored

- Make flto an alias of flto=full.
- Make foffload-lto an alias of foffload-lto=full.
- Make flto_EQ_jobserve

[clang][Driver] Update/cleanup LTO logic to ensure that the last lto argument is honored

- Make flto an alias of flto=full.
- Make foffload-lto an alias of foffload-lto=full.
- Make flto_EQ_jobserver, flto_EQ_auto aliases of flto=full,
since they are being treated as full lto right now.
- Clean up the code for parseLTOMode and setLTOMode.
- Replace uses of OPT_flto with OPT_flto_EQ since they alias now.

Change-Id: Iea5338c20cb800b43529b20745e92600e2cfd2b1

show more ...


# 655bea42 03-Sep-2021 Alexandre Rames <arames@apple.com>

[modules] Use `HashBuilder` and `MD5` for the module hash.

Per the comments, `hash_code` values "are not stable to save or
persist", so are unsuitable for the module hash, which must persist
across

[modules] Use `HashBuilder` and `MD5` for the module hash.

Per the comments, `hash_code` values "are not stable to save or
persist", so are unsuitable for the module hash, which must persist
across compilations for the implicit module hashes to match. Note that
in practice, today, `hash_code` are stable. But this is an
implementation detail, with a clear `FIXME` indicating we should switch
to a per-execution seed.

The stability of `MD5` also allows modules cross-compilation use-cases.
The `size_t` underlying storage for `hash_code` varying across platforms
could cause mismatching hashes when cross-compiling from a 64bit
target to a 32bit target.

Note that native endianness is still used for the hash computation. So hashes
will differ between platforms of different endianness.

Reviewed By: jansvoboda11

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

show more ...


# 555a817d 30-Aug-2021 Jan Svoboda <jan_svoboda@apple.com>

[clang] NFC: Extract DiagnosticOptions parsing

The way we parse `DiagnosticOptions` is a bit involved.

`DiagnosticOptions` are parsed as part of the cc1-parsing function `CompilerInvocation::Create

[clang] NFC: Extract DiagnosticOptions parsing

The way we parse `DiagnosticOptions` is a bit involved.

`DiagnosticOptions` are parsed as part of the cc1-parsing function `CompilerInvocation::CreateFromArgs` which takes `DiagnosticsEngine` as an argument to be able to report errors in command-line arguments. But to create `DiagnosticsEngine`, `DiagnosticOptions` are needed. This is solved by exposing the `ParseDiagnosticArgs` to clients and making its `DiagnosticsEngine` argument optional, essentially breaking the dependency cycle.

The `ParseDiagnosticArgs` function takes `llvm::opt::ArgList &`, which each client needs to create from the command-line (typically represented as `std::vector<const char *>`). Creating this data structure in this context is somewhat particular. This code pattern is copy-pasted in some places across the upstream code base and also in downstream repos. To make things a bit more uniform, this patch extracts the code into a new reusable function: `CreateAndPopulateDiagOpts`.

Reviewed By: dexonsmith

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

show more ...


# cec7c2b3 01-Sep-2021 Zahira Ammarguellat <zahira.ammarguellat@intel.com>

Revert "[CLANG][PATCH][FPEnv] Add support for option -ffp-eval-method and extend #pragma float_control similarly"
The intent of this patch is to add support of -fp-model=[source|double|extended] to a

Revert "[CLANG][PATCH][FPEnv] Add support for option -ffp-eval-method and extend #pragma float_control similarly"
The intent of this patch is to add support of -fp-model=[source|double|extended] to allow
the compiler to use a wider type for intermediate floating point calculations. As a side
effect to that, the value of FLT_EVAL_METHOD is changed according to the pragma
float_control.
Unfortunately some issue was uncovered with this change in preprocessing. See details in
https://reviews.llvm.org/D93769 . We are therefore reverting this patch until we find a way
to reconcile the value of FLT_EVAL_METHOD, the pragma and the -E flow.

This reverts commit 66ddac22e2a7f268e91c26d694112970dfa607ae.

show more ...


# f9bc1b3b 24-Aug-2021 Justas Janickas <Justas.Janickas@arm.com>

[OpenCL] Defines helper function for kernel language compatible OpenCL version

This change defines a helper function getOpenCLCompatibleVersion()
inside LangOptions class. The function contains mapp

[OpenCL] Defines helper function for kernel language compatible OpenCL version

This change defines a helper function getOpenCLCompatibleVersion()
inside LangOptions class. The function contains mapping between
C++ for OpenCL versions and their corresponding compatible OpenCL
versions. This mapping function should be updated each time a new
C++ for OpenCL language version is introduced. The helper function
is expected to simplify conditions on OpenCL C and C++ for OpenCL
versions inside compiler code.

Code refactoring performed.

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

show more ...


# 0d0628b2 12-Aug-2021 Justas Janickas <Justas.Janickas@arm.com>

[OpenCL] C++ for OpenCL version 2021 introduced to command line.

Introduces language standard `lang_openclcpp2021` and allows
`clc++2021` as a version flag for `-cl-std` in command line.
Defines mac

[OpenCL] C++ for OpenCL version 2021 introduced to command line.

Introduces language standard `lang_openclcpp2021` and allows
`clc++2021` as a version flag for `-cl-std` in command line.
Defines macros related to C++ for OpenCL version 2021.

C++ for OpenCL version 2021 has been proposed in an RFC:
https://lists.llvm.org/pipermail/cfe-dev/2021-August/068593.html

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

show more ...


# cfdfb75c 06-Aug-2021 Justas Janickas <Justas.Janickas@arm.com>

[OpenCL] Clang diagnostics allow reporting C++ for OpenCL version.

Some Clang diagnostics could only report OpenCL C version. Because
C++ for OpenCL can be used as an alternative to OpenCL C, the te

[OpenCL] Clang diagnostics allow reporting C++ for OpenCL version.

Some Clang diagnostics could only report OpenCL C version. Because
C++ for OpenCL can be used as an alternative to OpenCL C, the text
for diagnostics should reflect that.

Desrciptions modified for these diagnostics:
`err_opencl_unknown_type_specifier`
`warn_option_invalid_ocl_version`
`err_attribute_requires_opencl_version`
`warn_opencl_attr_deprecated_ignored`
`ext_opencl_ext_vector_type_rgba_selector`

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

show more ...


# 7df405e0 04-Aug-2021 Pavel Asyutchenko <sventeam@yandex.ru>

Apply -fmacro-prefix-map to __builtin_FILE()

This matches the behavior of GCC.
Patch does not change remapping logic itself, so adding one simple smoke test should be enough.

Reviewed By: MaskRay

Apply -fmacro-prefix-map to __builtin_FILE()

This matches the behavior of GCC.
Patch does not change remapping logic itself, so adding one simple smoke test should be enough.

Reviewed By: MaskRay

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

show more ...


# 05561386 04-Aug-2021 Jan Svoboda <jan_svoboda@apple.com>

[clang][cli] Expose -fno-cxx-modules in cc1

For some use-cases, it might be useful to be able to turn off modules for C++ in `-cc1`. (The feature is implied by `-std=C++20`.)

This patch exposes the

[clang][cli] Expose -fno-cxx-modules in cc1

For some use-cases, it might be useful to be able to turn off modules for C++ in `-cc1`. (The feature is implied by `-std=C++20`.)

This patch exposes the `-fno-cxx-modules` option in `-cc1`.

Reviewed By: arphaman

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

show more ...


# acc58504 30-Jul-2021 Anton Zabaznov <anton.zabaznov@intel.com>

[OpenCL] Add support of __opencl_c_pipes feature macro.

'pipe' keyword is introduced in OpenCL C 2.0: so do checks for OpenCL C version while
parsing and then later on check for language options to

[OpenCL] Add support of __opencl_c_pipes feature macro.

'pipe' keyword is introduced in OpenCL C 2.0: so do checks for OpenCL C version while
parsing and then later on check for language options to construct actual pipe. This feature
requires support of __opencl_c_generic_address_space, so diagnostics for that is provided as well.

This is the same patch as in D106748 but with a tiny fix in checking of diagnostic messages.
Also added tests when program scope global variables are not supported.

Reviewed By: Anastasia

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

show more ...


# 577220e8 29-Jul-2021 Anastasia Stulova <anastasia.stulova@arm.com>

[OpenCL] Add std flag aliases clc++1.0 and CLC++1.0

Renamed language standard from openclcpp to openclcpp10.
Added new std values i.e. '-cl-std=clc++1.0' and
'-cl-std=CLC++1.0'.

Patch by Topotuna (

[OpenCL] Add std flag aliases clc++1.0 and CLC++1.0

Renamed language standard from openclcpp to openclcpp10.
Added new std values i.e. '-cl-std=clc++1.0' and
'-cl-std=CLC++1.0'.

Patch by Topotuna (Justas Janickas)!

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

show more ...


# da6626d1 30-Jul-2021 Anton Zabaznov <anton.zabaznov@intel.com>

Revert "[OpenCL] Add support of __opencl_c_pipes feature macro."

This reverts commit d1e4b25756730576996457ba7324e9bf210e3693.


# d1e4b257 30-Jul-2021 Anton Zabaznov <anton.zabaznov@intel.com>

[OpenCL] Add support of __opencl_c_pipes feature macro.

'pipe' keyword is introduced in OpenCL C 2.0: so do checks for OpenCL C version while
parsing and then later on check for language options to

[OpenCL] Add support of __opencl_c_pipes feature macro.

'pipe' keyword is introduced in OpenCL C 2.0: so do checks for OpenCL C version while
parsing and then later on check for language options to construct actual pipe. This feature
requires support of __opencl_c_generic_address_space, so diagnostics for that is provided as well.

Reviewed By: Anastasia

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

show more ...


# 66ddac22 28-Jul-2021 Melanie Blower <melanie.blower@intel.com>

[CLANG][PATCH][FPEnv] Add support for option -ffp-eval-method and extend #pragma float_control similarly

The Intel compiler ICC supports the option "-fp-model=(source|double|extended)"
which causes

[CLANG][PATCH][FPEnv] Add support for option -ffp-eval-method and extend #pragma float_control similarly

The Intel compiler ICC supports the option "-fp-model=(source|double|extended)"
which causes the compiler to use a wider type for intermediate floating point
calculations. Also supported is a way to embed this effect in the source
program with #pragma float_control(source|double|extended).
This patch extends pragma float_control syntax, and also adds support
for a new floating point option "-ffp-eval-method=(source|double|extended)".
source: intermediate results use source precision
double: intermediate results use double precision
extended: intermediate results use extended precision

Reviewed By: Aaron Ballman

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

show more ...


# 81600160 26-Jul-2021 Anastasia Stulova <anastasia.stulova@arm.com>

[OpenCL] Change default standard version to CL1.2

Set default version for OpenCL C to 1.2. This means that the
absence of any standard flag will be equivalent to passing
'-cl-std=CL1.2'.

Note that

[OpenCL] Change default standard version to CL1.2

Set default version for OpenCL C to 1.2. This means that the
absence of any standard flag will be equivalent to passing
'-cl-std=CL1.2'.

Note that this patch also fixes incorrect version check for
the pointer to pointer kernel arguments diagnostic and
atomic test.

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

show more ...


# 3e2ad26b 22-Jul-2021 Amy Huang <akhuang@google.com>

[DebugInfo] Add -fno-ctor-homing for as counterpart to -fuse-ctor-homing

Add an opt out flag for constructor homing.

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


# d48ad358 20-Jul-2021 Melanie Blower <melanie.blower@intel.com>

Revert "[CLANG][PATCH][FPEnv] Add support for option -ffp-eval-method and extend #pragma float_control similarly"

This reverts commit ce8024e8ff76e7be8b9ffa1a39d1dc9310bf74c7.
There are a couple bui

Revert "[CLANG][PATCH][FPEnv] Add support for option -ffp-eval-method and extend #pragma float_control similarly"

This reverts commit ce8024e8ff76e7be8b9ffa1a39d1dc9310bf74c7.
There are a couple buildbot problems

show more ...


# ce8024e8 20-Jul-2021 Melanie Blower <melanie.blower@intel.com>

[CLANG][PATCH][FPEnv] Add support for option -ffp-eval-method and extend #pragma float_control similarly

The Intel compiler ICC supports the option "-fp-model=(source|double|extended)"
which causes

[CLANG][PATCH][FPEnv] Add support for option -ffp-eval-method and extend #pragma float_control similarly

The Intel compiler ICC supports the option "-fp-model=(source|double|extended)"
which causes the compiler to use a wider type for intermediate floating point
calculations. Also supported is a way to embed this effect in the source
program with #pragma float_control(source|double|extended).
This patch extends pragma float_control syntax, and also adds support
for a new floating point option "-ffp-eval-method=(source|double|extended)".
source: intermediate results use source precision
double: intermediate results use double precision
extended: intermediate results use extended precision

Reviewed By: Aaron Ballman

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

show more ...


# 61fa9afe 07-Apr-2021 Haowei Wu <haowei@google.com>

[ifs] Prepare llvm-ifs for elfabi/ifs merging.

This diff changes llvm-ifs to use unified IFS file format
and perform other renaming changes in preparation for the
merging between elfabi/ifs.

Differ

[ifs] Prepare llvm-ifs for elfabi/ifs merging.

This diff changes llvm-ifs to use unified IFS file format
and perform other renaming changes in preparation for the
merging between elfabi/ifs.

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

show more ...


# e5c7c171 23-Jun-2021 Martin Storsjö <martin@martin.st>

[clang] Rename StringRef _lower() method calls to _insensitive()

This is mostly a mechanical change, but a testcase that contains
parts of the StringRef class (clang/test/Analysis/llvm-conventions.c

[clang] Rename StringRef _lower() method calls to _insensitive()

This is mostly a mechanical change, but a testcase that contains
parts of the StringRef class (clang/test/Analysis/llvm-conventions.cpp)
isn't touched.

show more ...


# 76c931ae 23-Jun-2021 Zarko Todorovski <zarko@ca.ibm.com>

[AIX][PowerPC] Remove error when specifying mabi=vec-default on AIX

The default Altivec ABI was implemented but the clang error for specifying
its use still remains. Users could get around this but

[AIX][PowerPC] Remove error when specifying mabi=vec-default on AIX

The default Altivec ABI was implemented but the clang error for specifying
its use still remains. Users could get around this but not specifying the
type of Altivec ABI but we need to remove the error.

Reviewed By: jsji

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

show more ...


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