On Wed, 2 Aug 2017, Richard Sandiford wrote: > (1) Does the approach seem reasonable? > > (2) Would it be acceptable in principle to add this extension to the > GCC C frontend (only enabled where necessary)? > > (3) Should we submit this to the standards committee?
I think this only makes sense for WG14 in the context of a proposed standard feature that would use the new type properties. The CPLEX group, having produced the first draft TS 21938-1 (Extensions for parallel programming: Thread-based parallelism), may go on to other related work including SIMD-based parallelism. That might be the natural context for proposals related to vector types, both fixed-size and variable-size (see the discussion on the CPLEX list in June 2013, especially <http://www.open-std.org/pipermail/cplex/2013-June/000018.html> regarding types for native vector length rather than fixed vector length. (Or some kind of vector proposal could be made directly for C2x, given the widespread implementation experience with vector types.) I don't see how this proposal deals with initialization for such types (either by disallowing it, or by providing a suitable way to initialize them). A fixed-size vector can be initialized with a brace-enclosed initializer. But if you use a brace-enclosed initializer for a variable (with automatic storage duration) with one of these types, the compiler can't tell if the size is large enough at compile time. You allow compound literals and initialization because you want to allow aggregates of such types to be initialized, but that leaves unresolved the question of what's valid for initializing the vectors themselves. (The lack of a size from sizeof means memset and memcpy can't readily be used for initialization either; likewise e.g. reading data from a file into such a variable. Presumably you have other extensions to cover such things?) -- Joseph S. Myers jos...@codesourcery.com
