History log of /llvm-project/clang/lib/Frontend/CompilerInvocation.cpp (Results 601 – 625 of 1971)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# fc6057e3 22-Feb-2020 Fangrui Song <maskray@google.com>

[Frontend] Replace CC1 option -mcode-model with -mcmodel=

Before:

% clang -mcmodel=x -xc /dev/null
error: invalid argument 'x' in '-mcode-model x'

Now:

% clang -mcmodel=x -xc /dev/null
clang-11:

[Frontend] Replace CC1 option -mcode-model with -mcmodel=

Before:

% clang -mcmodel=x -xc /dev/null
error: invalid argument 'x' in '-mcode-model x'

Now:

% clang -mcmodel=x -xc /dev/null
clang-11: error: invalid argument 'x' to -mcmodel=

show more ...


# 2f215cf3 20-Feb-2020 Djordje Todorovic <djordje.todorovic@rt-rk.com>

Revert "Reland "[DebugInfo] Enable the debug entry values feature by default""

This reverts commit rGfaff707db82d.
A failure found on an ARM 2-stage buildbot.
The investigation is needed.


# faff707d 19-Feb-2020 Djordje Todorovic <djordje.todorovic@rt-rk.com>

Reland "[DebugInfo] Enable the debug entry values feature by default"

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


# 2bf44d11 18-Feb-2020 Djordje Todorovic <djordje.todorovic@rt-rk.com>

Revert "Reland "[DebugInfo] Enable the debug entry values feature by default""

This reverts commit rGa82d3e8a6e67.


# a82d3e8a 18-Feb-2020 Djordje Todorovic <djordje.todorovic@rt-rk.com>

Reland "[DebugInfo] Enable the debug entry values feature by default"

This patch enables the debug entry values feature.

- Remove the (CC1) experimental -femit-debug-entry-values option
- Enabl

Reland "[DebugInfo] Enable the debug entry values feature by default"

This patch enables the debug entry values feature.

- Remove the (CC1) experimental -femit-debug-entry-values option
- Enable it for x86, arm and aarch64 targets
- Resolve the test failures
- Leave the llc experimental option for targets that do not
support the CallSiteInfo yet

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

show more ...


# 97ed706a 12-Feb-2020 Djordje Todorovic <djordje.todorovic@rt-rk.com>

Revert "[DebugInfo] Enable the debug entry values feature by default"

This reverts commit rG9f6ff07f8a39.

Found a test failure on clang-with-thin-lto-ubuntu buildbot.


# 55e2678f 11-Feb-2020 jasonliu <jasonliu.development@gmail.com>

[clang] Add -fignore-exceptions

Summary:

This is trying to implement the functionality proposed in:
http://lists.llvm.org/pipermail/cfe-dev/2017-April/053417.html
An exception can throw, but no cle

[clang] Add -fignore-exceptions

Summary:

This is trying to implement the functionality proposed in:
http://lists.llvm.org/pipermail/cfe-dev/2017-April/053417.html
An exception can throw, but no cleanup is going to happen.
A module compiled with exceptions on, can catch the exception throws
from module compiled with -fignore-exceptions.

The use cases for enabling this option are:
1. Performance analysis of EH instrumentation overhead
2. The ability to QA non EH functionality when EH functionality is not available.
3. User of EH enabled headers knows the calls won't throw in their program and
wants the performance gain from ignoring EH construct.

The implementation tried to accomplish that by removing any landing pad code
that might get generated.

Reviewed by: aaron.ballman

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

show more ...


# 9f6ff07f 10-Feb-2020 Djordje Todorovic <djordje.todorovic@rt-rk.com>

[DebugInfo] Enable the debug entry values feature by default

This patch enables the debug entry values feature.

- Remove the (CC1) experimental -femit-debug-entry-values option
- Enable it for

[DebugInfo] Enable the debug entry values feature by default

This patch enables the debug entry values feature.

- Remove the (CC1) experimental -femit-debug-entry-values option
- Enable it for x86, arm and aarch64 targets
- Resolve the test failures
- Leave the llc experimental option for targets that do not
support the CallSiteInfo yet

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

show more ...


# 14f87036 11-Feb-2020 Ian Levesque <ianlevesque@fb.com>

[xray][clang] Always add xray-skip-entry/exit and xray-ignore-loops attrs

The function attributes xray-skip-entry, xray-skip-exit, and
xray-ignore-loops were only being applied if a function had an

[xray][clang] Always add xray-skip-entry/exit and xray-ignore-loops attrs

