[cfe-dev] Miscompilation of sizeof

[David Blaikie]

On Mon, Dec 12, 2011 at 9:16 AM, Abramo Bagnara <abramo.bagnara at gmail.com>wrote:

> Il 12/12/2011 17:29, Reid Kleckner ha scritto:
> > Most people use clang with assertions disabled, so this doesn't really
> > solve the underlying problem.
>
> Yes, it helps only to realize the issue (consider that there is a
> pending issue in bugzilla submitted more than one year ago).
>

At a quick glance I couldn't find the bug you're referring to - what's the
bug number?


>
> I guess this has not been yet solved because it impacts on several things.
>
> This is the reason why I've proposed the patch: hiding the problem while
> code is miscompiled does not help anyone, perhaps if the problem is more
> visible it will be easy to find someone that will fix it.
>

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.


>
> Also to decide (once seen the issue) that type size should be evaluated
> in bytes and not in bits would help. However I don't know if this is
> acceptable... I've asked, but I got no answer about the reason why it
> was considered that to compute the size in bits was the right thing to do.
>

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).

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111212/c70888e5/attachment.html>