<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Mar 11, 2008, at 9:47 PM, Patrick Meredith wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "> I thought pointer referencing like this was only valid for arrays. I could be wrong, but it might be that looping over the struct like that<div>is invalid, making it undefined behavior (and then the hole doesn't matter because there is no valid way to access it). That said, I've definitely</div><div>seen a lot of code that uses pointers to reference struct contents.</div></div></blockquote><div><br class="webkit-block-placeholder"></div><div>Anything can be addressed as characters. C99 6.5, see last line:</div><div><br class="webkit-block-placeholder"></div><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Times; ">An object shall have its stored value accessed only by an lvalue expression that has one of<span style="font: 12.0px Helvetica"> </span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Times; ">the following types:<span style="font: 9.0px Times">73)</span><span style="font: 12.0px Helvetica"> </span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Times; ">—atype compatible with the effective type of the object,<span style="font: 12.0px Helvetica"> </span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Times; ">—aqualified version of a type compatible with the effective type of the object,<span style="font: 12.0px Helvetica"> </span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Times; ">—atype that is the signed or unsigned type corresponding to the effective type of the<span style="font: 12.0px Helvetica"> </span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Times; ">object,<span style="font: 12.0px Helvetica"> </span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Times; ">—atype that is the signed or unsigned type corresponding to a qualified version of the<span style="font: 12.0px Helvetica"> </span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Times; ">effective type of the object,<span style="font: 12.0px Helvetica"> </span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Times; ">—anaggregate or union type that includes one of the aforementioned types among its<span style="font: 12.0px Helvetica"> </span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Times; ">members (including, recursively,amember of a subaggregate or contained union), or<span style="font: 12.0px Helvetica"> </span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Times; ">—a character type.<span style="font: 12.0px Helvetica"> </span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Times; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Times; ">C89 and C++ have similar language.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Times; "><br class="webkit-block-placeholder"></div><div>On Mar 11, 2008, at 10:22 PM, Shantonu Sen wrote:<div></div><blockquote type="cite"><div>Does the test case indicate the why it was added?</div></blockquote><div><br class="webkit-block-placeholder"></div><div>Actually it's testing something else entirely and tripped over this before it got to what it's supposed to be testing:(</div>Just assumed it would work, as it does with gcc's codegen, of course.</div><div><br><blockquote type="cite"><div>More of an implementation observation than a language interpretation, but if you add a "long l[6];" field, llvm-gcc continues to do field-by-field copies, but at l[7] it turns into machine-word copies, then at some point it turns into a rep/movsl (on Intel), and then at another threshold it turns into a memcpy(3) callout.</div><div><br></div><div>What part of LLVM's codegen for copying "struct x { char c; short s; long l[6] };" considers a movb + movw + 6 movl's to efficient in either time or space (I was using -Os)? What changes when the overall structure gets to 64 bytes such that it decides its more efficient to copy a word at a time?</div></blockquote><div><br class="webkit-block-placeholder"></div><div>Yeah, it's not efficient either. I didn't want to get into that since fixing the correctness issue, if there is one, will automatically fix this too.</div><div>I think the justification is that breaking the struct into fields early makes it easier to do other optimizations.</div><div><br></div><blockquote type="cite"><div>I think the test case is bogus in terms of language correctness, </div></blockquote><div><br class="webkit-block-placeholder"></div><div>Why?</div><br><blockquote type="cite"><div>but it might be indicative of a missed optimization for doing structure copies. Is that what GCC's test case is actually trying to validate? If so, it probably falls under a "gcc test case" and not a "C test case", if one can differentiate them.</div></blockquote><div><br class="webkit-block-placeholder"></div><div>There certainly are "gcc test cases", but so far I don't think this is one.</div><br><blockquote type="cite"><div>Maybe it would be reasonable for llvm-gcc to NOT copy the padding at -O0 and do explicit field copies, but to copy the padding as a side effect of an inlined memcpy() implementation for copying sizeof(struct x) when optimization is used. Copying using the largest appropriate registers/instructions given the structure size and alignment seems like it would always be faster than field copies, even for small structures.</div></blockquote><div><br></div></div><div><br></div></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><div>On Mar 11, 2008, at 10:42 PM, Dale Johannesen wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Looking through the gcc testsuite turned up an interesting edge case. Let's assume our target leaves a hole for alignment in struct x, as do x86 and powerpc. Do you think the following code can validly abort?</div><div><br class="webkit-block-placeholder"></div><div><div> struct x { char c; short s; };</div><div> int i; char *p;</div></div><div> memset(&X, 0, sizeof(struct x));</div><div> memset(&Y, 22, sizeof(struct x));</div><div> X = Y;</div><div> for (i=0, p=(char *)&X; i<sizeof(struct x); i++, p++)</div><div> if (*p != 22)</div><div> abort();</div><div><br></div></blockquote></div></div></div></blockquote></div></body></html>