maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity

Fix more inconsistent line endings. NFC. 

llvm-svn: 321016
This commit is contained in:
Dimitry Andric 2017-12-18 19:46:56 +00:00
parent 48176a5fb6
commit e4f5d01033
20 changed files with 657 additions and 657 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

152
clang-tools-extra/docs/modularize.rst
View File

@ -172,40 +172,40 @@ For example, for the header list::
The following module map will be generated::
// Output/NoProblemsAssistant.txt
// Output/NoProblemsAssistant.txt
// Generated by: modularize -module-map-path=Output/NoProblemsAssistant.txt \
-root-module=Root NoProblemsAssistant.modularize
module SomeTypes {
header "SomeTypes.h"
export *
}
module SomeDecls {
header "SomeDecls.h"
export *
}
module SubModule1 {
module Header1 {
header "SubModule1/Header1.h"
export *
}
module Header2 {
header "SubModule1/Header2.h"
export *
}
}
module SubModule2 {
module Header3 {
header "SubModule2/Header3.h"
export *
}
module Header4 {
header "SubModule2/Header4.h"
export *
}
header "SubModule2.h"
export *
}
-root-module=Root NoProblemsAssistant.modularize
module SomeTypes {
header "SomeTypes.h"
export *
}
module SomeDecls {
header "SomeDecls.h"
export *
}
module SubModule1 {
module Header1 {
header "SubModule1/Header1.h"
export *
}
module Header2 {
header "SubModule1/Header2.h"
export *
}
}
module SubModule2 {
module Header3 {
header "SubModule2/Header3.h"
export *
}
module Header4 {
header "SubModule2/Header4.h"
export *
}
header "SubModule2.h"
export *
}
An optional ``-root-module=<root-name>`` option can be used to cause a root module
to be created which encloses all the modules.
@ -216,50 +216,50 @@ problem headers can be fixed.
For example, with the same header list from above::
// Output/NoProblemsAssistant.txt
// Output/NoProblemsAssistant.txt
// Generated by: modularize -module-map-path=Output/NoProblemsAssistant.txt \
-root-module=Root NoProblemsAssistant.modularize
module Root {
module SomeTypes {
header "SomeTypes.h"
export *
}
module SomeDecls {
header "SomeDecls.h"
export *
}
module SubModule1 {
module Header1 {
header "SubModule1/Header1.h"
export *
}
module Header2 {
header "SubModule1/Header2.h"
export *
}
}
module SubModule2 {
module Header3 {
header "SubModule2/Header3.h"
export *
}
module Header4 {
header "SubModule2/Header4.h"
export *
}
header "SubModule2.h"
export *
}
}
Note that headers with dependents will be ignored with a warning, as the
Clang module mechanism doesn't support headers the rely on other headers
to be included first.
The module map format defines some keywords which can't be used in module
names. If a header has one of these names, an underscore ('_') will be
-root-module=Root NoProblemsAssistant.modularize
module Root {
module SomeTypes {
header "SomeTypes.h"
export *
}
module SomeDecls {
header "SomeDecls.h"
export *
}
module SubModule1 {
module Header1 {
header "SubModule1/Header1.h"
export *
}
module Header2 {
header "SubModule1/Header2.h"
export *
}
}
module SubModule2 {
module Header3 {
header "SubModule2/Header3.h"
export *
}
module Header4 {
header "SubModule2/Header4.h"
export *
}
header "SubModule2.h"
export *
}
}
Note that headers with dependents will be ignored with a warning, as the
Clang module mechanism doesn't support headers the rely on other headers
to be included first.
The module map format defines some keywords which can't be used in module
names. If a header has one of these names, an underscore ('_') will be
prepended to the name. For example, if the header name is ``header.h``,
because ``header`` is a keyword, the module name will be ``_header``.
For a list of the module map keywords, please see:
`Lexical structure <http://clang.llvm.org/docs/Modules.html#lexical-structure>`_
`Lexical structure <http://clang.llvm.org/docs/Modules.html#lexical-structure>`_

160
clang-tools-extra/docs/pp-trace.rst
View File

