<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>Hi,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I’m fairly new at poking around in llvm internals so if you find misconceptions / problems with the below let me know, this is just how I’ve understood this so far.  <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>When doing a build which uses functionality from LinkModules to combine bitcode from different versions of LLVM, or between LLVM-GCC (I know) and Clang,  I’ve noticed that multiple warnings which sometimes seem extraneous are generated because a direct string comparison is used to determine whether to warn.  The warnings are generated in llvm::ModuleLinker::run() <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>For example, it is possible to get a warning like: <br>WARNING: Linking two modules of different target triples: … :  armv5e-unknown-eabi and armv5e--unknown-eabi<o:p></o:p></p><p class=MsoNormal>That warning makes sense in theory because vendor / os are ambiguous in that triple, but the warning itself seems unnecessary because both seem to internally expand to “armv5e-unknown-unknown-eabi” in the current format.  <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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?  <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks,<o:p></o:p></p><p class=MsoNormal>Gordon Keiser<o:p></o:p></p><p class=MsoNormal>Software Development Engineer<o:p></o:p></p><p class=MsoNormal>Arxan Technologies, Inc.<o:p></o:p></p><p class=MsoNormal>1305 Cumberland Ave, Ste 215<o:p></o:p></p><p class=MsoNormal>West Lafayette, IN <o:p></o:p></p><p class=MsoNormal>47906<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>