No, unfortunately it doesn't. The existing int parser returns "0" when it can't parse a string, and I'm currently allowing zero as a valid preferred alignment (which is the last element of the string in constant-fold-gep) for compatibility with existing behavior. The PR7357 case was caught when I disallowed zero sized integers.<div>
<br></div><div>This seems a bit ugly, but Dan has convinced me that tidying up TargetData is a bigger job that I'd realized, so I'm putting this work on the back burner until I've had more time to think about it.</div>
<div><br></div><div>- Lang.<br><div><br><div class="gmail_quote">On Mon, Oct 17, 2011 at 4:16 PM, Jakob Stoklund Olesen <span dir="ltr"><<a href="mailto:stoklund@2pi.dk">stoklund@2pi.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On Oct 17, 2011, at 3:14 PM, Lang Hames wrote:<br>
<br>
> Not quite. Apparently the shell lines in the lit suite are tcl, which doesn't honor the embedded quote. This led to the trailing quote being passed through in the target data layout string. The parser used to swallow this silently, treating the resulting 'n32"' as zero and discard it. The new verifier barfed on it though (as it should).<br>

<br>
</div>Does it also catch test/Other/constant-fold-gep.ll?<br>
<font color="#888888"><br>
/jakob<br>
<br>
</font></blockquote></div><br></div></div>