Re: targetm.vectorize.builtin_vec_perm
Richard Henderson wrote on 17/11/2009 03:39:42:
> Richard Henderson
> 17/11/2009 03:39
>
> To
>
> Ira Rosen/Haifa/i...@ibmil
>
> cc
>
> gcc@gcc.gnu.org
>
> Subject
>
> targetm.vectorize.builtin_vec_perm
>
> What is this hook supposed to do? There is no description of its
arguments.
>
> What is the theory of operation of permute within the vectorizer? Do
> you actually need variable permute, or would constants be ok?
It is currently used for a specific load permutation of RGB to YUV
conversion (http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00445.html). The
arguments are vector type and mask type (the last one is returned by the
hook).
The permute is constant, it depends on the number of loads (group size) and
their type. However, there are cases, that we may want to support in the
future, that require variable permute - indirect accesses, for example.
>
> I'm contemplating adding a tree- and gimple-level VEC_PERMUTE_EXPR of
> the form:
>
>VEC_PERMUTE_EXPR (vlow, vhigh, vperm)
>
> which would be exactly equal to
>
>(vec_select
> (vec_concat vlow vhigh)
> vperm)
>
> at the rtl level. I.e. vperm is an integral vector of the same number
> of elements as vlow.
>
> Truly variable permutation is something that's only supported by ppc and
> spu.
Also Altivec and SPU support byte permutation (and not only element
permutation), however, the vectorizer does not make use of this at present.
> Intel AVX has a limited variable permutation -- 64-bit or 32-bit
> elements can be rearranged but only within a 128-bit subvector.
> So if you're working with 128-bit vectors, it's fully variable, but if
> you're working with 256-bit vectors, it's like doing 2 128-bit permute
> operations in parallel. Intel before AVX has no variable permute.
>
> HOWEVER! Most of the useful permutations that I can think of for the
> optimizers to generate are actually constant. And these can be
> implemented everywhere (with varying degrees of efficiency).
>
> Anyway, I'm thinking that it might be better to add such a general
> operation instead of continuing to add things like
>
>VEC_EXTRACT_EVEN_EXPR,
>VEC_EXTRACT_ODD_EXPR,
>VEC_INTERLEAVE_HIGH_EXPR,
>VEC_INTERLEAVE_LOW_EXPR,
>
> and other obvious patterns like broadcast, duplicate even to odd,
> duplicate odd to even, etc.
If the back end will be able to identify specific masks, e.g., {0,2,4,6} as
extract even operation, then we can certainly remove those codes.
>
> I can imagine having some sort of target hook that computed a cost
> metric for a given constant permutation pattern. For instance, I'd
> imagine that the interleave patterns are half as expensive as a full
> permute for altivec, due to not having to load a mask. This hook would
> be fairly complicated for x86, given all of the permuting insns that
> were incrementally added in various ISA revisions, but such is life.
>
> In any case, would a VEC_PERMUTE_EXPR, as described above, work for the
> uses of builtin_vec_perm within the vectorizer at present?
Yes.
Ira
>
>
> r~
Re: targetm.vectorize.builtin_vec_perm
> > I can imagine having some sort of target hook that computed a cost > > metric for a given constant permutation pattern. For instance, I'd > > imagine that the interleave patterns are half as expensive as a full > > permute for altivec, due to not having to load a mask. This hook would > > be fairly complicated for x86, given all of the permuting insns that > > were incrementally added in various ISA revisions, but such is life. > > There should be some way to account for the difference between the cost > in straight-line code, where a mask load is a hard cost, a large loop, > where the load can be hoisted at the cost of some target-dependent > register pressure (e.g. being able to use inverted masks might save half > of the cost), and a tight loop, where the constant load can be easily > amortized over the entire loop. Vectorizer cost model already does that. AFAIU, vectorizer cost model will call the cost model hook to get a cost of a permute, and then incorporate that cost into the general loop/basic block vectorization cost. Ira
RE: gcc Digest 16 Nov 2009 18:04:16 -0000 Issue 6154
Hi, I'm new to GCC and was wondering if anyone has done work on a back end for small micros such as microchip PICs? It is something I'd like to work on but would like to know if there are any reasons why GCC only appears to have back ends for larger format CPUs. Thanks Adrian
Re: targetm.vectorize.builtin_vec_perm
...
>
> >
> > I'm contemplating adding a tree- and gimple-level VEC_PERMUTE_EXPR of
> > the form:
> >
> >VEC_PERMUTE_EXPR (vlow, vhigh, vperm)
> >
> > which would be exactly equal to
> >
> >(vec_select
> > (vec_concat vlow vhigh)
> > vperm)
> >
> > at the rtl level. I.e. vperm is an integral vector of the same number
> > of elements as vlow.
> >
> > Truly variable permutation is something that's only supported by ppc
and
> > spu.
>
> Also Altivec and SPU support byte permutation (and not only element
> permutation), however, the vectorizer does not make use of this at
present.
>
Yes. I was trying to think if it would be useful to express
byte-permutations instead of element-permutations, but the only two useful
cases that came to mind are things we have covered by other, probably more
appropriate, idioms.
[One is realignment (for which we use the builtin_mask_for_load +
REALIGN_LOAD). The other is the VEC_PACK_TRUNC idiom (where the number of
elements in 'vperm' would be twice the number of elements as 'vlow'), but
other VEC_PACK variants are a little more than just a special case of
permute.]
So (unless we want VEC_PERMUTE to cover these cases, which I think we
don't), an element-wise permutations should suffice, so sounds like a good
suggestion to me.
> > Intel AVX has a limited variable permutation -- 64-bit or 32-bit
> > elements can be rearranged but only within a 128-bit subvector.
> > So if you're working with 128-bit vectors, it's fully variable, but if
> > you're working with 256-bit vectors, it's like doing 2 128-bit permute
> > operations in parallel. Intel before AVX has no variable permute.
> >
> > HOWEVER! Most of the useful permutations that I can think of for the
> > optimizers to generate are actually constant. And these can be
> > implemented everywhere (with varying degrees of efficiency).
> >
That's true for the moment, but there are cases where a variable permute
would be useful for vectorization. E.g. where vectors are used as a lookup
table. One example I know of is for finding delimiters (e.g. for XML
processing) - a lookup table of 256 bits holds one bit per ASCII character
to indicates if a character is a delimiter or not, and the scalar code
looks something like this:
table[256]={1,0,0,};
for (i...)
if (table[data[i]] == 1)
{found delimiter}
...and this is vectorized with 2 vector registers that hold the lookup
table and a shift on the input data vector to create the permutation mask
to access the table. I think there should be other examples for lookup
tables like that used for vectorization. I also saw variable permutes used
for sorting (
http://www.dia.eui.upm.es/asignatu/pro_par/articulos/AASort.pdf).
Indeed there are some serious challenges to overcome in order to do all
that automatically in the compiler... but some pattern-matching based
vectorization approach could conceptually do this.
Also, if one day someone was to introduce platform-independent vector
intrinsics, then such a generic permute would allow programmers to take
advantage of it, even for the cases that would be otherwise too complicated
for the compiler to auto-vectorize.
So I think it would be nice to allow the more general form, but since it
will probably take a while before we actually make use of it, it's probably
not critical for the short term...
> > Anyway, I'm thinking that it might be better to add such a general
> > operation instead of continuing to add things like
> >
> >VEC_EXTRACT_EVEN_EXPR,
> >VEC_EXTRACT_ODD_EXPR,
> >VEC_INTERLEAVE_HIGH_EXPR,
> >VEC_INTERLEAVE_LOW_EXPR,
> >
> > and other obvious patterns like broadcast, duplicate even to odd,
> > duplicate odd to even, etc.
>
agreed
> If the back end will be able to identify specific masks, e.g., {0,2,4,6}
as
> extract even operation, then we can certainly remove those codes.
>
agreed
dorit
> >
> > I can imagine having some sort of target hook that computed a cost
> > metric for a given constant permutation pattern. For instance, I'd
> > imagine that the interleave patterns are half as expensive as a full
> > permute for altivec, due to not having to load a mask. This hook would
> > be fairly complicated for x86, given all of the permuting insns that
> > were incrementally added in various ISA revisions, but such is life.
> >
> > In any case, would a VEC_PERMUTE_EXPR, as described above, work for the
> > uses of builtin_vec_perm within the vectorizer at present?
>
> Yes.
>
> Ira
>
> >
> >
> > r~
>
Re: gcc Digest 16 Nov 2009 18:04:16 -0000 Issue 6154
"Adrian Wadey" writes: > I'm new to GCC and was wondering if anyone has done work on a back end for > small micros such as microchip PICs? It is something I'd like to work on > but would like to know if there are any reasons why GCC only appears to have > back ends for larger format CPUs. People have written backends for relatively small processors such as the H8. In general it depends on how small is small. Often very small processors are not particularly orthogonal and have few registers, and it is hard for gcc to generate code which is better than hand-coded assembler. In particular, given the small amounts of memory available for small processors, it's hard for gcc to generate code which is smaller than hand-coded assembler. gcc is inherently tuned to generate code code for an orthogonal processor with lots of registers. The more a processor deviates from the model, the harder you have to work to get good code. Ian
[variadic templates]feature request: n-th element of expansion
As mentioned in a post of comp.std.c++:
http://preview.tinyurl.com/yaqvnnq
there's a need for some way to get the nth element of a pack
expansion. For example, boost::mpl::arg:
http://www.boost.org/doc/libs/1_40_0/libs/mpl/doc/refmanual/arg.html
wouldn't need the preprocessor for its implementation. Instead, using
something like the following grammar production:
get-nth-expansion-element:
expansion-pattern '...[' constant-expression ']'
where:
expansion-pattern is the "pattern of the expansion" described
on p. 327 of:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf
constant-expression is defined here:
http://www.csci.csusb.edu/dick/c++std/cd2/gram.html#gram.expr
then boost::mpl::arg would be simply implemented as:
template< int n > struct arg
{
template< typename A...>
struct apply
{
typedef A...[n] type;
};
};
where:
A is parsed as a expansion-pattern.
n is parsed as a constant-expression.
Could g++ provide this feature? How hard would it be to implement. I
would think it would just involve defining a new token:
...[
and then, wherever a expansion-pattern is currently parsed, this
would be followed by a test for whether the next token
is:
...
or:
...[
TIA.
-regards,
Larry
RE: [plugins-ici-cloning-instrumentation] new GCC plugin developements
Just one more issue to mention (particularly for those who have been writing ICI plugins). ICI sometime has been using environment variables inside GCC with its own invocation flags (-fici) and dynamic library loading. Naturally, Joern will remove duplicate dynamic library handling and invocation flags from ICI to use the plugin functionality from GCC 4.5. As for environment variables inside GCC - we needed it for transparent program analysis and optimizations but I remember that there were several concerns about that (I think Richard mentioned several times that it complicated debugging if there are problems), so we will remove them too. We will use current plugin flags to pass parameters to the plugins (we can pass a configuration file I guess that will be parsed by our plugins if there is lots of information to pass) and if we need to do transparent program analysis and optimization we will use a script and a wrapper around GCC that translated our environment variables into flags. I already did that recently for MILEPOST GCC so it should be easy. But for now we assume that it's fine to use environment variables (such as to control verbose output or pass some parameters) in plugins themselves ... However, eventually we should also use some configuration files for plugins that can be easily shared with the community if there is a bug in plugins ... Cheers, Grigori
RFC: PR 25137: moving -Wmissing-braces to -Wextra?
Hi,
I'm trying to resolve one way or another this PR, which I have assigned
to myself a long time ago... The issue essentially is very simple. This
kind of code:
struct S { int s[3]; };
struct S s1 = { 1, 1, 1 };
triggers a warning with -Wall about missing braces around initializer,
which some people consider a bit overzealous, in particular in
relationship with std::array (std::tr1::array).
Today, I was comparing GCC to ICC and SunStudio and noticed that, please
correct me if I'm wrong about the details:
- ICC: lacks completely an equivalent of -Wmissing-braces, never warns.
- SunStudio: only warns with +w2, doesn't warn with +w.
Therefore, my idea to resolve 25137 and make progress in this area would
be moving -Wmissing-braces from -Wall to -Wextra: the corresponding
patch, as expected, is trivial, and it would be for me only matter to
tweak the testsuites a bit (A refinement of that proposal would be doing
the change only for the C++ front-end)
Suggestions, other proposals?
Thanks,
Paolo.
Re: RFC: PR 25137: moving -Wmissing-braces to -Wextra?
Paolo Carlini wrote: > Therefore, my idea to resolve 25137 and make progress in this area would > be moving -Wmissing-braces from -Wall to -Wextra: the corresponding > patch, as expected, is trivial, and it would be for me only matter to > tweak the testsuites a bit (A refinement of that proposal would be doing > the change only for the C++ front-end) I don't really have an opinion. Almost all warnings are sometimes overzealous (if they weren't, they would be errors!), so I find deciding where to put things very hard. It's made harder by the fact that people only complain about what they don't like, so we don't know how many people are benefiting from it being where it currently is, but will complain after we move it. All that leads me to a conservative position: I'd recommend we just leave it alone. People who don't like it can always pass -Wno-missing-braces. But, that's not a position I'd argue for strongly. Whatever we do, I think the C and C++ front-ends should have the same behavior. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: targetm.vectorize.builtin_vec_perm
On 11/16/2009 06:37 PM, Joern Rennecke wrote: Variable permutations could be very useful for doing vector operations on unaligned inputs. To some degrees shifts can be used, but if they only have C semantics you'll get corner cases with word-sized shifts when the input is actually aligned. I'm assuming at this point that generic code will (continue to) use the MISALIGNED_INDIRECT_REF operation to load-and-realign such inputs. The ppc port does in fact use its variable permutation insn to implement this instruction. This special case is fairly important for targets that don't implement the fully general variable permute. (Curiously, the spu port fails to implement movmisalign.) r~
I want to use C and C + +
hello, I downloaded "gcc-4.4.2.tar.gz" and it's first time I use GCC, I do not know how to install it on windows vista. I want to use C and C + + cordialy _ Tchattez en direct en en vidéo avec vos amis ! http://www.windowslive.fr/messenger/
Re: I want to use C and C + +
2009/11/17 abdelali ghoulam: > > I downloaded "gcc-4.4.2.tar.gz" and it's first time I use GCC, I do not know > how to install it on windows vista. > I want to use C and C + + This mailing list is for discussing development of gcc, not how to install or use it, you should ask on the gcc-h...@gcc.gnu.org list. http://gcc.gnu.org/install/binaries.html gives links to relevant projects.
Re: I want to use C and C + +
abdelali ghoulam wrote: hello, I downloaded "gcc-4.4.2.tar.gz" and it's first time I use GCC, I do not know how to install it on windows vista. I want to use C and C + + cordialy _ Tchattez en direct en en vidéo avec vos amis ! http://www.windowslive.fr/messenger/ correct me if I'm wrong, but doesn't windows have their own compiler? Justin P. Mattock
Re: RFC: PR 25137: moving -Wmissing-braces to -Wextra?
Paolo Carlini writes:
> I'm trying to resolve one way or another this PR, which I have assigned
> to myself a long time ago... The issue essentially is very simple. This
> kind of code:
>
> struct S { int s[3]; };
> struct S s1 = { 1, 1, 1 };
>
> triggers a warning with -Wall about missing braces around initializer,
> which some people consider a bit overzealous, in particular in
> relationship with std::array (std::tr1::array).
>
> Today, I was comparing GCC to ICC and SunStudio and noticed that, please
> correct me if I'm wrong about the details:
>
> - ICC: lacks completely an equivalent of -Wmissing-braces, never warns.
> - SunStudio: only warns with +w2, doesn't warn with +w.
>
> Therefore, my idea to resolve 25137 and make progress in this area would
> be moving -Wmissing-braces from -Wall to -Wextra: the corresponding
> patch, as expected, is trivial, and it would be for me only matter to
> tweak the testsuites a bit (A refinement of that proposal would be doing
> the change only for the C++ front-end)
The point of -Wmissing-braces is to warn if you if you are not
initializing the fields you think you are. Given that, I tend to feel
that -Wmissing-braces is doing the right thing, and I tend to feel
that it should be in -Wall.
I could see a counter-argument for special cases like the above, but
then we have to start enumerating special cases.
I don't really understand how this interacts with std::tr1:array,
though.
Ian
Re: RFC: PR 25137: moving -Wmissing-braces to -Wextra?
2009/11/17 Ian Lance Taylor:
>
> I don't really understand how this interacts with std::tr1:array,
> though.
For it to be a more convenient drop-in replacement for builtin arrays
you want to initialise tr1::array like so:
std::tr1::array a = { 0, 1, 2 };
rather than
std::tr1::array a = { { 0, 1, 2 } };
but the former gives the warning.
Re: RFC: PR 25137: moving -Wmissing-braces to -Wextra?
Jonathan Wakely writes:
> 2009/11/17 Ian Lance Taylor:
>>
>> I don't really understand how this interacts with std::tr1:array,
>> though.
>
> For it to be a more convenient drop-in replacement for builtin arrays
> you want to initialise tr1::array like so:
>
> std::tr1::array a = { 0, 1, 2 };
>
> rather than
>
> std::tr1::array a = { { 0, 1, 2 } };
>
> but the former gives the warning.
OK, to me that seems like an excellent reason to implement a special
case for the warning here. For example, perhaps if a struct has only
one field, and that field is an aggregate, then we don't warn if there
is only one set of braces.
Ian
Re: RFC: PR 25137: moving -Wmissing-braces to -Wextra?
Ian Lance Taylor wrote: > OK, to me that seems like an excellent reason to implement a special > case for the warning here. For example, perhaps if a struct has only > one field, and that field is an aggregate, then we don't warn if there > is only one set of braces. > Sure, we considered that, you can find traces of that reasoning in the audit trail, then lately I noticed the ICC and SunStudio behaviors, and that idea appeared to me a tad too sophisticated... but if people agree, I can return to it. Do you think that version of the warning should be simply the default, right, simply the new behavior of -Wmissing-braces? Paolo.
gcc-4.4-20091117 is now available
Snapshot gcc-4.4-20091117 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20091117/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 154272 You'll find: gcc-4.4-20091117.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20091117.tar.bz2 C front end and core compiler gcc-ada-4.4-20091117.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20091117.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20091117.tar.bz2 C++ front end and runtime gcc-java-4.4-20091117.tar.bz2 Java front end and runtime gcc-objc-4.4-20091117.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20091117.tar.bz2The GCC testsuite Diffs from 4.4-20091110 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: RFC: PR 25137: moving -Wmissing-braces to -Wextra?
Paolo Carlini writes: > Ian Lance Taylor wrote: >> OK, to me that seems like an excellent reason to implement a special >> case for the warning here. For example, perhaps if a struct has only >> one field, and that field is an aggregate, then we don't warn if there >> is only one set of braces. >> > Sure, we considered that, you can find traces of that reasoning in the > audit trail, then lately I noticed the ICC and SunStudio behaviors, and > that idea appeared to me a tad too sophisticated... but if people agree, > I can return to it. Do you think that version of the warning should be > simply the default, right, simply the new behavior of -Wmissing-braces? I suppose so but I'd be happy to hear other opinions. Ian
Re: RFC: PR 25137: moving -Wmissing-braces to -Wextra?
On Tue, Nov 17, 2009 at 04:07:28PM -0800, Ian Lance Taylor wrote: > Paolo Carlini writes: > > > Ian Lance Taylor wrote: > >> OK, to me that seems like an excellent reason to implement a special > >> case for the warning here. For example, perhaps if a struct has only > >> one field, and that field is an aggregate, then we don't warn if there > >> is only one set of braces. > >> > > Sure, we considered that, you can find traces of that reasoning in the > > audit trail, then lately I noticed the ICC and SunStudio behaviors, and > > that idea appeared to me a tad too sophisticated... but if people agree, > > I can return to it. Do you think that version of the warning should be > > simply the default, right, simply the new behavior of -Wmissing-braces? > > I suppose so but I'd be happy to hear other opinions. I think that the cleanest way is to suppress the warning for structs with one member, rather than treating tr1::array as a special case, as Jonathan Wakely suggested. The point of warnings should be to help people write correct, non-buggy, portable code, and omitting the outer braces in this case is allowed by the standard and isn't going to result in unexpected behavior.
Re: RFC: PR 25137: moving -Wmissing-braces to -Wextra?
Joe Buck wrote:
> I think that the cleanest way is to suppress the warning for structs
> with one member
And recursively?
So that:
struct A { int i; };
struct B { struct A a };
struct C { struct B b };
struct C c = { 1 };
does not trigger the warning?
What if struct B is now:
struct B { struct A a; int j; };
and I write:
struct C c = { 1, 2 };
?
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
Re: RFC: PR 25137: moving -Wmissing-braces to -Wextra?
2009/11/18 Mark Mitchell:
> Joe Buck wrote:
>
>> I think that the cleanest way is to suppress the warning for structs
>> with one member
>
> And recursively?
>
> So that:
>
> struct A { int i; };
> struct B { struct A a };
> struct C { struct B b };
> struct C c = { 1 };
>
> does not trigger the warning?
I think not warning here is fine.
> What if struct B is now:
>
> struct B { struct A a; int j; };
>
> and I write:
>
> struct C c = { 1, 2 };
>
> ?
This still has exactly two initialisers for exactly two objects, so I
think it's OK. I'm concerned about missing braces when the meaning of
the code may not be what you expect.
e.g.
struct X { int i; };
struct Y { struct X x; int j; };
Y y = { 1, 2 };
is OK, but if someone changes X to:
struct X { int i; int j };
then I want the initialisation of y to warn, which it already does
because of -Wmissing-field-initializers. But maybe I should just use
-Wno-missing-braces and leave the missing braces warning for those who
find it useful.
Re: RFC: PR 25137: moving -Wmissing-braces to -Wextra?
On Tue, Nov 17, 2009 at 4:05 PM, Ian Lance Taylor wrote:
> Paolo Carlini writes:
>
>> I'm trying to resolve one way or another this PR, which I have assigned
>> to myself a long time ago... The issue essentially is very simple. This
>> kind of code:
>>
>> struct S { int s[3]; };
>> struct S s1 = { 1, 1, 1 };
>>
>> triggers a warning with -Wall about missing braces around initializer,
>> which some people consider a bit overzealous, in particular in
>> relationship with std::array (std::tr1::array).
>>
>> Today, I was comparing GCC to ICC and SunStudio and noticed that, please
>> correct me if I'm wrong about the details:
>>
>> - ICC: lacks completely an equivalent of -Wmissing-braces, never warns.
>> - SunStudio: only warns with +w2, doesn't warn with +w.
>>
>> Therefore, my idea to resolve 25137 and make progress in this area would
>> be moving -Wmissing-braces from -Wall to -Wextra: the corresponding
>> patch, as expected, is trivial, and it would be for me only matter to
>> tweak the testsuites a bit (A refinement of that proposal would be doing
>> the change only for the C++ front-end)
>
> The point of -Wmissing-braces is to warn if you if you are not
> initializing the fields you think you are. Given that, I tend to feel
> that -Wmissing-braces is doing the right thing, and I tend to feel
> that it should be in -Wall.
>
> I could see a counter-argument for special cases like the above, but
> then we have to start enumerating special cases.
>
> I don't really understand how this interacts with std::tr1:array,
> though.
That makes the use of std::array<> very annoying. From that perspective
I believe the warning *in this specific case* is not just overzealous, but
downright harmful.
-- Gaby
>
> Ian
>
Re: RFC: PR 25137: moving -Wmissing-braces to -Wextra?
Jonathan Wakely wrote: > This still has exactly two initialisers for exactly two objects, so I > think it's OK. I'm concerned about missing braces when the meaning of > the code may not be what you expect. I think you're right -- you want -Wmissing-field-initializers, not -Wmissing-braces. -Wmissing-braces is explicitly about not having all the brace groups fully specified. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: RFC: PR 25137: moving -Wmissing-braces to -Wextra?
On Tue, Nov 17, 2009 at 7:32 PM, Mark Mitchell wrote: > Jonathan Wakely wrote: > >> This still has exactly two initialisers for exactly two objects, so I >> think it's OK. I'm concerned about missing braces when the meaning of >> the code may not be what you expect. > > I think you're right -- you want -Wmissing-field-initializers, not > -Wmissing-braces. -Wmissing-braces is explicitly about not having all > the brace groups fully specified. > ok. -- Gaby
