[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[bernd.edlinger at hotmail dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671

--- Comment #74 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to rguenther@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)