@ -103,18 +103,18 @@ example:::
With real data:::
---
- Callback: FileChanged
Loc: "c:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-include.cpp:1:1"
Reason: EnterFile
FileType: C_User
PrevFID: (invalid)
(etc.)
- Callback: FileChanged
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-include.cpp:5:1"
Reason: ExitFile
FileType: C_User
PrevFID: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/Input/Level1B.h"
- Callback: EndOfMainFile
- Callback: FileChanged
Loc: "c:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-include.cpp:1:1"
Reason: EnterFile
FileType: C_User
PrevFID: (invalid)
(etc.)
- Callback: FileChanged
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-include.cpp:5:1"
Reason: ExitFile
FileType: C_User
PrevFID: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/Input/Level1B.h"
- Callback: EndOfMainFile
...
In all but one case (MacroDirective) the "Argument" scalars have the same
@ -171,11 +171,11 @@ PrevFID ((file)|(invalid)) FileID
Example:::
- Callback: FileChanged
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-include.cpp:1:1"
Reason: EnterFile
FileType: C_User
PrevFID: (invalid)
- Callback: FileChanged
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-include.cpp:1:1"
Reason: EnterFile
FileType: C_User
PrevFID: (invalid)
`FileSkipped <http://clang.llvm.org/doxygen/classclang_1_1PPCallbacks.html#ab5b338a0670188eb05fa7685bbfb5128>`_ Callback
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -195,10 +195,10 @@ FileType (C_User|C_System|C_ExternCSystem) SrcMgr::Ch
Example:::
- Callback: FileSkipped
ParentFile: "/path/filename.h"
FilenameTok: "filename.h"
FileType: C_User
- Callback: FileSkipped
ParentFile: "/path/filename.h"
FilenameTok: "filename.h"
FileType: C_User
`FileNotFound <http://clang.llvm.org/doxygen/classclang_1_1PPCallbacks.html#a3045151545f987256bfa8d978916ef00>`_ Callback
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -216,7 +216,7 @@ RecoveryPath (path) SmallVecto
Example:::
- Callback: FileNotFound
- Callback: FileNotFound
FileName: "/path/filename.h"
RecoveryPath:
@ -243,15 +243,15 @@ Imported ((module name)|(null)) const Modu
Example:::
- Callback: InclusionDirective
IncludeTok: include
FileName: "Input/Level1B.h"
IsAngled: false
FilenameRange: "Input/Level1B.h"
File: "D:/Clang/llvmnewmod/tools/clang/tools/extra/test/pp-trace/Input/Level1B.h"
SearchPath: "D:/Clang/llvmnewmod/tools/clang/tools/extra/test/pp-trace"
RelativePath: "Input/Level1B.h"
Imported: (null)
- Callback: InclusionDirective
IncludeTok: include
FileName: "Input/Level1B.h"
IsAngled: false
FilenameRange: "Input/Level1B.h"
File: "D:/Clang/llvmnewmod/tools/clang/tools/extra/test/pp-trace/Input/Level1B.h"
SearchPath: "D:/Clang/llvmnewmod/tools/clang/tools/extra/test/pp-trace"
RelativePath: "Input/Level1B.h"
Imported: (null)
`moduleImport <http://clang.llvm.org/doxygen/classclang_1_1PPCallbacks.html#af32dcf1b8b7c179c7fcd3e24e89830fe>`_ Callback
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -270,7 +270,7 @@ Imported ((module name)|(null)) const Modu
Example:::
- Callback: moduleImport
- Callback: moduleImport
ImportLoc: "d:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-modules.cpp:4:2"
Path: [{Name: Level1B, Loc: "d:/Clang/llvmnewmod/tools/clang/tools/extra/test/pp-trace/pp-trace-modules.cpp:4:9"}, {Name: Level2B, Loc: "d:/Clang/llvmnewmod/tools/clang/tools/extra/test/pp-trace/pp-trace-modules.cpp:4:17"}]
Imported: Level2B
@ -290,7 +290,7 @@ Argument Name Argument Value Syntax Clang C++
Example:::
- Callback: EndOfMainFile
- Callback: EndOfMainFile
`Ident <http://clang.llvm.org/doxygen/classclang_1_1PPCallbacks.html#a3683f1d1fa513e9b6193d446a5cc2b66>`_ Callback
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -308,7 +308,7 @@ str (name) const std:
Example:::
- Callback: Ident
- Callback: Ident
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-ident.cpp:3:1"
str: "$Id$"
@ -328,7 +328,7 @@ Introducer (PIK_HashPragma|PIK__Pragma|PIK___pragma) PragmaIntr
Example:::
- Callback: PragmaDirective
- Callback: PragmaDirective
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-pragma.cpp:3:1"
Introducer: PIK_HashPragma
@ -349,7 +349,7 @@ Str (message directive) const std:
Example:::
- Callback: PragmaComment
- Callback: PragmaComment
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-pragma.cpp:3:1"
Kind: library
Str: kernel32.lib
@ -371,7 +371,7 @@ Value (string) const std:
Example:::
- Callback: PragmaDetectMismatch
- Callback: PragmaDetectMismatch
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-pragma.cpp:3:1"
Name: name
Value: value
@ -392,7 +392,7 @@ DebugType (string) StringRef
Example:::
- Callback: PragmaDebug
- Callback: PragmaDebug
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-pragma.cpp:3:1"
DebugType: warning
@ -414,7 +414,7 @@ Str (string) StringRef
Example:::
- Callback: PragmaMessage
- Callback: PragmaMessage
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-pragma.cpp:3:1"
Namespace: "GCC"
Kind: PMK_Message
@ -436,7 +436,7 @@ Namespace (name) StringRef
Example:::
- Callback: PragmaDiagnosticPush
- Callback: PragmaDiagnosticPush
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-pragma.cpp:3:1"
Namespace: "GCC"
@ -456,7 +456,7 @@ Namespace (name) StringRef
Example:::
- Callback: PragmaDiagnosticPop
- Callback: PragmaDiagnosticPop
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-pragma.cpp:3:1"
Namespace: "GCC"
@ -478,7 +478,7 @@ Str (string) StringRef
Example:::
- Callback: PragmaDiagnostic
- Callback: PragmaDiagnostic
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-pragma.cpp:3:1"
Namespace: "GCC"
mapping: MAP_WARNING
@ -502,7 +502,7 @@ State (1|0) unsigned
Example:::
- Callback: PragmaOpenCLExtension
- Callback: PragmaOpenCLExtension
NameLoc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-pragma.cpp:3:10"
Name: Name
StateLoc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-pragma.cpp:3:18"
@ -525,7 +525,7 @@ Ids [(number)[, ...]] ArrayRef<i
Example:::
- Callback: PragmaWarning
- Callback: PragmaWarning
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-pragma.cpp:3:1"
WarningSpec: disable
Ids: 1,2,3
@ -546,7 +546,7 @@ Level (number) int
Example:::
- Callback: PragmaWarningPush
- Callback: PragmaWarningPush
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-pragma.cpp:3:1"
Level: 1
@ -565,7 +565,7 @@ Loc "(file):(line):(col)" SourceLoca
Example:::
- Callback: PragmaWarningPop
- Callback: PragmaWarningPop
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-pragma.cpp:3:1"
`MacroExpands <http://clang.llvm.org/doxygen/classclang_1_1PPCallbacks.html#a9bc725209d3a071ea649144ab996d515>`_ Callback
@ -586,11 +586,11 @@ Args [(name)|(number)|<(token name)>[, ...]] const Macr
Example:::
- Callback: MacroExpands
MacroNameTok: X_IMPL
MacroDirective: MD_Define
Range: [(nonfile), (nonfile)]
Args: [a <plus> y, b]
- Callback: MacroExpands
MacroNameTok: X_IMPL
MacroDirective: MD_Define
Range: [(nonfile), (nonfile)]
Args: [a <plus> y, b]
`MacroDefined <http://clang.llvm.org/doxygen/classclang_1_1PPCallbacks.html#a8448fc9f96f22ad1b93ff393cffc5a76>`_ Callback
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -608,9 +608,9 @@ MacroDirective (MD_Define|MD_Undefine|MD_Visibility) const Macr
Example:::
- Callback: MacroDefined
MacroNameTok: X_IMPL
MacroDirective: MD_Define
- Callback: MacroDefined
MacroNameTok: X_IMPL
MacroDirective: MD_Define
`MacroUndefined <http://clang.llvm.org/doxygen/classclang_1_1PPCallbacks.html#acb80fc6171a839db8e290945bf2c9d7a>`_ Callback
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -628,9 +628,9 @@ MacroDirective (MD_Define|MD_Undefine|MD_Visibility) const Macr
Example:::
- Callback: MacroUndefined
MacroNameTok: X_IMPL
MacroDirective: MD_Define
- Callback: MacroUndefined
MacroNameTok: X_IMPL
MacroDirective: MD_Define
`Defined <http://clang.llvm.org/doxygen/classclang_1_1PPCallbacks.html#a3cc2a644533d0e4088a13d2baf90db94>`_ Callback
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -649,7 +649,7 @@ Range ["(file):(line):(col)", "(file):(line):(col)"] SourceRang
Example:::
- Callback: Defined
- Callback: Defined
MacroNameTok: MACRO
MacroDirective: (null)
Range: ["D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:8:5", "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:8:19"]
@ -669,7 +669,7 @@ Range ["(file):(line):(col)", "(file):(line):(col)"] SourceRang
Example:::
- Callback: SourceRangeSkipped
- Callback: SourceRangeSkipped
Range: [":/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:8:2", ":/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:9:2"]
`If <http://clang.llvm.org/doxygen/classclang_1_1PPCallbacks.html#a645edcb0d6becbc6f256f02fd1287778>`_ Callback
@ -689,10 +689,10 @@ ConditionValue (true|false) bool
Example:::
- Callback: If
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:8:2"
ConditionRange: ["D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:8:4", "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:9:1"]
ConditionValue: false
- Callback: If
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:8:2"
ConditionRange: ["D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:8:4", "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:9:1"]
ConditionValue: false
`Elif <http://clang.llvm.org/doxygen/classclang_1_1PPCallbacks.html#a180c9e106a28d60a6112e16b1bb8302a>`_ Callback
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -712,11 +712,11 @@ IfLoc "(file):(line):(col)" SourceLoca
Example:::
- Callback: Elif
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:10:2"
ConditionRange: ["D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:10:4", "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:11:1"]
ConditionValue: false
IfLoc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:8:2"
- Callback: Elif
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:10:2"
ConditionRange: ["D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:10:4", "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:11:1"]
ConditionValue: false
IfLoc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:8:2"
`Ifdef <http://clang.llvm.org/doxygen/classclang_1_1PPCallbacks.html#a0ce79575dda307784fd51a6dd4eec33d>`_ Callback
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -735,10 +735,10 @@ MacroDirective (MD_Define|MD_Undefine|MD_Visibility) const Macr
Example:::
- Callback: Ifdef
- Callback: Ifdef
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-conditional.cpp:3:1"
MacroNameTok: MACRO
MacroDirective: MD_Define
MacroNameTok: MACRO
MacroDirective: MD_Define
`Ifndef <http://clang.llvm.org/doxygen/classclang_1_1PPCallbacks.html#a767af69f1cdcc4cd880fa2ebf77ad3ad>`_ Callback
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -757,10 +757,10 @@ MacroDirective (MD_Define|MD_Undefine|MD_Visibility) const Macr
Example:::
- Callback: Ifndef
- Callback: Ifndef
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-conditional.cpp:3:1"
MacroNameTok: MACRO
MacroDirective: MD_Define
MacroNameTok: MACRO
MacroDirective: MD_Define
`Else <http://clang.llvm.org/doxygen/classclang_1_1PPCallbacks.html#ad57f91b6d9c3cbcca326a2bfb49e0314>`_ Callback
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -778,9 +778,9 @@ IfLoc "(file):(line):(col)" SourceLoca
Example:::
- Callback: Else
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:10:2"
IfLoc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:8:2"
- Callback: Else
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:10:2"
IfLoc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:8:2"
`Endif <http://clang.llvm.org/doxygen/classclang_1_1PPCallbacks.html#afc62ca1401125f516d58b1629a2093ce>`_ Callback
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -798,9 +798,9 @@ IfLoc "(file):(line):(col)" SourceLoca
Example:::
- Callback: Endif
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:10:2"
IfLoc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:8:2"
- Callback: Endif
Loc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:10:2"
IfLoc: "D:/Clang/llvm/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp:8:2"
Building pp-trace
=================

