{"id":31355,"date":"2022-12-13T17:01:41","date_gmt":"2022-12-13T17:01:41","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/cppblog\/?p=31355"},"modified":"2022-12-13T17:01:41","modified_gmt":"2022-12-13T17:01:41","slug":"standards-conformance-improvements-to-gw-in-visual-studio-version-17-5-preview-2","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/standards-conformance-improvements-to-gw-in-visual-studio-version-17-5-preview-2\/","title":{"rendered":"Standards conformance improvements to \/Gw in Visual Studio version 17.5 Preview 2"},"content":{"rendered":"

The \/Gw switch<\/a> enables the linker to optimize global data to reduce binary size. As part of the 17.5 Preview 2 release a new flag, \/Zc:checkGwOdr[-]<\/code>,<\/em> has been added to improve C++ standards conformance when using \/Gw<\/code>. Previously, when using \/Gw<\/code>, certain One Definition Rule (ODR) violations were being ignored and would not cause an error. The new flag ensures that we do raise the appropriate errors. If you are currently using \/Gw<\/code> we recommend setting \/Zc:checkGwOdr<\/code> on your builds, as it\u2019s currently off by default. This may change in a future major update. For a more detailed explanation of ODR, \/Gw<\/code>, and how this issue came about, read on below.<\/p>\n

Let\u2019s go through three definitions that we need for background here:<\/p>\n

    \n
  1. First up are COMDATs, a short description is that COMDATs are extra segments that data can be placed in to enable the linker to potentially fold out said data from the binary. Importantly, these sections are flagged with a strategy for how duplicates are handled. For a deeper dive into the history of COMDATs, see Raymond\u2019s blog post which covers their use and history<\/a>.<\/li>\n
  2. Next, just what does \/Gw<\/code> do? For a full explanation, check out the blog post announcing the switch<\/a>, but for our purposes the flag enables the compiler to place global data into COMDATs. This lets us optimize out unreferenced globals, or merge identical globals via their COMDAT sections<\/li>\n
  3. Finally, the One Definition Rule (ODR) as described on Wikipedia<\/a>.<\/li>\n<\/ol>\n

    With the background out of the way we\u2019ll go through a simple but common enough example:<\/p>\n

    odr.h:<\/strong><\/p>\n

    #pragma once\r\n\/\/ defining a global here is an ODR violation\r\n\/\/ the initialization to 0 isn\u2019t required to cause a violation\r\n\/\/ but is needed to exhibit the incorrect \/Gw behavior\r\nint MyGlobal = 0;<\/code><\/pre>\n
    bar.cpp:<\/strong><\/p>\n
    #include \"odr.h\"\r\nint bar() {\r\n    return 2;\r\n}<\/code><\/pre>\n
    foo.cpp:<\/strong><\/p>\n
    #include \"odr.h\"\r\nint foo() {\r\n   return 1;\r\n}\r\n\r\nextern int bar();\r\n\r\nint main() {\r\n   foo();\r\n   bar();\r\n}\r\n<\/code><\/pre>\n
    Compiling this without \/Gw<\/code> leads to an error as we\u2019d expect:<\/p>\n
    cl \/nologo foo.cpp bar.cpp\r\nfoo.cpp\r\nbar.cpp\r\nGenerating Code...\r\nbar.obj : error LNK2005: \"int MyGlobal\" (?MyGlobal@@3HA) already defined in foo.obj\r\nfoo.exe : fatal error LNK1169: one or more multiply defined symbols found<\/code><\/pre>\n
    Since we defined MyGlobal<\/code> in odr.h<\/code>, we end up with a definition in both foo.obj<\/code> & bar.obj<\/code>, causing the linker to report the ODR violation. Now, if we compile with \/Gw<\/code>:<\/p>\n
    cl \/nologo \/Gw foo.cpp bar.cpp\r\nfoo.cpp\r\nbar.cpp\r\nGenerating Code...<\/code><\/pre>\n
    We don\u2019t end up with an error, so what happened? It ends up coming back to the COMDAT flags mentioned above. Looking at the obj headers, we can see that MyGlobal<\/code> has indeed been placed in a COMDAT:<\/p>\n
    link.exe \/dump \/headers foo.obj\r\n\u2026\r\nSECTION HEADER #3\r\n    .bss name\r\n    \u2026\r\nC0301080 flags\r\n         Uninitialized Data\r\n         COMDAT; sym= \"int MyGlobal\" (?MyGlobal@@3HA)\r\n         4 byte align\r\n         Read Write<\/code><\/pre>\n
    What this doesn\u2019t show is that this COMDAT has been flagged as PICKANY. So, when multiple definitions that would be candidates for merging are found the linker arbitrarily picks one of them and discards the rest. This is odd though, when \/Gw<\/code> is enabled this COMDAT was flagged with NOMATCH on creation. NOMATCH, as the name implies, means that the linker should raise an error if a duplicate is found, exactly what we want. So, what went wrong?<\/p>\n
    The key here is that the definition of MyGlobal<\/code> includes an assignment to zero. This causes another optimization to kick in. Since this global is initialized to zero, we notice that it can be moved into the .bss section<\/a>. Since we don\u2019t have to store the data for this global if it\u2019s in .bss<\/code>, moving the COMDAT lets us reduce the object file size. Unfortunately, when we move the COMDAT the flag was being reset from NOMATCH to PICKANY, causing our bug.<\/p>\n
    As of 17.5 Preview 2 you can now use the new flag to make sure you\u2019re not hiding these ODR violations on accident with \/Gw<\/code>:<\/p>\n
    cl \/nologo \/Gw \/Zc:checkGwOdr foo.cpp bar.cpp\r\nfoo.cpp\r\nbar.cpp\r\nGenerating Code...\r\nbar.obj : error LNK2005: \"int MyGlobal\" (?MyGlobal@@3HA) already defined in foo.obj\r\nfoo.exe : fatal error LNK1169: one or more multiply defined symbols found<\/code><\/pre>\n
    With the error exposed, we can make the global extern in our header, and move the definition to one of the cpp files to resolve the problem:<\/p>\n
    odr.h:\n<\/strong><\/p>\n
    #pragma once\r\nextern int MyGlobal;<\/code><\/pre>\n
    foo.cpp:<\/strong><\/p>\n
    #include \"odr.h\"\r\nint MyGlobal = 0;\r\n\u2026<\/code><\/pre>\n
    cl \/nologo \/Gw \/Zc:checkGwOdr foo.cpp bar.cpp\r\nfoo.cpp\r\nbar.cpp\r\nGenerating Code...<\/code><\/pre>\n
    Alternatively, for C++17 and higher, you can use an inline specifier<\/a> on the definition:<\/p>\n
    odr.h:<\/strong><\/p>\n
    inline int MyGlobal = 0;<\/code><\/pre>\n
    Usually fixing an ODR violation looks something like this, though not every case will be so simple. We encourage using \/Zc:checkGwOdr<\/code> to prevent these violations from creeping into your builds if you\u2019re using \/Gw<\/code>. As this is a standards conformance issue, we may change the default behavior of \/Gw<\/code> to imply \/Zc:checkGwOdr<\/code> in a future release.<\/p>\n
    Send us your feedback<\/h4>\n
    We hope you found these details interesting! If you have ideas for similar posts you\u2019d like to see, please let us know. We are also interested in your feedback to continue to improve our tools. The comments below are open. Feedback can also be shared through\u00a0Developer Community<\/a>. You can also reach us on Twitter (@VisualC<\/a>), or via email at\u00a0visualcpp@microsoft.com<\/a>.<\/p>\n
     <\/p>\n","protected":false},"excerpt":{"rendered":"
    The \/Gw switch enables the linker to optimize global data to reduce binary size. As part of the 17.5 Preview 2 release a new flag, \/Zc:checkGwOdr[-], has been added to improve C++ standards conformance when using \/Gw. Previously, when using \/Gw, certain One Definition Rule (ODR) violations were being ignored and would not cause an […]<\/p>\n","protected":false},"author":107351,"featured_media":35994,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-31355","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cplusplus"],"acf":[],"blog_post_summary":"
    The \/Gw switch enables the linker to optimize global data to reduce binary size. As part of the 17.5 Preview 2 release a new flag, \/Zc:checkGwOdr[-], has been added to improve C++ standards conformance when using \/Gw. Previously, when using \/Gw, certain One Definition Rule (ODR) violations were being ignored and would not cause an […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/31355","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/users\/107351"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/comments?post=31355"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/31355\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media\/35994"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media?parent=31355"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/categories?post=31355"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/tags?post=31355"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}