With this option, arbitrarily named module map files can be specified
to be loaded as required for headers in the respective (sub)directories.
This, together with the extern module declaration allows for specifying
module maps in a modular fashion without the need for files called
"module.map".
Among other things, this allows a directory to contain two modules that
are completely independent of one another.
Review: http://llvm-reviews.chandlerc.com/D1697.
llvm-svn: 191284
Review: http://llvm-reviews.chandlerc.com/D1546.
I have picked up this patch form Lawrence
(http://llvm-reviews.chandlerc.com/D1063) and did a few changes.
From the original change description (updated as appropriate):
This patch adds a check that ensures that modules only use modules they
have so declared. To this end, it adds a statement on intended module
use to the module.map grammar:
use module-id
A module can then only use headers from other modules if it 'uses' them.
This enforcement is off by default, but may be turned on with the new
option -fmodules-decluse.
When enforcing the module semantics, we also need to consider a source
file part of a module. This is achieved with a compiler option
-fmodule-name=<module-id>.
The compiler at present only applies restrictions to the module directly
being built.
llvm-svn: 191283
Make sure that the code that handles the constant addresses is run for the
GEPs. This just refactors that code and then calls it for the GEPs that are
collected during the iteration.
<rdar://problem/12445434>
llvm-svn: 191281
literal operators. Also, for now, allow the proposed C++1y "il", "i", and "if"
suffixes too. (Will revert the latter if LWG decides not to go ahead with that
change after all.)
llvm-svn: 191274
/PDBALTPATH:<path> is an option to embed a different path for the PDB file to
the binary than the actual PDB file location. Because we don't support PDB
file, we'll just ignore the option for now.
llvm-svn: 191273
the CFA instructions when it was profiling an -fomit-frame-pointer function
and a "volatile" register was saved on the stack (e.g. an argument register).
<rdar://problem/15036546>
llvm-svn: 191267
1. Fixed constructor of shared clause.
2. Some macros for clauses processing are replaced by private template methods.
3. Additional checks in sema analysis of OpenMP clauses.
llvm-svn: 191265
Patch by Ana Pazos.
1.Added support for v1ix and v1fx types.
2.Added Scalar Pairwise Reduce instructions.
3.Added initial implementation of Scalar Arithmetic instructions.
llvm-svn: 191264
Patch by Ana Pazos.
1.Added support for v1ix and v1fx types.
2.Added Scalar Pairwise Reduce instructions.
3.Added initial implementation of Scalar Arithmetic instructions.
llvm-svn: 191263
default-at-first-instruction UnwindPlan if we're at the beginning of a function and
the ABI can provide us with an UnwindPlan to get out of there before falling back
to the generic architectural default UnwindPlan (which usually assumes that the stack
has already been set up.)
Update the FuncUnwinders methods to gracefully handle the case where an assembly
profiler may not be available.
Fix a bug where FuncUnwinders::GetUnwindPlanArchitectureDefaultAtFunctionEntry was
returning the wrong UnwindPlan to its caller.
llvm-svn: 191262
Sometimes a copy from a vreg -> vreg sneaks into the middle of a terminator
sequence. It is safe to slice this into the stack protector success bb.
This fixes PR16979.
llvm-svn: 191260
The recursive nature of the address selection code can cause the stack to
explode if there is a long chain of GEPs. Convert the recursive bit into a
iterative method to avoid this.
<rdar://problem/12445434>
llvm-svn: 191252
gcc doesn't support "gcc -m sse" and this was not tested in clang and only
used for link argument on darwin, so this was very likely just a bug.
llvm-svn: 191251
This solves two problems:
1) MSBuild will not flag the build as unsuccessful just because we print
an error in the output, since "error(clang):" doesn't seem to match
the regex it's using.
2) It becomes more clear that the diagnostic is coming from clang as
supposed to cl.exe.
Differential Revision: http://llvm-reviews.chandlerc.com/D1735
llvm-svn: 191250
This doesn't change a lot since clang still thinks it knows all of the
-f*, -m* and -W* options for example.
Other than the options clang explicitly claims to know, this fixes pr9701.
llvm-svn: 191249
We used to support both Windows and Unix style command line options. In Windows
style, an option and its value are separated by ":" (colon). In Unix, separator
is a space. Accepting both styles were convenient, but we can no longer allow
Unix style because I found that can be ambiguous.
For example, /nodefaultlib option takes an optional argument. In Windows style
it's going to be something like "/nodefaultlib:foo". There's no ambiguity what
"foo" means. However, if the option is "/nodefaultlib foo", "foo" can be
interpreted either an optional argument for "/nodefaultlib" or an input file
"foo.obj". We should just stop accepting the non-standard command line style.
llvm-svn: 191247
Alexander Potapenko