本节按字母顺序介绍 cc 选项。手册页 cc (1) 中也提供了这些说明。使用 cc -flags 选项可获得一行有关这些说明的摘要。
注明特定于一个或多个平台的选项可被接受,且不会出现错误,但在其他所有平台上会被忽略。有关用于选项和参数的印刷符号的说明,请参阅印刷约定。
在调用每个组件时显示该组件,但不实际执行它。还显示命令选项扩展的过程。
将 name 作为谓词与指定的 tokens 关联,如同使用 #assert 预处理指令一样。预断言:
system(unix)
machine(sparc) (SPARC)
machine(i386) (x86)
cpu(sparc) (SPARC)
cpu(i386) (x86)
这些预断言在 -Xc 模式下无效。
如果 -A 后面仅跟随一个短横线 (-),将导致所有预定义宏(除那些以 __ 开头的宏以外)和预定义断言被忽略。
指定用于链接的库绑定是 static 类型还是 dynamic 类型,可分别指明库是非共享的还是共享的。
如果给定 -lx 选项,则 -Bdynamic 使链接编辑器查找名称为 libx.so 的文件,然后查找名称为 libx.a 的文件。
–Bstatic 使链接编辑器仅查找名称为 libx.a 的文件。此选项可作为一个切换开关在命令行中多次指定。此选项及其参数将传递给 ld(1)。
在 Solaris 64 位编译环境中,许多系统库(例如 libc)都只能作为动态库使用。因此,请勿在命令行上将 -Bstatic 用作最后一个切换开关。
此选项及其参数传递给链接程序。
防止 C 预处理程序删除注释,位于预处理指令行中的注释除外。
指示 C 编译器用 ld(1) 抑制链接并为每个源文件生成一个 .o 文件。您可使用 -o 选项显式指定单个目标文件。当编译器生成每个 i 或 . c 输入文件的对象代码时,总是会在当前的工作目录中创建一个对象 (.o) 文件。如果抑制链接步骤,将会同时抑制删除目标文件。
使用可选参数定义宏,如同使用 #define 预处理指令定义宏一样。如果未指定 =expansion,则编译器假定为 1。
有关编译器预定义宏的列表,请参见 cc(1) 手册页。
-dn 指定链接编辑器中的静态链接。
此选项及其参数将传递给 ld(1)。
如果将此选项与动态库结合使用,将导致致命错误。大多数系统库仅作为动态库可用。
(SPARC) 已废弃。您不该使用此选项。改用 -xmemalign=8s。有关更多信息,请参见B.2.117 -xmemalign=ab。有关已废弃的选项的完整列表,请参见A.1.15 废弃的选项。在 x86 平台上会在无提示的情况下忽略此选项。
仅通过预处理程序运行源文件,并将输出发送给 stdout。预处理程序直接构建到编译器中,但 -Xs 模式除外,因为该模式会调用 /usr/ccs/lib/cpp。包含预处理程序行号信息。另请参见 – P 选项。
如果要将字符串 "error: " 作为前缀添加到错误消息开头以将错误消息与警告消息相区分,可使用此选项。此前缀也可附加到通过 -errwarn 转换成错误的警告。
表 B–1 -errfmt 标志
标志 |
含义 |
---|---|
error |
向所有错误消息添加前缀 "error: "。 |
no%error |
不向任何错误消息添加前缀 "error: "。 |
如果不指定此选项,则编译器将其设置为 -errfmt=no%error。如果您指定 -errfmt,但不提供值,则编译器将其设置为 -errfmt=error。
将来自头文件的警告限制为由以下标志所指示的头文件组:
表 B–2 -errhdr 选项
值 |
含义 |
---|---|
%all |
检查使用的所有头文件。 |
%none |
不检查头文件。 |
%user |
检查所有用户头文件,但 /usr/include 及其子目录中的头文件除外。此外,还检查编译器提供的所有头文件。这是缺省值。 |
此命令抑制 C 编译器警告消息,但对错误消息没有影响。此选项适用于所有警告消息,无论这些警告消息是否已被 -errwarn 指定为导致非零退出状态。
t 是一个以逗号分隔的列表,它包含以下项中的一项或多项:tag、no% tag、%all、%none。顺序是很重要的;例如 %all,no%tag 抑制除 tag 以外的所有警告消息。下表列出了 -erroff 值:
表 B–3 -erroff 标志
标志 |
含义 |
---|---|
tag |
抑制由该 tag 指定的警告消息。可通过 -errtags=yes 选项来显示消息的标记。 |
no%tag |
启用此 tag 指定的警告消息 |
%all |
抑制所有警告消息 |
%none |
启用所有警告消息(缺省值) |
缺省值为 -erroff=%none。指定 -erroff 与指定 -erroff=%all 等效。
-erroff 选项只能抑制来自 C 编译器前端并在使用 -errtags 选项时显示标记的警告消息。您可以更好地控制错误消息抑制。请参见2.9.6 error_messages。
使用此选项可在编译器发现类型不匹配时控制所生成错误消息的详细程度。当编译器发现涉及到大聚集的类型不匹配时,此选项特别有用。
i 可以是以下各项之一:
表 B–4 -errshort 标志
标志 |
含义 |
---|---|
short |
以短形式输出错误消息,且不会出现类型扩展。不扩展聚集成员、函数参数和返回类型。 |
full |
以完全详细形式输出错误消息,并显示不匹配类型的完全扩展。 |
tags |
对于具有标记名称的类型,输出错误消息的标记名称。无标记名称的类型将以扩展形式显示。 |
如果不指定 -errshort,编译器会将该选项设置为 -errshort=full。如果指定 -errshort 但不提供值,编译器会将该选项设置为 -errshort=tags。
此选项不会累积,它接受在命令行指定的最后一个值。
为 C 编译器前端可用 -erroff 选项抑制或用 -errwarn 选项生成致命错误的每条警告消息显示消息标记。来自 C 编译器驱动程序以及 C 编译系统其他组件的消息不带错误标记,使用 -errof 选项并不能抑制这些消息,而使用 -errwarn 选项也不会产生致命错误。
a 可以是 yes 或 no。缺省值为 -errtags=no。指定 -errtags 与指定 -errtags=yes 等效。
使用 -errwarn 选项会使 C 编译器以给定警告消息的故障状态退出。
t 是一个以逗号分隔的列表,它包含以下项中的一项或多项:tag、no% tag、%all、%none。顺序很重要,例如如果出现除 tag 之外的任何警告,%all,no%tag 会使 cc 以致命状态退出。
由于编译器错误检查的改善和功能的增加,C 编译器生成的警告消息也会因发行版本而异。使用 -errwarn=%all 进行编译而不会产生错误的代码,在编译器下一个发行版本中编译时也可能出现错误。
只有来自 C 编译器前端在使用 -errtags 选项时会显示标记的警告消息可以使用 -errwarn 选项进行指定,从而使 C 编译器以失败状态退出。
下表详细列出了 -errwarn 值:
表 B–5 -errwarn 标志
标志 |
含义 |
---|---|
tag |
在此 tag 指定的消息作为警告消息发出时导致 cc 以致命状态退出。如果未出现 tag,则没有影响。 |
no%tag |
在 tag 指定的消息仅作为警告消息发出时防止 cc 以致命状态退出。如果未发出 tag 指定的消息,则不会产生任何影响。为了避免在发出警告消息时导致 cc 以致命状态退出,可使用该选项来还原以前用该选项和 tag 或 %all 指定的警告消息。 |
%all |
在发出任何警告消息时导致编译器以致命状态退出。%all 可以后跟 no%tag,以避免该行为的特定警告消息。 |
%none |
在发出任何警告消息时防止警告消息导致编译器以致命状态退出。 |
缺省值为 -errwarn=%none。如果单独指定 -errwarn,它与 -errwarn=%all 等效。
此选项是一个宏,可将其有效用作为尽量提高运行时性能而调整可执行程序的起点。-fast 是一个宏,随编译器发行版本的升级而变化,并扩展为目标平台特定的多个选项。可使用 -# 选项或 -xdryrun 检查 -fast 的扩展选项,并将 -fast 的相应选项结合到正在进行的可执行文件优化过程中。
-fast 的扩展选项包括 -xlibmopt 选项,该选项使编译器可使用优化的数学例程库。有关更多信息,请参见B.2.105 -xlibmopt。
-fast 选项会影响 errno 的值。有关更多信息,请参见2.11 errno 的值。
用 -fast 编译的模块必须也用 -fast 进行链接。有关在编译时和链接时都必须指定的所有编译器选项的完整列表,请参见A.1.2 编译时选项和链接时选项。
–fast 选项不适于计划在编译机器之外的其他目标机器上运行的程序。在这种情况下,请在 -fast 后附带相应的 -xtarget 选项。例如:
cc -fast -xtarget=ultra ... |
对于依赖于 SUID 指定的异常处理的 C 模块,请在 -fast 后附带 -xnolibmil:
% cc -fast -xnolibmil |
使用 -xlibmil 时,通过设置 errno 或调用 matherr(3m) 无法标记异常。
–fast 选项不适于要求与 IEEE 754 标准严格一致的程序。
下表列出了 -fast 在各平台中选择的选项集。
表 B–6 -fast 扩展选项标志
选项 |
SPARC |
x86 |
---|---|---|
X |
X |
|
X |
X |
|
X |
X |
|
- |
X |
|
X |
X |
|
X |
X |
|
X |
X |
|
X |
X |
|
X |
- |
|
-xO5 |
X |
X |
-xprefetch=auto,explicit |
X |
- |
-xregs=frameptr |
- |
X |
-xtarget=native |
X |
X |
有些优化对程序行为进行特定假定。如果程序不符合这些假定,应用程序将会崩溃或产生错误结果。请参阅各个选项的描述,以确定您的程序是否适合用 -fast 编译。
由这些选项执行的优化可能会改变由 ISO C 和 IEEE 标准定义的程序的行为。有关详细信息,请参见特定选项的描述。
–fast 的作用与命令行上的宏扩展相同。因此,您可以通过在 -fast 后附带预期的优化级别或代码生成选项来覆盖优化级别和代码生成选项。使用 -fast -xO4 对进行编译类似于使用 -xO2 -xO4 对进行编译。后者优先。
请勿对依赖于 IEEE 标准异常处理的程序使用此选项;否则会产生不同的数值结果、程序提前终止或意外的 SIGFPE 信号。
要在运行的平台上查看 -fast 的实际扩展,请使用
% cc -fast -xdryrun |
值 |
含义 |
---|---|
[no%]conststrings |
启用或禁用将文本字符串放置在只读内存中。缺省值为 -features=conststrings,这会将文本字符串放在只读的数据段中。请注意,现在,使用此选项进行编译时,编译尝试写入文本字符串内存位置的程序会导致段故障。 |
extensions |
允许零大小的结构/联合声明以及返回语句返回一个值的 void 函数起作用。 |
extinl |
将外部内联函数生成为全局函数。这是缺省值,符合 1999 C 标准。使用 -features=no%extinl 编译新代码可获得与旧版的 C 和 C++ 编译器相同的 extern 内联函数处理方式。 |
no%extinl |
将外部内联函数生成为静态函数。 |
%none |
此选项被禁用。 |
旧的 C 和 C++ 对象(使用本发行版之前的 Sun 编译器创建的对象)可以与新的 C 和 C++ 对象链接,而不会更改旧对象的行为。要获得标准的符合规范的行为,您必须使用当前编译器重新编译旧代码。
如果不为 -features 指定设置,编译器将把它设置为 -features=extinl。
标志 |
含义 |
---|---|
2 |
浮点表达式求值为 long double。 |
any |
根据构成表达式的变量和常量类型的组合来对浮点表达式进行求值。 |
如果未指定 -flteval,编译器会将其设置为 -flteval=any。如果指定了 -flteval 但未提供值,编译器会将其设置为 -flteval=2。
您不能将以下选项与 -flteval=2 一起指定:
另请参见D.1.1 浮点计算器的精度。
(SPARC) 启用自动生成浮点乘加指令。-fma=none 禁用这些指令的生成。-fma=fused 允许编译器通过使用浮点乘加指令,尝试寻找改进代码性能的机会。
缺省值是 -fma=none。
要使编译器生成乘加指令,最低要求是 -xarch=sparcfmaf 且优先级别至少为 -xO2。如果生成了乘加指令,编译器会标记此二进制程序,以防止该程序在不受支持的平台上执行。
合并的乘加消除了乘法与加法之间的中间舍入步骤。因此,当使用 -fma=fused 进行编译时,程序可能产生不同的结果,但精度往往会提高,而不是降低。
(SPARC) 此选项是用于 -fns 和 -ftrap=common 的宏。
缺省值为 -fns=no ,即 SPARC 标准浮点模式。-fns 与 -fns=yes 相同。
可以选择使用 =yes 或 =no,此方法使您可以切换包含 -fns 的其他某个宏标志(如 -fast)后面的 -fns 标志。
在一些 SPARC 系统上,使用非标准浮点模式会禁用“渐进下溢”,导致将微小的结果刷新为零,而不是产生非正规数。它还导致次正规操作数被替换为零而无提示。在那些不支持硬件中的渐进下溢和次正规数的 SPARC 系统上,使用此选项将显著提高某些程序的性能。
在启用了非标准模式的情况下,浮点运算可能会产生不符合 IEEE 754 标准要求的结果。有关详细信息,请参见《数值计算指南》。
此选项仅对 SPARC 系统且仅在编译主程序时使用才有效。在 x86 系统上,忽略此选项。
(x86) 选择 SSE 刷新为零模式以及(如果可用)非正规数为零模式。
此选项导致将次正规结果刷新为零。如果可用的话,此选项还导致将次正规操作数视为零。
此选项不会影响不利用 SSE 或 SSE2 指令集的传统 x86 浮点运算。
与 -KPIC 等效
与 -Kpic 等效
(x86) -fprecision={single, double, extended}
将浮点控制字中的舍入精度模式位分别初始化为 single(24 位)、double(53 位)或 extended(64 位)。缺省的浮点舍入精度模式为 extended。
注意,在 x86 中,浮点舍入精度模式的设置只影响精度,不影响指数、范围。
设置程序初始化期间在运行时建立的 IEEE 754 舍入模式。
r 必须是以下值之一: nearest、 tozero、negative、positive。
缺省值为 -fround=nearest。
含义与 ieee_flags 子例程的含义相同。
如果 r 为 tozero、negative 或 positive,此标志将在程序开始执行时分别将舍入方向模式设置为舍入到零、舍入到负无穷大或舍入到正无穷大。当 r 为 nearest 或未使用 -fround 标志时,舍入方向模式将保留其初始值不变(缺省为舍入到最接近的值)。
只有编译主程序时该选项才有效。
编译器缺省采用 -fsimple=0。指定 -fsimple 与指定 -fsimple=1 等效。
如果存在 n,它必须是 0、1 或 2。
表 B–9 -fsimple 标志
即使 -fsimple=2,也不允许优化器在不产生任何内容的程序中引入浮点异常。
有关优化对精度的影响的详细说明,请参见由 Rajat Garg 和 Ilya Sharapov 合著的《Techniques for Optimizing Applications: High Performance Computing》。
(仅限 -Xt 和 -Xs 模式)使编译器按单精度而非双精度对 float 表达式求值。由于已按单精度对 float 表达式进行求值,因此如果在 -Xa 或 -Xc 模式下使用编译器,此选项将无效。
(x86) 将表达式或函数赋值给一个变量时或将表达式强制转换为短浮点类型时,该命令可使编译器将浮点表达式或函数的值转换为赋值语句左侧的类型,而不是在寄存器中保留值。由于舍入和截尾,结果可能会与使用寄存器值生成的结果不同。这是缺省模式。
要关闭此选项,请使用 -nofstore 选项。
设置启动时生效的 IEEE 捕获模式,但不安装 SIGFPE 处理程序。可以使用 ieee_handler(3M) 或 fex_set_handling(3M) 启用陷阱并同时安装 SIGFPE 处理程序。如果指定多个值,则按从左到右顺序处理列表。
t 可以是下列值之一。
表 B–10 -ftrap 标志
标志 |
含义 |
---|---|
[no%]division |
[不] 在除以零时自陷。 |
[no%]inexact |
[不] 在结果不精确时自陷。 |
[no%]invalid |
[不] 在无效操作上自陷。 |
[no%]overflow |
[不] 在溢出上自陷。 |
[no%]underflow |
[不] 在下溢上自陷。 |
%all |
在所有以上内容中自陷。 |
%none |
不在以上任何内容中自陷。 |
common |
在无效、除以零和溢出时自陷。 |
注意,选项的 [no%] 形式只用于修改 %all 和 common 值的含义,且必须与其中的一个值一起使用,如以下示例所示。选项自身的 [no%] 形式不会显式导致禁用特定的陷阱。
如果不指定 -ftrap,则编译器假定 -ftrap=%none。
示例: –ftrap=%all,no%inexact 意味着设置所有陷阱,但 inexact 除外。
如果使用 -ftrap=t 编译一个例程,就还要使用相同的 -ftrap=t 选项来编译该程序的所有例程;否则就会获得意外的结果。
使用 -ftrap=inexact 陷阱时务必谨慎。只要浮点值不能精确表示,使用 – ftrap=inexact 便会产生自陷。例如,以下语句就会产生这种情况:
x = 1.0 / 3.0; |
只有编译主程序时该选项才有效。请小心使用该选项。如果希望启用 IEEE 陷阱,请使用 –ftrap=common。
生成共享对象而非动态链接的可执行文件。此选项将传递给 ld(1),并且无法与 -dn 选项一起使用。
使用 -G 选项时,编译器不将任何缺省 -l 选项传递到 ld 选项。如果您要使共享库具有对另一共享库的依赖性,就必须在命令行上传递必需的 -l 选项。
如果通过指定 -G 以及其他必须在编译时和链接时指定的编译器选项来创建共享对象,请确保在与生成的共享对象链接时也指定这些选项。
创建共享对象时,用 -xarch=v9 编译的所有目标文件还必须用显式 -xcode 值(如B.2.86 -xcode[= v]中所记录)进行编译。
为使用 dbx(1) 和性能分析器 analyzer(1) 进行调试生成附加符号表信息。
如果指定 -g,并且优化级别为 -xO3 或更低,则编译器提供几乎进行全面优化的最佳效果符号信息。尾部调用优化和后端内联被禁用。
如果指定 -g,并且优化级别为 -xO4,则编译器提供进行全面优化的最佳效果符号信息。
使用 -g 选项进行编译,以使用性能分析器的全部功能。虽然某些性能分析功能不需要使用 -g,但必须使用 -g 进行编译,以便查看注释的源代码、部分函数级别信息以及编译器注释消息。有关更多信息,请参见 analyzer(1) 手册页和《性能分析器》手册。
使用 -g 生成的注释消息描述编译器在编译程序时进行的优化和变换。使用 er_src(1) 命令来显示与源代码交叉的消息。
在以前的发行版中,此选项强制编译器在缺省情况下使用增量链接程序 (ild),而不使用用于编译器的仅链接调用的链接程序 (ld)。也就是说,使用 -g 时,只要使用编译器来链接目标文件,编译器的缺省行为就是自动调用 ild 而不是 ld,除非您在命令行上指定了 -G 或源文件。现在已不再是这种情况。增量链接程序不再可用。
有关调试的更多信息,请参见《使用 dbx 调试程序》手册。
输出到标准错误,每行一个错误,包含当前编译期间每个文件的路径名。这样输出的目的是显示包含在其他文件中的文件。
此处,程序 sample.c 包含文件 stdio.h 和 math.h;math.h 包含文件 floatingpoint.h,该文件本身还包含使用 sys/ieeefp.h 的函数:
% cc -H sample.c /usr/include/stdio.h /usr/include/math.h /usr/include/floatingpoint.h /usr/include/sys/ieeefp.h |
为动态共享库分配一个名称,从而可以获得一个库的不同版本。通常,-h 后面的 name 应与 -o 选项后指定的文件名相同。-h 和 name 之间的空格是可选的。
链接程序会为该库分配指定的 name,并在库文件中将该名称记录为库的内在名称。如果 -hname 选项不存在,则库文件中不记录任何内在名称。
当运行时链接程序将库装入可执行文件时,它将内在名称从库文件复制到可执行文件和一组所需共享库文件中。每个可执行文件都有这样的列表。如果没有共享文件的内部名称,链接程序就复制共享库文件的路径。
-I dir 将 dir 添加到在其中搜索 #include 文件(/usr/include 前是相对文件名)的目录列表中,也就是说,这些目录路径不以 /(斜线)开头。
以指定的顺序搜索多个 -I 选项的目录。
有关编译器搜索模式的更多信息,请参见2.14.1 使用 -I- 选项更改搜索算法。
将选项传递给链接程序,以忽略任何 LD_LIBRARY_PATH 或 LD_LIBRARY_PATH_64 设置。
此选项使编译器将 filename 视为作为 #include 预处理程序指令出现在主源文件的第一行。考虑源文件 t.c:
main() { ... } |
如果使用命令 cc -include t.h t.c 编译 t.c,则编译时好像源文件包含以下项:
#include "t.h" main() { ... } |
编译器在其中搜索 filename 的第一个目录是当前工作目录而不是包含主源文件的目录,这就是显式包括某个文件时的情况。例如,下面的目录结构包含两个名称相同但位置不同的头文件:
foo/ t.c t.h bar/ u.c t.h |
如果您的工作目录是 foo/bar,并且您使用命令 cc ../t.c -include t.h 进行编译,则编译器会包括 foo/bar 中的 t.h 而不是 foo/ 中的此文件,后者是源文件 t.c 内包含 #include 指令时的情况。
如果编译器在当前工作目录中找不到使用 -include 指定的文件,则会在正常目录路径中搜索该文件。如果您指定多个 -include 选项,则文件的包括顺序与它们在命令行中的顺序相同。
(SPARC) 已废弃。您不该使用此选项。改用 -xcode=pic32。
有关更多信息,请参见B.2.86 -xcode[= v]。有关废弃选项的完整列表,请参见A.1.15 废弃的选项。
(SPARC) 已废弃。您不该使用此选项。改用 -xcode=pic13。有关更多信息,请参见B.2.86 -xcode[= v]。有关废弃选项的完整列表,请参见A.1.15 废弃的选项。
(x86) 生成要在共享库中使用的与位置无关的代码。允许最多引用 2**11 个唯一外部符号。
将 dir 添加到通过 ld(1) 在其中搜索库的目录列表中。此选项及其参数将传递给 ld(1)。
任何时候都不要将编译器安装区域 /usr/include、/lib 或 /usr/lib 指定为搜索目录。
与目标库 libname.so 或 libname.a 链接。库在命令行中的顺序很重要,因为符号是从左向右进行解析。
此选项必须位于 sourcefile 参数之后。
指定编译的二进制对象的内存模型。
使用 -m32 来创建 32 位可执行文件和共享库。使用 -m64 来创建 64 位可执行文件和共享库。
在所有 Solaris 平台和不支持 64 位的 Linux 平台上,ILP32 内存模型(32 位 int、long、pointer 数据类型)是缺省值。在启用了 64 位的 Linux 平台上缺省为 LP64 内存模型(64 位 long 和指针数据类型)。-m64 仅允许在支持 LP64 模型的平台上使用。
使用 -m32 编译的对象文件或库无法与使用 -m64 编译的对象文件或库链接。
使用 -m32|-m64 编译的模块必须还使用 -m32 |-m64 进行链接。有关在编译时和链接时都必须指定的编译器选项的完整列表,请参见A.1.2 编译时选项和链接时选项。
使用 -m64 编译具有大量静态数据的应用程序时,可能还需要 -xmodel=medium。请注意,部分 Linux 平台不支持中等模型。
请注意,在早期的编译器发行版中,由 -xarch 选项中选择的指令集来指定内存模型(ILP32 或 LP64)。从 Sun Studio 12 编译器开始,就不再是这样了。在大多数平台上,仅需将 -m64 添加到命令行便可以创建 64 位对象。
在 Solaris 上,-m32 是缺省选项。在支持 64 位程序的 Linux 系统上,-m64 -xarch=sse2 是缺省选项。
另请参见 -xarch。
从目标文件的 .comment 部分中删除重复字符串。使用 -mc 标志时,会调用 mcs -c。
(SPARC) 已废弃。您不该使用此选项。应改用 -xmemalign=1i 选项。有关更多信息,请参见B.2.117 -xmemalign=ab。有关废弃选项的完整列表,请参见A.1.15 废弃的选项。
(SPARC) 已废弃。您不该使用此选项。应改用 -xmemalign=2i 选项。有关更多信息,请参见B.2.117 -xmemalign=ab。有关废弃选项的完整列表,请参见A.1.15 废弃的选项。
-mr 可从 .comment 部分中删除所有字符串。使用此标志时,会调用 mcs -d -a。
-mr,string 可从 .comment 部分中删除所有字符串,并在目标文件的该部分插入 string。如果 string 包含嵌入空白,则必须将其括入引号。空 string 将导致 .comment 部分为空。此选项将作为 -d -astring 传递给 mcs。
使用此选项,可以通过 Solaris 线程或 POSIX 线程 API 编译和链接多线程代码。-mt 选项确保库以正确的顺序链接。
此选项将 -D_REENTRANT 传递给预处理程序。
要使用 Solaris 线程,请包括 thread.h 头文件并使用 -mt 选项进行编译。要在 Solaris 平台上使用 POSIX 线程,请包括 pthread.h 头文件并使用 -mt -lpthread 选项进行编译。
在 Linux 平台上,只有 POSIX 线程 API 可用。(Linux 平台上没有 libthread)。因此,Linux 平台上的 -mt 会添加 -lpthread,而不是 -lthread。要在 Linux 平台上使用 POSIX 线程,请使用 -mt 进行编译。
请注意,当使用 -G 进行编译时,-lthread 和 -lpthread 均不会自动包括在 -mt 内。生成共享库时,您需要显式列出这些库。
-xopenmp 选项(用于使用 OpenMP 共享内存并行化 API)自动包括 -mt。
如果使用 -mt 进行编译并在一个单独的步骤中进行链接,则必须在链接步骤和编译步骤中使用 -mt 选项。如果使用 -mt 编译和链接一个翻译单元,则必须使用 -mt 编译和链接程序的所有单元。
-xnolib、Solaris《多线程编程指南》和《链接程序和库指南》
(x86) 将表达式或函数赋值给一个变量时或将表达式强制转换为短浮点类型时,该命令不将浮点表达式或函数的值转换为赋值语句左侧的类型,而在寄存器中保留该值。另请参见B.2.31 -fstore。
使用缺省优化级别 -xO3。-O 宏现在扩展为 -xO3 而非 -xO2。
这种特殊变化会提高运行时性能。但是,对于依赖于被自动视为 volatile 的所有变量的程序,-x03 可能不适用。可能做出此假定的典型程序包括设备驱动程序,以及实现其自己的同步基元的较旧的多线程应用程序。解决方法是用 -xO2 而不是 -O 进行编译。
将输出文件命名为 filename(与缺省文件名 a.out 相对)。filename 的名称不能与sourcefile 相同,因为 cc 不覆盖源文件。 此选项及其参数将传递给 ld(1)。
只通过 C 预处理程序运行源文件。然后将输出放在带有 .i 后缀的文件中。与 -E 不同,此选项不在输出中包括预处理程序类型的行号信息。另请参见 -E 选项。
已废弃,请参见B.2.134 -xpg。
如果使用 -Qy,则将关于每个调用的编译工具的标识信息添加到输出文件的 .comment 部分,使用 mcs 可访问这部分文件。此选项对软件管理十分有用。
-Qn 可抑制此信息。
将用来指定库搜索目录的、冒号分隔的目录列表传递给运行时链接程序。如果此选项存在且非空,则它记录在输出目标文件中并传递给运行时链接程序。
如果同时指定了 LD_RUN_PATH 和 -R 选项,则 -R 选项优先。
从输出目标文件中删除所有符号调试信息。此选项不能与 -g 一同指定。
传递给 ld(1)。
取消定义预处理程序符号 name。此选项可删除由 -D 在命令行上创建的预处理程序符号 name 的任何初始定义,包括那些由命令行驱动程序放置的定义。
-U 对源文件中的预处理程序指令没有任何影响。可以在命令行上指定多个 -U 选项。
如果在命令行中为 -D 和 -U 指定了相同的 name,则取消定义 name,而无论这些选项出现的顺序如何。在以下示例中,-U 取消定义 __sun:
cc -U__sun text.c |
由于已取消定义 __sun,因此在 test.c 中采用以下形式的预处理程序语句将不会生效。
#ifdef(__sun) |
有关预定义符号的列表,请参见B.2.7 -Dname[( arg[,arg])][= expansion]。
指示编译器执行更严格的语义检查并启用其他与 lint 类似的检查。例如,如下所示代码:
#include <stdio.h> main(void) { printf("Hello World.\n"); } |
编译和执行时不会出现问题。如果使用 -v,该代码仍可编译;但是,编译器会显示以下警告:
"hello.c", line 5: warning: function has no return statement: main |
-v 不能给出 lint(1) 给出的所有警告。尝试通过 lint 运行以上示例。
将参数 arg 传递给指定的组件 c。有关组件的列表,请参见表 1–1。
每个参数与前一个参数之间仅以逗号分隔。所有 -W 参数均在常规命令行参数之后进行传递。在紧靠逗号之前使用转义符 \(反斜杠)可将逗号作为参数的一部分。所有 -W 参数均在常规命令行参数之后进行传递。
例如,-Wa,-o,objfile 按顺序将 -o 和 objfile 传递给汇编程序。此外,-Wl,-I,name 将导致链接阶段覆盖动态链接程序的缺省名称 /usr/lib/ld.so.1。
参数传递到工具的顺序可能会因其他指定的命令行选项而更改。
c 可以是以下项之一:
表 B–11 -W 标志
标志 |
含义 |
---|---|
a |
汇编程序: (fbe); (gas) |
c |
C 代码生成器: (cg) (SPARC) ; |
d |
cc 驱动程序 |
h |
中间代码翻译者 (ir2hf)(x86) |
l |
链接编辑器 (ld) |
m |
mcs |
O(大写的 o) |
过程间优化器 |
o(小写的 o) |
后优化器 |
p |
预处理程序 (cpp) |
u |
C 代码生成器 (ube) (x86) |
0 (Zero) |
编译器 (acomp) (ssbd, SPARC) |
2 |
优化器: (iropt) |
此选项会覆盖 error_messages pragma。
-X(注意是大写的 X)选项指定对 ISO C 标准不同程度的遵从性。-xc99 的值影响 -X 选项所应用的 ISO C 标准的版本。-xc99 选项的缺省值为支持 1999 ISO/IEC C 标准的 -xc99=all。-xc99=none 支持 1990 ISO/IEC C 标准。有关对 1999 ISO/IEC 支持功能的讨论,请参见表 C–6。有关 ISO/IEC C 与 K&R C 的不同点的讨论,请参见G.2 libfast.a 库。
-Xc
(c =一致性)对使用非 ISO C 构造的程序发出错误和警告。此选项与 ISO C 严格一致,没有 K&R C 兼容性扩展。如果使用 -Xc 选项,预定义的宏 __STDC__ 的值为 1。
-Xa
这是缺省编译器模式。ISO C 以及 K&R C 兼容性扩展,具有 ISO C 要求的语义更改。如果 K&R C 和 ISO C 为同一构造指定不同语义,则编译器使用 ISO C 解释。如果 -Xa 选项与 -xtransition 选项配合使用,则编译器发出关于不同语义的警告。如果使用 -Xa 选项,预定义的宏 __STDC__ 的值为 -0。
-Xt
(t = transition) 此选项使用 ISO C 加 K&R C 兼容性扩展,而没有 ISO C 所要求的语义更改。 当 K&R C 和 ISO C 为相同的结构指定不同的语义时,编译器使用 K&R C 解释。如果将 -Xt 选项与 -xtransition 选项配合使用,则编译器发出关于不同语义的警告。使用 -Xt 选项时,预定义的宏 __STDC__ 的值为 0。
-Xs
(s = K&R C) 试图对 ISO C 和 K&R C 产生不同行为的所有语言构造发出警告。编译器语言包括与 K&R C 兼容的所有功能。此选项调用 cpp 以进行预处理。__STDC__ 在此模式下未定义。
(x86) 已废弃。您不该使用此选项。改用 -xchip=generic。有关废弃选项的完整列表,请参见A.1.15 废弃的选项。
(x86) 已废弃。您不该使用此选项。改用 -xchip=generic。有关废弃选项的完整列表,请参见A.1.15 废弃的选项。
已过时。不使用此选项。改用 -xprofile=tcov。有关废弃选项和标志的完整列表,请参见A.1.15 废弃的选项。
(仅限 Solaris x86/x64)-xaddr32=yes 编译标志将生成的可执行文件或共享对象限定为 32 位地址空间。
以这种方式编译的可执行文件会导致创建限定为 32 位地址空间的进程。
当指定了 -xaddr32=no 时,会产生通常的 64 位二进制文件。
如果未指定 -xaddr32 选项,则假定 -xaddr32=no。
如果仅指定了 -xaddr32,则假定 -xaddr32=yes。
此选项仅适用于 -m64 编译,并且仅仅在支持 SF1_SUNW_ADDR32 软件功能的 Solaris 平台上适用。由于 Linux 内核不支持地址空间限制,因此该选项在 Linux 上不可用。
链接时,如果单个目标文件是使用 -xaddr32=yes 编译的,则假定整个输出文件是使用 -xaddr32=yes 编译的。
限定为 32 位地址空间的共享对象必须由在受限的 32 位模式地址空间内执行的进程装入。
有关更多信息,请参阅《链接程序和库指南》中介绍的 SF1_SUNW_ADDR32 软件功能定义。
编译器使用 -xalias_level 选项确定为了使用基于类型的别名分析执行优化可以进行何种假设。此选项使指定的别名级别对正在编译的转换单元生效。
如果不指定 -xalias_level 命令,编译器将假定 -xalias_level=any。如果指定不带值的 -xalias_level,则缺省值为 -xalias_level=layout。
-xalias_level 选项要求的优化级别为 -xO3 或更高。如果优化级别设置较低,则发出警告并忽略 -xalias_level 选项。
切记,如果使用 -xalias_level 选项,但无法坚持为任何别名级别描述的关于别名的所有假定和约束,则程序的行为未定义。
将 l 替换为下表中的某一术语。
表 B–12 别名歧义消除级别
(Solaris) 指示编译器创建以后可由诸如 binopt(1) 之类的二进制修改工具转换的二进制文件。使用 -xannotate=no 选项可以阻止这些工具修改该二进制文件。-xannotate=yes 选项必须与 --xO1 或更高的优化级别一起使用时才有效。
此选项在 Linux 平台上不可用。
指定指令集体系结构 (instruction set architecture, ISA)。如果在进行优化时使用该选项,那么在指定体系结构上适当选择就可以提供高性能的可执行文件。如果选择不当,则会导致二进制程序在预定的目标平台上无法执行。
分别使用 -m64 或 -m32 选项来指定打算使用的内存模型 LP64(64 位)或 ILP32(32 位)。-xarch 选项不再指示内存模型,除非是为了与早期的发行版兼容,如下所示。
如果在不同的步骤中编译和链接,请确保在两个步骤中为 -xarch 指定了相同的值。有关在编译和链接时都必须指定的所有编译器选项的完整列表,请参见表 A–2。
虽然 -xarch 可单独使用,但它是 -xtarget 选项扩展的一部分,并可能会用于覆盖由特定的 -xtarget 选项设置的 -xarch 值。例如:
% cc -xtarget=ultra2 -xarch=v8plusb ... |
会覆盖 -xtarget=ultra2 设置的 -xarch=v8。
下表详细说明了使用指定的 -xarch 选项编译后由各种 SPARC 处理器执行的可执行程序的性能。此表的目的在于帮助您识别适合您的可执行程序在特定目标机器上运行的最佳 -xarch 选项。首先识别您关心的机器的范围,然后考虑维护多个二进制程序的成本与在较新的机器上获得最高性能的好处。
表 B–13 -xarch 矩阵
SPARC 机器指令集: |
||||||
---|---|---|---|---|---|---|
V8a |
V8 |
V9 (非 Sun 处理器) |
V9 (Sun 处理器) |
V9b |
||
v8a |
N |
S |
S |
S |
S |
|
-xarch 编译选项 |
v8 |
PD |
N |
S |
S |
S |
v8plus |
NE |
NE |
N |
S |
S |
|
v8plusa |
NE |
NE |
** |
N |
S |
|
v8plusb |
NE |
NE |
** |
NE |
N |
|
v9 |
NE |
NE |
N |
S |
S |
|
v9a |
NE |
NE |
** |
N |
S |
|
v9b |
NE |
NE |
NE |
N |
||
**注: 使用此指令集编译的可执行程序可能会在 V9 非 Sun 处理器芯片中在名义上执行,或者根本不执行。请咨询硬件供应商,以确保您的可执行程序可在其目标机器上运行。 |
N 反映标称性能。程序执行,并充分利用处理器的指令集。
S 反映满意性能。程序执行,但并不利用所有可用的处理器指令。
PD 反映性能降低。程序执行,但根据使用的指令可能会导致性能轻微或显著下降。当内核对处理器未实现的指令进行仿真时,出现性能下降。
NE 表示不可执行。程序因内核不对处理器未实现的指令进行仿真而不可执行。
如果要使用 v8plus 或 v8plusa 指令集编译可执行文件,请考虑改用 v9 或 v9a 进行编译。提供了 v8plus 和 v8plusa 选项,因此程序可在支持 64 位程序的 Solaris 8 软件可用之前利用一些 SPARC V9 和 UltraSPARC 功能。使用 v8plus 或 v8plusa 选项编译的程序不可移植到 SPARC V8 或更旧的机器上。您可以分别使用 v9 或 v9a 重新编译此类程序,以充分利用 SPARC V9 和 UltraSPARC 的所有功能。您可以从 Sun 代表那里获取《The V8+ Technical Specification》白皮书(文件号码 802-7447-10),该书说明了 v8plus 和 v8plusa 的限制。
SPARC 指令集体系结构 V8 和 V8a 均是二进制兼容的。
由 v8plus 和 v8plusa 编译的二进制目标文件 (.o) 可以进行链接并可一起执行,但只能在与 SPARC V8plusa 兼容的平台上运行。
由 v8plus、v8plusa 和 v8plusb 编译的二进制目标文件 (.o) 可以进行链接并可一起执行,但只能在与 SPARC V8plusb 兼容的平台上运行。
-xarch 值 v9、v9a 和 v9b 只能在 UltraSPARC 64 位 Solaris 操作系统中使用。
使用 v9 和 v9a 编译的二进制目标文件 (.o) 可以进行链接并可一起执行,但是只能在与 SPARC V9a 兼容的平台上运行。
使用 v9、v9a 和 v9b 编译的二进制目标文件 (.o) 可以进行链接并可一起执行,但是只能在与 SPARC V9b 兼容的平台上运行。
对于任何特定选择,生成的可执行文件在早期体系结构中运行时都会慢得多。此外,虽然在多数指令集体系结构中都可以使用四精度(REAL*16 和 long double)浮点指令,但编译器不在它生成的代码中使用这些指令。
下表提供了 SPARC 平台上每个 -xarch 关键字的详细信息。
表 B–14 用于 SPARC 平台的 -xarch 标志
下表列出了 x86 体系结构上的 -xarch 标志。
表 B–15 x86 上的 -xarch 标志
标志 |
含义 |
---|---|
amd64 |
等效于 -m64 -xarch=sse2(仅限 Solaris)。使用 -xarch=amd64 来获取 64 位内存模型的传统 makefile 和脚本仅需要使用 -m64。 |
amd64a |
等效于 -m64 -xarch=sse2a(仅限 Solaris)。 |
amdsse4a |
使用 AMD SSE4a 指令集。 |
generic |
使用大多数处理器通用的指令集。这是缺省设置。当使用 -m32 进行编译时,等效于 entium_pr ,当使用 -m64 进行编译时,等效于 sse2。 |
generic64 |
为了在大多数 64 位 平台上获得良好性能而进行编译。(仅限 Solaris)。 该选项等效于 -m64 -xarch=generic,用于与早期的发行版兼容。可使用 -m64 指定 64 位编译,来取代 - xarch=generic64。 |
native |
为了在此系统上获得良好性能而进行编译。编译器为运行它的当前系统处理器选择适当的设置。 |
native64 |
编译以在此系统中取得良好的性能(仅限 Solaris)。该选项等效于 -m64 -xarch=native,用于与早期的发行版兼容。 |
pentium_pro |
使指令集限于 32 位 pentium_pro 体系结构。 |
pentium_proa |
将 AMD 扩展(3DNow!、3DNow!扩展和 MMX 扩展)添加到 32 位 pentium_pro 体系结构中。 |
sse |
将 SSE 指令集添加到 pentium_pro 体系结构。 |
ssea |
将 AMD 扩展(3DNow!、3DNow!扩展和 MMX 扩展)添加到 32 位 SSE 体系结构中。 |
sse2 |
将 SSE2 指令集添加到 pentium_pro 体系结构。 |
sse2a |
将 AMD 扩展(3DNow!、3DNow!扩展和 MMX 扩展)添加到 32 位 SSE2 体系结构中。 |
sse3 |
将 SSE3 指令集添加到 SSE2 指令集中。 |
ssse3 |
使用 SSSE3 指令集补充 pentium_pro、SSE、SSE2 和 SSE3 指令集。 |
sse4_1 |
使用 SSE4.1 指令集补充 pentium_pro、SSE、SSE2、SSE3 和 SSSE3 指令集。 |
sse4_2 |
使用 SSE4.2 指令集补充 pentium_pro、SSE、SSE2、SSE3、SSSE3 和 SSE4.1 指令集。 |
针对 x86 Solaris 平台进行编译时,有一些重要问题值得注意。
传统的 Sun 样式的并行 pragma 在 x86 上不可用。而改用 OpenMP。有关将传统并行化指令转换为 OpenMP 的信息,请参见 《Sun Studio 12 Update 1:OpenMP API 用户指南》。
在 -xarch 设置为 sse、sse2、sse2a、sse3 或更高级别的情况下编译的程序只能在提供这些扩展和功能的平台上运行。
从 Solaris 9 4/04 开始的操作系统发行版在 Pentium 4 兼容的平台上支持 SSE/SSE2。早期版本的 Solaris OS 不支持 SSE/SSE2。如果正在运行的 Solaris OS 不支持 -xarch 选择的指令集,则编译器将无法为该指令集生成或链接代码。
如果在单独的步骤中编译和链接,请始终使用编译器以及相同的 -xarch 设置进行链接,以确保链接正确的启动例程。
x86 上的数值结果可能与 SPARC 上的结果不同,这是由 x86 80 位浮点寄存器造成的。为了最大限度减少这些差异,请使用 -fstore 选项或使用 -xarch=sse2 进行编译(如果硬件支持 SSE2)。
因为内部数学库(例如,sin(x))不同,所以 Solaris 和 Linux 之间的数值结果也会不同。
从 Sun Studio 11 和 Solaris 10 OS 开始,会对使用这些专用的 -xarch 硬件标志编译和生成的程序二进制文件进行验证,看其是否在适当的平台上运行。
在 Solaris 10 之前的系统中,不执行任何验证,用户负责确保使用这些标志生成的对象部署在合适的硬件上。
如果在没有相应功能或指令集扩展的平台上运行使用这些 -xarch 选项编译的程序,则可能会导致段故障或不正确的结果,并且不显示任何显式警告消息。
这一警告也扩展到使用 .il 内联汇编语言功能或使用 SSE、SSE2、SSE2a 和 SSE3 指令和扩展的 __asm() 汇编程序代码。
现在,C 编译器为其生成代码的缺省体系结构是 v8plus (UltraSPARC)。以后的发行版中将不再支持 v7。
新的缺省设置几乎可为当前使用的所有计算机都产生更高的运行时性能。但是,在缺省情况下,设计用于在 UltraSPARC 之前的计算机上进行部署的应用程序将不再在那些计算机上执行。使用 -xarch=v8 编译可以确保这些应用程序在那些计算机上执行。
如果要在 v8 系统上部署,则必须在每个编译器命令行以及任何链接时命令中显式指定选项 -xarch=v8。提供的系统库将在 v8 体系结构上运行。
如果要在 v7 系统上部署,则必须在每个编译器命令行以及任何链接时命令上显式指定选项 -xarch=v7。提供的系统库将使用 v8 指令集。对于本发行版,唯一支持 v7 的操作系统是 Solaris 8 软件。遇到 v8 指令时,Solaris 8 操作系统会在软件中解释指令。程序会运行,但性能将下降。
此选项不接受 OpenMP 并行化指令。Sun 特定的 MP pragma 已过时,并且不再受支持。有关标准的指令的迁移信息,请参见《Sun Studio 12 Update 1:OpenMP API 用户指南》。
(SPARC) 为多个处理程序打开自动并行化。执行依赖性分析(对循环进行迭代间数据依赖性分析)和循环重构。如果优化级别不是 -xO3 或更高级别,则将优化级别提高到 -xO3 并发出警告。
如果要进行自己的线程管理,请勿使用 -xautopar。
为了使执行速度更快,该选项要求使用多处理器系统。在单处理器系统中,生成的二进制文件的运行速度通常较慢。
要在多线程环境中运行已并行化的程序,必须在执行之前设置 OMP_NUM_THREADS环境变量。有关更多信息,请参见《Sun Studio 12 Update 1:OpenMP API 用户指南》。
如果使用 -xautopar 且在一个步骤中进行编译和链接,则链接会自动将微任务化库和线程安全的 C 运行时库包含进来。如果使用 -xautopar,而且在不同的步骤中进行编译和链接,则还必须使用 -xautopar 进行链接。有关在编译和链接时都必须指定的所有编译器选项的完整列表,请参见表 A–2。
(SPARC) 指示编译器为稍后进行的优化、转换和分析准备二进制文件,请参见 binopt(1)。此选项可用于生成可执行文件或共享对象。此选项必须与 -xO1 或更高的优化级别一起使用时才有效。使用此选项生成二进制文件时,文件大小会有所增加。
如果在不同的步骤中进行编译,则在编译步骤和链接步骤中都必须有 -xbinopt:
example% cc -c -xO1 -xbinopt=prepare a.c b.c example% cc -o myprog -xbinopt=prepare a.o |
如果有些源代码不可用于编译,仍可使用此选项来编译其余代码。然后,应将其用于可创建最终库的链接步骤中。在此情况下,只有用此选项编译的代码才能进行优化、转换或分析。
使用 -xbinopt=prepare 和 -g 编译会将调试信息包括在内,从而增加可执行文件的大小。缺省值为 -xbinopt=off。
如果要改进调用标准库函数的代码的优化,请使用 -xbuiltin[=(%all|%none)] 命令。很多标准库函数(例如在 math.h 和 stdio.h 中定义的函数)通常由多个程序使用。此命令使编译器可在对性能有益时替换内函数或内联系统函数。有关如何读取目标文件中的编译器注解来确定编译器实际对哪些函数进行替换的说明,请参见 er_src(1) 手册页。
但是,这些替换会使 errno 的设置变得不可靠。如果您的程序依赖于 errno 的值,请不要使用此选项。另请参见2.11 errno 的值。
如果不指定 -xbuiltin,则缺省值为 -xbuiltin=%none,该值表示不替换或内联标准库中的任何函数。如果指定 -xbuiltin,但未提供任何参数,则缺省值为 -xbuiltin%all,该值表示编译器在确定优化好处时替换内部函数或内联标准库函数。
如果使用 -fast 进行编译,则 -xbuiltin 设置为 %all。
-xbuiltin 仅内联系统头文件中定义的全局函数,从不内联用户定义的静态函数。
当指定 -xc99=none 和 -xCC 时,编译器将接受 C++ 样式注释。特别是,可使用 // 指示注释的开始。
-xc99 选项可控制编译器对根据 C99 标准(ISO/IEC 9899:1999,编程语言 - C)实现的功能的识别。
o 可以是包含以下内容的以逗号分隔的列表:
表 B–16 -xc99 标志
标志 |
含义 |
---|---|
[no]_lib |
[不] 启用同时在 1990 和 1999 C 标准中出现的例程的 1999 C 标准例程库语义。 |
all |
打开识别支持的 C99 语言功能,并启用同时在 1990 和 1999 C 标准中出现的例程的 1999 C 标准库语义。 |
none |
关闭识别支持的 C99 语言功能,并且不启用同时在 1990 和 1999 C 标准中出现的例程的 1999 C 标准库语义。 |
如果未指定 -xc99,编译器缺省采用 -xc99=all,no_lib。如果指定了 -xc99,但没有指定任何值,该选项将设置为 -xc99=all。
虽然编译器支持级别缺省为 C99 标准的语言功能,但 /usr/include 中的 Solaris 8 和 Solaris 9 操作系统提供的标准头文件不符合 1999 ISO/IEC C 标准。如果遇到错误消息,请尝试指定 -xc99=none,从而获取这些头文件的 1990 ISO/IEC C 标准行为。
出现在 1999 和 1999 C 标准中的 1990 C 标准例程库语义不可用,因此无法在 Solaris 8 和 Solaris 9 软件中启用。在 Solaris 8 或 Solaris 9 软件上直接或间接指定 -xc99=lib 时,编译器会发出错误消息。
定义可供优化器使用的缓存属性。此选项不保证使用每个特定的缓存属性。
尽管该选项可单独使用,但它是 -xtarget 选项扩展的一部分;其主要用途是覆盖 -xtarget 选项提供的值。
此发行版引入一个可选属性 [/ti],该属性用来设置可以共享缓存的线程数。如果没有为 t 指定值,则缺省值为 1。
c 必须是以下值之一:
generic
native
s1/ l1/a 1[/t1]
s1/ l1/a 1[/t1]: s2/l 2/a2[ /t2]
s1/ l1/a 1[/t1]: s2/l 2/a2[ /t2]: s3/l 3/a3[ /t3]
s/l /a/t 属性定义如下:
si |
级别为 i 的数据高速缓存的大小,以千字节为单位 |
li |
级别为 i 的数据高速缓存的行大小,以字节为单位 |
ai |
级别为 i 的数据高速缓存的关联性 |
ti |
共享级别为 i 的缓存的硬件线程数 |
下表列出了 -xcache 值。
表 B–17 -xcache 标志
标志 |
含义 |
---|---|
generic |
这是缺省值,该值指示编译器使用能达到以下效果的缓存属性:多数 x86 和 SPARC 处理器上都能获得良好性能,同时任何处理器性能都不会明显下降。 如果需要,在每个新的发行版本中都会调整最佳定时属性。 |
native |
设置在主机环境中最佳性能的参数。 |
s1/l1 /a1[/t1] |
定义 1 级高速缓存属性。 |
s1/l1 /a1[/t1] :s2/l2 /a2[/t 2] |
定义 1 级和 2 级高速缓存属性。 |
s1/l1 /a1[/t1] :s2/l2 /a2[/t 2]:s3/ l3/a3[/ t3] |
定义 1 级、2 级和 3 级缓存属性。 |
示例: -xcache=16/32/4:1024/32/1 指定以下内容:
级别 1 缓存具有以下属性: 16 千字节 32 字节行大小 4 方向关联 |
2 级缓存具有: 1024 千字节 32 字节行大小 指示映射关联 |
(SPARC) 已废弃。您不该使用此选项。当前的 Solaris 操作系统不再支持 SPARC V7 体系结构。使用此选项编译生成的代码在当前的 SPARC 平台中运行较慢。应改用 -O,并利用 -xarch、-xchip 和 -xcache 编译器缺省值。
提供此选项仅仅是为了便于从将字符类型定义为无符号的系统中迁移代码。如果不是从这样的系统中迁移,最好不要使用该选项。只有那些依赖字符类型符号的程序才需要重写,它们要改写成显式指定带符号或者无符号。
o 可以是下列值之一:
表 B–18 -xchar 标志
标志 |
含义 |
---|---|
signed |
将声明为字符的字符常量和变量视为带符号的。这会影响已编译代码的行为,而不影响库例程的行为。 |
s |
与 signed 等效。 |
unsigned |
将声明为字符的字符常量和变量视为无符号的。这会影响已编译代码的行为,而不影响库例程的行为。 |
u |
与 unsigned 等效。 |
如果未指定 -xchar,编译器将假定 -xchar=s。
如果指定了 -xchar 但未指定值,编译器将假定 -xchar=s。
-xchar 选项仅更改用 -xchar 编译的代码中类型 char 的值范围。该选项不更改任何系统例程或头文件中类型 char 的值范围。具体来讲,指定选项时不更改 limits.h 定义的 CHAR_MAX 和 CHAR_MIN 的值。因此,CHAR_MAX 和 CHAR_MIN 不再表示无格式字符中可编码的值的范围。
如果使用 -xchar,则在将字符与预定义的系统宏进行比较时要特别小心,原因是宏中的值可能带符号。任何返回错误代码而且可以用宏来访问错误代码的例程通常是这样的。错误代码一般是负值,因此在将字符与此类宏中的值进行比较时,结果始终为假。负数永远不等于无符号类型的值。
强烈建议不要使用 -xchar 为通过库导出的任何接口编译例程。Solaris ABI 将类型 char 指定为带符号,并且系统库也按此指定。还未对系统库针对将 char 指定为无符号的效果进行广泛测试。可以不使用该选项,而修改您的代码使其不依赖于类型 char 是否带符号。类型 char 的符号因不同的编译器和操作系统而不同。
以指定的字节顺序放置多字符字符常量构成的字符,以生成一个整型常量。可将 o 替换成下列值之一:
low:按由低到高的字节顺序放置多字符字符常量构成的字符。
high: 按由高到低的字节顺序放置多字符字符常量构成的字符。
default: 按编译模式B.2.67 -X[c|a| t|s]所确定的顺序放置多字符字符常量构成的字符。有关更多信息,请参见2.1.2 字符常量。
可将 o 替换成下列值之一:
表 B–19 -xcheck 标志
标志 |
含义 |
---|---|
%none |
不执行任何 -xcheck 检查。 |
%all |
执行全部 -xcheck 检查。 |
stkovf |
启用栈溢出检查。-xcheck=stkovf 将添加针对单线程程序中的主线程以及多线程程序中的从属线程栈的栈溢出运行时检查。如果检测到栈溢出,则生成 SIGSEGV。如果您的应用程序需要以不同于处理其他地址空间违规的方式处理栈溢出导致的 SIGSEGV,请参见 sigaltstack(2)。 |
no%stkovf |
关闭栈溢出检查。 |
init_local |
初始化局部变量。 |
no%init_local |
不初始化局部变量。 |
如果未指定 -xcheck,则编译器缺省使用 -xcheck=%none。如果指定了没有任何参数的 -xcheck,则编译器缺省使用 -xcheck=%all。
在命令行上 -xcheck 选项不进行累积。编译器按照上次出现的命令设置标志。
c 必须是以下值之一:generic、old、super、super2、micro、micro2、hyper、hyper2、powerup、ultra、ultra2、ultra2e、ultra2i、ultra3、ultra3cu、pentium、pentium_pro。
尽管该选项可单独使用,但它是 -xtarget 选项扩展的一部分;其主要用途是覆盖 -xtarget 选项提供的值。
此选项通过指定目标处理器来指定计时属性。其部分影响表现在以下方面:
指令的顺序,即调度
编译器使用分支的方法
语义上等价的其他指令可用时使用的指令
下表列出了用于 SPARC 平台的 -xchip 值:
表 B–20 SPARC -xchip 标志
标志 |
含义 |
---|---|
generic |
使用计时属性,以便在大多数 SPARC 体系结构上获得良好性能。 这是缺省值,该值指示编译器使用最佳计时属性以便在多数处理器上获得良好性能,而不会使任何处理器性能明显下降。 |
native |
设置在主机环境中最佳性能的参数。 |
old |
使用 SuperSPARC 以前的处理器的计时属性。 |
sparc64vi |
针对 SPARC64 VI 处理器进行优化。 |
sparc64vii |
针对 SPARC64 VII 处理器进行优化 |
super |
使用 SuperSPARC 处理器的计时属性。 |
super2 |
使用 SuperSPARC II 处理器的计时属性。 |
micro |
使用 microSPARC 处理器的计时属性。 |
micro2 |
使用 microSPARC II 处理器的计时属性。 |
hyper |
使用 hyperSPARC 处理器的计时属性。 |
hyper2 |
使用 hyperSPARC II 处理器的计时属性。 |
powerup |
使用 Weitek PowerUp 处理器的计时属性。 |
ultra |
使用 UltraSPARC 处理器的计时属性。 |
ultra2 |
使用 UltraSPARC II 处理器的计时属性。 |
ultra2e |
使用 UltraSPARC IIe 处理器的计时属性。 |
ultra2i |
使用 UltraSPARC IIi 处理器的计时属性。 |
ultra3 |
使用 UltraSPARC III 处理器的计时属性。 |
ultra3cu |
使用 UltraSPARC III Cu 处理器的计时属性。 |
ultra3i |
使用 UltraSPARC IIIi 处理器的计时属性。 |
ultra4 |
使用 UltraSPARC IV 处理器的计时属性。 |
ultra4plus |
使用 UltraSPARC IVplus 处理器的计时属性。 |
ultraT1 |
使用 UltraSPARC T1 处理器的计时属性。 |
ultraT2 |
使用 UltraSPARC T2 处理器的计时属性。 |
ultraT2plus |
使用 UltraSPARC T2+ 处理器的计时属性。 |
下表列出了用于 x86 平台的 -xchip 值:
表 B–21 x86 -xchip 标志
标志 |
含义 |
---|---|
generic |
使用计时属性,以便在大多数 x86 体系结构上获得良好性能。 这是缺省值,该值指示编译器使用最佳计时属性以便在多数处理器上获得良好性能,而不会使任何处理器性能明显下降。 |
native |
设置在主机环境中最佳性能的参数。 |
core2 |
针对 Intel Core2 处理器进行优化。 |
nehalem |
针对 Intel Nehalem 处理器进行优化。 |
opteron |
针对 AMD Opteron 处理器进行优化。 |
penryn |
针对 Intel Penryn 处理器进行优化。 |
pentium |
使用 x86 pentium 体系结构的计时属性。 |
pentium_pro |
使用 x86 pentium_pro 体系结构的计时属性。 |
pentium3 |
使用 x86 Pentium 3 体系结构的计时属性。 |
pentium4 |
使用 x86 Pentium 4 体系结构的计时属性。 |
amdfam10 |
针对 AMD AMDFAM10 处理器进行优化。 |
强烈建议您通过指定 -xcode=pic13 或 -xcode=pic32 来生成共享对象。可以使用 -xarch=v9 -xcode=abs64 和 -xarch=v8 -xcode=abs32 生成可用的共享对象,但这样做效率很低。用 -xarch=v9、-xcode=abs32 或 -xarch=v9、-xcode=abs44 生成的共享对象无法工作。
v 必须是以下项之一:
表 B–22 -xcode 标志
值 |
含义 |
abs32 |
这是 32 位体系结构的缺省值。生成 32 位绝对地址。代码 + 数据 + bss 的大小被限制为 2**32 字节。 |
abs44 |
这是 64 位体系结构的缺省值。生成 44 位绝对地址。代码+数据+bss 的大小不应超过 2**44 字节。只适用于 64 位体系结构。 |
abs64 |
生成 64 位绝对地址。只适用于 64 位架构。 |
pic13 |
生成共享库(小模型)中使用的与位置无关的代码。与 -Kpic 等效。允许在 32 位体系结构中最多引用 2**11 个唯一的外部符号,而在 64 位体系结构中可以最多引用 2**10 个。 |
pic32 |
生成共享库(大模型)中使用的与位置无关的代码。与 -KPIC 等效。允许在 32 位体系结构中最多引用 2**30 个唯一的外部符号,而在 64 位体系结构中可以最多引用 2**29 个。 |
对于 32 位体系结构,缺省值是 -xcode=abs32。64 位体系结构的缺省值是 -xcode=abs44。
生成共享动态库时,缺省 -xcode 值 abs44 和 abs32 将与 64 位体系结构一起使用。但指定 -xcode=pic13 或 -xcode=pic32。在 SPARC 上使用 -xcode=pic13 和 -xcode=pic32 时,存在两项名义性能成本。
用 -xcode=pic13 或 -xcode=pic32 编译的例程会在入口点执行一些附加指令,以便将寄存器设置为指向用于访问共享库的全局或静态变量的表 (_GLOBAL_OFFSET_TABLE_)。
对全局或静态变量的每次访问都会涉及通过 _GLOBAL_OFFSET_TABLE_ 的额外间接内存引用。如果编译包括 -xcode=pic32,则每个全局和静态内存引用中都会有两个附加指令。
在考虑上述成本时,请记住:由于受到库代码共享的影响,使用 -xcode=pic13 和 -xcode=pic32 会大大减少系统内存需求。共享库中使用 -xcode=pic13 或 – xcode=pic32 编译的每页代码都可以供使用该库的每个进程共享。如果共享库中的代码页包含非 pic(即绝对)内存引用,即使仅包含单个非 pic 内存引用,该页也将变为不可共享,而且每次执行使用该库的程序时都必须创建该页的副本。
确定是否已经使用 -xcode=pic13 或 -xcode=pic32 编译 .o 文件的最简单方法是使用 nm 命令:
% nm file.o | grep _GLOBAL_OFFSET_TABLE_ U _GLOBAL_OFFSET_TABLE_ |
包含与位置无关的代码的 .o 文件将包含对 _GLOBAL_OFFSET_TABLE_ 无法解析的外部引用(用字母 U 标记)。
要确定使用 -xcode=pic13 还是 -xcode=pic32,请使用 elfdump -c(有关更多信息,请参见 elfdump(1) 手册页)检查全局偏移表 (Global Offset Table, GOT) 的大小并查找节标题 sh_name: .got。sh_size 值是 GOT 的大小。如果 GOT 小于 8,192 字节,请指定 -xcode=pic13,否则指定 -xcode=pic32。
通常,应根据以下准则来确定如何使用 -xcode:
如果是生成可执行文件,则不应该使用 – xcode=pic13 或 -xcode=pic32。
如果是生成仅用于链接到可执行文件的归档库,则不应该使用 -xcode=pic13 或 -xcode=pic32。
如果要生成共享库,请先使用 -xcode=pic13,一旦 GOT 大小超过 8,192 字节,再使用 -xcode=pic32。
如果要生成用于链接到共享库的归档库,则应该使用 -xcode=pic32。
已废弃,不使用。改用 -xipo。-xcrossfile 是 -xipo=1 的别名。
允许 C 编译器接受在不符合 ISO C 源字符代码要求的语言环境中编写的源代码。这些语言环境包括: ja_JP.PCK。
处理此类语言环境所需的编译器转换阶段可能导致编译时间明显延长。仅当编译的源文件包含此类语言环境中某个语言环境的源代码字符时,才应该使用此选项。
除非指定 -xcsi,否则编译器不识别在不符合 ISO C 源字符代码要求的语言环境中编写的源代码。
如果您维护的软件可读取 dwarf 格式的调试信息,请指定 -xdebugformat=dwarf。使用此选项,编译器会生成使用 dwarf 标准格式的调试信息,这是缺省设置。
表 B–23 -xdebugformat 标志
值 |
含义 |
---|---|
stabs |
-xdebugformat=stabs 生成使用 stabs 标准格式的调试信息。 |
dwarf |
-xdebugformat=dwarf 使用 dwarf 标准格式(缺省设置)生成调试信息。 |
如果未指定 -xdebugformat,编译器将假定 -xdebugformat=dwarf。此选项需要一个参数。
此选项影响使用 -g 选项记录的数据的格式。即使在没有使用 -g 的情况下记录少量调试信息,此选项仍可控制其信息格式。因此,即使不使用 -g,-xdebugformat 仍有影响。
dbx 和性能分析器软件可识别 stabs 和 dwarf 格式,因此使用此选项对任何工具的功能都没有影响。
有关更多信息,另请参见 dumpstabs(1) 和 dwarfdump(1) 手册页。
分析循环以了解迭代之间的数据依赖性,并执行循环重构,包括循环交换、循环合并、标量替换以及消除“死数组”赋值。
在 SPARC 上,对于 -xO3 及以上的所有优化级别,-xdepend 的缺省设置均为 -xdepend=on。否则,-xdepend 的缺省设置为 -xdepend=off。指定 -xdepend 的显式设置会覆盖任何缺省设置。
在 x86 上,-xdepend 的缺省设置为 -xdepend=off。如果指定了 -xdepend,而优化级别不为 -xO3 或更高级别,则编译器会将优化级别提高至 -xO3 并发出警告。
指定不带参数的 -xdepend 等效于 -xdepend=yes。
-xautopar 中包含依赖性分析。依赖性分析在编译时完成。
依赖性分析在单处理器系统中可能很有用。但是,如果您在单处理器系统上使用 -xdepend,则不应同时指定 -xautopar,否则会针对多处理器系统执行 -xdepend 优化。
另请参见:-xprefetch_auto_type
对源文件仅执行语法和语义检查,但不生成任何目标或可执行代码。
(SPARC) 已废弃,请不要使用。应改用 -xopenmp。
-xexplicitpar 不接受 OpenMP 并行化指令。但是,Sun 特定的 MP pragma 已被废弃,不再受支持。编译器改为支持 OpenMP 3.0 规范指定的 API。有关标准的指令的迁移信息,请参见《Sun Studio 12 Update 1:OpenMP API 用户指南》。
该选项指示编译器将函数和/或数据变量放置到单独的分段中,这使链接程序(使用链接程序的 -M 选项指定的映射文件中的指示)将这些段重新排序以优化程序性能。通常,该优化仅在缺页时间构成程序运行时间的一大部分时才有效。
对变量重新排序有助于解决对运行时性能产生负面影响的以下问题:
在内存中存放位置很近的无关变量会造成缓存和页的争用。
在内存中存放位置很远的相关变量会造成不必要的过大工作集。
未用到的弱变量副本会造成不必要的过大工作集,从而降低有效数据密度。
为优化性能而对变量和函数进行重新排序时,需要执行以下操作:
使用 -xF 进行编译和链接。
按照《程序性能分析工具》手册中关于如何生成函数的映射文件(或“链接程序和库向导”中关于如何生成数据的映射文件)的说明进行操作。
使用通过链接程序的 -M 选项生成的新映射文件重新链接。
在分析器下重新执行以验证是否增强。
v 可以是下列其中一个或多个值:
表 B–24 -xF 值
值 |
含义 |
---|---|
[no%]func |
[不] 将函数分段到单独的段中。 |
[no%]gbldata |
[不] 将全局数据(具有外部链接的变量)分段到单独的段中。 |
[no%]lcldata |
[不] 将局部数据(具有内部链接的变量)分段到单独的段中。 |
%all |
分段函数、全局数据和局部数据。 |
%none |
不分段。 |
如果未指定 -xF,则缺省值为 -xF=%none。如果指定了没有任何参数的 -xF,则缺省值为 -xF=%none,func。
使用 -xF=lcldata 会限制某些地址计算优化,因此,只应在必要时才使用该标志。
请参见 analyzer(1)、debugger(1) 和 ld(1) 手册页。
f 必须为 flags 或 readme。
-xhelp=flags 显示编译器选项汇总信息。
-xhelp=readme 显示 README 文件。
如果启用了 -xhwcprof,编译器将生成信息,这些信息可帮助工具将文件配置的加载和存储指令与其所引用的数据类型和结构成员相关联(与由 -g 生成的符号信息一起)。它将配置文件数据同目标文件的数据空间(而不是指令空间)相关联,并对行为进行洞察,而这仅从指令配置中是无法轻易获得的。
可使用 -xhwcprof 编译一组指定的目标文件。但是,-xhwcprof 在应用于应用程序中的所有目标文件时,作用最大。它能全面识别并关联分布在应用程序目标文件中的所有内存引用。
如果分别在单独的步骤中进行编译和链接,最好在链接时使用 -xhwcprof。如果将来扩展为 -xhwcprof,则在链接时可能需要使用它。有关在编译和链接时都必须指定的所有编译器选项的完整列表,请参见表 A–2。
-xhwcprof=enable 或 -xhwcprof=disable 的实例将会覆盖同一命令行中 -xhwcprof 的所有以前的实例。
在缺省情况下,禁用 -xhwcprof。指定不带任何参数的 -xhwcprof 与 -xhwcprof=enable 等效。
-xhwcprof 要求启用优化并将调试数据的格式设置为 DWARF (-xdebugformat=dwarf)。
-xhwcprof 和 -g 的组合会增加编译器临时文件的存储需求,而且比单独指定 -xhwcprof 和 -g 所引起的增加总量还多。
下列命令可编译 example.c,并可为硬件计数器文件配置以及针对使用 DWARF 符号的数据类型和结构成员的符号分析指定支持:
example% cc -c -O -xhwcprof -g -xdebugformat=dwarf example.c |
有关基于硬件计数器的文件配置的更多信息,请参见《程序性能分析工具》手册。
用于 -xinline 的 list 的格式如下所示:[{%auto,func_name ,no%func_name}[,{%auto ,func_name,no%func_name }]...]
-xinline 尝试只内联可选列表中指定的函数。该列表可为空,或者由逗号分隔的 func_name、no%func_name 或 %auto 列表组成,其中 func_name 是函数名称。仅在 -xO3 或更高级别上,-xinline 才起作用。
表 B–25 -xinline 标志
标志 |
含义 |
---|---|
%auto |
指定编译器将尝试自动内联源文件中的所有函数。仅在 -xO4 或更高优化级别上,%auto 才起作用。在 -xO3 或更低优化级别上,%auto 被忽略而无提示。 |
func_name |
指定编译器内联已命名的函数。 |
no%func_name |
指定编译器不内联已命名的函数。 |
该列表值从左至右进行累积。因此对于 -xinline=%auto,no%foo 的规范,编译器试图内联除 foo 之外的所有函数。对于 -xinline=%bar,%myfunc,no%bar 的规范,编译器仅尝试内联 myfunc。
在优化级别为 -xO4 或更高级别上编译时,编译器通常尝试内联源文件中定义的对函数的所有引用。通过指定 -xinline 选项,您可以限定编译器试图内联的函数集。如果只指定 -xinline=,即不指定任何函数或 %auto,这表示不内联源文件中的任何例程。如果您指定了一系列 func_name 和 no%func_name,而未指定 %auto,则编译器只试图内联列表中指定的函数。如果在优化级别设置为 -xO4 或更高级别时用 -xinline 选项在值列表中指定 %auto,编译器将试图内联所有未被 no%func_name 显式排除的函数。
如果以下任何条件适用,则不内联函数。且不发出任何警告。
优化级别低于 -xO3。
无法找到例程。
优化器无法内联例程。
正编译的文件中不存在该例程的源代码(请参见 -xcrossfile)。
如果在命令行指定多个 -xinline 选项,它们将不会累积。命令行上的最后一个 -xinline 指定编译器试图内联的函数。
另请参见 -xldscope。
指定此选项编译您的程序并为其提供程序设备,以供线程分析器进行分析。有关线程分析器的更多详细信息,请参见 tha(1)。
然后可使用性能分析器以 collect -r races 来运行此检测的程序,从而创建数据竞争检测实验。可以单独运行已提供了程序设备的代码,但其运行速度将非常缓慢。
可指定 -xinstrument=no%datarace 来关闭线程分析器的源代码准备。这是缺省值。
指定 -xinstrument 而不带参数是非法操作。
如果在不同的步骤中进行编译和链接,则在编译和链接步骤都必须指定 -xinstrument=datarace。
此选项定义了预处理程序令牌 __THA_NOTIFY。可指定 #ifdef __THA_NOTIFY 来保护对 libtha(3) 例程的调用。
该选项也设置 -g。
用 0、1 或 2 替换 a。没有任何参数的 -xipo 等效于 -xipo=1。-xipo=0 是缺省设置,表示关闭 -xipo。在 -xipo=1 时,编译器会跨所有源文件执行内联。
在 -xipo=2 时,编译器执行过程间调用别名分析同时优化内存分配和布局,以提高缓存的性能。
编译器可通过调用过程间分析组件执行部分程序优化。它在链接步骤中跨所有目标文件执行优化,并且不限于编译命令的源文件。但是,使用 -xipo 执行的整个程序优化不包括汇编 (.s) 源文件。
编译时和链接时都必须指定 -xipo。有关在编译和链接时都必须指定的所有编译器选项的完整列表,请参见表 A–2。
由于执行跨文件优化时需要附加信息,因此 -xipo 选项会生成更大的目标文件。不过,该附加信息不会成为最终的二进制可执行文件的一部分。可执行程序大小的增加都是由于执行的附加优化导致的。在编译步骤中创建的目标文件具有在这些文件内编译的附加分析信息,这样就可以在链接步骤中执行跨文件优化。
在编译和链接大型多文件应用程序时,-xipo 特别有用。用该标志编译的对象目标文件具有在这些文件内编译的分析信息,这些信息实现了在源码和预编译的程序文件中的过程间分析。
但分析和优化只限于使用 -xipo 编译的目标文件,并不扩展到目标文件或库。
-xipo 是多阶段的,因此如果要在单独的步骤中进行编译和链接,需要为每一步指定 -xipo。
关于 -xipo 的其他重要信息:
它要求优化级别最低为 -xO4。
编译时未使用 -xipo 的对象可以自由地与使用 -xipo 编译的对象链接。
在此例中,编译和链接在单独的步骤中进行:
cc -xipo -xO4 -o prog part1.c part2.c part3.c |
优化器在三个源文件之间执行交叉文件内联。这是在最终链接步骤中完成的,因此源文件的编译不必全部在单个编译中进行,可以通过多个单独的编译来进行,且每个编译都要指定 -xipo。
在此例中,编译和链接在单独的步骤中进行:
cc -xipo -xO4 -c part1.c part2.c cc -xipo -xO4 -c part3.c cc -xipo -xO4 -o prog part1.o part2.o part3.o |
即使用 -xipo 编译,仍存在库不参与交叉文件过程间分析的约束,如下例所示:
cc -xipo -xO4 one.c two.c three.c ar -r mylib.a one.o two.o three.o ... cc -xipo -xO4 -o myprog main.c four.c mylib.a |
在此例中,过程间调用优化是在以下例程之间执行的:one.c、two.c 和 three.c 之间,main.c 和 four.c 之间,但不在 main.c 或 four.c 和 mylib.a 上的例程之间执行。(第一次编译可能产生未定义符号警告,但是由于它是编译与链接步骤,所以会执行过程间调用优化。)
在链接步骤中使用目标文件集合时,编译器试图执行整个程序分析和优化。对于该目标文件集合中定义的任何函数或子例程 foo(),编译器做出以下两个假定:
foo() 无法在运行时被在该目标文件集合之外定义的其他例程显式调用。
来自该目标文件集合中的任何例程的 foo() 调用将不受在该目标文件集合以外定义的不同版本的 foo() 的干预。
如果假定 2 不成立,请不要使用 -xipo=1 也不要使用 -xipo=2 进行编译。
例如,如果对函数 malloc() 创建了您自己的版本,并使用 -xipo=2 进行编译。这样,对于任何库中引用 malloc() 且与您的代码链接的所有函数,都必须使用 -xipo=2 进行编译,并且需要在链接步骤中对其目标文件进行操作。由于这对于系统库不大可能,因此不要使用 -xipo=2 编译您的 malloc 版本。
另举一例,如果生成了一个共享库,有两个外部调用(foo() 和 bar())分别在两个不同的源文件中。并假设 bar() 调用 foo()。如果可能会在运行时插入 foo(),则不要使用 -xipo=1 或 -xipo=2 编译 foo() 和 bar() 的源文件。否则,foo() 会内联到 bar() 中,从而导致出现错误的结果。
-xipo_archive 选项使编译器可在生成可执行文件之前,用通过 -xipo 编译且驻留在归档库 (.a) 中的目标文件来优化传递给链接程序的目标文件。库中包含的在编译期间优化的任何目标文件都会替换为其优化后的版本。
a 是以下项之一:
表 B–26 -xipo_archive 标志
值 |
含义 |
---|---|
writeback |
生成可执行文件之前,编译器使用通过 -xipo 编译的目标文件(驻留在归档库 (.a) 中)来优化传递到链接程序的目标文件。库中包含的在编译期间优化的任何目标文件都会替换为优化后的版本。 对于使用归档库通用集的并行链接,每个链接都应创建自己的归档库备份,从而在链接前进行优化。 |
readonly |
生成可执行文件之前,编译器使用通过 -xipo 编译的目标文件(驻留在归档库 (.a) 中)来优化传递到链接程序的目标文件。 通过 -xipo_archive=readonly 选项,可在链接时指定的归档库中进行对象文件的跨模块内联和程序间数据流分析。但是,它不启用对归档库代码的跨模块优化,除非代码已经通过跨模块内联插入到其他模块中。 要对归档库内的代码应用跨模块优化,要求 -xipo_archive=writeback。注意,这样做将修改从中提取代码的归档库的内容。 |
none |
这是缺省值。没有对归档文件的处理。编译器不对使用 -xipo 编译和在链接时从归档库中提取的对象文件应用跨模块内联或其他跨模块优化。要执行此操作,链接时必须指定 -xipo,以及 -xipo_archive=readonly 或 -xipo_archive=writeback 中的任一个。 |
如果不为 -xipo_archive 指定设置,编译器会将其设置为 -xipo_archive=none。
指定不带标志的 -xipo_archive 是非法的。
指定 -xjobs 选项,以设置编译器为完成工作需要创建的进程数。在多 CPU 计算机上,该选项可以缩短生成时间。目前,-xjobs 只能与 -xipo 选项一起使用。如果指定 -xjobs=n,过程间优化器就将 n 作为其在编译不同文件时可调用的最大代码生成器实例数。
通常,n 的安全值等于 1.5 乘以可用处理器数。如果使用的值是可用处理器数的数倍,则会降低性能,因为有在产生的作业间进行的上下文切换开销。此外,如果使用很大的数值会耗尽系统资源(如交换空间)。
指定 -xjobs 时务必要指定值。否则会发出错误诊断并使编译终止。
出现最合适的实例之前,-xjobs 的多重实例在命令行上会互相覆盖。
以下示例在有两个处理器的系统上进行的编译,速度比使用相同命令但没有 -xjobs 选项时进行的编译快。
example% cc -xipo -xO4 -xjobs=3 t1.c t2.c t3.c |
指定不带标志的 -xipo_archive 是非法的。
指定 -xldscope 选项,以更改用于外部符号定义的缺省链接程序作用域。由于实现更隐蔽,因此更改缺省值可使共享库更快、更安全。
v 必须是下列值之一:
表 B–27 -xldscope 标志
标志 |
含义 |
---|---|
global |
全局链接程序作用域是限制最少的链接程序作用域。该符号的所有引用都绑定到在第一个动态模块中定义该符号的定义上。该链接程序作用域是外部符号的当前链接程序作用域。 |
symbolic |
符号链接程序作用域比全局链接程序作用域具有更多的限制。从所链接的动态模块内部对符号的所有引用都绑定到在模块内部定义的符号上。在模块外部,符号也显示为全局符号。该链接程序作用域对应于链接程序选项 -Bsymbolic。有关链接程序的更多信息,请参见 ld(1)。 |
hidden |
隐藏链接程序作用域具有比符号和全局链接程序作用域更高的限制。动态模块内部的所有引用都绑定到该模块内部的一个定义上。符号在模块外部是不可视的。 |
如果未指定 -xldscope,编译器将假定 -xldscope=global。如果指定不带参数的 -xldscope,编译器会发出错误信息。在到达最右边的实例之前,命令行上此选项的多个实例相互覆盖。
如果要使客户端覆盖库中的函数,就必须确保该库生成期间未以内联方式生成该函数。编译程序在以下情况下将内联函数:用 -xinline 指定函数的名称、在可以自动内联的 -xO4 或更高级别进行编译、使用内联说明符、使用内联 pragma 或者使用交叉文件优化。
例如,假定库 ABC 具有缺省的分配器函数,该函数可用于库的客户端,也可在库的内部使用:
void* ABC_allocator(size_t size) { return malloc(size); }
如果在 -xO4 或更高级别生成库,则编译器将内联库组件中出现的对 ABC_allocator 的调用。如果库的客户端要用定制的版本替换 ABC_allocator,则在调用 ABC_allocator 的库组件中不能进行该替换。最终程序将包括函数的不同版本。
生成库时,用 __hidden 或 __symbolic 说明符声明的库函数可以内联生成。假定这些库函数不被客户端覆盖。请参见2.2 链接程序作用域说明符。
用 __global 说明符声明的库函数不应内联声明,并且应该使用 -xinline 编译器选项来防止内联。
另请参见 -xinline、-xO、-xcrossfile、#pragma、inline。
强制为异常类中的数学例程返回 IEEE 754 样式的值。在此情况下,不输出异常消息,并且不应依赖 errno。
内联一些库例程,以加快执行速度。此选项可为浮点选项和系统平台选择合适的汇编语言内联模板。
无论将函数的任何规范作为 -xlibmil 标记的一部分,-xlibmil 都会内联函数。
但是,这些替换会导致 errno 的设置变得不可靠。如果您的程序依赖于 errno 的值,请尽量不要使用此选项。另请参见2.11 errno 的值。
使编译器可以使用优化数学例程的库。使用此选项时,必须通过指定 -fround=nearest 来使用缺省舍入模式。
数学例程库优化了性能,并且通常会生成运行速度更快的代码。结果可能与普通数学库产生的结果略有不同。如果有差别,通常是最后一位不同。
但是,这些替换会使 errno 的设置变得不可靠。如果您的程序依赖于 errno 的值,请不要使用此选项。另请参见2.11 errno 的值。
该库选项在命令行上的顺序并不重要。
此选项由 -fast 选项设置。
Sun 提供的性能库中的链接。
编译器忽略此选项且不显示任何提示。
(SPARC) 指示编译器对可重定位的目标文件执行链接时优化。这些优化在链接时通过分析二进制目标代码来执行。虽然未重写目标文件,但生成的可执行代码可能与初始目标代码不同。
必须至少在部分编译命令中使用 -xlinkopt,才能使 -xlinkopt 在链接时有效。优化器仍可以对未使用 -xlinkopt 进行编译的二进制目标文件执行部分受限的优化。
-xlinkopt 优化出现在编译器命令行上的静态库代码,但会跳过出现在命令行上的共享(动态)库代码而不对其进行优化。还可以在生成共享库(用 -G 编译)时使用 -xlinkopt。
级别设置执行的优化级别,必须为 0、1 或 2。优化级别为:
表 B–28 -xlinkopt 标志
标志 |
含义 |
---|---|
0 |
禁用后优化器。(这是缺省情况。) |
1 |
在链接时根据控制流分析执行优化,包括指令高速缓存着色和分支优化。 |
2 |
在链接时执行附加的数据流分析,包括无用代码删除和地址计算简化。 |
如果在不同的步骤中编译,-xbinopt 必须同时出现在编译和链接步骤中:
example% cc -c -xlinkopt a.c b.c example% cc -o myprog -xlinkopt=2 a.o
有关在编译和链接时都必须指定的所有编译器选项的完整列表,请参见表 A–2。
注意,仅当链接编译器时才使用级别参数。在以上示例中,即使二进制目标代码是用隐含级别 1 编译的,使用的后优化级别仍然是 2。
指定 -xlinkopt 时若不带级别参数,则表示 -xlinkopt=1。
当编译整个程序并且使用配置文件反馈时,该选项才最有效。文件配置会显示代码中最常用和最少用的部分并相应地指导优化器集中其努力方向。这对大型应用程序尤为重要,因为在链接时执行代码优化放置可降低指令高速缓存未命中数。通常,编译如下所示:
example% cc -o progt -xO5 -xprofile=collect:prog file.c example% progt example% cc -o prog -xO5 -xprofile=use:prog -xlinkopt file.c |
有关使用配置文件反馈的详细信息,请参见B.2.138 -xprofile=p。
使用 -xlinkopt 编译时,请不要使用 -zcombreloc 链接程序选项。
注意,使用该选项编译会略微延长链接的时间,目标文件的大小也会增加,但可执行文件的大小保持不变。使用 -xlinkopt 和 -g 编译会将调试信息包括在内,从而增加了可执行文件的大小。
显示哪些循环已并行化以及哪些循环未并行化。简要说明循环未并行化的原因。仅当指定了 -xautopar、-xparallel 或 -xexplicitpar 时,-xloopinfo 选项才有效,否则,编译器将发出警告。
要达到更快的执行速度,则该选项需要多处理器系统。在单处理器系统中,生成的代码通常运行得较慢。
只对指定的 C 程序运行预处理程序,请求它生成 makefile 依赖性并将结果发送至标准输出(有关 make 文件和依赖性的详细信息,请参见 make(1))。
例如:
#include <unistd.h> void main(void) {} |
生成的输出如下:
e.o: e.c e.o: /usr/include/unistd.h e.o: /usr/include/sys/types.h e.o: /usr/include/sys/machtypes.h e.o: /usr/include/sys/select.h e.o: /usr/include/sys/time.h e.o: /usr/include/sys/types.h e.o: /usr/include/sys/time.h e.o: /usr/include/sys/unistd.h |
如果您指定 -xM 和 -xMF,则编译器会将所有 makefile 依赖性信息追加到使用 -xMF 指定的文件中。
生成 makefile 依赖性类似 -xM,但不包括 /usr/include 文件。例如:
more hello.c #include<stdio.h> main() { (void)printf(“hello\n”); } cc– xM hello.c hello.o: hello.c hello.o: /usr/include/stdio.h |
使用 -xM1 编译不会报告头文件的依赖性:
cc– xM1 hello.c hello.o: hello.c |
-xM1 在 -Xs 模式下不可用。
如果您指定 -xM 和 -xMF,则编译器会将所有 makefile 依赖性信息附加至使用 -xMF 指定的文件中。
像 -xM 一样生成 makefile 依赖性,但包括编译。-xMD 基于输入文件名为 makefile 依赖性信息生成一个输出文件,但增加 .d 后缀。如果您指定 -xMD 和 -xMF,则预处理程序会将所有 makefile 依赖性信息附加至使用 -xMF 指定的文件中。
使用此选项可为 makefile 依赖性输出指定一个文件。目前,没有方法可以在一个命令行上使用 -xMF 为多个输入文件指定单独的文件名。
使用此选项可生成不包括系统头文件的 makefile 依赖性。此选项与 -xM1 的功能相同,只是它还包括编译功能。-xMMD 基于输入文件名为 makefile 依赖性信息生成一个输出文件,但增加 .d 后缀。如果您指定 -xMF,则编译器将改用您提供的文件名。
将数据段合并为文本段。在此编译所生成的目标文件中初始化的数据是只读数据,并可(除非用 ld-N 链接)在进程间共享。
三个选项 -xMerge -ztext -xprofile=collect 不应同时使用。-xMerge 会强制将静态初始化的数据存储到只读存储器中,-ztext 禁止在只读存储器中进行依赖于位置的符号重定位,而 -xprofile=collect 会在可写存储器中生成静态初始化的、依赖于位置的符号重定位。
此命令可将 pragma opt 的级别限制为指定级别。v 是 off、1、2、3、4、5 中的一个值。缺省值为 -xmaxopt=off ,表示忽略 pragma opt。如果指定 -xmaxopt 但未提供参数,相当于指定 - xmaxopt=5。
如果同时指定了 -xO 和 -xmaxopt,则使用 -xO 设置的优化级别不能超过 -xmaxopt 值。
(SPARC) 使用 -xmemalign 选项控制编译器对数据对齐所做的假定。通过控制可能会出现非对齐内存访问的代码和出现非对齐内存访问时的处理程序,可以更轻松的将程序移植到 SPARC。
指定最大假定内存对齐和未对齐数据访问行为。必须有一个同时用于 a(对齐)和 b(行为)的值。a 指定最大假定内存对齐,b 指定未对齐内存访问行为。下表列出了 -xmemalign 的对齐值和行为值。
表 B–29 -xmemalign 对齐和行为标志
a |
b | ||
---|---|---|---|
1 |
假定最多 1 字节对齐。 |
i |
解释访问并继续执行。 |
2 |
假定最多 2 字节对齐。 |
s |
产生信号 SIGBUS。 |
4 |
假定最多 4 字节对齐。 |
f |
仅限于 -xarch=v9 变体: 为小于或等于 4 的对齐产生信号 SIGBUS,否则解释访问并继续执行。对于其他所有 -xarch 值,f 标志与 i 等效。 |
8 |
假定最多 8 字节对齐。 | ||
16 |
假定最多 16 字节对齐。 |
如果要链接到某个已编译的目标文件,并且编译该目标文件时 b 的值设置为 i 或 f,就必须指定 -xmemalign。有关在编译和链接时都必须指定的所有编译器选项的完整列表,请参见表 A–2。
对于可在编译时确定对齐的内存访问,编译器会为该数据对齐生成适当的装入/存储指令序列。
对于不能在编译时确定对齐的内存访问,编译器必须假定一个对齐以生成所需的装入/存储序列。
-xmemalign 选项允许您在这些未确定情况下指定编译器要假定的数据最大内存对齐。它还指定在运行时发生未对齐内存访问时要执行的错误行为。
如果运行时的实际数据对齐小于指定的对齐,则未对齐的访问尝试(内存读取或写入)生成一个陷阱。对陷阱的两种可能响应是
操作系统将陷阱转换为 SIGBUS 信号。如果程序无法捕捉到信号,则程序终止。即使程序捕捉到信号,未对齐的访问尝试仍将无法成功。
操作系统通过翻译未对齐的访问并将控制返回给程序(仿佛访问已成功正常结束)来处理陷阱。
以下缺省值仅适用于未使用 -xmemalign 选项时:
-xmemalgin=8i(适于所有 v8 体系结构)。
-xmemalign=8s(适于所有 v9 体系结构)。
在出现 -xmemalign 选项但未给定任何值时,缺省值为:
-xmemalign=1i(对于所有 -xarch 值)。
下表说明了如何使用 -xmemalign 来处理不同的对齐情况。
表 B–30 -xmemalign 示例
命令 |
情况 |
---|---|
-xmemalign=1s |
大量未对齐访问导致了自陷处理非常缓慢。 |
-xmemalign=8i |
在发生错误的代码中存在偶然的、有目的的、未对齐访问。 |
-xmemalign=8s |
程序中应该没有任何未对齐访问。 |
-xmemalign=2s |
要检查可能存在的奇字节访问。 |
-xmemalign=2i |
要检查可能存在的奇字节访问并要使程序工作。 |
(x86) -xmodel 选项使编译器可针对 Solaris x86 平台修改 64 位对象的格式,只能为此类对象的编译指定此选项。
仅当启用了 64 位的 x64 处理器上还指定了 -m64 时,该选项才有效。
a 必须是以下值之一:
表 B–31 -xmodel 标志
值 |
含义 |
---|---|
small |
此选项可为小模型生成代码,其中执行代码的虚拟地址在链接时已知,并且已知在 0 到 2^31 - 2^24 - 1 的虚拟地址范围内可以找到所有符号。 |
kernel |
按内核模型生成代码,在该模型中, 所有符号都定义在 2^64 - 2^31 到 2^64 - 2^24 范围内。 |
medium |
按中等模型生成代码,在该模型中, 不对数据段的符号引用范围进行假定。文本段的大小和地址的限制与小型代码模型的限制相同。使用 -m64 编译时,具有大量静态数据的应用程序可能会要求 -xmodel=medium。 |
此选项不累积,因此编译器根据命令行最右侧的 -xmodel 实例设置模型值。
如果未指定 -xmodel,编译器将假定 -xmodel=small。如果指定没有参数的 -xmodel,将出现错误。
不必使用此选项编译所有转换单元。只有可以确保访问的对象在可访问范围之内,才可编译选择的文件。
您应了解,不是所有的 Linux 系统都支持中等模型。
缺省情况下不链接任何库;即不向 ld(1) 传递任何 -l 选项。通常,cc 驱动程序将 -lc 传递给 ld。
在您使用 -xnolib 时,必须自己传递所有 -l 选项。
% cc– fast– xnolibmil.... |
通过关闭以前指定的所有 -xlibmopt 选项,禁止编译器使用优化的数学库。在 -fast 之后使用此选项(-fast 可以通过设置 -xlibmopt 允许使用优化数学库):
% cc -fast -xnolibmopt ... |
不将共享库的运行时搜索路径生成到可执行文件中。
通常 cc 不向链接程序传递任何 -R 路径。有一些选项会向链接程序传递 -R 路径,如 -xliclib=sunperf 和 -xopenmp。可使用 - xnorunpath 选项来加以阻止。
建议用该选项生成提交到客户(这些客户的程序使用的共享库具有不同路径)的可执行文件。
优化目标代码;注意大写字母 O 后跟数字 1、2、3、4 或 5。一般说来,优化级别越高,运行时性能越好。不过,较高的优化级别会延长编译时间并生成较大的可执行文件。
在少数情况下,-xO2 级别的性能可能比其他优化级别好,而 -xO3 也可能胜过 -xO4。尝试用每个级别进行编译,以查看您是否会遇到这种少见的情况。
如果优化器内存不足,它将尝试通过在较低的优化级别中重试当前的过程来进行恢复,并以命令行选项中指定的原始级别继续后续过程。
缺省为不优化。不过,只有不指定优化级别时才可能使用缺省设置。如果指定了优化级别,则没有任何选项可用来关闭优化。
如果尝试不设置优化级别,请不要指定任何隐含优化级别的选项。例如,-fast 是将优化级别设置为 -xO5 的宏选项。隐含优化级别的所有其他选项都会给出优化已设置的警告消息。不使用任何优化来编译的方法是从命令行删除所有选项或创建指定优化级别的文件。
如果使用 -g 并且优化级别为 -xO3 或更低,编译器将提供几乎进行全面优化的最佳效果符号信息。尾部调用优化和后端内联被禁用。
如果使用 -g 并且优化级别为 -xO4 或更高,编译器将提供进行全面优化的最佳效果符号信息。
使用 -g 进行调试不会抑制 -xOn,但 -xOn 会在某些方面限制 -g。例如,优化选项会降低调试的效用,以致无法显示 dbx 中的变量,但仍可使用 dbx where 命令获取符号回溯。有关更多信息,请参见《使用 dbx 调试程序》第 1 章中的“调试优化的代码”。
如果同时指定了 -xO 和 -xmaxopt,那么用 -xO 设置的优化级别不得超过 -xmaxopt 值。
如果在 -xO3 或 -xO4 级别上优化非常大的程序(在同一程序中有数千行代码),优化器可能需要大量虚拟内存。在这种情况下,机器性能可能会降低。
下表描述了它们在 SPARC 平台上如何操作。
表 B–32 SPARC 平台上的 -xO 标志
值 |
含义 |
---|---|
-xO1 |
执行基本局部优化(窥孔优化)。 |
-xO2 |
执行基本局部和全局优化。其中包括感应变量排除、局部和全局常用子表达式排除、代数简化、 副本传播、常量传播、循环不可变优化、寄存器分配、基本块合并、尾部循环排除、死代码排除、尾部调用排除和复杂表达式扩展。 -xO2 级别不会将全局、外部或间接引用或定义分配给寄存器。它将这些引用和定义视为被声明为 volatile。一般说来,-xO2 级别产生的代码最小。 |
-xO3 |
类似于执行 -xO2,但还会优化外部变量的引用或定义。还执行循环解开和软件流水线作业。该级别不跟踪指针赋值的结果。在编译设备驱动程序或从信号处理程序内部修改外部变量的程序时,可能需要使用 volatile 类型限定符来保护对象,使其免于优化。一般说来,-xO3 级别会导致代码增大。 |
-xO4 |
类似于执行 -xO3,但是还自动内联包含在相同文件中的函数;这通常会提高执行速度。如果要控制内联哪些函数,请参见B.2.97 -xinline=list。 该级别跟踪指针赋值的效果,通常导致代码增大。 |
-xO5 |
试图生成最高优化级别。使用编辑时间更长或减少执行时间的程度不是很高的优化算法。如果使用配置文件反馈执行该级别上的优化,则更容易提高性能。请参见B.2.138 -xprofile=p。 |
下表描述了优化级别在 x86 平台上的工作原理。
表 B–33 x86 平台上的 -xO 标志
值 |
含义 |
---|---|
-xO1 |
从内存、交叉跳跃(尾部合并)以及缺省优化的单个传递中预装入参数。 |
-xO2 |
同时调度高级和低级指令,并执行改进的溢出分析、循环内存引用排除、寄存器生命周期分析、增强的寄存器分配以及全局通用子表达式的排除。 |
-xO3 |
执行循环长度约简、感应变量排除以及在级别 2 完成的优化。 |
-xO4 |
除执行 -xO3 的优化之外,还自动内联包含在同一文件中的函数。自动内联通常会提高执行速度,但有时却会使速度变得更慢。通常该级别会增加代码的大小。 |
-xO5 |
生成最高级别优化。使用编辑时间更长或减少执行时间的程度不是很高的优化算法。其中包含为导出的函数生成局部的调用约定入口点、进一步优化溢出代码和增加分析,以改善指令调度。 |
有关调试的更多信息,请参见 《》Sun Studio 使用 dbx 调试程序手册。有关优化的更多信息,请参见《Sun Studio 12: Performance Analyzer》手册。
另请参见 -xldscope 和 -xmaxopt。
使用 -xopenmp 选项可通过 OpenMP 指令启用显式并行化。要在多线程环境中运行已并行化的程序,必须在执行之前设置 OMP_NUM_THREADS环境变量。
要启用嵌套并行操作,必须将 OMP_NESTED 环境变量设置为 TRUE。缺省情况下,禁用嵌套并行操作。
下表列出了 i 值:
表 B–34 -xopenmp 标志
值 |
含义 |
---|---|
parallel |
启用 OpenMP pragma 的识别。-xopenmp=parallel 时的优化级别为 -x03。如有必要,编译器会将优化级别更改为 -x03 并发出警告。 此标志还定义处理器标记 _OPENMP。 |
noopt |
启用 OpenMP pragma 的识别。如果优化级别低于 -O3,编译器将不会提高优化级别。 如果将优化级别显式设置为低于 -O3,如同在 cc -O2 -xopenmp=noopt 中一样,编译器会发出错误。如果没有使用 -xopenmp=noopt 指定优化级别,则会识别 OpenMP pragma,并相应地对程序进行并行处理,但不进行优化。 此标志还定义处理器标记 _OPENMP。 |
none |
该标志为缺省设置;它不启用 OpenMP pragma 识别,不更改程序的优化级别且不预定义任何预处理程序标记。 |
如果指定 -xopenmp 但未给定值,编译器将假定 -xopenmp=parallel。如果不指定 -xopenmp,编译器将假定 -xopenmp=none。
如果使用 dbx 调试 OpenMP 程序,那么编译时选用 -g 和 -xopenmp=noopt 可以在并行区设置断点并显示变量内容。
请不要将 -xopenmp 和 -xexplicitpar 或 -xparallel 一起指定。
在以后的发行版中,-xopenmp 的缺省值可能会更改。可以通过显式指定适当的优化来避免警告消息。
如果您在生成任何 .so 时使用 -xopenmp,则必须在链接可执行文件时使用 -xopenmp,并且可执行文件的编译器版本不能比使用 -xopenmp 生成 .so 的编译器版本低。这在编译包含 OpenMP 指令的库时尤其重要。有关在编译和链接时都必须指定的所有编译器选项的完整列表,请参见表 A–2。
为了取得最佳的性能,请确保在系统上安装了最新的 OpenMP 运行时库 libmtsk.so。
有关特定于 OpenMP 的 C 实现的更多信息,请参见3.2 OpenMP 并行化。
有关 OpenMP 的信息,请参见《Sun Studio 12 Update 1:OpenMP API 用户指南》。
编译器对源文件仅执行语法和语义检查,以输出所有 K&R C 函数的原型。此选项不生成任何目标代码或可执行代码。例如,对以下源文件指定 -xP,
f() { } main(argc,argv) int argc; char *argv[]; { } |
产生以下输出:
int f(void); int main(int, char **); |
下列值在 SPARC 上有效:4k、8K、64K、512K、2M、4M、32M、256M、2G、16G 或 default。
下列值在 x86/x64 上有效:4K、2M、4M、1G 或 default。
如果不指定有效的页面大小,运行时将忽略该请求,且不显示任何提示。必须指定适于目标平台的有效页面大小。
在 Solaris 操作系统中使用 getpagesize(3C) 命令可以确定页面中的字节数。Solaris 操作系统不保证支持页面大小请求。可以使用 pmap(1) 或 meminfo(2) 来确定目标平台的页面大小。
可以使用 pmap(1) 或 meminfo(2) 来确定目标平台的页面大小。
除非在编译和链接时使用,否则 -xpagesize 选项不会生效。有关在编译和链接时都必须指定的所有编译器选项的完整列表,请参见表 A–2。
如果指定 -xpagesize=default,Solaris 操作系统将设置页面大小。
使用该选项进行编译与使用等效的选项将 LD_PRELOAD 环境变量设置为 mpss.so.1 或在运行程序之前使用等效的选项运行 Solaris 9 命令 ppgsz(1) 具有相同的效果。有关详细信息,请参见 Solaris 手册页。
此选项是用于 -xpagesize_heap 和 -xpagesize_stack 的宏。这两个选项与 -xpagesize 接受相同的参数。可以通过指定 -xpagesize 为它们设置相同值,也可以分别为它们指定不同的值。
此选项与 -xpagesize 接受相同的值。如果不指定有效的页面大小,运行时将忽略该请求,且不显示任何提示。
在 Solaris 操作系统中使用 getpagesize(3C) 命令可以确定页面中的字节数。Solaris 操作系统不保证支持页面大小请求。可以使用 pmap(1) 或 meminfo(2) 来确定目标平台的页面大小。
可以使用 pmap(1) 或 meminfo(2) 在目标平台中设置页面大小。
如果指定 -xpagesize_heap=default,Solaris 操作系统将设置页面大小。
使用该选项进行编译与使用等效的选项将 LD_PRELOAD 环境变量设置为 mpss.so.1 或在运行程序之前使用等效的选项运行 Solaris 9 命令 ppgsz(1) 具有相同的效果。有关详细信息,请参见 Solaris 手册页。
除非在编译和链接时使用,否则 -xpagesize_heap 选项不会生效。有关在编译和链接时都必须指定的所有编译器选项的完整列表,请参见表 A–2。
此选项与 -xpagesize 接受相同的值。如果不指定有效的页面大小,运行时将忽略该请求,且不显示任何提示。
在 Solaris 操作系统中使用 getpagesize(3C) 命令可以确定页面中的字节数。Solaris 操作系统不保证支持页面大小请求。可以使用 pmap(1) 或 meminfo(2) 来确定目标平台的页面大小。
如果指定 -xpagesize_stack=default,Solaris 操作系统将设置页面大小。
使用该选项进行编译与使用等效的选项将 LD_PRELOAD 环境变量设置为 mpss.so.1 或在运行程序之前使用等效的选项运行 Solaris 9 命令 ppgsz(1) 具有相同的效果。有关详细信息,请参见 Solaris 手册页。
除非在编译和链接时使用,否则 -xpagesize_stack 选项不会生效。有关在编译和链接时都必须指定的所有编译器选项的完整列表,请参见表 A–2。
-xparallel 不接受 OpenMP 并行化指令。但是,Sun 特定的 MP pragma 已被废弃,不再受支持。OpenMP API 是所支持的首选并行化模型。有关标准的指令的迁移信息,请参见《Sun Studio 12 Update 1:OpenMP API 用户指南》。
此编译器选项可激活预编译头文件功能。v 可以是 auto、autofirst、collect: pch_filename 或 use:pch_filename。通过将 -xpch(在B.2.130 -xpch=v中进行了详细介绍)和 -xpchstop(在B.2.131 -xpchstop=[file|<include>]中进行了详细介绍)选项与 #pragma hdrstop 指令(在2.9.8 hdrstop中进行了详细介绍)结合使用,可利用此功能。
使用 -xpch 选项可以创建预编译头文件并减少编译时间。预编译头文件的作用是减少源代码共享同一组 include 文件的应用程序的编译时间,这些 include 文件往往包含大量的源代码。预编译头文件的工作机理是,首先从一个源文件收集一组头文件信息,然后在重新编译该源文件或者编译其他有同样头文件顺序的源文件时就可以使用这些收集到的信息。编译器收集的信息存储在预编译头文件中。
另请参见:
可以让编译器自动生成预编译头文件。选择以下两种方法之一来实现此目的。一种方法是让编译器从在源文件找到的第一个 include 文件创建预编译头文件。另一种方法是让编译器从在源文件中找到的 include 文件集合中选择,选择范围从第一个 include 文件开始,直到已经定义好的确定哪个 include 文件是最后一个的点结束。使用以下标志之一可以确定编译器用于自动生成预编译头文件的方法:
表 B–35 -xpch 标志
标志 |
含义 |
---|---|
-xpch=auto |
预编译头文件的内容基于编译器在源文件中找到的最长的活前缀(有关如何识别活前缀的说明,请参见下文)。此标志生成的预编译头文件可能包含最多的头文件。 |
-xpch=autofirst |
此标志生成的预编译头文件仅包含在源文件中找到的第一个头文件。 |
如果决定手动创建预编译头文件,则必须首先使用 -xpch,并指定 collect 模式。指定 -xpch=collect 的编译命令只能指定一个源文件。在以下示例中,-xpch 选项根据源文件 a.c 创建名为 myheader.cpch 的预编译头文件:
cc -xpch=collect:myheader a.c
有效的预编译头文件通常具有后缀 .cpch。在指定 pch_filename 时,后缀可以由您自己增加或由编译器增加。例如,如果指定 cc -xpch=collect:foo a.c,则预编译的头文件名为 foo.cpch。
如果编译器无法使用 -xpch=auto 和 -xpch=autofirst 时的预编译头文件,则会生成新的预编译头文件。如果编译器无法使用 -xpch=use 时的预编译头文件,将发出一个警告,并且使用真实头文件来完成编译。
您还可以指示编译器使用特定的预编译头文件。要实现此目的,请指定 -xpch=use:pch_filename。您可以将 include 文件同一序列中任意数量的源文件指定为用于创建预编译头文件的源文件。例如,在 use 模式中的命令可类似于以下命令: cc -xpch=use:foo.cpch foo.c bar.c foobar.c.
如果以下条件都成立,则只能使用现有的预编译的头文件。如果以下任意条件不成立,则应重新创建预编译头文件:
用于访问预编译头文件的编译器与创建预编译头文件的编译器相同。由某一版本的编译器创建的预编译头文件不能被其他版本的编译器使用。
除 -xpch 选项之外,用 -xpch=use 指定的编译器选项必须与创建预编译头文件时指定的选项相匹配。
用 -xpch=use 指定的包含头文件的集合与创建预编译头文件时指定的头文件集合是相同的。
用 -xpch=use 指定的包含头文件的内容与创建预编译头文件时指定的包含头文件的内容是相同的。
当前目录(即发生编译并尝试使用给定预编译头文件的目录)与创建预编译头文件所在的目录相同。
在用 -xpch=collect 指定的文件中预处理指令(包括 #include)的初始序列,与在用 -xpch=use 指定的文件中预处理指令的序列相同。
要在多个源文件间共享预编译头文件,这些源文件必须共享一组共同的 include 文件(按其初始标记序列)。标记是指关键字、名称或标点符号。被 #if 指令排除的注释和代码不能被编译器识别为标记。该初始标记序列称为活前缀。也就是说,活前缀是源文件中通用于所有源文件的最靠前的部分。创建预编译头文件并进而确定源文件中哪些头文件是预编译的时,编译器使用此活前缀作为整个操作的依据。
编译器在当前编译期间找到的活前缀必须与用于创建预编译头文件的活前缀匹配。也就是说,必须在使用相同预编译头文件的所有源文件中对活前缀给出一致的解释。
源文件的活前缀只能包含注释和以下任意预处理程序指令:
#include #if/ifdef/ifndef/else/elif/endif #define/undef #ident (if identical, passed through as is) #pragma (if identical)
以上任何指令都可以引用宏。#else、#elif 和 #endif 指令必须在活前缀内匹配。注释被忽略。
指定 -xpch=auto 或 -xpch=autofirst 时,编译器自动确定活前缀的终点,定义如下:
第一个声明/定义
第一个 #line 指令
#pragma hdrstop 指令
在指定的 include 文件之后(如果您指定 -xpch=auto 和 -xpchstop)
第一个 include 文件(如果您指定 -xpch=autofirst)
预处理程序条件编译语句中的终点会生成一个警告,并禁止自动创建预编译头文件。另外,如果同时指定 #pragma hdrstop 和 -xpchstop 选项,编译器将使用两个停止点中较早的那一个来终止活前缀。
对于 -xpch=collect 或 -xpch=use,活前缀以 #pragma hdrstop 结尾。
在共享预编译头文件的每个文件的活前缀中,每个相应的 #define 和 #undef 指令都必须引用相同的符号(例如每个 #define 必须引用同一个值)。这些指令在每个活前缀中出现的顺序也必须相同。每个相应 pragma 也必须相同,并且必须按相同顺序出现在共享预编译头文件的所有文件中。
如何能够使头文件可以预编译?在不同的源文件中解释一致时,头文件可以预编译。具体来说,就是当它仅包含完全声明时。也就是说,任何一个文件中的声明都必须独自成为有效声明。不完全的类型声明,例如 struct S;,是有效声明。完全类型声明可以出现在某些其他文件中。请考虑这些头文件示例:
file a.h struct S { #include "x.h" /* not allowed */ }; file b.h struct T; // ok, complete declaration struct S { int i; [end of file, continued in another file] /* not allowed*/ |
并入预编译头文件的头文件一定不得违反以下约束。这里没有定义对违反上述约束的程序的编译结果。
头文件不得使用 __DATE__ 和 __TIME__。
头文件不得包含 #pragma hdrstop。
如果头文件还包含变量和函数定义,则也是可预编译的。
编译器自动创建预编译头文件时,会将该文件写入 SunWS_cache 目录中。此目录始终位于创建目标文件的位置。该文件的更新受锁保护,这样可在 dmake 下正常工作。
如果需要强制编译器重新生成自动生成的预编译头文件,可以使用 CCadmin 工具清除预编译头文件高速缓存目录。有关更多信息,请参见 CCadmin(1) 手册页。
不要在命令行上指定冲突的 -xpch 标志。例如,同时指定 -xpch=collect 和 -xpch=auto 或同时指定 -xpch=autofirst 和 -xpchstop=<include> 会产生错误。
如果指定 -xpch=autofirst,或指定不带 -xpchstop 的 -xpch=auto,则出现在第一个 include 文件之前或出现在使用用于 -xpch=auto 的 -xpchstop 指定的 include 文件之前的任何声明、定义或 #line 指令都会生成警告,并禁止自动生成预编译头文件。
-xpch=autofirst 或 -xpch=auto 时的第一个 include 文件之前的 #pragma hdrstop 会禁止自动生成预编译头文件。
指定 -xpch=collect 时,编译器会生成预编译头文件的依赖性信息。需要在 make 文件中创建适当的规则,以利用这些依赖性。考虑下面的 make 文件示例:
%.o : %.c shared.cpch $(CC) -xpch=use:shared -xpchstop=foo.h -c $< default : a.out foo.o + shared.cpch : foo.c $(CC) -xpch=collect:shared -xpchstop=foo.h foo.c -c a.out : foo.o bar.o foobar.o $(CC) foo.o bar.o foobar.o clean : rm -f *.o shared.cpch .make.state a.out |
这些 make 规则以及编译器生成的依赖性,会在与 -xpch=collect 一起使用的任何源文件或属于预编译头文件的一部分的任何头文件发生更改时,强制重新创建手动创建的预编译头文件。这样可防止使用过期的预编译头文件。
您无需在 make 文件中为 -xpch=auto 或 -xpch=autofirst 创建任何其他 make 规则。
使用 -xpchstop=file 选项可为预编译头文件指定活前缀的最后一个 include 文件。在命令行使用 -xpchstop 与将 hdrstop pragma 置于第一个包含指令之后等效,此包含指令在您使用 cc 命令指定的每个源文件中引用 file。
结合使用 -xpchstop=<include> 和 -xpch-auto 可以创建基于从其往上并包括 <include> 的头文件的预编译头文件。此标志覆盖缺省的 -xpch=auto 行为(使用整个活前缀中包含的所有头文件的行为)。
在以下示例中,-xpchstop 选项指定了预编译头文件的活前缀以 projectheader.h 的包含结束。因此,privateheader.h 不是活前缀的一部分。
example% cat a.c #include <stdio.h> #include <strings.h> #include "projectheader.h" #include "privateheader.h" . . . example% cc -xpch=collect:foo.cpch a.c -xpchstop=projectheader.h -c |
另请参见 -xpch。
生成可移植的可执行代码 (Portable Executable Code, PEC) 库。PEC 二进制文件可与自动调优系统 (Automatic Tuning System, ATS) 一起使用,该系统出于优化和故障排除的目的重新生成编译的 PEC 二进制文件(原始源代码不是必需的)。http://cooltools.sunsource.net/ 上提供了有关 ATS 的更多信息。
使用 -xpec 生成的二进制文件通常比未使用 -xpec 生成的文件大五倍到十倍。
如果不指定 -xpec,则编译器会将其设置为 -xpec=no。如果您指定 -xpec,但不提供标志,则编译器会将其设置为 -xpec=yes。
准备目标代码,以收集用 gprof(1) 进行文件配置所需的数据。此选项调用在正常终止情况下产生 gmon.out 文件的运行时记录机制。
如果指定 -xpg,-xprofile 将没有用处。两者不能准备或使用对方提供的数据。
在 64 位 Solaris 平台上,使用 prof(1) 或 gprof(1) 生成配置文件,在 32 位 Solaris 平台上,则只使用 gprof 生成配置文件,配置文件中包含大概的用户 CPU 时间。这些时间来自主可执行文件中的例程以及共享库中例程(链接可执行文件时将共享库指定为链接程序参数)的 PC 示例数据(请参见 pcsample(2))。其他共享库(在进程启动后使用 dlopen(3DL) 打开的库)不进行文件配置。
在 32 位 Solaris 系统中,使用 prof(1) 生成的配置文件仅限于可执行文件中的例程。32 位共享库通过用 -xpg 和 gprof(1) 链接可执行程序可以进行文件配置。
Solaris 10 软件不包括使用 -p 编译的系统库。因此,在 Solaris 10 平台上收集的配置文件不包含系统库例程的调用计数。
如果在编译时指定 -xpg,则还必须在链接时指定它。有关在编译时和链接时都必须指定的选项的完整列表,请参见A.1.2 编译时选项和链接时选项。
显式预取只应在度量支持的特殊环境下使用。
val 必须是以下值之一:
表 B–36 -xprefetch 标志
标志 |
含义 |
---|---|
latx:factor |
根据指定的因子,调整编译器假定的“预取到装入”和“预取到存储”延迟。只能将此标志与 -xprefetch=auto 结合使用。请参见B.2.135.1 预取等待时间比率。 |
[no%]auto |
[禁用] 启用预取指令的自动生成 |
[no%]explicit |
(SPARC) [禁用] 启用显式预取宏 |
yes |
已废弃 - 不使用。改用 -xprefetch=auto,explicit。 |
no |
已废弃 - 不使用。改用 -xprefetch=no%auto,no%explicit。 |
缺省值为 -xprefetch=auto,explicit。此缺省值会对实质上具有非线性内存访问模式的应用程序造成负面影响。要覆盖该缺省值,请指定 -xprefetch=no%auto,no%explicit。
sun_prefetch.h 头文件提供了可用来指定显式预取指令的宏。预取的位置大约为可执行文件中对应于宏出现的位置。
预取延迟是从执行预取指令到所预取的数据在高速缓存中可用那一刻之间的硬件延迟。
该因子必须是形式为 n.n. 的正数。
在确定发出预取指令到发出使用所预取数据的装入或存储指令之间的间隔时,编译器就采用预取延迟值。在预取和装入之间采用的延迟可能与在预取和存储之间采用的延迟不同。
编译器可以在众多计算机与应用程序间调整预取机制,以获得最佳性能。这种调整并非总能达到最优。对于占用大量内存的应用程序,尤其是要在大型多处理器上运行的应用程序,可以通过增加预取延迟值来提高性能。要增加值,请使用大于 1 的因子。介于 .5 和 2.0 之间的值最有可能提供最佳性能。
对于数据集完全位于外部高速缓存中的应用程序,可以通过减小预取延迟值来提高性能。要减小此值,请使用小于 1 的因子。
要使用 latx:factor 子选项,则以接近 1.0 的因子值开始并对应用程序进行性能测试。然后适当增加或减小该因子,并再次运行性能测试。继续调整因子并运行性能测试,直到获得最佳性能。以很小的增量逐渐增加或减小因子时,前几步中不会看到性能差异,之后会突然出现差异,然后再趋于稳定。
其中,a 是 [no%]indirect_array_access。
使用此选项可以确定编译器是否以为直接内存访问生成预取的方式为由选项 -xprefetch_level 指示的循环生成间接预取。
如果不指定 -xprefetch_auto_type 的设置,编译器会将其设置为 -xprefetch_auto_type=no%indirect_array_access。
类似 -xalias_level 的选项可以影响计算候选间接预取的主动性,进而影响因更好的内存别名歧义消除信息而发生的自动插入间接预取的主动性。
使用 -xprefetch_level 选项可以控制通过 -xprefetch=auto 确定的预取指令的自动插入的主动性。l 必须为 1、2 或 3。编译器更加主动,换句话说,引入了更多更高 -xprefetch_level 级别的预取。
-xprefetch_level 的适当值取决于应用程序可能具有的缓存缺失的数量。较高级别的 -xprefetch_level 值具有提高应用程序性能的潜能。
仅当使用 -xprefetch=auto 进行编译且优化级别为 3 或更高级别时此选项才有效,并可为支持预取(v8plus、v8plusa、 v9、v9a、v9b、generic64、 native64)的平台生成代码。
-xprefetch_level=1 启用预取指令的自动生成。-xprefetch_level=2 启用级别 1 之外的额外生成,-xprefetch_level=3 启用级别 2 之外的额外生成。
指定了 -xprefetch=auto 时,缺省值为 -xprefetch_level=1。
使用该选项收集并保存执行频率数据,从而可在以后的运行中使用该数据来提高性能。只有将优化级别指定为 -xO2 或更高时,该选项才有效。
必须在编译和链接时指定 -xprofile。有关在编译和链接时都必须指定的所有编译器选项的完整列表,请参见表 A–2。
通过为编译器提供运行时性能反馈可以增强在较高优化级别(例如,-xO5)进行的编译。为了生成运行时的性能反馈,必须使用 -xprofile=collect 编译,然后针对典型数据集运行可执行文件,最后在最高的优化级别使用 -xprofile=use 重新编译。
另请参见 cc(1) 手册页,以了解额外的功能以及如何控制环境变量。
对多线程应用程序来讲,配置文件集合是安全的。也就是说,对执行自身多任务 (-mt) 的程序进行文件配置会产生准确的结果。
p 必须为 collect[: name]、use[:name] 或 tcov。
collect[:name]
优化器使用 -xprofile=use 收集并保存执行频率数据以备将来使用。编译器生成可测量语句执行频率的代码。
name 是执行程序时要在其中存储配置文件数据的目录的名称(可选)。如果指定 name,则它应为绝对 UNIX 路径名。如果未指定 name,则在执行 program 时,名为 program 的已进行文件配置的程序的配置文件数据将存储在当前工作目录中的 program.profile 目录中。
可以设置环境变量 SUN_PROFDATA 和 SUN_PROFDATA_DIR,以控制用 -xprofile=collect 编译的程序存储配置文件数据的位置。如果设置了这两个环境变量,则 -xprofile=collect 数据将写入到 SUN_PROFDATA_DIR/SUN_PROFDATA。
这些环境变量同样控制 tcov 写入的配置文件数据文件的路径和名称,如 tcov(1) 手册页所述。
如果未设置这些环境变量,则配置文件数据将写入当前目录内的 name.profile/feedback 中,其中 name 是可执行文件的名称或在 -xprofile=collect: name 标志中指定的名称。如果 name 已经以 .profile 结尾,则 -xprofile 不会将 .profile 附加到 name 中。如果多次运行程序,那么执行频率数据会累积在 feedback 文件中;也就是说,以前执行的输出不会丢失。
如果在不同的步骤中进行编译和链接,应确保使用 -xprofile=collect 编译的任何目标文件也使用 -xprofile=collect 进行链接。
三个选项 -xMerge -ztext -xprofile=collect 不应同时使用。-xMerge 会强制将静态初始化的数据存储到只读存储器中,-ztext 禁止在只读存储器中进行依赖于位置的符号重定位,而 -xprofile=collect 会在可写存储器中生成静态初始化的、依赖于位置的符号重定位。
use[:name]
使用在 feedback 文件中生成并保存在该文件中的执行频率数据来优化程序,该数据由先前执行使用 – xprofile=collect 编译的程序生成。
name 是所分析程序的名称。该名称是可选的。如果未指定 name,则假定 a.out 为可执行程序的名称。
除了从 -xprofile=collect 更改为 -xprofile=use 的 -xprofile 选项之外,源文件和其他编译器选项必须与用于(创建了之后生成 feedback 文件的编译程序的)编译的源文件和编译器选项完全相同。编译器的相同版本必须既用于收集生成也用于使用生成。如果使用 -xprofile=collect:name 进行编译,则相同的程序名称 name 必须出现在优化编译中:-xprofile=use:name。
目标文件与其配置文件数据之间的关联依据的是使用 -xprofile=collect 编译目标文件时该文件的 UNIX 路径名。在某些情况下,编译器不会将目标文件与其配置文件数据相关联:由于以前没有使用 -xprofile=collect 编译目标文件,因此目标文件没有配置文件数据;程序中的目标文件未使用 -xprofile=collect 进行链接;从未执行过该程序。
如果先前使用 -xprofile=collect 在不同目录中编译了目标文件,而该目标文件与使用 -xprofile=collect 编译的其他目标文件共享一个公共基名,但却无法通过它们的包含目录名称进行唯一标识,编译器也会产生混淆。在这种情况下,即使目标文件有配置文件数据,使用 -xprofile=use 重新编译目标文件时,编译器也不能在 feedback 目录中找到该目标文件。
所有这些情况都能使编译器丢失目标文件及其文件配置数据之间的关联。因此,在您指定 -xprofile=use 时,如果目标文件具有文件配置数据但编译器无法将其与目标文件的路径名相关联,那么请使用 -xprofile_pathmap 选项来标识正确的目录。请参见B.2.140 -xprofile_pathmap。
tcov
-xprofile=tcov 选项是 tcov 的基本块文件配置的新样式。其功能与 -xa 选项相似,此外还能正确地为在头文件中具有源代码的程序收集数据。请参见B.2.70 -xa,以了解有关旧样式文件配置的信息;请参见 tcov(1) 手册页和 Program Performance Analysis Tools,以了解详细信息。
执行代码检测与执行 -xa 选项相似,但是不再生成 .d 文件。相反却生成单一文件,并且该文件的名称是按照最后的可执行文件命名的。例如,如果程序在 /foo/bar/myprog.profile 外运行,则数据文件将存储在 /foo/bar/myprog.profile/myprog.tcovd 中。
-xprofile=tcov 和 -xa 选项在单个可执行程序中兼容。也就是说,您可以链接一个程序,该程序中包含的部分文件已用 -xprofile=tcov 编译,而其他文件是用 -xa 编译的。您不能同时用这两个选项来编译同一个文件。
运行 tcov 时,您必须将 -x 选项传递给它,以便它使用新式数据。否则,tcov 使用原来的 .d 文件(如果有;这是数据的缺省值),并产生不可预测的输出。
与 -xa 选项不同,TCOVDIR 环境变量在编译时无效。不过,在程序运行时可以使用环境变量的值。有关详细信息,请参见 tcov(1) 和 Program Performance Analysis Tools。
如果由于 -xO4 或 -xinline 存在例程的内联处理,则 tcov 的代码覆盖报告可能不可靠。
在 Linux 平台上,不应将 -xprofile=collect 或 -xprofile=tcov 与 -G 一起使用来生成共享库。
当您使用 -xprofile=collect 来编译用于配置文件收集的程序,而用 -xprofile=use 来编译用于配置文件反馈的程序时,在这两个编译中,除 -xprofile=collect 和 -xprofile=use 之外的源文件和编译器选项必须相同。
-xprofile=use: name 选项指定的配置文件反馈目录名称从该选项在一次编译器调用中的所有实例中累积。例如,假定分别执行名称为 a、b 和 c 的已进行文件配置的二进制文件结果是创建文件配置目录 a.profile、b.profile 和 c.profile。
cc -O -c foo.c -xprofile=use:a -xprofile=use:b -xprofile=use:c |
这三个配置文件目录均被使用。编译目标文件时,与特定目标文件有关的任何有效配置文件反馈数据都从指定的反馈目录中开始累积。
如果在同一的命令行上同时指定 -xprofile=collect和 -xprofile=use,则命令行中最右边 -xprofile 选项的应用如下所示:
如果最右边的 -xprofile 选项是 -xprofile=use,则 -xprofile=use 选项指定的所有配置文件反馈目录名都将用于定向反馈优化,同时忽略以前的 -xprofile=collect 选项。
如果最右边的 -xprofile 选项是 -xprofile=collect,则忽略 -xprofile=use 选项指定的所有配置文件反馈目录名,同时启用配置文件生成的检测。
另请参见: -xhwcprof、-xprofile_ircache、-xprofile_pathmap
(SPARC) 将 -xprofile_ircache[=path] 与 -xprofile=collect|use 一起使用,通过重用 collect 阶段保存的编译数据来缩短 use 阶段的编译时间。
在编译大程序时,由于中间数据的保存,使得 use 阶段的编译时间大大减少。注意,所保存的数据会占用相当大的磁盘空间。
在使用 -xprofile_ircache[=path] 时,path 会覆盖保存缓存文件的位置。缺省情况下,这些文件会作为目标文件保存在同一目录下。collect 和 use 阶段出现在两个不同目录中时,指定路径很有用。以下是典型的命令序列:
example% cc -xO5 -xprofile=collect -xprofile_ircache t1.c t2.c example% a.out // run collects feedback data example% cc -xO5 -xprofile=use -xprofile_ircache t1.c t2.c |
(SPARC) 如果同时还指定 -xprofile=use 命令,请使用 -xprofile_pathmap=collect_prefix: use_prefix 选项。以下两个条件都成立且编译器无法找到使用 -xprofile=use 编译的目标文件的配置文件数据时,使用 -xprofile_pathmap。
使用 -xprofile=use 编译目标文件所在的目录与先前使用 -xprofile=collect 编译目标文件所在的目录不同。
目标文件会共享配置文件中的公共基名,但可以根据它们在不同目录中的位置互相区分。
collect-prefix 是目录树的 UNIX 路径名的前缀,该目录树中的目标文件是使用 -xprofile=collect 编译的。
use-prefix 是目录树的 UNIX 路径名的前缀,该目录树中的目标文件是使用 -xprofile=use 编译的。
如果指定了 -xprofile_pathmap 的多个实例,编译器将按照这些实例的出现顺序对其进行处理。将 -xprofile_pathmap 实例指定的每个 use-prefix 与目标文件路径名进行比较,直至找到匹配的 use-prefix 或发现最后一个指定的 use-prefix 与目标文件路径名也不匹配。
在自动并行化期间打开约简识别。必须使用 -xautopar 或 -xparallel 指定 -xreduction ,否则编译器将会发出警告。
当启用约简识别时,编译器并行化约简,例如 dot 产品、最大与最小查找。这些约简产生的舍入与通过非并行化代码获得的舍入不同。
r 是一个逗号分隔列表,它包含以下项中的一项或多项:[no%]appl、[no%]float、[no%]frameptr。
示例: -xregs=appl,no%float
表 B–37 -xregs 标志
SPARC 缺省值为 -xregs=appl,float。
x86 缺省值为 -xregs=no%frameptr。-xregs=frameptr 包含在 -fast 的扩展中。
强烈推荐您用 -xregs=no%appl,float 编译那些用于与应用程序链接的共享库的代码。至少共享库应该显式说明它如何使用应用程序寄存器,以便与这些库链接的应用程序知道如何处理该问题。
例如,在某种全局意义上使用寄存器(例如,使用寄存器指向一些关键数据结构)的应用程序,需要确切地知道其代码未使用 -xregs=no%appl 编译的某个库如何使用应用程序寄存器,以便安全地与该库链接。
将返回赋值指针函数参数视为限定的指针。f 为 %all、%none 或由下面的一个或多个函数名构成的逗号分隔列表:{%all|%none|fn[,fn...]。
如果使用该选项指定函数列表,则指定的函数中的指针参数将被视为限定的;如果指定 -xrestrict=%all,则整个 C 文件中的所有指针参数均被视为限定的。有关更多信息,请参阅3.8.2 限定指针。
此命令行选项可以单独使用,但最好将其用于优化。例如,命令:
%cc -xO3 -xrestrict=%all prog.c |
将文件 prog.c 中的所有指针参数都视为限定指针。命令:
%cc -xO3 -xrestrict=agc prog.c |
将文件 prog.c 中函数 agc 中的所有指针参数都视为限定指针。
缺省值为 %none;指定 -xrestrict 与指定 -xrestrict=%all 等效。
该选项导致所有调试信息被复制到可执行程序中。这对 dbx 的性能或程序的运行时性能几乎没有什么影响,但需要更多磁盘空间。
该选项允许在 SPARC V9 体系结构中使用无故障装入指令。
由于在发生诸如地址未对齐或段违规的故障时,无故障装入不会导致陷阱,因此您应该只对不会发生此类故障的程序使用该选项。因为只有很少的程序会导致基于内存的陷阱,所以您可以安全地将该选项用于大多数程序。对于显式依赖基于内存的自陷来处理异常情况的程序,请勿使用该选项。
仅当与优化级别 -xO5 及以下 -xarch 值中的一个一起使用时,该选项才能生效: sparc、 sparcvis 或 sparcvis2(用于 -m32 和 -m64)
已废弃-不使用。不再支持源代码浏览器功能。
已废弃-不使用。不再支持源代码浏览器功能。
将无后缀的浮点常量表示为单精度模式,而非缺省的双精度模式。与 -Xc 一起使用时无效。
示例: 如果编译器增加代码大小,它不会解开循环或并行化循环。
此选项已废弃,可能会在将来的发行版中删除。-xstrconst 是 -features=conststrings 的别名。
t 的值必须是下列值之一: native、generic、native64、generic64 或 system-name。
-xtarget 的每个特定值都会扩展到 -xarch、-xchip 和 -xcache 选项值的特定集合。使用 -xdryrun 选项可在运行的系统上确定 -xtarget=native 的扩展。
例如,-xtarget=sun4/15 与以下内容等效: -xarch=v8a -xchip=micro -xcache=2/16/1。
-xtarget 在特定主机平台上的扩展在该平台上编译时扩展到的 -xarch、-xchip 或 -xcache 设置可能与 -xtarget=native 不同。
标志 |
含义 |
---|---|
native |
在主机系统上获取最佳性能。 编译器生成能在主机系统上提供最佳性能的代码。它决定了运行编译器的计算机的可用架构、芯片和缓存属性。 |
native64 |
在主机系统上获取 64 位二进制目标文件的最佳性能。编译器生成为主机系统优化的 64 位二进制目标文件。它决定了运行编译器的计算机的可用 64 位体系结构、芯片和缓存属性。 |
generic |
这是缺省值。获取通用体系结构、芯片和高速缓存的最佳性能。 |
generic64 |
为了在大多数 64 位平台体系结构上获得 64 位二进制目标文件的最佳性能而设置参数。 |
system-name |
获取指定系统的最佳性能。 从以下代表您所面向的实际系统的列表中选择系统名称: |
通过为编译器提供目标计算机硬件的精确描述,某些程序的性能可得到提高。当程序性能很重要时,目标硬件的正确指定是非常重要的。在较新的 SPARC 处理器上运行时,尤其是这样。不过,对大多数程序和较旧的 SPARC 处理器来讲,性能的提高微不足道,因此指定 generic 就足够了。
在 SPARC 还是 UltraSPARC V9 上针对 64 位 Solaris 软件进行编译,是由 -m64 选项指示。如果为 -xtarget 指定 native64 或 generic64 以外的标志,则还必须如下所示指定 -m64 选项:-xtarget=ultra ... -m64,否则编译器将使用 32 位内存模型。
表 B–39 SPARC 上的 -xtarget 扩展
-xtarget= |
-xarch |
-xchip |
-xcache |
---|---|---|---|
generic |
generic |
generic |
generic |
cs6400 |
v8 |
super |
16/32/4:2048/64/1 |
entr150 |
v8 |
ultra |
16/32/1:512/64/1 |
entr2 |
v8plusa |
ultra |
16/32/1:512/64/1 |
entr2/1170 |
v8plusa |
ultra |
16/32/1:512/64/1 |
entr2/1200 |
v8plusa |
ultra |
16/32/1:512/64/1 |
entr2/2170 |
v8plusa |
ultra |
16/32/1:512/64/1 |
entr2/2200 |
v8plusa |
ultra |
16/32/1:512/64/1 |
entr3000 |
v8plusa |
ultra |
16/32/1:512/64/1 |
entr4000 |
v8plusa |
ultra |
16/32/1:512/64/1 |
entr5000 |
v8plusa |
ultra |
16/32/1:512/64/1 |
entr6000 |
v8plusa |
ultra |
16/32/1:512/64/1 |
sc2000 |
v8 |
super |
16/32/4:2048/64/1 |
solb6 |
v8 |
super |
16/32/4:1024/32/1 |
ss10 |
v8 |
super |
16/32/4 |
ss10/20 |
v8 |
super |
16/32/4 |
ss10/30 |
v8 |
super |
16/32/4 |
ss10/40 |
v8 |
super |
16/32/4 |
ss10/402 |
v8 |
super |
16/32/4 |
ss10/41 |
v8 |
super |
16/32/4:1024/32/1 |
ss10/412 |
v8 |
super |
16/32/4:1024/32/1 |
ss10/50 |
v8 |
super |
16/32/4 |
ss10/51 |
v8 |
super |
16/32/4:1024/32/1 |
ss10/512 |
v8 |
super |
16/32/4:1024/32/1 |
ss10/514 |
v8 |
super |
16/32/4:1024/32/1 |
ss10/61 |
v8 |
super |
16/32/4:1024/32/1 |
ss10/612 |
v8 |
super |
16/32/4:1024/32/1 |
ss10/71 |
v8 |
super2 |
16/32/4:1024/32/1 |
ss10/712 |
v8 |
super2 |
16/32/4:1024/32/1 |
ss10/hs11 |
v8 |
hyper |
256/64/1 |
ss10/hs12 |
v8 |
hyper |
256/64/1 |
ss10/hs14 |
v8 |
hyper |
256/64/1 |
ss10/hs21 |
v8 |
hyper |
256/64/1 |
ss10/hs22 |
v8 |
hyper |
256/64/1 |
ss1000 |
v8 |
super |
16/32/4:1024/32/1 |
ss20 |
v8 |
super |
16/32/4:1024/32/1 |
ss20/151 |
v8 |
hyper |
512/64/1 |
ss20/152 |
v8 |
hyper |
512/64/1 |
ss20/50 |
v8 |
super |
16/32/4 |
ss20/502 |
v8 |
super |
16/32/4 |
ss20/51 |
v8 |
super |
16/32/4:1024/32/1 |
ss20/512 |
v8 |
super |
16/32/4:1024/32/1 |
ss20/514 |
v8 |
super |
16/32/4:1024/32/1 |
ss20/61 |
v8 |
super |
16/32/4:1024/32/1 |
ss20/612 |
v8 |
super |
16/32/4:1024/32/1 |
ss20/71 |
v8 |
super2 |
16/32/4:1024/32/1 |
ss20/712 |
v8 |
super2 |
16/32/4:1024/32/1 |
ss20/hs11 |
v8 |
hyper |
256/64/1 |
ss20/hs12 |
v8 |
hyper |
256/64/1 |
ss20/hs14 |
v8 |
hyper |
256/64/1 |
ss20/hs21 |
v8 |
hyper |
256/64/1 |
ss20/hs22 |
v8 |
hyper |
256/64/1 |
ss4 |
v8a |
micro2 |
8/16/1 |
ss4/110 |
v8a |
micro2 |
8/16/1 |
ss4/85 |
v8a |
micro2 |
8/16/1 |
ss5 |
v8a |
micro2 |
8/16/1 |
ss5/110 |
v8a |
micro2 |
8/16/1 |
ss5/85 |
v8a |
micro2 |
8/16/1 |
ss600/41 |
v8 |
super |
16/32/4:1024/32/1 |
ss600/412 |
v8 |
super |
16/32/4:1024/32/1 |
ss600/51 |
v8 |
super |
16/32/4:1024/32/1 |
ss600/512 |
v8 |
super |
16/32/4:1024/32/1 |
ss600/514 |
v8 |
super |
16/32/4:1024/32/1 |
ss600/61 |
v8 |
super |
16/32/4:1024/32/1 |
ss600/612 |
v8 |
super |
16/32/4:1024/32/1 |
sslc |
v8a |
micro |
2/16/1 |
sslx |
v8a |
micro |
2/16/1 |
sslx2 |
v8a |
micro2 |
8/16/1 |
ssvyger |
v8a |
micro2 |
8/16/1 |
sun4/15 |
v8a |
micro |
2/16/1 |
sun4/30 |
v8a |
micro |
2/16/1 |
ultra |
v8plusa |
ultra |
16/32/1:512/64/1 |
ultra1/140 |
v8plusa |
ultra |
16/32/1:512/64/1 |
ultra1/170 |
v8plusa |
ultra |
16/32/1:512/64/1 |
ultra1/200 |
v8plusa |
ultra |
16/32/1:512/64/1 |
ultra2 |
v8plusa |
ultra2 |
16/32/1:512/64/1 |
ultra2/1170 |
v8plusa |
ultra |
16/32/1:512/64/1 |
ultra2/1200 |
v8plusa |
ultra |
16/32/1:1024/64/1 |
ultra2/1300 |
v8plusa |
ultra2 |
16/32/1:2048/64/1 |
ultra2/2170 |
v8plusa |
ultra |
16/32/1:512/64/1 |
ultra2/2200 |
v8plusa |
ultra |
16/32/1:1024/64/1 |
ultra2/2300 |
v8plusa |
ultra2 |
16/32/1:2048/64/1 |
ultra2e |
v8plusa |
ultra2e |
16/32/1:256/64/4 |
ultra2i |
v8plusa |
ultra2i |
16/32/1:512/64/1 |
ultra3 |
v8plusa |
ultra3 |
64/32/4:8192/512/1 |
ultra3cu |
v8plusa |
ultra3cu |
64/32/4:8192/512/2 |
ultra3i |
v8plusa |
ultra3i |
64/32/4:1024/64/4 |
ultra4 |
v8plusa |
ultra4 |
64/32/4:8192/128/2 |
ultra4plus |
v8plusa |
ultra4plus |
64/32/4:2048/64/4/2:32768/64/4 |
ultraT1 |
v8plusa |
ultraT1 |
8/16/4/4:3072/64/12/32 |
ultraT2 |
sparcvis2 |
ultraT2 |
8/16/4:4096/64/16 |
ultraT2plus |
sparcvis2 |
ultraT2plus |
8/16/4:4096/64/16 |
sparc64vi |
sparcfmaf |
sparc64vi |
128/64/2:5120/64/10 |
sparc64vii |
sparcima |
sparc64vii |
64/64/2:5120/256/10 |
有关 UltraSPARC IVplus、UltraSPARC T1 和 UltraSPARC T2 芯片的缓存属性的更多信息,请参见B.2.80 -xcache[= c]。 |
在 64 位 x86 平台上针对 64 位 Solaris 软件进行编译是由 -m64 选项指示的。如果为 -xtarget 指定 native64 或 generic64 以外的标志,则还必须如下所示指定 -m64 选项:-xtarget=opteron ... -m64,否则编译器将使用 32 位内存模型。
表 B–40 x86 上的 -xtarget 扩展
-xtarget= |
-xarch |
-xchip |
-xcache |
---|---|---|---|
generic |
generic |
generic |
generic |
opteron |
sse2a |
opteron |
64/64/2:1024/64/16 |
386 |
pentium |
generic |
|
pentium_pro |
pentium_pro |
pentium_pro |
generic |
pentium3 |
sse |
pentium3 |
16/32/4:256/32/4 |
pentium4 |
sse2 |
pentium4 |
8/64/4:256/128/8 |
nehalem |
sse4_2 |
nehalem |
32/64/8:256/64/8:8192/64/16 |
penryn |
sse4_1 |
penryn |
2/64/8:6144/64/24 |
woodcrest |
ssse3 |
core2 |
32/64/8:4096/64/16 |
barcelona |
amdsse4a |
amdfam10 |
64/64/2:512/64/16 |
将 cc 使用的临时文件的目录设置为 dir。在此选项字符串中不允许有空格。如果不指定此选项,临时文件将保存到 /tmp。-xtemp 优先于 TMPDIR 环境变量。
指定 -xthreadvar 来控制线程局部变量的实现。将此选项与 __thread 声明说明符结合使用,可利用编译器的线程局部存储功能。使用 __thread 说明符声明线程变量后,请指定 -xthreadvar,以便能够将线程局部存储用于动态(共享)库中的位置相关的代码(非 PIC 代码)。有关如何使用 __thread 的更多信息,请参见2.3 线程局部存储说明符。
o 必须为下列值之一:
表 B–41 -xthreadvar 标志
标志 |
含义 |
---|---|
[no%]dynamic |
[不] 编译动态装入的变量。使用 -xthreadvar=no%dynamic 时对线程变量的访问明显加快,但是不能在动态库中使用目标文件。也就是说,只能在可执行文件中使用目标文件。 |
如果未指定 -xthreadvar,编译器所用的缺省设置取决于是否启用与位置无关的代码。如果启用了与位置无关的代码,则该选项设置为 -xthreadvar=dynamic。如果禁用了与位置无关的代码,则该选项设置为 -xthreadvar=no%dynamic。
如果指定 -xthreadvar,但未指定任何值,则该选项设置为 -xthreadvar=dynamic。
如果动态库中存在与位置有关的代码,那么就必须指定 -xthreadvar。
链接程序不支持在动态库中与非 PIC 代码等效的线程变量。由于非 PIC 线程变量要快很多,所以应将其用作可执行文件的缺省设置。
在 Solaris 软件的不同版本上使用线程变量需要在命令行中使用不同选项。
在 Solaris 8 软件中,对于使用 __thread 的对象,必须使用 -mt 进行编译,且必须使用 -mt -L/usr/lib/lwp -R/usr/lib/lwp 进行链接。
在 Solaris 9 软件中,使用 __thread 的对象必须使用 -mt 来编译和链接。
另请参见:-xcode、-KPIC、-Kpic
针对 K&R C 与 Sun ISO C 之间的差异发出警告。
-xtransition 选项与 -Xa 和 -Xt 选项一起使用时将发出警告。通过适当编码,可以消除关于不同行为的所有警告消息。除非使用 -xtransition 选项,否则不再出现以下警告:
\a is ISO C “alert” character
\x is ISO C hex escape
bad octal digit
base type is really type tag: name
comment is replaced by “##”
comment does not concatenate tokens
declaration introduces new type in ISO C: type tag
macro replacement within a character constant
macro replacement within a string literal
no macro replacement within a character constant
no macro replacement within a string literal
operand treated as unsigned
trigraph sequence replaced
ISO C treats constant as unsigned: operator
semantics of operator change in ISO C; use explicit cast
-xtrigraphs 选项确定编译器是否识别 ISO C 标准定义的三字符序列。
缺省情况下,编译器假定 -xtrigraphs=yes 并识别整个编译单元的所有三字符序列。
如果源代码具有包含问号 ( ?) 的文字串(编译器将其解释为三字符序列),那么您可以使用 -xtrigraph=no 子选项禁用对三字符序列的识别。-xtrigraphs=no 选项可关闭整个编译单元内的所有三字母识别。
请考虑以下名为 trigraphs_demo.c 的源文件示例。
#include <stdio.h> int main () { (void) printf("(\?\?) in a string appears as (??)\n"); return 0; } |
下面是使用 -xtrigraphs=yes 编译该代码后的输出。
example% cc -xtrigraphs=yes trigraphs_demo.c example% a.out (??) in a string appears as (] |
下面是使用 -xtrigraphs=no 编译该代码后的输出。
example% cc -xtrigraphs=no trigraphs_demo.c example% a.out (??) in a string appears as (??) |
建议优化器解开循环 n 次。n 是正整数。当 n 等于 1 时,它是一个命令,此时编译器不解开任何循环。当 n 大于 1 时,-xunroll=n 只建议编译器解开循环 n 次。
如果您需要支持使用 ISO10646 UTF-16 串文字的国际化应用程序,请使用此选项。换句话说,如果代码中包含您希望在目标文件中由编译器转换成 UTF-16 字符串的串文字,请使用该选项。如果不指定该选项,编译器既不生成、也不识别 16 位的文本字符串。该选项使编译器可以将 U"ASCII_string" 串文字识别成无符号短整型数组。因为这样的字符串还不属于任何标准,所以该选项的作用是使非标准 C++ 得以识别。
通过指定 -xustr=no,可以关闭编译器识别 U"ASCII_string" 串文字。该选项在命令行上最右侧的实例覆盖了先前的所有实例。
缺省值为 -xustr=no。如果指定了没有参数的 -xustr,编译器将不接受该选项,而是发出一个警告。如果 C 或 C++ 标准定义了语法的含义,那么缺省设置是可以更改的。
指定 -xustr=ascii_utf16_ushort 时未指定 U"ASCII_string" 串文字不是错误。
不是所有文件都必须使用该选项编译。
下面的示例显示了带有 U 前缀的带引号文本字符串。还显示了指定 -xustr 的命令行。
example% cat file.c const unsigned short *foo = U"foo"; const unsigned short bar[] = U"bar"; const unsigned short *fun() { return foo;} example% cc -xustr=ascii_utf16_ushort file.c -c |
8 位字符文字可以带有 U 前缀,以形成一个 unsigned short 类型的 16 位 UTF-16 字符。示例:
const unsigned short x = U'x'; const unsigned short y = U'\x79'; |
启用对向量库函数的调用的自动生成和/或 SIMD(Single Instruction Multiple Data,单个指令多个数据)指令的生成。使用此选项时,必须通过指定 -fround=nearest 来使用缺省的舍入模式。
a 可以为下列值:
表 B–42 -xvector 标志
值 |
含义 |
---|---|
[no%]lib |
如果循环内的数学库调用可转换为对等效向量数学例程的单个调用,则 [不] 允许编译器进行此类转换。此类转换可提高那些循环计数较大的循环的性能。(仅限 Solaris) |
[no%]simd |
[不] 指示编译器使用本机 x86 SSE SIMD 指令来提高某些循环的性能。如果目标体系结构支持 SIMD 指令,则编译器只能接受此转换。例如,必须指定 -xarch=amd64、-xarch=amd64a 或 -xarch=generic64。还必须将优化级别指定为 -xO3 或更高级别,而且指定 -xvector=simd 时还必须指定 -xdepend。 |
yes |
此选项已废弃,改为指定 -xvector=lib。 |
no |
此选项已废弃,改为指定 -xvector=none。 |
缺省值为 -xvector=%none。如果指定了 -xvector 但未提供标志,编译器将假定 -xvector=lib。
如果在以前没有指定 -xdepend 的情况下在命令行上使用 -xvector,则 -xvector 会触发 -xdepend。如果未指定优化级别或优化级别低于 -x03,则 -xvector 选项还会将优化级别提高到 -x03。
在装入步骤中,编译器包含 libmvec 库。如果使用不同的命令进行编译和链接,请确保在链接 cc 命令时使用 -xvector。有关在编译和链接时都必须指定的所有编译器选项的完整列表,请参见表 A–2。
(SPARC) 在使用 VIS[tm] 指令集软件开发者工具包 (VIS[tm] instruction-set Software Developers Kit, VSDK) 中定义的汇编语言模板时,请使用 -xvis=[yes| no] 命令。缺省值为 -xvis=no。指定 -xvis 与指定 -xvis=yes 等效。
VIS 指令集是 SPARC v9 指令集的扩展。尽管 UltraSPARC 是 64 位处理器,但在很多情况下数据都限制在 8 位或 16 位范围内,特别是多媒体应用程序中。VIS 指令可以用一条指令处理 4 个 16 位数据,这个特性使得处理诸如图像、线性代数、信号处理、音频、视频以及网络等新媒体的应用程序的性能大大提高。
有关 VSDK 的更多信息,请访问 http://www.sun.com/processors/vis/。
发出有关可能存在的并行编程相关问题的警告,这些问题可能导致在使用 OpenMP 时出现错误的结果。与 -xopenmp 和 OpenMP API 指令一起使用。
编译器在检测到下列情形时会发出警告。
循环是使用 MP 指令并行化的,而这些指令中的不同循环迭代之间存在数据依赖性
OpenMP 数据共享属性子句存在问题。例如,声明在 OpenMP 并行区域中的访问可能导致数据争用的变量 "shared",或者声明其在并行区域中的值在并行区域之后使用的变量 "private"。
如果所有并行化指令在处理期间均未出现问题,则不显示警告。
示例:
cc -xopenmp -vpara any.c |
Sun Studio 编译器支持 OpenMP 2.5 API 并行化。因此,已废弃 MP pragma 指令,不再支持此类指令。 有关迁移到 OpenMP API 的信息,请参见《OpenMP API 用户指南》。
指定新目录 dir 作为组件 c 的位置。c 可以包含任何字符,这些字符表示 -W 选项下列出的组件。
如果已指定组件的位置,则工具的新路径名称为 dir/tool。如果对任何一项应用了多个 -Y 选项,则保留最后一个选项。
指定用来搜索所有编译器组件的目录 dir。如果 dir 中找不到组件,搜索将转至安装编译器的目录。
(SPARC) 为 lock_lint 创建程序数据库,但不生成可执行代码。请参阅 lock_lint(1) 手册页,以了解更多详细信息。