2
clang/include/clang/AST/OperationKinds.def
View File

@ -327,7 +327,7 @@ CAST_OPERATION(ZeroToOCLQueue)
// Convert a pointer to a different address space.
CAST_OPERATION(AddressSpaceConversion)
// Convert an integer initializer to an OpenCL sampler.
// Convert an integer initializer to an OpenCL sampler.
CAST_OPERATION(IntToOCLSampler)
//===- Binary Operations -------------------------------------------------===//

4
clang/lib/Parse/ParseTemplate.cpp
View File

@ -1024,8 +1024,8 @@ bool Parser::AnnotateTemplateIdToken(TemplateTy Template, TemplateNameKind TNK,
? OO_None
: TemplateName.OperatorFunctionId.Operator;
TemplateIdAnnotation *TemplateId = TemplateIdAnnotation::Create(
SS, TemplateKWLoc, TemplateNameLoc, TemplateII, OpKind, Template, TNK,
TemplateIdAnnotation *TemplateId = TemplateIdAnnotation::Create(
SS, TemplateKWLoc, TemplateNameLoc, TemplateII, OpKind, Template, TNK,
LAngleLoc, RAngleLoc, TemplateArgs, TemplateIds);
Tok.setAnnotationValue(TemplateId);

8
clang/www/cxx_dr_status.html
View File

@ -1292,7 +1292,7 @@
<tr id="209">
<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#209">209</a></td>
<td>NAD</td>
<td>Must friend declaration names be
<td>Must friend declaration names be
accessible?</td>
<td class="full" align="center">Yes</td>
</tr>
@ -1653,7 +1653,7 @@ accessible?</td>
<tr id="269">
<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#269">269</a></td>
<td>NAD</td>
<td>Order of initialization of multiply-defined static data members
<td>Order of initialization of multiply-defined static data members
of class templates</td>
<td class="na" align="center">N/A</td>
</tr>
@ -3268,8 +3268,8 @@ of class templates</td>
<tr id="538">
<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#538">538</a></td>
<td>CD1</td>
<td>Definition and usage
of <I>structure</I>, <I>POD-struct</I>, <I>POD-union</I>,
<td>Definition and usage
of <I>structure</I>, <I>POD-struct</I>, <I>POD-union</I>,
and <I>POD class</I></td>
<td class="na" align="center">N/A</td>
</tr>

2
compiler-rt/lib/builtins/CMakeLists.txt
View File

@ -516,7 +516,7 @@ else ()
if (CAN_TARGET_${arch})
# NOTE: some architectures (e.g. i386) have multiple names. Ensure that
# we catch them all.
set(_arch ${arch})
set(_arch ${arch})
if("${arch}" STREQUAL "armv6m")
set(_arch "arm|armv6m")
elseif("${arch}" MATCHES "^(armhf|armv7|armv7s|armv7k|armv7m|armv7em)$")

2
lld/test/COFF/pdb-options.test
View File

@ -18,4 +18,4 @@
# RUN: lld-link /DEBUG /entry:main /nodefaultlib %t1.obj %t2.obj
# RUN: ls %t1.pdb
# RUN: rm %t*
# RUN: cd %T/..
# RUN: cd %T/..

28
lldb/www/build.html
View File

@ -123,20 +123,20 @@
</li>
</ul>
Sample command line:<br/>
<code>cmake -G Ninja -DLLDB_TEST_DEBUG_TEST_CRASHES=1 -DPYTHON_HOME=C:\Python35 -DLLDB_TEST_COMPILER=d:\src\llvmbuild\ninja_release\bin\clang.exe ..\..\llvm</code>
<h2>Working with both Ninja and MSVC</h2>
<p>
Compiling with <code>ninja</code> is both faster and simpler than compiling with MSVC, but chances are you still want
to debug LLDB with MSVC (at least until we can debug LLDB on Windows with LLDB!). One solution to this is to run
<code>cmake</code> twice and generate the output into two different folders. One for compiling (the <code>ninja</code>
folder), and one for editing / browsing / debugging (the MSVC folder).
</p>
<p>
To do this, simply run <code>`cmake -G Ninja &lt;arguments&gt;`</code> from one folder, and
<code>`cmake -G "Visual Studio 14 2015" &lt;arguments&gt;`</code> in another folder. Then you can open the .sln file
in Visual Studio, set <code>lldb</code> as the startup project, and use F5 to run it. You need only edit the project
settings to set the executable and the working directory to point to binaries inside of the <code>ninja</code> tree.
</p>
<code>cmake -G Ninja -DLLDB_TEST_DEBUG_TEST_CRASHES=1 -DPYTHON_HOME=C:\Python35 -DLLDB_TEST_COMPILER=d:\src\llvmbuild\ninja_release\bin\clang.exe ..\..\llvm</code>
<h2>Working with both Ninja and MSVC</h2>
<p>
Compiling with <code>ninja</code> is both faster and simpler than compiling with MSVC, but chances are you still want
to debug LLDB with MSVC (at least until we can debug LLDB on Windows with LLDB!). One solution to this is to run
<code>cmake</code> twice and generate the output into two different folders. One for compiling (the <code>ninja</code>
folder), and one for editing / browsing / debugging (the MSVC folder).
</p>
<p>
To do this, simply run <code>`cmake -G Ninja &lt;arguments&gt;`</code> from one folder, and
<code>`cmake -G "Visual Studio 14 2015" &lt;arguments&gt;`</code> in another folder. Then you can open the .sln file
in Visual Studio, set <code>lldb</code> as the startup project, and use F5 to run it. You need only edit the project
settings to set the executable and the working directory to point to binaries inside of the <code>ninja</code> tree.
</p>
</div>
</div>
<div class="post" id="BuildingLldbOnMacOSX">

176
lldb/www/test.html
View File

@ -27,13 +27,13 @@
both the LLDB command line interface and the scripting API.
</p>
</div>
<h1 class="postheader">Running tests</h1>
<h1 class="postheader">Running tests</h1>
<div class="postcontent">
<h2>Running the full test suite</h2>
<p>
<strong>Windows Note</strong>: In the examples that follow, any invocations of <code>python</code>
should be replaced with <code>python_d</code>, the debug interpreter, when running the test
suite against a debug version of LLDB.
<strong>Windows Note</strong>: In the examples that follow, any invocations of <code>python</code>
should be replaced with <code>python_d</code>, the debug interpreter, when running the test
suite against a debug version of LLDB.
</p>
<p>
The easiest way to run the LLDB test suite is to use the <tt>check-lldb</tt> build
@ -134,93 +134,93 @@
<h1 class="postheader">Debugging test failures</h1>
<div class="postcontent">
<h2>Non-Windows platforms</h2>
<p>
On non-Windows platforms, you can use the <code>-d</code> option to <code>dotest.py</code> which will cause the script to wait
<p>
On non-Windows platforms, you can use the <code>-d</code> option to <code>dotest.py</code> which will cause the script to wait
for a while until a debugger is attached.
</p>
<h2>Windows</h2>
<h2>Windows</h2>
<p>
On Windows, it is strongly recommended to use <a href="https://github.com/Microsoft/PTVS/releases">Python Tools for Visual Studio</a>
for debugging test failures. It can seamlessly step between native and managed code, which is very helpful when you need to step
through the test itself, and then into the LLDB code that backs the operations the test is performing. A quick guide to getting
started with PTVS is as follows:
<ul>
<li>Install PTVS</li>
<li>
Create a Visual Studio Project for the Python code.
<ul>
<li>Go to File -> New -> Project -> Python -> From Existing Python Code.</li>
<li>Choose <code>llvm/tools/lldb</code> as the directory containing the Python code.</li>
<li>
When asked where to save the <code>.pyproj</code> file, choose the folder <code>llvm/tools/lldb/pyproj</code>.
This is a special folder that is ignored by the <code>.gitignore</code> file, since it is not checked in.
</li>
</ul>
</li>
<li>Set <code>test/dotest.py</code> as the startup file</li>
<li>
Make sure there is a Python Environment installed for your distribution. For example, if you installed Python to
<code>C:\Python35</code>, PTVS needs to know that this is the interpreter you want to use for running the test suite.
<ul>
<li>Go to Tools -> Options -> Python Tools -> Environment Options</li>
<li>Click Add Environment, and enter <code>Python 3.5 Debug</code> for the name. Fill out the values correctly.</li>
</ul>
</li>
<li>
Configure the project to use this debug interpreter.
<ul>
<li>Right click the Project node in Solution Explorer</li>
<li>In the <code>General</code> tab, Make sure <code>Python 3.5 Debug</code> is the selected Interpreter.</li>
<li>In <code>Debug/Search Paths</code>, enter the path to your <code>ninja/lib/site-packages</code> directory.</li>
<li>
In <code>Debug/Environment Variables</code>, enter<br/>
<code>VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\</code>
</li>
<li>
If you want to enabled mixed mode debugging, check <code>Enable native code debugging</code> (this slows down debugging,
so enable it only on an as-needed basis.)
</li>
</ul>
</li>
<li>
Set the command line for the test suite to run.
<ul>
<li>Right click the project in solution explorer and choose the <code>Debug</code> tab.</li>
<li>Enter the arguments to <code>dotest.py</code>. Note you must add <code>--no-multiprocess</code></li>
<li>
Example command options:
<code>
<br/># quiet mode
<br/>-q
<br />--arch=i686
<br /># Path to debug lldb.exe
<br />--executable D:/src/llvmbuild/ninja/bin/lldb.exe
<br /># Directory to store log files
<br />-s D:/src/llvmbuild/ninja/lldb-test-traces
<br />-u CXXFLAGS -u CFLAGS
<br /># If a test crashes, show JIT debugging dialog.
<br />--enable-crash-dialog
<br /># Path to release clang.exe
<br />-C d:\src\llvmbuild\ninja_release\bin\clang.exe
<br /># Path to the particular test you want to debug.
<br />-p TestPaths.py
<br /># Root of test tree
<br />D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test
<br /># Required in order to be able to debug the test.
<br />--no-multiprocess
</code>
</li>
<li>
As copy-pastable command line:<br/>
<code>
-q --arch=i686 --executable D:/src/llvmbuild/ninja/bin/lldb.exe -s D:/src/llvmbuild/ninja/lldb-test-traces
-u CXXFLAGS -u CFLAGS --enable-crash-dialog -C d:\src\llvmbuild\ninja_release\bin\clang.exe
-p TestPaths.py D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test --no-multiprocess
</code>
</li>
</ul>
</li>
</ul>
On Windows, it is strongly recommended to use <a href="https://github.com/Microsoft/PTVS/releases">Python Tools for Visual Studio</a>
for debugging test failures. It can seamlessly step between native and managed code, which is very helpful when you need to step
through the test itself, and then into the LLDB code that backs the operations the test is performing. A quick guide to getting
started with PTVS is as follows:
<ul>
<li>Install PTVS</li>
<li>
Create a Visual Studio Project for the Python code.
<ul>
<li>Go to File -> New -> Project -> Python -> From Existing Python Code.</li>
<li>Choose <code>llvm/tools/lldb</code> as the directory containing the Python code.</li>
<li>
When asked where to save the <code>.pyproj</code> file, choose the folder <code>llvm/tools/lldb/pyproj</code>.
This is a special folder that is ignored by the <code>.gitignore</code> file, since it is not checked in.
</li>
</ul>
</li>
<li>Set <code>test/dotest.py</code> as the startup file</li>
<li>
Make sure there is a Python Environment installed for your distribution. For example, if you installed Python to
<code>C:\Python35</code>, PTVS needs to know that this is the interpreter you want to use for running the test suite.
<ul>
<li>Go to Tools -> Options -> Python Tools -> Environment Options</li>
<li>Click Add Environment, and enter <code>Python 3.5 Debug</code> for the name. Fill out the values correctly.</li>
</ul>
</li>
<li>
Configure the project to use this debug interpreter.
<ul>
<li>Right click the Project node in Solution Explorer</li>
<li>In the <code>General</code> tab, Make sure <code>Python 3.5 Debug</code> is the selected Interpreter.</li>
<li>In <code>Debug/Search Paths</code>, enter the path to your <code>ninja/lib/site-packages</code> directory.</li>
<li>
In <code>Debug/Environment Variables</code>, enter<br/>
<code>VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\</code>
</li>
<li>
If you want to enabled mixed mode debugging, check <code>Enable native code debugging</code> (this slows down debugging,
so enable it only on an as-needed basis.)
</li>
</ul>
</li>
<li>
Set the command line for the test suite to run.
<ul>
<li>Right click the project in solution explorer and choose the <code>Debug</code> tab.</li>
<li>Enter the arguments to <code>dotest.py</code>. Note you must add <code>--no-multiprocess</code></li>
<li>
Example command options:
<code>
<br/># quiet mode
<br/>-q
<br />--arch=i686
<br /># Path to debug lldb.exe
<br />--executable D:/src/llvmbuild/ninja/bin/lldb.exe
<br /># Directory to store log files
<br />-s D:/src/llvmbuild/ninja/lldb-test-traces
<br />-u CXXFLAGS -u CFLAGS
<br /># If a test crashes, show JIT debugging dialog.
<br />--enable-crash-dialog
<br /># Path to release clang.exe
<br />-C d:\src\llvmbuild\ninja_release\bin\clang.exe
<br /># Path to the particular test you want to debug.
<br />-p TestPaths.py
<br /># Root of test tree
<br />D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test
<br /># Required in order to be able to debug the test.
<br />--no-multiprocess
</code>
</li>
<li>
As copy-pastable command line:<br/>
<code>
-q --arch=i686 --executable D:/src/llvmbuild/ninja/bin/lldb.exe -s D:/src/llvmbuild/ninja/lldb-test-traces
-u CXXFLAGS -u CFLAGS --enable-crash-dialog -C d:\src\llvmbuild\ninja_release\bin\clang.exe
-p TestPaths.py D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test --no-multiprocess
</code>
</li>
</ul>
</li>
</ul>
</p>
</div>
<div class="postfooter"></div>

18
llvm/lib/LTO/LTOCodeGenerator.cpp
View File

@ -466,15 +466,15 @@ void LTOCodeGenerator::restoreLinkageForExternals() {
if (I == ExternalSymbols.end())
return;
GV.setLinkage(I->second);
};
llvm::for_each(MergedModule->functions(), externalize);
llvm::for_each(MergedModule->globals(), externalize);
llvm::for_each(MergedModule->aliases(), externalize);
}
void LTOCodeGenerator::verifyMergedModuleOnce() {
GV.setLinkage(I->second);
};
llvm::for_each(MergedModule->functions(), externalize);
llvm::for_each(MergedModule->globals(), externalize);
llvm::for_each(MergedModule->aliases(), externalize);
}
void LTOCodeGenerator::verifyMergedModuleOnce() {
// Only run on the first call.
if (HasVerifiedInput)
return;

2
llvm/lib/Target/ARC/ARCInstrFormats.td
View File

@ -29,7 +29,7 @@ class immS<int BSz> : Operand<i32>, PatLeaf<(imm),
let DecoderMethod = "DecodeSignedOperand<"#BSz#">";
}
// e.g. s3 field may encode the signed integers values -1 .. 6
// e.g. s3 field may encode the signed integers values -1 .. 6
// using binary codes 111, 000, 001, 010, 011, 100, 101, and 110, respectively
class immC<int BSz> : Operand<i32>, PatLeaf<(imm),
"\n return isInt<"#BSz#">(N->getSExtValue());"> {

