On Wed, Jun 5, 2013 at 6:05 PM, Jordan Rose <[email protected]> wrote:
> > On Jun 5, 2013, at 17:51 , Richard Smith <[email protected]> wrote: > > On Wed, Jun 5, 2013 at 5:19 PM, Anna Zaks <[email protected]> wrote: > >> Author: zaks >> Date: Wed Jun 5 19:19:36 2013 >> New Revision: 183359 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=183359&view=rev >> Log: >> [analyzer] Fix a crash that occurs when processing an rvalue array. >> >> When processing ArrayToPointerDecay, we expect the array to be a >> location, not a LazyCompoundVal. >> Special case the rvalue arrays by using a location to represent them. >> This case is handled similarly >> elsewhere in the code. >> > > Hmm, maybe we should be generating a MaterializeTemporaryExpr between the > ImplicitCastExpr and the array temporary? > > > Is there an array temporary? Or is the whole struct materialized? > The whole struct. MaterializeTemporaryExpr materializes the complete object of which its operand is a subobject, per the rules of [class.temporary]p5. > 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. > 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. 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: struct S {}; void f(S *p); f(&S());
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
