<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 4 February 2014 18:46, Jim Grosbach <span dir="ltr"><<a href="mailto:grosbach@apple.com" target="_blank">grosbach@apple.com</a>></span> wrote:<br><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>It’s coming from varying instantiations of things that all happen to go through the code path that has this terrible direct-to-errs() stuff. Those could honestly be changed to assertions and be more correct, imo.</div>
</div></div></blockquote><div><br></div><div>I concur. The back end hard failing on bogus input should help *develop* front-ends, not *hide* front-end bugs.</div><div><br></div><div><br></div><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"><span style="color:rgb(34,34,34)">As a backend guy, my immediate thought is that there should be an LLVM API to ask “for this target, is this a valid arch/cpu name?” That gets into a bit of a nasty circular problem, though, as when we’re parsing and validating the command line arguments, we don’t have an LLVM backend to ask that question of, so we can’t do that. The current implementation is to just duplicate the information in the front end and the backend. One could envision a helper library to abstract that out, but it’s a fair question whether that’d be worth the hassle/complexity. I suspect it would, but the front-end folks will have a more educated opinion on that topic.</span></div>
</div></div></blockquote><div></div></div><br></div><div class="gmail_extra">There was (again) the discussion on what to do about the driver regarding target support, and that's a fourth option I hadn't thought about. We should definitely move this issue to the Clang's list.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">--renato</div></div>