<div dir="ltr">Hi Richard,<br><br>(Lang, you're here because I mentioned stumbling across this on Friday in ORC - this is the reduced test case (where 't' is the NameMutex member and 'nt' is the Name member))<br><br>Working on getting all LLVM binaries linking successfully under modular codegen, I've hit something that seems it'll need a bit more feature work (which I'm happy/planning to do myself - though always happy for help/advice/etc)... <br><br>The test case I have boils down to the following modular header:<br><font face="monospace"><br></font><div><font face="monospace">  struct trivial {};</font></div><div><font face="monospace">  struct nontrivial { nontrivial(); };</font></div><div><font face="monospace">  // namespace foo {</font></div><div><font face="monospace">  void sink(void *);</font></div><div><font face="monospace">  template <typename T> struct bar {</font></div><div><font face="monospace">    static void baz() {</font></div><div><font face="monospace">      sink(&t);</font></div><div><font face="monospace">      sink(&nt);</font></div><div><font face="monospace">    }</font></div><div><font face="monospace">    static trivial t;<br></font><div><font face="monospace">    static nontrivial nt;</font></div><div><font face="monospace">  };</font></div><div><font face="monospace">  template <typename T> trivial bar<T>::t;</font></div><div><font face="monospace">  template <typename T> nontrivial bar<T>::nt;</font></div><div><font face="monospace">  //} // namespace foo</font></div><div><font face="monospace">  template struct bar<int>;</font></div><div><font face="monospace">  // inline void use() { (void)bar<int>::baz(); }</font><br><br>To build with modular codegen:<br><br><font face="monospace">  $ echo 'module foo { header "foo.h" }' > foo.cppmap<br>  $ clang++ -cc1 -xc++ -emit-module -fmodules -w -fmodule-name=foo foo.cppmap -o foo.pcm -fmodules-codegen <br></font><br>So here are some interesting facts I know, some of which may be relevant, some of which may not:<br><ol><li> Code as written ends up with <font face="monospace" color="#660000">linkonce_odr</font> definitions for <font face="monospace" color="#660000">t</font> and <font face="monospace" color="#660000">nt</font><br></li><li>Use <font face="monospace" color="#660000">use</font> instead of the explicit instantiation and are both <font face="monospace" color="#660000">t</font> and <font face="monospace" color="#660000">nt</font> are only declarations</li><li>Add the outer namespace <font face="monospace">foo</font> and then <font face="monospace" color="#660000">t</font> is emitted as a <font face="monospace" color="#660000">linkonce_odr</font> definition and <font face="monospace" color="#660000">nt</font> is emitted as a declaration</li></ol>That last one (which was the first result I got) really confuses me - any ideas why a namespace would change the behavior here?<br><br><br>In any case, all those mysteries/differences in behavior might be aside to actually fixing the behavior here, which is what this email is really about.<br><br>This is basically the same problem as inline variables, and maybe even would allow some support for static variables in headers too (not sure, will see).<br><br>Any ideas what the behavior should be here? Since there's a desire not to run all global initializers if their specific submodule header isn't included in the program (for iostream's sake), how would this be done correctly under modular codegen?<br>My initial thought is potentially to defer the global initializers to the includers (that seems necessary to get the lazy/only-those-included behavior, right?) But that may not account for indirect inclusion? I guess that's already handled somehow for the iostreams non-modular case, so maybe it works.<br><br>& then the modular object file would perhaps have the weak_odr definition of the global variable itself, but no global initializer - depending on any live codepaths that reference the global necessarily requiring the using TU to have caused the initializer to run? That seems vaguely concerning... <br><br>Is this making sense? Any good ideas? Pointers to where to start, etc?<br><br>Thanks,<br>- Dave<br><br></div></div></div>