14
llvm/lib/Target/ARC/ARCInstrInfo.td
View File

@ -534,13 +534,13 @@ let isBranch = 1 in {
def BEQ_S : F16_BCC_s10<0b01, "beq_s">;
def BNE_S : F16_BCC_s10<0b10, "bne_s">;
def BGT_S : F16_BCC_s7<0b000, "bgt_s">;
def BGE_S : F16_BCC_s7<0b001, "bge_s">;
def BLT_S : F16_BCC_s7<0b010, "blt_s">;
def BLE_S : F16_BCC_s7<0b011, "ble_s">;
def BHI_S : F16_BCC_s7<0b100, "bhi_s">;
def BHS_S : F16_BCC_s7<0b101, "bhs_s">;
def BLO_S : F16_BCC_s7<0b110, "blo_s">;
def BGT_S : F16_BCC_s7<0b000, "bgt_s">;
def BGE_S : F16_BCC_s7<0b001, "bge_s">;
def BLT_S : F16_BCC_s7<0b010, "blt_s">;
def BLE_S : F16_BCC_s7<0b011, "ble_s">;
def BHI_S : F16_BCC_s7<0b100, "bhi_s">;
def BHS_S : F16_BCC_s7<0b101, "bhs_s">;
def BLO_S : F16_BCC_s7<0b110, "blo_s">;
def BLS_S : F16_BCC_s7<0b111, "bls_s">;
} // let isBranch

