<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jun 5, 2013, at 8:09 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Wed, Jun 5, 2013 at 6:05 PM, Jordan Rose<span class="Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;"><div class="im"><br><div><div>On Jun 5, 2013, at 17:51 , Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:</div><br><blockquote type="cite">On Wed, Jun 5, 2013 at 5:19 PM, Anna Zaks<span class="Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:ganna@apple.com" target="_blank">ganna@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">Author: zaks<br>Date: Wed Jun 5 19:19:36 2013<br>New Revision: 183359<br><br>URL:<span class="Apple-converted-space"> </span><a href="http://llvm.org/viewvc/llvm-project?rev=183359&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=183359&view=rev</a><br>Log:<br>[analyzer] Fix a crash that occurs when processing an rvalue array.<br><br>When processing ArrayToPointerDecay, we expect the array to be a location, not a LazyCompoundVal.<br>Special case the rvalue arrays by using a location to represent them. This case is handled similarly<br>elsewhere in the code.<br></blockquote><div><br></div><div>Hmm, maybe we should be generating a MaterializeTemporaryExpr between the ImplicitCastExpr and the array temporary?</div></div></blockquote></div><br></div><div>Is there an array temporary? Or is the whole struct materialized?</div></div></blockquote><div><br></div><div>The whole struct. MaterializeTemporaryExpr materializes the complete object of which its operand is a subobject, per the rules of [class.temporary]p5. </div><div> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;">The analyzer's had to do this before (for compound literals), so I didn't think about the wider implications, but clearly at run time some sort of temporary allocation is needed.</div></blockquote><div><br></div><div>IR generation deals with this essentially by ignoring the value categories in the AST and emitting the getChars() call as an lvalue because it's used as an lvalue (this actually matches the odr-use rules quite nicely, despite not matching the rest of the language's rules). Constant expression evaluation deals with this by implicitly materializing a temporary when an array-to-pointer decay is performed on an array rvalue.</div><div><br></div><div>There is precedent for using MaterializeTemporaryExpr to take the address of a temporary. The -Waddress-of-temporary extension synthesizes a MaterializeTemporaryExpr in cases like this:</div><div><br></div><div> struct S {};</div><div> void f(S *p);</div><div> f(&S());</div></div></div></blockquote></div><br><div>It would be great not to have to special case these in neither the analyzer nor the other places.</div></body></html>