[cfe-dev] Huge arrays: how to represent their size?

[Serge Pavlov]

Agree, there is no point in features that cannot be used. The only excuse
for huge array support is that gcc supports them. If it is not a problem,
emitting an error looks as the best solution.


2013/7/15 David Chisnall <David.Chisnall at cl.cam.ac.uk>

> On 12 Jul 2013, at 19:38, Serge Pavlov <sepavloff at gmail.com> wrote:
>
> > Hi all,
> >
> > There are several bugs, manifested as a crash when clang treats really
> huge arrays (PRs 8256, 12816, 15216). The arrays are so huge that bit size
> cannot be represented by 64-bit integer.
> >
> > There are several ways to fix these defects.
> >
> > 1. Emit an error if the array size cannot be represented by 64-bit
> number. In this case changes to the clang sources are minimal. However some
> arrays accepted by GCC would be rejected.
> > 2. Use bytes to represent size and alignment of a type. It looks like
> values other than multiples of 8 aren't used.
> > 3. Represent the bit size by some new type, say BitUnits (similar to
> CharUnits). This type could allocate more space to represent all possible
> values of bit size, or use some encoding to pack any bit size into uint64_t
> (for instance to store the size in bytes, if it is larger that some value).
> >
> > Probably using bytes to represent size and alignment is the most natural
> way to fix these problems. Is there a need to keep size/alignment with bit
> precision?
> >
> > Any thoughts?
>
> What is the use case for this?  I am not aware of any existing platforms
> that support more than 2^56 bytes of virtual address space and so such an
> array would be impossible to represent in the TLB, let alone in physical
> memory.  I'd have thought that the correct solution would be for clang to
> emit a 'this array is bigger than your target platform can handle' error
> until someone brings out some hardware that actually supports 64-bit
> virtual address spaces.
>
> David
>
>


-- 
Thanks,
--Serge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130715/96473a79/attachment.html>