The function attributes xray-skip-entry, xray-skip-exit, and
xray-ignore-loops were only being applied if a function had an
xray-instrument attribute, but they should apply if xray is enabled
globally too.

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

show more ...


# e67cbac8 09-Sep-2019 serge_sans_paille <sguelton@redhat.com>

Support -fstack-clash-protection for x86

Implement protection against the stack clash attack [0] through inline stack
probing.

Probe stack allocation every PAGE_SIZE during frame lowering or dynami

Support -fstack-clash-protection for x86

Implement protection against the stack clash attack [0] through inline stack
probing.

Probe stack allocation every PAGE_SIZE during frame lowering or dynamic
allocation to make sure the page guard, if any, is touched when touching the
stack, in a similar manner to GCC[1].

This extends the existing `probe-stack' mechanism with a special value `inline-asm'.
Technically the former uses function call before stack allocation while this
patch provides inlined stack probes and chunk allocation.

Only implemented for x86.

[0] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
[1] https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00556.html

This a recommit of 39f50da2a357a8f685b3540246c5d762734e035f with proper LiveIn
declaration, better option handling and more portable testing.

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

show more ...


# 45462116 09-Feb-2020 serge-sans-paille <sguelton@redhat.com>

Revert "Support -fstack-clash-protection for x86"

This reverts commit 0fd51a4554f5f4f90342f40afd35b077f6d88213.

Failures:

http://lab.llvm.org:8011/builders/llvm-clang-win-x-armv7l/builds/4354


# 0fd51a45 09-Sep-2019 serge_sans_paille <sguelton@redhat.com>

Support -fstack-clash-protection for x86

Implement protection against the stack clash attack [0] through inline stack
probing.

Probe stack allocation every PAGE_SIZE during frame lowering or dynami

Support -fstack-clash-protection for x86

Implement protection against the stack clash attack [0] through inline stack
probing.

Probe stack allocation every PAGE_SIZE during frame lowering or dynamic
allocation to make sure the page guard, if any, is touched when touching the
stack, in a similar manner to GCC[1].

This extends the existing `probe-stack' mechanism with a special value `inline-asm'.
Technically the former uses function call before stack allocation while this
patch provides inlined stack probes and chunk allocation.

Only implemented for x86.

[0] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
[1] https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00556.html

This a recommit of 39f50da2a357a8f685b3540246c5d762734e035f with proper LiveIn
declaration, better option handling and more portable testing.

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

show more ...


# 658495e6 08-Feb-2020 serge-sans-paille <sguelton@redhat.com>

Revert "Support -fstack-clash-protection for x86"

This reverts commit e229017732bcf1911210903ee9811033d5588e0d.

Failures:

http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-debia

Revert "Support -fstack-clash-protection for x86"

This reverts commit e229017732bcf1911210903ee9811033d5588e0d.

Failures:

http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-debian/builds/2604
http://lab.llvm.org:8011/builders/llvm-clang-win-x-aarch64/builds/4308

show more ...


# e2290177 09-Sep-2019 serge_sans_paille <sguelton@redhat.com>

Support -fstack-clash-protection for x86

Implement protection against the stack clash attack [0] through inline stack
probing.

Probe stack allocation every PAGE_SIZE during frame lowering or dynami

Support -fstack-clash-protection for x86

Implement protection against the stack clash attack [0] through inline stack
probing.

Probe stack allocation every PAGE_SIZE during frame lowering or dynamic
allocation to make sure the page guard, if any, is touched when touching the
stack, in a similar manner to GCC[1].

This extends the existing `probe-stack' mechanism with a special value `inline-asm'.
Technically the former uses function call before stack allocation while this
patch provides inlined stack probes and chunk allocation.

Only implemented for x86.

[0] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
[1] https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00556.html

This a recommit of 39f50da2a357a8f685b3540246c5d762734e035f with better option
handling and more portable testing

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

show more ...


# b03c3d8c 07-Feb-2020 Nico Weber <thakis@chromium.org>

Revert "Support -fstack-clash-protection for x86"

This reverts commit 4a1a0690ad6813a4c8cdb8dc20ea6337aa1f61e0.
Breaks tests on mac and win, see https://reviews.llvm.org/D68720


# 4a1a0690 09-Sep-2019 serge_sans_paille <sguelton@redhat.com>

Support -fstack-clash-protection for x86

Implement protection against the stack clash attack [0] through inline stack
probing.

Probe stack allocation every PAGE_SIZE during frame lowering or dynami

Support -fstack-clash-protection for x86

