Merge pull request #3427 from corob-msft/docs/corob/cpp-docs-zh-cn-168

Fix loc issue in /GL docs for cpp-docs.zh-cn 168

Author: v-ccolin

docs/build/reference/gl-whole-program-optimization.md

@@ -1,58 +1,55 @@
 ---
-description: "Learn more about: /GL (Whole Program Optimization)"
-title: "/GL (Whole Program Optimization)"
-ms.date: "11/04/2016"
-f1_keywords: ["/gl"]
+description: "Learn more about: /GL (Whole program optimization)"
+title: "/GL (Whole program optimization)"
+ms.date: 03/05/2021
+f1_keywords: ["/GL"]
 helpviewer_keywords: ["/GL compiler option [C++]", "whole program optimizations and C++ compiler", "-GL compiler option [C++]", "GL compiler option [C++]"]
-ms.assetid: 09d51e2d-9728-4bd0-b5dc-3b8284aca1d1
 ---
-# /GL (Whole Program Optimization)
+# `/GL` (Whole program optimization)
 
 Enables whole program optimization.
 
 ## Syntax
 
-```
-/GL[-]
-```
+> **`/GL`**[**`-`**]
 
 ## Remarks
 
-Whole program optimization allows the compiler to perform optimizations with information on all modules in the program. Without whole program optimization, optimizations are performed on a per module (compiland) basis.
+Whole program optimization allows the compiler to perform optimizations with information on all modules in the program. Without whole program optimization, optimizations are performed on a per-module (compiland) basis.
 
-Whole program optimization is off by default and must be explicitly enabled. However, it is also possible to explicitly disable it with **/GL-**.
+Whole program optimization is off by default and must be explicitly enabled. However, it's also possible to explicitly disable it with **`/GL-`**.
 
 With information on all modules, the compiler can:
 
 - Optimize the use of registers across function boundaries.
 
 - Do a better job of tracking modifications to global data, allowing a reduction in the number of loads and stores.
 
-- Do a better job of tracking the possible set of items modified by a pointer dereference, reducing the numbers of loads and stores.
+- Track the possible set of items modified by a pointer dereference, reducing the required loads and stores.
 
 - Inline a function in a module even when the function is defined in another module.
 
-.obj files produced with **/GL** will not be available to such linker utilities as [EDITBIN](editbin-reference.md) and [DUMPBIN](dumpbin-reference.md).
+*`.obj`* files produced with **`/GL`** aren't usable by linker utilities such as [`EDITBIN`](editbin-reference.md) and [`DUMPBIN`](dumpbin-reference.md).
 
-If you compile your program with **/GL** and [/c](c-compile-without-linking.md), you should use the /LTCG linker option to create the output file.
+If you compile your program with **`/GL`** and [`/c`](c-compile-without-linking.md), you should use the /LTCG linker option to create the output file.
 
-[/ZI](z7-zi-zi-debug-information-format.md) cannot be used with **/GL**
+[`/ZI`](z7-zi-zi-debug-information-format.md) can't be used with **`/GL`**
 
-The format of files produced with **/GL** in the current version may not be readable by subsequent versions of Visual C++. You should not ship a .lib file comprised of .obj files that were produced with **/GL** unless you are willing to ship copies of the .lib file for all versions of Visual C++ you expect your users to use, now and in the future.
+The format of files produced with **`/GL`** in the current version often isn't readable by later versions of Visual Studio and the MSVC toolset. Unless you're willing to ship copies of the *`.lib`* file for all versions of Visual Studio you expect your users to use, now and in the future, don't ship a *`.lib`* file made up of *`.obj`* files  produced by **`/GL`** . For more information, see [Restrictions on binary compatibility](../../porting/binary-compat-2015-2017.md#restrictions).
 
-.obj files produced with **/GL** and precompiled header files should not be used to build a .lib file unless the .lib file will be linked on the same machine that produced the **/GL** .obj file. Information from the .obj file's precompiled header file will be needed at link time.
+*`.obj`* files produced by **`/GL`** and precompiled header files shouldn't be used to build a *`.lib`* file unless the *`.lib`* file is linked on the same machine that produced the **`/GL`** *`.obj`* file. Information from the *`.obj`* file's precompiled header file is needed at link time.
 
-For more information on the optimizations available with and the limitations of whole program optimization, see [/LTCG](ltcg-link-time-code-generation.md).  **/GL** also makes profile guided optimization available; see /LTCG.  When compiling for profile guided optimizations and if you want function ordering from your profile guided optimizations, you must compile with [/Gy](gy-enable-function-level-linking.md) or a compiler option that implies /Gy.
+For more information on the optimizations available with and the limitations of whole program optimization, see [`/LTCG`](ltcg-link-time-code-generation.md).  **`/GL`** also makes profile guided optimization available. When compiling for profile guided optimizations and if you want function ordering from your profile guided optimizations, you must compile with [`/Gy`](gy-enable-function-level-linking.md) or a compiler option that implies /Gy.
 
 ### To set this linker option in the Visual Studio development environment
 
-1. See [/LTCG (Link-time Code Generation)](ltcg-link-time-code-generation.md) for information on how to specify **/GL** in the development environment.
+For more information on how to specify **`/GL`** in the development environment, see [`/LTCG` (Link-time code generation)](ltcg-link-time-code-generation.md) .
 
 ### To set this linker option programmatically
 
-1. See <xref:Microsoft.VisualStudio.VCProjectEngine.VCCLCompilerTool.WholeProgramOptimization%2A>.
+- See <xref:Microsoft.VisualStudio.VCProjectEngine.VCCLCompilerTool.WholeProgramOptimization%2A>.
 
 ## See also
 
-[MSVC Compiler Options](compiler-options.md)<br/>
-[MSVC Compiler Command-Line Syntax](compiler-command-line-syntax.md)
+[MSVC compiler options](compiler-options.md)\
+[MSVC compiler command-line syntax](compiler-command-line-syntax.md)

docs/porting/binary-compat-2015-2017.md

@@ -10,7 +10,7 @@ The Microsoft C++ (MSVC) compiler toolsets in Visual Studio 2013 and earlier don
 
 We've changed this behavior in Visual Studio 2015, 2017, and 2019. The runtime libraries and apps compiled by any of these versions of the compiler are binary-compatible. It's reflected in the C++ toolset major number, which starts with 14 for all three versions. (The toolset version is v140 for Visual Studio 2015, v141 for 2017, and v142 for 2019). Say you have third-party libraries built by Visual Studio 2015. You can still use them in an application built by Visual Studio 2017 or 2019. There's no need to recompile with a matching toolset. The latest version of the Microsoft Visual C++ Redistributable package (the Redistributable) works for all of them.
 
-## Restrictions on binary compatibility
+## <a name="restrictions"></a> Restrictions on binary compatibility
 
 There are three important restrictions on binary compatibility between the the v140, v141, and v142 toolsets and minor numbered version updates: