[llvm] r281990 - Emit S_COMPILE3 CodeView record

[Adrian Prantl via llvm-commits]

> On Sep 29, 2016, at 1:42 PM, Adrian McCarthy <amccarth at google.com> wrote:
> 
> Sorry about the trouble.  Fixed in r282761. 

thanks for the quick turnaround!

-- adrian
> 
> On Thu, Sep 29, 2016 at 1:16 PM, Adrian McCarthy <amccarth at google.com <mailto:amccarth at google.com>> wrote:
> Sure, I'll post a fix in a few minutes.  Running tests now...
> 
> On Thu, Sep 29, 2016 at 12:58 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:
> 
> > On Sep 20, 2016, at 10:20 AM, Adrian McCarthy via llvm-commits <llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>> wrote:
> > +
> > +  // Some Microsoft tools, like Binscope, expect a backend version number of at
> > +  // least 8.something, so we'll coerce the LLVM version into a form that
> > +  // guarantees it'll be big enough without really lying about the version.
> > +  Version BackVer = {
> > +      1000 * LLVM_VERSION_MAJOR +
> > +      10 * LLVM_VERSION_MINOR +
> > +      LLVM_VERSION_PATCH,
> > +      0, 0, 0 };
> > +  OS.AddComment("Backend version");
> > +  for (int N = 0; N < 4; ++N)
> > +    OS.EmitIntValue(BackVer.Part[N], 2);
> > +
> 
> This happens to break some of our internal buildbots. Some of them are configured to set LLVM_VERSION_MAJOR to 9999 which doesn't fit into the allocated 2 bytes when multiplied with 1000 and asserts in OS.EmitIntValue. Since we don't impose any limits on LLVM_VERSION_MAJOR it would be good to handle this gracefully here. Could you please take a look? I'm fine with clamping the number to 0xffff or something like that.
> 
> thanks!
> -- adrian
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160929/8d38b278/attachment.html>