On Tue, 16 Sep 2014, Richard Biener wrote: > Hmm. How is it with other compositive types like vectors and complex? > It's bad that the middle-end needs to follow a specific frontends need. > Why's the representation tied so closely together?
Complex types aren't derived types in C terms; they don't have an element type, but a corresponding real type. Vectors should presumably be treated like complex types. So both can have qualifiers. > OTOH that address-spaces are "qualifiers" is an implementation detail > (and maybe not the very best). So I don't see how the C frontend > needs to view them as qualifiers? It's not an implementation detail, it's how TR 18037 defines them, and thus how the C front end should represent them in order to follow the requirements of TR 18037. If something different is appropriate on GIMPLE, when GIMPLE gets its own type system independent of trees then the lowering could of course change this sort of thing. (I think the fixed-point support, also from TR 18037, would better be implemented through lowering from fixed-point types at front-end level to special (e.g. saturating) operations on normal types and modes, rather than carrying a load of special types and modes through to the back end.) -- Joseph S. Myers jos...@codesourcery.com