Implement protection against the stack clash attack [0] through inline stack
probing.

Probe stack allocation every PAGE_SIZE during frame lowering or dynamic
allocation to make sure the page guard, if any, is touched when touching the
stack, in a similar manner to GCC[1].

This extends the existing `probe-stack' mechanism with a special value `inline-asm'.
Technically the former uses function call before stack allocation while this
patch provides inlined stack probes and chunk allocation.

Only implemented for x86.

[0] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
[1] https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00556.html

This a recommit of 39f50da2a357a8f685b3540246c5d762734e035f with correct option
flags set.

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

show more ...


# 75f09b54 07-Feb-2020 Alexandre Ganea <alexandre.ganea@ubisoft.com>

Re-land "[Clang][Driver] Remove -M group options ..." and "[Clang] Avoid crashing when generating crash diagnostics when '#pragma clang __debug ..."

This re-lands commits f41ec709d9d388dc43469e6ac7f

Re-land "[Clang][Driver] Remove -M group options ..." and "[Clang] Avoid crashing when generating crash diagnostics when '#pragma clang __debug ..."

This re-lands commits f41ec709d9d388dc43469e6ac7f51b6313f7e4af (https://reviews.llvm.org/D74076)
and commit 5fedc2b410853a6aef05e8edf19ebfc4e071e28f (https://reviews.llvm.org/D74070)

The previous build break was caused by '#pragma clang __debug llvm_unreachable' used in a non-assert build. Move it to a separate test in crash-report-with-asserts.c.

show more ...


# f6d98429 07-Feb-2020 serge-sans-paille <sguelton@redhat.com>

Revert "Support -fstack-clash-protection for x86"

This reverts commit 39f50da2a357a8f685b3540246c5d762734e035f.

The -fstack-clash-protection is being passed to the linker too, which
is not intended

Revert "Support -fstack-clash-protection for x86"

This reverts commit 39f50da2a357a8f685b3540246c5d762734e035f.

The -fstack-clash-protection is being passed to the linker too, which
is not intended.

Reverting and fixing that in a later commit.

show more ...


# 9d869180 07-Feb-2020 Diogo Sampaio <diogo.sampaio@arm.com>

[ARM] Follow AACPS for preserving number of loads/stores of volatile bit-fields

Summary:
Following the AAPCS, every store to a volatile bit-field requires to generate one load of that field, even if

[ARM] Follow AACPS for preserving number of loads/stores of volatile bit-fields

Summary:
Following the AAPCS, every store to a volatile bit-field requires to generate one load of that field, even if all the bits are going to be replaced.
This patch allows the user to opt-in in following such rule, whenever the a.

AAPCS Release 2019Q1.1 (https://static.docs.arm.com/ihi0042/g/aapcs32.pdf)
section 8.1 Data Types, page 35, paragraph: Volatile bit-fields – preserving number and width of container accesses

```
When a volatile bit-field is written, and its container does not overlap with any non-bit-field member, its
container must be read exactly once and written exactly once using the access width appropriate to the
type of the container. The two accesses are not atomic.

```

Reviewers: lebedev.ri, ostannard, jfb, eli.friedman

Reviewed By: jfb

Subscribers: rsmith, rjmccall, dexonsmith, kristof.beyls, jfb, cfe-commits

Tags: #clang

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

show more ...


# 39f50da2 09-Sep-2019 serge_sans_paille <sguelton@redhat.com>

Support -fstack-clash-protection for x86

Implement protection against the stack clash attack [0] through inline stack
probing.

Probe stack allocation every PAGE_SIZE during frame lowering or dynami

Support -fstack-clash-protection for x86

Implement protection against the stack clash attack [0] through inline stack
probing.

Probe stack allocation every PAGE_SIZE during frame lowering or dynamic
allocation to make sure the page guard, if any, is touched when touching the
stack, in a similar manner to GCC[1].

This extends the existing `probe-stack' mechanism with a special value `inline-asm'.
Technically the former uses function call before stack allocation while this
patch provides inlined stack probes and chunk allocation.

Only implemented for x86.

[0] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
[1] https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00556.html

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

show more ...


# fafddbd9 07-Feb-2020 Jordan Rupprecht <rupprecht@google.com>

Revert "[Clang][Driver] Remove -M group options ..." and "[Clang] Avoid crashing when generating crash diagnostics when '#pragma clang __debug ..."

This reverts commits f41ec709d9d388dc43469e6ac7f51

Revert "[Clang][Driver] Remove -M group options ..." and "[Clang] Avoid crashing when generating crash diagnostics when '#pragma clang __debug ..."

This reverts commits f41ec709d9d388dc43469e6ac7f51b6313f7e4af and 5fedc2b410853a6aef05e8edf19ebfc4e071e28f. On some buildbots, Clang :: Driver/crash-report.c is broken with:

```
Command Output (stderr):
--
/home/buildslave/ps4-buildslave1/clang-with-thin-lto-ubuntu/llvm-project/clang/test/Driver/crash-report.c:48:11: error: CHECK: expected string not found in input
// CHECK: Preprocessed source(s) and associated run script(s) are located at:
^
<stdin>:1:1: note: scanning from here
/home/buildslave/ps4-buildslave1/clang-with-thin-lto-ubuntu/llvm-project/clang/test/Driver/crash-report.c:50:1: error: unknown type name 'BAZ'
```

Example: http://lab.llvm.org:8011/builders/clang-with-thin-lto-ubuntu/builds/21321/steps/test-stage1-compiler/logs/stdio

show more ...


# 5fedc2b4 06-Feb-2020 Alexandre Ganea <alexandre.ganea@ubisoft.com>

[Clang] Avoid crashing when generating crash diagnostics when '#pragma clang __debug [assert|crash|parser_crash|llvm_fatal_error|llvm_unreachable|overflow_stack]' are used

Previously, when the above

[Clang] Avoid crashing when generating crash diagnostics when '#pragma clang __debug [assert|crash|parser_crash|llvm_fatal_error|llvm_unreachable|overflow_stack]' are used

Previously, when the above '#pragma clang __debug' were used, Driver::generateCompilationDiagnostics() wouldn't work as expected.
The 'clang -E' process created for diagnostics would crash, because it would reach again the intended crash in Pragma.cpp, PragmaDebugHandler::HandlePragma() while preprocessing.

When generating crash diagnostics, we now disable the intended crashing behavior with a new cc1 flag -disable-pragma-debug-crash.

Notes:
- #pragma clang __debug llvm_report_fatal isn't currently tested by crash-report.c, because it needs exit() to be handled differently in -fintegrated-cc1 mode. See https://reviews.llvm.org/D73742 for an upcoming fix.
- This is also needed to further validate that -MF is removed from the 'clang -E ' crash diagnostic cmd-line (currently not the case). See https://reviews.llvm.org/D74076 for an upcoming fix.

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

show more ...


# ccac6b2b 03-Feb-2020 Michael Liao <michael.hliao@gmail.com>

[hip] Properly populate macros based on host processor.

Summary:
- The device compilation needs to have a consistent source code compared
to the corresponding host compilation. If macros based on

[hip] Properly populate macros based on host processor.

Summary:
- The device compilation needs to have a consistent source code compared
to the corresponding host compilation. If macros based on the
host-specific target processor is not properly populated, the device
compilation may fail due to the inconsistent source after the
preprocessor. So far, only the host triple is used to build the
macros. If a detailed host CPU target or certain features are
specified, macros derived from them won't be populated properly, e.g.
`__SSE3__` won't be added unless `+sse3` feature is present. On
Windows compilation compatible with MSVC, that missing macros result
in that intrinsics are not included and cause device compilation
failure on the host-side source.

- This patch addresses this issue by introducing two `cc1` options,
i.e., `-aux-target-cpu` and `-aux-target-feature`. If a specific host
CPU target or certain features are specified, the compiler driver will
append them during the construction of the offline compilation
actions. Then, the toolchain in `cc1` phase will populate macros
accordingly.

- An internal option `--gpu-use-aux-triple-only` is added to fall back
the original behavior to help diagnosing potential issues from the new
behavior.

Reviewers: tra, yaxunl

Subscribers: cfe-commits

Tags: #clang

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

show more ...


# a3c814d2 07-Nov-2019 Matt Arsenault <Matthew.Arsenault@amd.com>

Separately track input and output denormal mode

AMDGPU and x86 at least both have separate controls for whether
denormal results are flushed on output, and for whether denormals are
implicitly treat

Separately track input and output denormal mode

AMDGPU and x86 at least both have separate controls for whether
denormal results are flushed on output, and for whether denormals are
implicitly treated as 0 as an input. The current DAGCombiner use only
really cares about the input treatment of denormals.

show more ...


# 2513118a 04-Feb-2020 Fangrui Song <maskray@google.com>

[Driver] Change -fmax-tokens $arg to -fmax-tokens=$arg

Reviewed By: hans

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


1...<<21222324252627282930>>...79