History log of /llvm-project/clang/lib/Frontend/CompilerInvocation.cpp (Results 1276 – 1300 of 1971)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 825fb3c9 09-Jun-2015 Aaron Ballman <aaron@aaronballman.com>

Removing spurious semi colons; NFC.

llvm-svn: 239400


# 14facf30 09-Jun-2015 Sean Silva <chisophugis@gmail.com>

range-for'ify Args->filtered_begin(...) loops

We already have Args->filtered(...) which is a drop-in range-for
replacement.

llvm-svn: 239381


# ab70cfa3 09-Jun-2015 Sean Silva <chisophugis@gmail.com>

Simplify this code a bit.

We weren't using the short-circuiting property anyway.

llvm-svn: 239376


# dc9293d0 03-Jun-2015 Rafael Espindola <rafael.espindola@gmail.com>

Revert "add the -mrecip driver flag and process its options (2nd try)"

This reverts commit r238851.

It depends on a llvm commit that was reverted.

llvm-svn: 238904


# d79da016 02-Jun-2015 Sanjay Patel <spatel@rotateright.com>

add the -mrecip driver flag and process its options (2nd try)

The first try to land this (r238055) was reverted due to bot failures
caused by the LLVM part of the patch. That was hopefully fixed by

add the -mrecip driver flag and process its options (2nd try)

The first try to land this (r238055) was reverted due to bot failures
caused by the LLVM part of the patch. That was hopefully fixed by r238788,
and the LLVM patch was resubmitted at r238842.

This is the front-end counterpart to D8982.

The -mrecip option interface is based on maintaining compatibility with gcc:
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/i386-and-x86-64-Options.html#index-mrecip_003dopt-1627
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/RS_002f6000-and-PowerPC-Options.html#index-mrecip-2289

...while adding more functionality (allowing users to specify the number of refinement steps for each
estimate type).

Differential Revision: http://reviews.llvm.org/D8989

llvm-svn: 238851

show more ...


# 3204b152 29-May-2015 Benjamin Kramer <benny.kra@googlemail.com>

Replace push_back(Constructor(foo)) with emplace_back(foo) for non-trivial types

If the type isn't trivially moveable emplace can skip a potentially
expensive move. It also saves a couple of charact

Replace push_back(Constructor(foo)) with emplace_back(foo) for non-trivial types

If the type isn't trivially moveable emplace can skip a potentially
expensive move. It also saves a couple of characters.


Call sites were found with the ASTMatcher + some semi-automated cleanup.

memberCallExpr(
argumentCountIs(1), callee(methodDecl(hasName("push_back"))),
on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))),
hasArgument(0, bindTemporaryExpr(
hasType(recordDecl(hasNonTrivialDestructor())),
has(constructExpr()))),
unless(isInTemplateInstantiation()))

No functional change intended.

llvm-svn: 238601

show more ...


# 992c6fa5 23-May-2015 Rafael Espindola <rafael.espindola@gmail.com>

This reverts commit r238064 and r238055.

They depend on a reverted llvm commit.

llvm-svn: 238076


# f5019e60 22-May-2015 Sanjay Patel <spatel@rotateright.com>

add the -mrecip driver flag and process its options

This is the front-end counterpart to D8982 (LLVM r238051).

The -mrecip option interface is based on maintaining compatibility with gcc:
https://g

add the -mrecip driver flag and process its options

This is the front-end counterpart to D8982 (LLVM r238051).

The -mrecip option interface is based on maintaining compatibility with gcc:
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/i386-and-x86-64-Options.html#index-mrecip_003dopt-1627
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/RS_002f6000-and-PowerPC-Options.html#index-mrecip-2289

...while adding more functionality (allowing users to specify the number of refinement steps for each
estimate type).

Differential Revision: http://reviews.llvm.org/D8989

llvm-svn: 238055

show more ...


# 24d59d14 22-May-2015 Faisal Vali <faisalv@yahoo.com>

