This revision was automatically updated to reflect the committed changes.
Closed by commit rL272788: Don't use static variables in LambdaCapture
(authored by john.brawn).
Changed prior to commit:
http://reviews.llvm.org/D20732?vs=58787&id=60831#toc
Repository:
rL LLVM
http://reviews.llvm.or
jyknight accepted this revision.
jyknight added a comment.
This revision is now accepted and ready to land.
Fine with me.
Repository:
rL LLVM
http://reviews.llvm.org/D20732
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm
john.brawn added a comment.
In http://reviews.llvm.org/D20732#456239, @jyknight wrote:
> This looks okay. The only downside: it will increase sizeof(Decl) on 32bit
> platforms, since the layout is:
> vtable ptr (4)
> NextInContextAndBits ptr (4)
> DeclCtx ptr (4)
> Loc int (4)
> bitfield in
jyknight added a comment.
This looks okay. The only downside: it will increase sizeof(Decl) on 32bit
platforms, since the layout is:
vtable ptr (4)
NextInContextAndBits ptr (4)
DeclCtx ptr (4)
Loc int (4)
bitfield int (4)
Totaling 20 bytes, which will now be rounded up to 24 bytes. I don't know
john.brawn added a comment.
In http://reviews.llvm.org/D20732#452055, @faisalv wrote:
> I'm assuming you've given some thought to any existing pathological code that
> might break if the actual compile-time alignment of Decl itself is changed
> (since currently it seems to be that the alignment
faisalv added a comment.
Seems reasonable to me if we have the bit to spare. I wasn't a huge fan of the
sentinel approach - but i appreciated Richard showing me that trick. I don't
think I realized that Decl has to be aligned on an 8 byte boundary. I'm not
too familiar with the alignment gym
john.brawn added a comment.
Ping
Repository:
rL LLVM
http://reviews.llvm.org/D20732
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
