接手一个旧工程，编译能通过，warning却不断往外滚，着实让人难以下手。往前翻几屏，又发现不少编号和文件位置完全相同。Green Hills的构建日志里，重复提示、代码问题和配置差异可能混在一起。先弄清每条提示来自哪里，再处理代码和选项，会比从上到下逐行修改更有头绪。

　　一、Green Hills怎么查看编译警告

　　MULTI项目管理器提供了构建详情窗口，可以查看完整输出，也可以从警告跳转到源码。查看前应确认正在检查哪个项目、哪套配置。

　　1、找到最近一次构建输出

　　①选中目标项目，点击【Build】→【Build selected file】，执行构建。

　　②构建结束后，点击【Build】→【View Build Details】，也可以按F6打开最近一次构建详情。

　　③在【Build Details】中查看warning前后的输出，记下产生提示的工具、文件名和行号。

　　窗口没有自动弹出，也值得手动打开看一眼。MULTI可以设置构建详情的自动打开条件，窗口是否出现，不能用来判断警告是否存在。

　　2、让警告带上诊断编号

　　同类警告的文字可能很长，编号则便于检索。它既能帮助整理日志，也能用于查找当前工具链的诊断说明。

　　①在项目树中右键目标项目或源文件，选择【Set Build Options】。

　　②打开【Compiler Diagnostics】→【Warnings】，选择【Display】。

　　③展开【C/C++Messages】→【Varying Message Severity】。

　　④将【Display Diagnostic Numbers】设为开启；不同工具链版本的名称可能略有差异，可查阅随软件安装的帮助。

　　⑤重新编译相关源文件，保留包含编号和完整提示的输出。

　　3、从提示进入源码

　　①双击【Build Details】中的警告条目，打开对应文件，在提示位置附近查看声明、赋值、调用及相关宏。

　　被标出的行通常是编译器发现问题的位置。原因可能在前面的声明，也可能藏在宏展开或头文件中。例如，参数类型不匹配，就需要连同函数声明、定义和调用一起核对。

　　二、Green Hills编译警告过多如何处理

　　日志条数与待修改位置并不总是一一对应。一个公共头文件被许多源文件包含，同一处问题就可能被报告多次。

　　1、把重复提示归到同一个原因下

　　①按工具、诊断编号和文件位置整理警告，找出反复出现的条目。

　　②先修正公共声明、宏或内联函数中的问题，再重新编译受影响的文件，观察这些提示是否一起减少。

　　如果同类提示只在个别源文件中保留，就继续看该文件的宏定义、包含关系和专用选项。这样既能减少重复劳动，也不容易漏掉表面相似、原因不同的问题。

　　2、代码修改不能只看提示是否消失

　　未初始化变量、数据截断、符号位变化和指针类型不匹配，可能改变程序行为。处理这类警告时，需要看清实际的数据范围和执行路径。

　　①对未初始化提示，沿各条相关分支检查赋值是否先于使用。

　　②对整数转换，比较源类型、目标类型的宽度和符号，以及业务中可能出现的取值。

　　③对函数或指针类型提示，检查声明、定义及调用方式是否一致，再修改接口或调用代码。

　　④重新编译，并运行与改动有关的测试，补查边界值及异常分支。

　　3、同一头文件只在部分文件中报警

　　①对报警源文件打开【Set Build Options】，查看【Set In】所示的选项来源。

　　②对照【Build Details】中的实际命令，比较宏定义、头文件路径及语言相关选项。

　　工程里存在同名头文件时，不同包含路径可能让编译器读到不同版本。宏定义也可能切换出另一套声明。因此，这种情况不宜直接认定为编译器误报。

　　4、确实保留的警告再做局部抑制

　　第三方库和生成代码可能不适合直接修改，更新或重新生成也可能覆盖手工改动。处理前还要区分C/C++、汇编器、链接器和DoubleCheck的输出，它们不能共用一套诊断设置。

　　①查明代码来源，检查是否有兼容版本、生成配置或模板可以修正问题。

　　②对仍需保留的提示，查阅对应工具的帮助，确认该诊断允许调整级别。

　　③对C/C++编译器中允许调整的诊断，选中相关源文件或子项目，在【Set Build Options】中的【Varying Message Severity】→【Set Message to Silent】填写已核实的编号。

　　④重新构建，确认只抑制了预期提示，并记录原因及适用范围。

　　三、Green Hills警告减少后还要检查什么

　　改完几处代码，再编译时只剩零星提示，很容易以为清理工作已经结束。不过，这次参与编译的文件可能并不完整，还需要回头检查未重新编译的部分，以及之前留下的屏蔽设置。

　　1、重新构建，看看有没有遗漏

　　①选中目标项目，进入【Build】→【Advanced Build selected file】，勾选【Clean all output before building】，执行一次干净构建。

　　②将本轮日志与修改前的记录对照，检查原有警告是否消失，以及其他文件中是否仍有相同问题。

　　③如果工程平时使用多套构建配置，分别切换到需要交付的配置进行检查，保留对应结果。

　　有些代码只在特定宏条件下参与编译，当前配置没有提示，并不能说明其他配置也已处理妥当。复核时沿用实际交付条件，结果才有参考意义。

　　2、给保留的警告留个交代

　　第三方代码中的某条警告经过检查后决定暂时保留，最好把判断依据记下来。过几个月再遇到它，接手的人才能知道当时为什么这样处理。

　　①检查【Set Message to Silent】中的编号，逐项核对对应文件、保留原因和适用的工具链版本。

　　②对已经修复或失去依据的屏蔽项，撤销相关设置并重新编译；仍需保留的，则补充记录，供后续更新代码或工具链时复查。

　　总结

　　查看Green Hills编译警告，可以从构建详情入手，结合诊断编号和源码位置逐项判断。重复出现的提示，找到公共原因后可能一次解决多处；涉及类型转换、变量赋值的问题，则要连同程序行为一起检查。清理完成后，再用完整构建确认结果，也给暂时保留的警告留下说明，后续维护会省心一些。希望这些方法能帮大家理清处理思路，减少反复翻查日志的时间。如果还有相关需求，欢迎联系我们交流。