<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="im">
<blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><br></div></div><div>It would be isolated to target-specific logic in target-specific parts of the toolchain instead of inventing a new option that's basically "do what PNaCl wants" and then propagating it through the entire compiler.</div>

</div></blockquote><div><br></div><div>Clang currently supports le32 as a target. So it's not an issue of a single "driver wrapper". We purposefully keep PNaCl as open as possible, and other developers and toolchain writers may use this target to generate PNaCl bitcode or something similar with Clang.</div>
</div></div></div></blockquote><div><br></div></div>I'm not asking you to wrap the driver.  I'm asking you to change clang's driver logic when targeting *-*-nacl to use the existing logic to suppress builtin treatment of functions.</div>
</div></blockquote><div><br></div><div>OK, I'll take a look at the driver logic and try to see if I can come up with an alternative patch.</div><div><br></div><div>Eli</div><div><br></div><div><br></div><div><br></div>
<div> </div></div><br></div></div>