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

[Chris Lattner]

I agree, we should definitely just emit an error on them for now.

-Chris

On Jul 15, 2013, at 4:24 AM, Serge Pavlov <sepavloff at gmail.com> wrote:

> 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
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

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