18
llvm/lib/Transforms/Utils/SplitModule.cpp
View File

@ -141,15 +141,15 @@ static void findPartitions(Module *M, ClusterIDMapType &ClusterIDMap,
}
if (GV.hasLocalLinkage())
addAllGlobalValueUsers(GVtoClusterMap, &GV, &GV);
};
llvm::for_each(M->functions(), recordGVSet);
llvm::for_each(M->globals(), recordGVSet);
llvm::for_each(M->aliases(), recordGVSet);
// Assigned all GVs to merged clusters while balancing number of objects in
// each.
addAllGlobalValueUsers(GVtoClusterMap, &GV, &GV);
};
llvm::for_each(M->functions(), recordGVSet);
llvm::for_each(M->globals(), recordGVSet);
llvm::for_each(M->aliases(), recordGVSet);
// Assigned all GVs to merged clusters while balancing number of objects in
// each.
auto CompareClusters = [](const std::pair<unsigned, unsigned> &a,
const std::pair<unsigned, unsigned> &b) {
if (a.second || b.second)

4
llvm/test/CodeGen/X86/evex-to-vex-compress.mir
View File

@ -4628,6 +4628,6 @@ body: |
VUCOMISSZrm %xmm16, %rdi, %noreg, %noreg, %noreg, %noreg, implicit-def %eflags
; CHECK: VUCOMISSZrr %xmm16, %xmm1, implicit-def %eflags
VUCOMISSZrr %xmm16, %xmm1, implicit-def %eflags
RET 0, %zmm0, %zmm1
RET 0, %zmm0, %zmm1
...

24
llvm/test/Other/lit-globbing.ll
View File

@ -15,15 +15,15 @@ RUN: echo %t/'T'??.txt | FileCheck -check-prefix=QUESTION2 %s
RUN: echo 'T*' 'T?.txt' 'T??.txt' | FileCheck -check-prefix=QUOTEDARGS %s
STAR-NOT: TB.txt
STAR: {{(TA.txt.*TAB.txt|TAB.txt.*TA.txt)}}
QUESTION-NOT: TAB.txt
QUESTION: {{(TA.txt.*TB.txt|TB.txt.*TA.txt)}}
QUESTION2-NOT: TA.txt
QUESTION2-NOT: TB.txt
QUESTION2: TAB.txt
QUOTEDARGS-NOT: .txt
QUOTEDARGS: T* T?.txt T??.txt
STAR-NOT: TB.txt
STAR: {{(TA.txt.*TAB.txt|TAB.txt.*TA.txt)}}
QUESTION-NOT: TAB.txt
QUESTION: {{(TA.txt.*TB.txt|TB.txt.*TA.txt)}}
QUESTION2-NOT: TA.txt
QUESTION2-NOT: TB.txt
QUESTION2: TAB.txt
QUOTEDARGS-NOT: .txt
QUOTEDARGS: T* T?.txt T??.txt

14
llvm/tools/llvm-cxxdump/llvm-cxxdump.cpp
View File

@ -546,10 +546,10 @@ int main(int argc, const char *argv[]) {
cl::ParseCommandLineOptions(argc, argv, "LLVM C++ ABI Data Dumper\n");
// Default to stdin if no filename is specified.
if (opts::InputFilenames.size() == 0)
opts::InputFilenames.push_back("-");
llvm::for_each(opts::InputFilenames, dumpInput);
return EXIT_SUCCESS;
}
if (opts::InputFilenames.size() == 0)
opts::InputFilenames.push_back("-");
llvm::for_each(opts::InputFilenames, dumpInput);
return EXIT_SUCCESS;
}

12
llvm/tools/llvm-mcmarkup/llvm-mcmarkup.cpp
View File

@ -215,9 +215,9 @@ int main(int argc, char **argv) {
ToolName = argv[0];
// If no input files specified, read from stdin.
if (InputFilenames.size() == 0)
InputFilenames.push_back("-");
llvm::for_each(InputFilenames, parseMCMarkup);
return 0;
}
if (InputFilenames.size() == 0)
InputFilenames.push_back("-");
llvm::for_each(InputFilenames, parseMCMarkup);
return 0;
}

14
llvm/tools/llvm-objdump/llvm-objdump.cpp
View File

@ -2194,10 +2194,10 @@ int main(int argc, char **argv) {
&& !PrintFaultMaps
&& DwarfDumpType == DIDT_Null) {
cl::PrintHelpMessage();
return 2;
}
llvm::for_each(InputFilenames, DumpInput);
return EXIT_SUCCESS;
}
return 2;
}
llvm::for_each(InputFilenames, DumpInput);
return EXIT_SUCCESS;
}

14
llvm/tools/llvm-size/llvm-size.cpp
View File

@ -880,13 +880,13 @@ int main(int argc, char **argv) {
}
if (InputFilenames.size() == 0)
InputFilenames.push_back("a.out");
MoreThanOneFile = InputFilenames.size() > 1;
llvm::for_each(InputFilenames, printFileSectionSizes);
if (OutputFormat == berkeley && TotalSizes)
printBerkelyTotals();
InputFilenames.push_back("a.out");
MoreThanOneFile = InputFilenames.size() > 1;
llvm::for_each(InputFilenames, printFileSectionSizes);
if (OutputFormat == berkeley && TotalSizes)
printBerkelyTotals();
if (HadError)
return 1;
}

646
openmp/runtime/doc/doxygen/libomp_interface.h
View File

