<html><head><base href="x-msg://804/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Feb 18, 2012, at 11:30 PM, Gordon Keiser wrote:</div><blockquote type="cite"><span class="Apple-style-span" style="font-family: Calibri, sans-serif; font-size: 15px; ">Something similar happens with iOS targets because they contain a version in the OS part of the string, so multiple warnings are generated about “armv6-apple-ios4.0.0” and “armv6-apple-ios4.0.1” and similar, which isn’t really desirable most of the time. Even whether the arm version part of the string matters is kind of questionable given that bitcode for armv6 shouldn’t contain anything that would make it fail with armv7, right?</span></blockquote><div><br></div><div>Yes, I agree. This is overly annoying and not super useful. It will be hard to figure out how to subset this though.</div><br><blockquote type="cite"><span class="Apple-style-span" style="font-family: Calibri, sans-serif; font-size: 15px; ">This happens with the warning about module data layouts as well, where, (again from the eabi example above) a warning can be displayed about two layouts which are identical except for one explicitly listing stack function minimum stack alignment (-S64) at the end of the string. Stack alignment should be implied to be 64 by eabi though, so the triple implies that part unless it is overridden for some reason. There’s a very good chance I’m not understanding something here, but this should only matter once everything is lowered to machine code / assembly, no? </span><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1" style="page: WordSection1; "><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p></o:p></div></div></div></span></blockquote></div><font class="Apple-style-span" face="Calibri, sans-serif"><span class="Apple-style-span" style="font-size: 15px;"><br></span></font><div><font class="Apple-style-span" face="Calibri, sans-serif"><span class="Apple-style-span" style="font-size: 15px;">This actually is correct behavior. TargetData is not a request by a frontend for the target to do something: it is required to match what the target expects. If a frontend isn't providing the right string, bad things will happen. That said, we do want old .bc files to work with new versions of LLVM, so perhaps we should tolerate *missing* pieces like this better.</span></font></div><div><font class="Apple-style-span" face="Calibri, sans-serif"><span class="Apple-style-span" style="font-size: 15px;"><br></span></font></div><div><font class="Apple-style-span" face="Calibri, sans-serif"><span class="Apple-style-span" style="font-size: 15px;">-Chris</span></font></div></body></html>