| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 187521
|
| |
|
|
|
|
| |
changing '->' to '.' when there is no operator-> defined for a class.
llvm-svn: 187504
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is that the command is quoted differently from the arguments. The
command has '\' and the argument has '\\'. This is made unclear because
FileCheck escapes the single matched '\' when it prints the contents of
the variable, thus fooling me into thinking it had matched '\\' as
intended. The solution is to bind the gcc_install variable in the
argument list rather than out of the command. To do so we also have to
be a bit more careful so that we don't get stray other things into the
'.*' regex.
Also, because of the argument difference, '\\\\' is the correct
formulation before crtbegin, go back to that.
llvm-svn: 187489
|
| |
|
|
|
|
|
| |
replacing one variable with the regex. This won't fix anything, but will
hopefully shed light on the nature of the failure.
llvm-svn: 187488
|
| |
|
|
|
|
| |
testcase.
llvm-svn: 187487
|
| |
|
|
|
|
|
|
| |
the path separator used when locating crtbegin.o.
I'll watch the bots to see if there are other issues lurking here.
llvm-svn: 187486
|
| |
|
|
| |
llvm-svn: 187483
|
| |
|
|
| |
llvm-svn: 187467
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang when linking and using a GCC installation from a GCC
cross-compiler.
This was desired already by two special case platforms (Android and
Mips), and turns out to be generally (if frustratingly) true. I've added
a substantial comment to the code clarifying the underlying assumptions
of doing actual cross compiles with Clang (or GCC for that matter!) and
help avoid further confusion here.
The end result is to realize that fully general form of PR12478 cannot
be resolved while we support existing cross-compiling GCC toolchains,
and linking with them (namely, linking against their libgcc and
libstdc++ installs). GCC installs these target libraries under
a target-specific prefix but one that may not be available within the
actual sysroot in use. When linking in this world, GCC works and Clang
should as well, but caveat emptor: DSOs from this tree must be
replicated and rpath-fixed to be found at runtime within the sysroot.
I've extended the cross compile test cases to cover these issues by
pointing them at a sysroot and actually checking the library search
paths.
llvm-svn: 187466
|
| |
|
|
|
|
| |
err_attribute_argument_type.
llvm-svn: 187420
|
| |
|
|
| |
llvm-svn: 187419
|
| |
|
|
| |
llvm-svn: 187409
|
| |
|
|
|
|
| |
requires the feature 'clang-driver' for cygming.
llvm-svn: 187405
|
| |
|
|
| |
llvm-svn: 187400
|
| |
|
|
|
|
| |
of using custom logic. No functional changes intended.
llvm-svn: 187398
|
| |
|
|
| |
llvm-svn: 187387
|
| |
|
|
|
|
|
|
|
| |
output rather than just part of it.
Also, remove the frighteningly ancient comment about not working with
the gcc-driver. (!!!)
llvm-svn: 187376
|
| |
|
|
|
|
|
|
| |
'builtin' if
corresponding 'operator new' was actually emitted as a function marked 'nobuiltin'.
llvm-svn: 187374
|
| |
|
|
|
|
|
|
|
| |
The quotes (from r187330) didn't really help here, the trick was to disable
the test on MSYS builds. This removes those quotes, changes back the comment
to explain why /? has to be quoted specifically, and moves the REQUIRES
line to the top of the file because that's important.
llvm-svn: 187366
|
| |
|
|
|
|
| |
Patch by Ethan Jackson.
llvm-svn: 187365
|
| |
|
|
| |
llvm-svn: 187337
|
| |
|
|
|
|
|
|
| |
It was still failing with double quotes:
http://bb.pgr.jp/builders/clang-i686-msys/builds/698/steps/test_clang/logs/Clang%20%3A%3A%20Driver__cl.c
llvm-svn: 187330
|
| |
|
|
|
|
| |
Should fix some of the bots that have assertions disabled.
llvm-svn: 187329
|
| |
|
|
|
|
|
|
|
| |
This test would fail in weird ways on systems with a one-letter filename
in the root directory, because the shell would helpfully expand /? to e.g. /n.
Make sure this doesn't happen by adding quotes.
llvm-svn: 187295
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This establishes a new Flag in Options.td, which can be assigned to
options that should be made available in clang's cl.exe compatible
mode, and updates the Driver to make use of the flag.
(The whitespace change to CMakeLists forces the build to re-run CMake
and pick up the include dependency on the new .td file. This makes the
build work if someone moves backwards in commit history after this change.)
Differential Revision: http://llvm-reviews.chandlerc.com/D1215
llvm-svn: 187280
|
| |
|
|
|
|
|
|
|
|
| |
This matches how we normally perform semantic analysis for other sorts
of invalid expressions: it means we don't have to reason about invalid
sub-expressions.
Fixes PR16680.
llvm-svn: 187276
|
| |
|
|
|
|
|
| |
no return type is specified, C++11 will deduce a cv-qualified return type in
some cases, but C++1y never will.
llvm-svn: 187275
|
| |
|
|
|
|
| |
return type has already been determined to be a type containing an 'auto'.
llvm-svn: 187266
|
| |
|
|
|
|
|
|
|
|
| |
Restore it after each argument is emitted. This fixes the scope info for
inlined subroutines inside of function argument expressions. (E.g.,
anything STL).
rdar://problem/12592135
llvm-svn: 187240
|
| |
|
|
|
|
|
|
|
| |
comment to be attached to a decl.
It's common to use an availability function macro at the start of a decl.
rdar://13965065
llvm-svn: 187230
|
| |
|
|
|
|
|
|
| |
command-line.
rdar://14556182
llvm-svn: 187207
|
| |
|
|
| |
llvm-svn: 187203
|
| |
|
|
|
|
| |
This also reverts r187197.
llvm-svn: 187199
|
| |
|
|
| |
llvm-svn: 187197
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When binding a temporary object to a static local variable, the analyzer would
complain about a dangling reference even though the temporary's lifetime should
be extended past the end of the function. This commit tries to detect these
cases and construct them in a global memory region instead of a local one.
Reviewers: jordan_rose
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1133
llvm-svn: 187196
|
| |
|
|
|
|
| |
can be removed.
llvm-svn: 187194
|
| |
|
|
|
|
| |
them later.
llvm-svn: 187192
|
| |
|
|
|
|
| |
Attempt 2. Sorry about the noise.
llvm-svn: 187183
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch provides basic support for powerpc64le as an LLVM target.
However, use of this target will not actually generate little-endian
code. Instead, use of the target will cause the correct little-endian
built-in defines to be generated, so that code that tests for
__LITTLE_ENDIAN__, for example, will be correctly parsed for
syntax-only testing. Code generation will otherwise be the same as
powerpc64 (big-endian), for now.
The patch leaves open the possibility of creating a little-endian
PowerPC64 back end, but there is no immediate intent to create such a
thing.
The new test case variant ensures that correct built-in defines for
little-endian code are generated.
llvm-svn: 187180
|
| |
|
|
| |
llvm-svn: 187178
|
| |
|
|
|
|
| |
Based on patch by Yunzhong Gao.
llvm-svn: 187176
|
| |
|
|
|
|
|
|
| |
Just more craziness to find crtbegin.o etc.
Patch by Stephen Kelly.
llvm-svn: 187175
|
| |
|
|
|
|
|
|
|
| |
This allows the ObjFW runtime to correctly implement message forwarding
for messages which return a struct.
Patch by Jonathan Schleifer.
llvm-svn: 187174
|
| |
|
|
|
|
|
|
| |
It turns out that Plum Hall depends on us not emitting an error on
integer literals which fit into long long, but fit into
unsigned long long. So C99 conformance requires not conforming to C99. :)
llvm-svn: 187172
|
| |
|
|
|
|
| |
Also, fix the wording to reflect this.
llvm-svn: 187171
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sufficient to only consider names visible at the point of instantiation,
because that may not include names that were visible when the template was
defined. More generally, if the instantiation backtrace goes through a module
M, then every declaration visible within M should be available to the
instantiation. Any of those declarations might be part of the interface that M
intended to export to a template that it instantiates.
The fix here has two parts:
1) If we find a non-visible declaration during name lookup during template
instantiation, check whether the declaration was visible from the defining
module of all entities on the active template instantiation stack. The defining
module is not the owning module in all cases: we look at the module in which a
template was defined, not the module in which it was first instantiated.
2) Perform pending instantiations at the end of a module, not at the end of the
translation unit. This is general goodness, since it significantly cuts down
the amount of redundant work that is performed in every TU importing a module,
and also implicitly adds the module containing the point of instantiation to
the set of modules checked for declarations in a lookup within a template
instantiation.
There's a known issue here with template instantiations performed while
building a module, if additional imports are added later on. I'll fix that
in a subsequent commit.
llvm-svn: 187167
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the same filtering for assembly arguments to -cc1as as we do for
-cc1, this allows a consistent (& more useful) diagnostic experience for
users (rather than getting an error from -cc1as (which a user shouldn't
really be thinking about) about --foo, they get an error from clang
about --foo in -Wa,)
I'm sort of surprised by the separation of -cc1as & the separate
argument handling, etc, but at least this removes a little bit of the
duplication.
llvm-svn: 187156
|
| |
|
|
|
|
| |
Approval in here http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064169.html
llvm-svn: 187143
|
| |
|
|
|
|
|
|
| |
This goes with r186925, which reverted Pavel's commit in r186498.
Also, add a correctness test for the future.
llvm-svn: 187133
|
| |
|
|
|
|
| |
PR16690
llvm-svn: 187132
|