<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 12 May 2017 at 09:54, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div dir="ltr">On Thu, May 11, 2017 at 11:18 PM Boris Kolpackov <<a href="mailto:boris@codesynthesis.com" target="_blank">boris@codesynthesis.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi David,<br>
<br>
David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> writes:<br>
<br>
>   -Xclang -fmodules-codegen<br>
>   -Xclang -fmodules-debuginfo<br>
><br>
> [...]<br>
><br>
> It should work naturally either way, I think.<br>
<br>
Yep, all works now, thanks.<br>
<br>
Somewhat related question: what happens if I pass -fPIC? I assume I<br>
will need different .o for PIC/non-PIC. Will I also need different<br>
.pcm files?<br>
<br>
I tend to think the answer is yes since at the minimum -fPIC may<br>
define preprocessor macros that may change the translation unit.<br></blockquote></span><div><br>If a flag changes things like preprocessor macros then it would need to be consistently passed to all stages (including the first one - that generates the .pcm). I know Clang has some enforcement of matching flags between PCM generation steps and uses (& hopefully that also triggers on the PCM->Object step too, though I haven't checked).<br><br>I'm not sure how lenient those checks are (whether they have many false positives (flagging mismatched flags that are benign/can be composed without conflicting) or false negatives (allowing mismatched flags that are incompatible))<br><br>Richard might be able to say more about that.<br></div></div></div></blockquote><div><br></div><div>We have a bunch of flags whitelisted that are permitted to change between module build and use. We permit flags to change between module build and use if the flag change does not affect interoperability of the pcm file, even though in some cases the resulting combination doesn't make a lot of sense. For example, flags that affect predefined macros (__OPTIMIZE__, __PIC__, ...) *are* permitted to vary between module build and use, with each side seeing the value of the macro as it was defined for that compilation, and flags that affect minor details of the language mode are also permitted to vary.</div><div><br></div><div>The whitelist is likely incomplete (there are probably flags for which it would be useful and reasonable for them to differ between module build and use, but where we disallow them differing), and as noted above allows some combinations that work (we'll do what you asked us to do) but might not make a lot of sense.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>I think -O flags also generate preprocessor defines, so I expect they would be checked/enforced by this too, and not possible to use a PCM built with a different -O level than its use.<br> </div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I guess what I am trying to understand is if .pcm is just the AST<br>
or if it actually includes some object/intermediate code? For example,<br>
does it make sense to pass -O when generating .pcm? Sorry if these<br>
are stupid/obvious questions ;-).</blockquote></span></div></div></blockquote><div><br></div><div>In our default configuration, the .pcm file is just the AST (at least for now). We also have a mode in which the .pcm file is actually a .o file that contains the AST as well as debug information, and there's been some discussion of including other things in it too, for example LLVM IR for inline functions (to speed up optimized compilation of module users).</div><div><br></div><div>Even now, it makes sense to pass those flags, and as David says, the easiest thing to do is to pass the same flags you use for source compilations to module compilations. As an example of a case where this makes a difference today, the glibc headers will sometimes provide different definitions of C standard library functions based on whether the __OPTIMIZE__ macro is defined, and if you want the module build to take advantage of that, you need to make sure you pass -O<n> to the module compilation.</div><div><br></div><div>The intent is that the same set of flags would typically be passed to a compilation building the module interface for a particular module as would be passed to a compilation building the module interface. That way, the user can decide on a per-module basis how they want the compiler to act (including things like which warnings they want enabled for their module, and perhaps some details of the language it's written in).</div></div></div></div>