"This adds -fconcepts-ts as a cc1 option for enabling the
in-progress implementation of the Concepts TS. The recommended feature
test macro __cpp_experimental_concepts is set to 1 (as opposed to
2015

"This adds -fconcepts-ts as a cc1 option for enabling the
in-progress implementation of the Concepts TS. The recommended feature
test macro __cpp_experimental_concepts is set to 1 (as opposed to
201501) to indicate that the feature is enabled, but the
implementation is incomplete.

The link to the Concepts TS in cxx_status is updated to refer to the
PDTS (N4377). Additional changes related to __has_feature and
__has_extension are to follow in a later change.

Relevant tests include:

test/Lexer/cxx-features.cpp

The test file is updated with testing of the C++14 + Concepts TS mode.
The expected behaviour is the same as that of the C++14 modes except
for the case of __cpp_experimental_concepts."

- Hubert Tong.

Being committed for Hubert (as per his understanding with Richard Smith) as we start work on the concepts-ts following our preliminary strategy session earlier today.

The patch is tiny and seems quite standard.

Thanks Hubert!

llvm-svn: 237982

show more ...


# db39021c 20-May-2015 Alexey Bataev <a.bataev@hotmail.com>

[OPENMP] -fopenmp enables OpenMP support (fix for http://llvm.org/PR23492)

-fopenmp turns on OpenMP support and links libiomp5 as OpenMP library. Also there is -fopenmp={libiomp5|libgomp} option tha

[OPENMP] -fopenmp enables OpenMP support (fix for http://llvm.org/PR23492)

-fopenmp turns on OpenMP support and links libiomp5 as OpenMP library. Also there is -fopenmp={libiomp5|libgomp} option that allows to override effect of -fopenmp and link libgomp library (if -fopenmp=libgomp is specified).
Differential Revision: http://reviews.llvm.org/D9736

llvm-svn: 237769

show more ...


# 42413141 15-May-2015 Richard Smith <richard-llvm@metafoo.co.uk>

[modules] Add local submodule visibility support for declarations.

With this change, enabling -fmodules-local-submodule-visibility results in name
visibility rules being applied to submodules of the

[modules] Add local submodule visibility support for declarations.

With this change, enabling -fmodules-local-submodule-visibility results in name
visibility rules being applied to submodules of the current module in addition
to imported modules (that is, names no longer "leak" between submodules of the
same top-level module). This also makes it much safer to textually include a
non-modular library into a module: each submodule that textually includes that
library will get its own "copy" of that library, and so the library becomes
visible no matter which including submodule you import.

llvm-svn: 237473

show more ...


Revision tags: llvmorg-3.6.1
# e9bcddd5 14-May-2015 Pirama Arumuga Nainar <pirama@google.com>

Add flag to enable native half type

Summary:
r235215 enables support in LLVM for legalizing f16 type in the IR. AArch64
already had support for this. r235215 and some backend patches brought suppo

Add flag to enable native half type

Summary:
r235215 enables support in LLVM for legalizing f16 type in the IR. AArch64
already had support for this. r235215 and some backend patches brought support
for ARM, X86, X86-64, Mips and Mips64.

This change exposes the LangOption 'NativeHalfType' in the command line, so the
backend legalization can be used if desired. NativeHalfType is enabled for
OpenCL (current behavior) or if '-fnative-half-type' is set.

Reviewers: olista01, steven_wu, ab

Subscribers: cfe-commits, srhines, aemerson

Differential Revision: http://reviews.llvm.org/D9781

llvm-svn: 237406

show more ...


# 470d9424 13-May-2015 Peter Collingbourne <peter@pcc.me.uk>

Make GNUInline consistent with whether we use traditional GNU inline semantics.

Previously we were setting LangOptions::GNUInline (which controls whether we
use traditional GNU inline semantics) if

Make GNUInline consistent with whether we use traditional GNU inline semantics.

Previously we were setting LangOptions::GNUInline (which controls whether we
use traditional GNU inline semantics) if the language did not have the C99
feature flag set. The trouble with this is that C++ family languages also
do not have that flag set, so we ended up setting this flag in C++ modes
(and working around it in a few places downstream by also checking CPlusPlus).

The fix is to check whether the C89 flag is set for the target language,
rather than whether the C99 flag is cleared. This also lets us remove most
CPlusPlus checks. We continue to test CPlusPlus when deciding whether to
pre-define the __GNUC_GNU_INLINE__ macro for consistency with GCC.

There is a change in semantics in two other places
where we weren't checking both CPlusPlus and GNUInline
(FunctionDecl::doesDeclarationForceExternallyVisibleDefinition and
FunctionDecl::isInlineDefinitionExternallyVisible), but this change seems to
put us back into line with GCC's semantics (test case: test/CodeGen/inline.c).

While at it, forbid -fgnu89-inline in C++ modes, as GCC doesn't support it,
it didn't have any effect before, and supporting it just makes things more
complicated.

Differential Revision: http://reviews.llvm.org/D9333

llvm-svn: 237299

show more ...


# bf59c34b 11-May-2015 Peter Collingbourne <peter@pcc.me.uk>

Move sanitizer parser and group expander from Driver to Basic.

No functional change.

Differential Revision: http://reviews.llvm.org/D9621

llvm-svn: 237056


# 3eea677f 11-May-2015 Peter Collingbourne <peter@pcc.me.uk>

Unify sanitizer kind representation between the driver and the rest of the compiler.

No functional change.

Differential Revision: http://reviews.llvm.org/D9618

llvm-svn: 237055


Revision tags: llvmorg-3.6.1-rc1
# 52cc487b 07-May-2015 Artem Belevich <tra@google.com>

[cuda] Include GPU binary into host object file and generate init/deinit code.

- added -fcuda-include-gpubinary option to incorporate results of
device-side compilation into host-side one.
- gener

[cuda] Include GPU binary into host object file and generate init/deinit code.

- added -fcuda-include-gpubinary option to incorporate results of
device-side compilation into host-side one.
- generate code to register GPU binaries and associated kernels
with CUDA runtime and clean-up on exit.
- added test case for init/deinit code generation.

Differential Revision: http://reviews.llvm.org/D9507

llvm-svn: 236765

show more ...


# 3f3b3abe 07-May-2015 Alexey Samsonov <vonosmas@gmail.com>

[SanitizerCoverage] Give clang-cc1 the power to precisly specify needed sanitizier coverage mode.

Summary:
The next step is to add user-friendly control over these options
to driver via -fsanitize-c

[SanitizerCoverage] Give clang-cc1 the power to precisly specify needed sanitizier coverage mode.

Summary:
The next step is to add user-friendly control over these options
to driver via -fsanitize-coverage= option.

Test Plan: regression test suite

Reviewers: kcc

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D9545

llvm-svn: 236756

show more ...


# ee977933 01-May-2015 Richard Smith <richard-llvm@metafoo.co.uk>

[modules] Add -fmodules-local-submodule-visibility flag.

This flag specifies that the normal visibility rules should be used even for
local submodules (submodules of the currently-being-built module

[modules] Add -fmodules-local-submodule-visibility flag.

This flag specifies that the normal visibility rules should be used even for
local submodules (submodules of the currently-being-built module). Thus names
will only be visible if a header / module that declares them has actually been
included / imported, and not merely because a submodule that happened to be
built earlier declared those names. This also removes the need to modularize
bottom-up: textually-included headers will be included into every submodule
that includes them, since their include guards will not leak between modules.

So far, this only governs visibility of macros, not of declarations, so is not
ready for real use yet.

llvm-svn: 236350

show more ...


# a71e6817 30-Apr-2015 Justin Bogner <mail@justinbogner.com>

InstrProf: Support for setting profile output from command line

This change is the third of 3 patches to add support for specifying
the profile output from the command line via -fprofile-instr-gener

InstrProf: Support for setting profile output from command line

This change is the third of 3 patches to add support for specifying
the profile output from the command line via -fprofile-instr-generate=<path>,
where the specified output path/file will be overridden by the
LLVM_PROFILE_FILE environment variable.

This patch adds the necessary support to the clang frontend, and adds a
new test.

The compiler-rt and llvm parts are r236055 and r236288, respectively.

Patch by Teresa Johnson. Thanks!

llvm-svn: 236289

show more ...


# d7214a76 27-Apr-2015 Paul Robinson <paul_robinson@playstation.sony.com>

Support generating NMake/Jom-style depfiles.

NMake is a Make-like builder that comes with Microsoft Visual Studio.
Jom (https://wiki.qt.io/Jom) is an NMake-compatible build tool.
Dependency files fo

Support generating NMake/Jom-style depfiles.

NMake is a Make-like builder that comes with Microsoft Visual Studio.
Jom (https://wiki.qt.io/Jom) is an NMake-compatible build tool.
Dependency files for NMake/Jom need to use double-quotes to wrap
filespecs containing special characters, instead of the backslash
escapes that GNU Make wants.

Adds the -MV option, which specifies to use double-quotes as needed
instead of backslash escapes when writing the dependency file.

Differential Revision: http://reviews.llvm.org/D9260

llvm-svn: 235903

show more ...


# 4bdc50ec 15-Apr-2015 Eli Bendersky <eliben@google.com>

Create a frontend flag to disable CUDA cross-target call checks

For CUDA source, Sema checks that the targets of call expressions make sense
(e.g. a host function can't call a device function).

Add

Create a frontend flag to disable CUDA cross-target call checks

For CUDA source, Sema checks that the targets of call expressions make sense
(e.g. a host function can't call a device function).

Adding a flag that lets us skip this check. Motivation: for source-to-source
translation tools that have to accept code that's not strictly kosher CUDA but
is still accepted by nvcc. The source-to-source translation tool can then fix
the code and leave calls that are semantically valid for the actual compilation
stage.

Differential Revision: http://reviews.llvm.org/D9036

llvm-svn: 235049

show more ...


# bb61825c 15-Apr-2015 Duncan P. N. Exon Smith <dexonsmith@apple.com>

uselistorder: -mllvm -preserve-bc-use-list-order => -emit-llvm-uselists

Stop relying on `cl::opt` to pass along the driver's decision to
preserve use-lists. Create a new `-cc1` option called
`-emit

uselistorder: -mllvm -preserve-bc-use-list-order => -emit-llvm-uselists

Stop relying on `cl::opt` to pass along the driver's decision to
preserve use-lists. Create a new `-cc1` option called
`-emit-llvm-uselists` that does the right thing (when -emit-llvm-bc).
Note that despite its generic name, it *doesn't* do the right thing when
-emit-llvm (LLVM assembly) yet. I'll hook that up soon.

This doesn't really change the behaviour of the driver. The default is
still to preserve use-lists for `clang -emit-llvm` and `clang
-save-temps`, and nothing else. But it stops relying on global state
(and also is a nicer interface for hackers using `clang -cc1`).

llvm-svn: 234962

show more ...


# 256a869d 11-Apr-2015 Ahmed Bougacha <ahmed.bougacha@gmail.com>

[Driver] Properly support -mglobal-merge using explicit options.

Follow-up to r234666. With this, the -m[no-]global-merge options
have the expected behavior. Previously, -mglobal-merge was ignored,

[Driver] Properly support -mglobal-merge using explicit options.

Follow-up to r234666. With this, the -m[no-]global-merge options
have the expected behavior. Previously, -mglobal-merge was ignored,
and there was no way of enabling the optimization.

llvm-svn: 234668

show more ...


# 359b1057 09-Apr-2015 Sanjay Patel <spatel@rotateright.com>

Process the -freciprocal-math optimization flag (PR20912)

The driver currently accepts but ignores the -freciprocal-math flag.
This patch passes the flag through and enables 'arcp' fast-math-flag
ge

Process the -freciprocal-math optimization flag (PR20912)

The driver currently accepts but ignores the -freciprocal-math flag.
This patch passes the flag through and enables 'arcp' fast-math-flag
generation in IR.

Note that this change does not actually enable the optimization for
any target. The reassociation optimization that this flag specifies
was implemented by http://reviews.llvm.org/D6334 :
http://llvm.org/viewvc/llvm-project?view=revision&revision=222510

Because the optimization is done in the backend rather than IR,
the backend must be modified to understand instruction-level
fast-math-flags or a new function-level attribute must be created.

Also note that -freciprocal-math is independent of any target-specific
usage of reciprocal estimate hardware instructions. That requires
its own flag ('-mrecip').

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

llvm-svn: 234493

show more ...


# c371ff04 22-Mar-2015 David Majnemer <david.majnemer@gmail.com>

MS ABI: Implement driver-level support for thread-safe statics

Decide whether or not to use thread-safe statics depending on whether or
not we have an explicit request from the driver. If we don't

MS ABI: Implement driver-level support for thread-safe statics

Decide whether or not to use thread-safe statics depending on whether or
not we have an explicit request from the driver. If we don't have an
explicit request, infer which behavior to use depending on the
compatibility version we are targeting.

N.B. CodeGen support is still ongoing.

llvm-svn: 232906

show more ...


1...<<51525354555657585960>>...79