https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
--- Comment #74 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to rguent...@suse.de from comment #73)
>
> Ah, I remember seeing this. So this introduces object size as a way
> to allow some TBAA to happen. Specifically it forbids creating
> a series of float sub-objects inside a char[sizeof(float)*4] sub-object
> due to "there is no smaller array object that satisfies these
> constraints"(?). One would need to use sth like
>
> struct { unsigned char storage[sizeof(float)]; } st[4];
>
I think that is meant differently, but I am not sure if I
understand this kind of english good enough..., the sample uses:
template<typename ...T>
struct AlignedUnion {
alignas(T...) unsigned char data[max(sizeof(T)...)];
};
so that data array is max of sizeof(int) and sizeof(char)
... the more they write the less clear it becomes :)
> to work around that "limitation". Not if it's really possible to
> take advantage of that size restriction in alias analysis though...
>
> If we'd want to implement sth like this in the middle-end I'd suggest
> to force frontends to mark these storage areas in some way.
> In the C++ case all unsigned char arrays -- does the "array of N unsigned
> char"
> wording allow for struct C {} to be created within a unsigned char
> (no array!) member or has it to be unsigned char[1]?).
>
> I suggest sth like
>
> /* For an ARRAY_TYPE, indicates that when the dynamic type of the storage
> it provides differs from the declard type it is still valid to access
> it via the declared type or the type of a containing object. */
> #define ARRAY_TYPE_IS_STORAGE (NODE) \
> (ARRAY_TYPE_CHECK (NODE)->type_common.array_type_is_storage)
