<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:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";
        mso-fareast-language:EN-US;}
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";
        mso-fareast-language:EN-US;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
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-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>Hi Chandler,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The attached patch fixes a bug that could cause SROA to go into infinite recursion (stack overflow in debug mode, infinite loop in release mode).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The function findCommonType() attempts to use a type from a load/store inst, and if there are non-load-store instructions or their types do not match it falls back to trying to find an integral type that covers all uses. Otherwise, it should return failure (NULL).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The mechanism to fall back to integral types does not reset the “winning” type to NULL. This means that depending on the order in which the input uses are iterated over changes the output of the function. If a non-load-store instruction comes first, it will return NULL (as Ty is never set). If a load/store inst comes first, it will return the Ty of that instruction.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>There is no testcase as the bug depends on memory layout; I could not force it to fail with opt/llc.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Is it OK to commit?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Cheers,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>James<o:p></o:p></p></div></body></html>