<br><br><div class="gmail_quote">On Mon, Dec 12, 2011 at 9:16 AM, Abramo Bagnara <span dir="ltr"><<a href="mailto:abramo.bagnara@gmail.com">abramo.bagnara@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
Il 12/12/2011 17:29, Reid Kleckner ha scritto:<br>
<div class="im">> Most people use clang with assertions disabled, so this doesn't really<br>
> solve the underlying problem.<br>
<br>
</div>Yes, it helps only to realize the issue (consider that there is a<br>
pending issue in bugzilla submitted more than one year ago).<br></blockquote><div> </div><div>At a quick glance I couldn't find the bug you're referring to - what's the bug number?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">

<br>
I guess this has not been yet solved because it impacts on several things.<br>
<br>
This is the reason why I've proposed the patch: hiding the problem while<br>
code is miscompiled does not help anyone, perhaps if the problem is more<br>
visible it will be easy to find someone that will fix it.<br></blockquote><div> </div><div>I tend to agree - at least having the assert gives some uses some value until the bug is addressed if it's been around for this long. Adding a FIXME next to the assert so it's clear that it's just temporary (possibly even referring to the bug number - I'm not sure if LLVM/Clang coding conventions have rules around whether to avoid or prefer referring to specific bug numbers in the production code). It'd make it easier to diagnose duplicates of the bug, for example - simply by running the code against a debug build.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<br>
Also to decide (once seen the issue) that type size should be evaluated<br>
in bytes and not in bits would help. However I don't know if this is<br>
acceptable... I've asked, but I got no answer about the reason why it<br>
was considered that to compute the size in bits was the right thing to do.<br></blockquote><div> </div><div>I haven't looked closely - but I expect one of the reasons that sizes are handled in bits is for codegen to LLVM IR which represents the size of types in bits (eg: a Boolean value can be represented as an 'i1'). I don't know whether LLVM IR has limitations on the size of its types (eg: if LLVM itself parses these sizes & stores them in uint64s too - in which case the size of your array may be too big to even be described in current LLVM IR which would seem... problematic). </div>
<div> </div><div>- David</div></div>