@ -1,6 +1,6 @@
// This file does not contain any code; it just contains additional text and formatting
// for doxygen.
// This file does not contain any code; it just contains additional text and formatting
// for doxygen.
//===----------------------------------------------------------------------===//
//
@ -11,323 +11,323 @@
//
//===----------------------------------------------------------------------===//
/*! @mainpage LLVM&nbsp; OpenMP* Runtime Library Interface
@section sec_intro Introduction
This document describes the interface provided by the
LLVM &nbsp;OpenMP\other runtime library to the compiler.
Routines that are directly called as simple functions by user code are
not currently described here, since their definition is in the OpenMP
specification available from http://openmp.org
The aim here is to explain the interface from the compiler to the runtime.
The overall design is described, and each function in the interface
has its own description. (At least, that's the ambition, we may not be there yet).
@section sec_building Quickly Building the Runtime
For the impatient, we cover building the runtime as the first topic here.
CMake is used to build the OpenMP runtime. For details and a full list of options for the CMake build system,
see <tt>Build_With_CMake.txt</tt> inside the <tt>runtime/</tt> subdirectory. These
instructions will provide the most typical build.
In-LLVM-tree build:.
@code
$ cd where-you-want-to-live
Check out openmp into llvm/projects
$ cd where-you-want-to-build
$ mkdir build && cd build
$ cmake path/to/llvm -DCMAKE_C_COMPILER=<C compiler> -DCMAKE_CXX_COMPILER=<C++ compiler>
$ make omp
@endcode
Out-of-LLVM-tree build:
@code
$ cd where-you-want-to-live
Check out openmp
$ cd where-you-want-to-live/openmp/runtime
$ mkdir build && cd build
$ cmake path/to/openmp -DCMAKE_C_COMPILER=<C compiler> -DCMAKE_CXX_COMPILER=<C++ compiler>
$ make
@endcode
@section sec_supported Supported RTL Build Configurations
The architectures supported are IA-32 architecture, Intel&reg;&nbsp; 64, and
Intel&reg;&nbsp; Many Integrated Core Architecture. The build configurations
supported are shown in the table below.
<table border=1>
<tr><th> <th>icc/icl<th>gcc<th>clang
<tr><td>Linux\other OS<td>Yes(1,5)<td>Yes(2,4)<td>Yes(4,6,7)
<tr><td>FreeBSD\other<td>Yes(1,5)<td>Yes(2,4)<td>Yes(4,6,7,8)
<tr><td>OS X\other<td>Yes(1,3,4)<td>No<td>Yes(4,6,7)
<tr><td>Windows\other OS<td>Yes(1,4)<td>No<td>No
</table>
(1) On IA-32 architecture and Intel&reg;&nbsp; 64, icc/icl versions 12.x
are supported (12.1 is recommended).<br>
(2) gcc version 4.7 is supported.<br>
(3) For icc on OS X\other, OS X\other version 10.5.8 is supported.<br>
(4) Intel&reg;&nbsp; Many Integrated Core Architecture not supported.<br>
(5) On Intel&reg;&nbsp; Many Integrated Core Architecture, icc/icl versions 13.0 or later are required.<br>
(6) Clang\other version 3.3 is supported.<br>
(7) Clang\other currently does not offer a software-implemented 128 bit extended
precision type. Thus, all entry points reliant on this type are removed
from the library and cannot be called in the user program. The following
functions are not available:
@code
__kmpc_atomic_cmplx16_*
__kmpc_atomic_float16_*
__kmpc_atomic_*_fp
@endcode
(8) Community contribution provided AS IS, not tested by Intel.
Supported Architectures: IBM(R) Power 7 and Power 8
<table border=1>
<tr><th> <th>gcc<th>clang
<tr><td>Linux\other OS<td>Yes(1,2)<td>Yes(3,4)
</table>
(1) On Power 7, gcc version 4.8.2 is supported.<br>
(2) On Power 8, gcc version 4.8.2 is supported.<br>
(3) On Power 7, clang version 3.7 is supported.<br>
(4) On Power 8, clang version 3.7 is supported.<br>
@section sec_frontend Front-end Compilers that work with this RTL
The following compilers are known to do compatible code generation for
this RTL: icc/icl, gcc. Code generation is discussed in more detail
later in this document.
@section sec_outlining Outlining
The runtime interface is based on the idea that the compiler
"outlines" sections of code that are to run in parallel into separate
functions that can then be invoked in multiple threads. For instance,
simple code like this
@code
void foo()
{
#pragma omp parallel
{
... do something ...
}
}
@endcode
is converted into something that looks conceptually like this (where
the names used are merely illustrative; the real library function
names will be used later after we've discussed some more issues...)
@code
static void outlinedFooBody()
{
... do something ...
}
void foo()
{
__OMP_runtime_fork(outlinedFooBody, (void*)0); // Not the real function name!
}
@endcode
@subsection SEC_SHAREDVARS Addressing shared variables
In real uses of the OpenMP\other API there are normally references
from the outlined code to shared variables that are in scope in the containing function.
Therefore the containing function must be able to address
these variables. The runtime supports two alternate ways of doing
this.
@subsubsection SEC_SEC_OT Current Technique
The technique currently supported by the runtime library is to receive
a separate pointer to each shared variable that can be accessed from
the outlined function. This is what is shown in the example below.
We hope soon to provide an alternative interface to support the
alternate implementation described in the next section. The
alternative implementation has performance advantages for small
parallel regions that have many shared variables.
@subsubsection SEC_SEC_PT Future Technique
The idea is to treat the outlined function as though it
were a lexically nested function, and pass it a single argument which
is the pointer to the parent's stack frame. Provided that the compiler
knows the layout of the parent frame when it is generating the outlined
function it can then access the up-level variables at appropriate
offsets from the parent frame. This is a classical compiler technique
from the 1960s to support languages like Algol (and its descendants)
that support lexically nested functions.
The main benefit of this technique is that there is no code required
at the fork point to marshal the arguments to the outlined function.
Since the runtime knows statically how many arguments must be passed to the
outlined function, it can easily copy them to the thread's stack
frame. Therefore the performance of the fork code is independent of
the number of shared variables that are accessed by the outlined
function.
If it is hard to determine the stack layout of the parent while generating the
outlined code, it is still possible to use this approach by collecting all of
the variables in the parent that are accessed from outlined functions into
a single `struct` which is placed on the stack, and whose address is passed
to the outlined functions. In this way the offsets of the shared variables
are known (since they are inside the struct) without needing to know
the complete layout of the parent stack-frame. From the point of view
of the runtime either of these techniques is equivalent, since in either
case it only has to pass a single argument to the outlined function to allow
it to access shared variables.
A scheme like this is how gcc\other generates outlined functions.
@section SEC_INTERFACES Library Interfaces
The library functions used for specific parts of the OpenMP\other language implementation
are documented in different modules.
- @ref BASIC_TYPES fundamental types used by the runtime in many places
- @ref DEPRECATED functions that are in the library but are no longer required
- @ref STARTUP_SHUTDOWN functions for initializing and finalizing the runtime
- @ref PARALLEL functions for implementing `omp parallel`
- @ref THREAD_STATES functions for supporting thread state inquiries
- @ref WORK_SHARING functions for work sharing constructs such as `omp for`, `omp sections`
- @ref THREADPRIVATE functions to support thread private data, copyin etc
- @ref SYNCHRONIZATION functions to support `omp critical`, `omp barrier`, `omp master`, reductions etc
- @ref ATOMIC_OPS functions to support atomic operations
- @ref STATS_GATHERING macros to support developer profiling of libomp
- Documentation on tasking has still to be written...
@section SEC_EXAMPLES Examples
@subsection SEC_WORKSHARING_EXAMPLE Work Sharing Example
This example shows the code generated for a parallel for with reduction and dynamic scheduling.
@code
extern float foo( void );
int main () {
int i;
float r = 0.0;
#pragma omp parallel for schedule(dynamic) reduction(+:r)
for ( i = 0; i < 10; i ++ ) {
r += foo();
}
}
@endcode
The transformed code looks like this.
@code
extern float foo( void );
int main () {
static int zero = 0;
auto int gtid;
auto float r = 0.0;
__kmpc_begin( & loc3, 0 );
// The gtid is not actually required in this example so could be omitted;
// We show its initialization here because it is often required for calls into
// the runtime and should be locally cached like this.
gtid = __kmpc_global thread num( & loc3 );
__kmpc_fork call( & loc7, 1, main_7_parallel_3, & r );
__kmpc_end( & loc0 );
return 0;
}
struct main_10_reduction_t_5 { float r_10_rpr; };
static kmp_critical_name lck = { 0 };
static ident_t loc10; // loc10.flags should contain KMP_IDENT_ATOMIC_REDUCE bit set
// if compiler has generated an atomic reduction.
void main_7_parallel_3( int *gtid, int *btid, float *r_7_shp ) {
auto int i_7_pr;
auto int lower, upper, liter, incr;
auto struct main_10_reduction_t_5 reduce;
reduce.r_10_rpr = 0.F;
liter = 0;
__kmpc_dispatch_init_4( & loc7,*gtid, 35, 0, 9, 1, 1 );
while ( __kmpc_dispatch_next_4( & loc7, *gtid, & liter, & lower, & upper, & incr ) ) {
for( i_7_pr = lower; upper >= i_7_pr; i_7_pr ++ )
reduce.r_10_rpr += foo();
}
switch( __kmpc_reduce_nowait( & loc10, *gtid, 1, 4, & reduce, main_10_reduce_5, & lck ) ) {
case 1:
*r_7_shp += reduce.r_10_rpr;
__kmpc_end_reduce_nowait( & loc10, *gtid, & lck );
break;
case 2:
__kmpc_atomic_float4_add( & loc10, *gtid, r_7_shp, reduce.r_10_rpr );
break;
default:;
}
}
void main_10_reduce_5( struct main_10_reduction_t_5 *reduce_lhs,
struct main_10_reduction_t_5 *reduce_rhs )
{
reduce_lhs->r_10_rpr += reduce_rhs->r_10_rpr;
}
@endcode
@defgroup BASIC_TYPES Basic Types
Types that are used throughout the runtime.
@defgroup DEPRECATED Deprecated Functions
Functions in this group are for backwards compatibility only, and
should not be used in new code.
@defgroup STARTUP_SHUTDOWN Startup and Shutdown
These functions are for library initialization and shutdown.
@defgroup PARALLEL Parallel (fork/join)
These functions are used for implementing <tt>\#pragma omp parallel</tt>.
@defgroup THREAD_STATES Thread Information
These functions return information about the currently executing thread.
@defgroup WORK_SHARING Work Sharing
These functions are used for implementing
<tt>\#pragma omp for</tt>, <tt>\#pragma omp sections</tt>, <tt>\#pragma omp single</tt> and
<tt>\#pragma omp master</tt> constructs.
When handling loops, there are different functions for each of the signed and unsigned 32 and 64 bit integer types
which have the name suffixes `_4`, `_4u`, `_8` and `_8u`. The semantics of each of the functions is the same,
so they are only described once.
Static loop scheduling is handled by @ref __kmpc_for_static_init_4 and friends. Only a single call is needed,
since the iterations to be executed by any give thread can be determined as soon as the loop parameters are known.
Dynamic scheduling is handled by the @ref __kmpc_dispatch_init_4 and @ref __kmpc_dispatch_next_4 functions.
The init function is called once in each thread outside the loop, while the next function is called each
time that the previous chunk of work has been exhausted.
@defgroup SYNCHRONIZATION Synchronization
These functions are used for implementing barriers.
@defgroup THREADPRIVATE Thread private data support
These functions support copyin/out and thread private data.
@defgroup STATS_GATHERING Statistics Gathering from OMPTB
These macros support profiling the libomp library. Use --stats=on when building with build.pl to enable
and then use the KMP_* macros to profile (through counts or clock ticks) libomp during execution of an OpenMP program.
@section sec_stats_env_vars Environment Variables
This section describes the environment variables relevant to stats-gathering in libomp
@code
KMP_STATS_FILE
@endcode
This environment variable is set to an output filename that will be appended *NOT OVERWRITTEN* if it exists. If this environment variable is undefined, the statistics will be output to stderr
@code
KMP_STATS_THREADS
@endcode
This environment variable indicates to print thread-specific statistics as well as aggregate statistics. Each thread's statistics will be shown as well as the collective sum of all threads. The values "true", "on", "1", "yes" will all indicate to print per thread statistics.
@defgroup TASKING Tasking support
These functions support tasking constructs.
@defgroup USER User visible functions
These functions can be called directly by the user, but are runtime library specific, rather than being OpenMP interfaces.
*/
/*! @mainpage LLVM&nbsp; OpenMP* Runtime Library Interface
@section sec_intro Introduction
This document describes the interface provided by the
LLVM &nbsp;OpenMP\other runtime library to the compiler.
Routines that are directly called as simple functions by user code are
not currently described here, since their definition is in the OpenMP
specification available from http://openmp.org
The aim here is to explain the interface from the compiler to the runtime.
The overall design is described, and each function in the interface
has its own description. (At least, that's the ambition, we may not be there yet).
@section sec_building Quickly Building the Runtime
For the impatient, we cover building the runtime as the first topic here.
CMake is used to build the OpenMP runtime. For details and a full list of options for the CMake build system,
see <tt>Build_With_CMake.txt</tt> inside the <tt>runtime/</tt> subdirectory. These
instructions will provide the most typical build.
In-LLVM-tree build:.
@code
$ cd where-you-want-to-live
Check out openmp into llvm/projects
$ cd where-you-want-to-build
$ mkdir build && cd build
$ cmake path/to/llvm -DCMAKE_C_COMPILER=<C compiler> -DCMAKE_CXX_COMPILER=<C++ compiler>
$ make omp
@endcode
Out-of-LLVM-tree build:
@code
$ cd where-you-want-to-live
Check out openmp
$ cd where-you-want-to-live/openmp/runtime
$ mkdir build && cd build
$ cmake path/to/openmp -DCMAKE_C_COMPILER=<C compiler> -DCMAKE_CXX_COMPILER=<C++ compiler>
$ make
@endcode
@section sec_supported Supported RTL Build Configurations
The architectures supported are IA-32 architecture, Intel&reg;&nbsp; 64, and
Intel&reg;&nbsp; Many Integrated Core Architecture. The build configurations
supported are shown in the table below.
<table border=1>
<tr><th> <th>icc/icl<th>gcc<th>clang
<tr><td>Linux\other OS<td>Yes(1,5)<td>Yes(2,4)<td>Yes(4,6,7)
<tr><td>FreeBSD\other<td>Yes(1,5)<td>Yes(2,4)<td>Yes(4,6,7,8)
<tr><td>OS X\other<td>Yes(1,3,4)<td>No<td>Yes(4,6,7)
<tr><td>Windows\other OS<td>Yes(1,4)<td>No<td>No
</table>
(1) On IA-32 architecture and Intel&reg;&nbsp; 64, icc/icl versions 12.x
are supported (12.1 is recommended).<br>
(2) gcc version 4.7 is supported.<br>
(3) For icc on OS X\other, OS X\other version 10.5.8 is supported.<br>
(4) Intel&reg;&nbsp; Many Integrated Core Architecture not supported.<br>
(5) On Intel&reg;&nbsp; Many Integrated Core Architecture, icc/icl versions 13.0 or later are required.<br>
(6) Clang\other version 3.3 is supported.<br>
(7) Clang\other currently does not offer a software-implemented 128 bit extended
precision type. Thus, all entry points reliant on this type are removed
from the library and cannot be called in the user program. The following
functions are not available:
@code
__kmpc_atomic_cmplx16_*
__kmpc_atomic_float16_*
__kmpc_atomic_*_fp
@endcode
(8) Community contribution provided AS IS, not tested by Intel.
Supported Architectures: IBM(R) Power 7 and Power 8
<table border=1>
<tr><th> <th>gcc<th>clang
<tr><td>Linux\other OS<td>Yes(1,2)<td>Yes(3,4)
</table>
(1) On Power 7, gcc version 4.8.2 is supported.<br>
(2) On Power 8, gcc version 4.8.2 is supported.<br>
(3) On Power 7, clang version 3.7 is supported.<br>
(4) On Power 8, clang version 3.7 is supported.<br>
@section sec_frontend Front-end Compilers that work with this RTL
The following compilers are known to do compatible code generation for
this RTL: icc/icl, gcc. Code generation is discussed in more detail
later in this document.
@section sec_outlining Outlining
The runtime interface is based on the idea that the compiler
"outlines" sections of code that are to run in parallel into separate
functions that can then be invoked in multiple threads. For instance,
simple code like this
@code
void foo()
{
#pragma omp parallel
{
... do something ...
}
}
@endcode
is converted into something that looks conceptually like this (where
the names used are merely illustrative; the real library function
names will be used later after we've discussed some more issues...)
@code
static void outlinedFooBody()
{
... do something ...
}
void foo()
{
__OMP_runtime_fork(outlinedFooBody, (void*)0); // Not the real function name!
}
@endcode
@subsection SEC_SHAREDVARS Addressing shared variables
In real uses of the OpenMP\other API there are normally references
from the outlined code to shared variables that are in scope in the containing function.
Therefore the containing function must be able to address
these variables. The runtime supports two alternate ways of doing
this.
@subsubsection SEC_SEC_OT Current Technique
The technique currently supported by the runtime library is to receive
a separate pointer to each shared variable that can be accessed from
the outlined function. This is what is shown in the example below.
We hope soon to provide an alternative interface to support the
alternate implementation described in the next section. The
alternative implementation has performance advantages for small
parallel regions that have many shared variables.
@subsubsection SEC_SEC_PT Future Technique
The idea is to treat the outlined function as though it
were a lexically nested function, and pass it a single argument which
is the pointer to the parent's stack frame. Provided that the compiler
knows the layout of the parent frame when it is generating the outlined
function it can then access the up-level variables at appropriate
offsets from the parent frame. This is a classical compiler technique
from the 1960s to support languages like Algol (and its descendants)
that support lexically nested functions.
The main benefit of this technique is that there is no code required
at the fork point to marshal the arguments to the outlined function.
Since the runtime knows statically how many arguments must be passed to the
outlined function, it can easily copy them to the thread's stack
frame. Therefore the performance of the fork code is independent of
the number of shared variables that are accessed by the outlined
function.
If it is hard to determine the stack layout of the parent while generating the
outlined code, it is still possible to use this approach by collecting all of
the variables in the parent that are accessed from outlined functions into
a single `struct` which is placed on the stack, and whose address is passed
to the outlined functions. In this way the offsets of the shared variables
are known (since they are inside the struct) without needing to know
the complete layout of the parent stack-frame. From the point of view
of the runtime either of these techniques is equivalent, since in either
case it only has to pass a single argument to the outlined function to allow
it to access shared variables.
A scheme like this is how gcc\other generates outlined functions.
@section SEC_INTERFACES Library Interfaces
The library functions used for specific parts of the OpenMP\other language implementation
are documented in different modules.
- @ref BASIC_TYPES fundamental types used by the runtime in many places
- @ref DEPRECATED functions that are in the library but are no longer required
- @ref STARTUP_SHUTDOWN functions for initializing and finalizing the runtime
- @ref PARALLEL functions for implementing `omp parallel`
- @ref THREAD_STATES functions for supporting thread state inquiries
- @ref WORK_SHARING functions for work sharing constructs such as `omp for`, `omp sections`
- @ref THREADPRIVATE functions to support thread private data, copyin etc
- @ref SYNCHRONIZATION functions to support `omp critical`, `omp barrier`, `omp master`, reductions etc
- @ref ATOMIC_OPS functions to support atomic operations
- @ref STATS_GATHERING macros to support developer profiling of libomp
- Documentation on tasking has still to be written...
@section SEC_EXAMPLES Examples
@subsection SEC_WORKSHARING_EXAMPLE Work Sharing Example
This example shows the code generated for a parallel for with reduction and dynamic scheduling.
@code
extern float foo( void );
int main () {
int i;
float r = 0.0;
#pragma omp parallel for schedule(dynamic) reduction(+:r)
for ( i = 0; i < 10; i ++ ) {
r += foo();
}
}
@endcode
The transformed code looks like this.
@code
extern float foo( void );
int main () {
static int zero = 0;
auto int gtid;
auto float r = 0.0;
__kmpc_begin( & loc3, 0 );
// The gtid is not actually required in this example so could be omitted;
// We show its initialization here because it is often required for calls into
// the runtime and should be locally cached like this.
gtid = __kmpc_global thread num( & loc3 );
__kmpc_fork call( & loc7, 1, main_7_parallel_3, & r );
__kmpc_end( & loc0 );
return 0;
}
struct main_10_reduction_t_5 { float r_10_rpr; };
static kmp_critical_name lck = { 0 };
static ident_t loc10; // loc10.flags should contain KMP_IDENT_ATOMIC_REDUCE bit set
// if compiler has generated an atomic reduction.
void main_7_parallel_3( int *gtid, int *btid, float *r_7_shp ) {
auto int i_7_pr;
auto int lower, upper, liter, incr;
auto struct main_10_reduction_t_5 reduce;
reduce.r_10_rpr = 0.F;
liter = 0;
__kmpc_dispatch_init_4( & loc7,*gtid, 35, 0, 9, 1, 1 );
while ( __kmpc_dispatch_next_4( & loc7, *gtid, & liter, & lower, & upper, & incr ) ) {
for( i_7_pr = lower; upper >= i_7_pr; i_7_pr ++ )
reduce.r_10_rpr += foo();
}
switch( __kmpc_reduce_nowait( & loc10, *gtid, 1, 4, & reduce, main_10_reduce_5, & lck ) ) {
case 1:
*r_7_shp += reduce.r_10_rpr;
__kmpc_end_reduce_nowait( & loc10, *gtid, & lck );
break;
case 2:
__kmpc_atomic_float4_add( & loc10, *gtid, r_7_shp, reduce.r_10_rpr );
break;
default:;
}
}
void main_10_reduce_5( struct main_10_reduction_t_5 *reduce_lhs,
struct main_10_reduction_t_5 *reduce_rhs )
{
reduce_lhs->r_10_rpr += reduce_rhs->r_10_rpr;
}
@endcode
@defgroup BASIC_TYPES Basic Types
Types that are used throughout the runtime.
@defgroup DEPRECATED Deprecated Functions
Functions in this group are for backwards compatibility only, and
should not be used in new code.
@defgroup STARTUP_SHUTDOWN Startup and Shutdown
These functions are for library initialization and shutdown.
@defgroup PARALLEL Parallel (fork/join)
These functions are used for implementing <tt>\#pragma omp parallel</tt>.
@defgroup THREAD_STATES Thread Information
These functions return information about the currently executing thread.
@defgroup WORK_SHARING Work Sharing
These functions are used for implementing
<tt>\#pragma omp for</tt>, <tt>\#pragma omp sections</tt>, <tt>\#pragma omp single</tt> and
<tt>\#pragma omp master</tt> constructs.
When handling loops, there are different functions for each of the signed and unsigned 32 and 64 bit integer types
which have the name suffixes `_4`, `_4u`, `_8` and `_8u`. The semantics of each of the functions is the same,
so they are only described once.
Static loop scheduling is handled by @ref __kmpc_for_static_init_4 and friends. Only a single call is needed,
since the iterations to be executed by any give thread can be determined as soon as the loop parameters are known.
Dynamic scheduling is handled by the @ref __kmpc_dispatch_init_4 and @ref __kmpc_dispatch_next_4 functions.
The init function is called once in each thread outside the loop, while the next function is called each
time that the previous chunk of work has been exhausted.
@defgroup SYNCHRONIZATION Synchronization
These functions are used for implementing barriers.
@defgroup THREADPRIVATE Thread private data support
These functions support copyin/out and thread private data.
@defgroup STATS_GATHERING Statistics Gathering from OMPTB
These macros support profiling the libomp library. Use --stats=on when building with build.pl to enable
and then use the KMP_* macros to profile (through counts or clock ticks) libomp during execution of an OpenMP program.
@section sec_stats_env_vars Environment Variables
This section describes the environment variables relevant to stats-gathering in libomp
@code
KMP_STATS_FILE
@endcode
This environment variable is set to an output filename that will be appended *NOT OVERWRITTEN* if it exists. If this environment variable is undefined, the statistics will be output to stderr
@code
KMP_STATS_THREADS
@endcode
This environment variable indicates to print thread-specific statistics as well as aggregate statistics. Each thread's statistics will be shown as well as the collective sum of all threads. The values "true", "on", "1", "yes" will all indicate to print per thread statistics.
@defgroup TASKING Tasking support
These functions support tasking constructs.
@defgroup USER User visible functions
These functions can be called directly by the user, but are runtime library specific, rather than being OpenMP interfaces.
*/