Re: Intermittent/non-reproducible gcc testsuite failures

[Michael Eager]

Dave Korn wrote:

Michael Eager wrote:


Does anyone have any suggestions on how to get one of
these tests to fail consistently, or a different approach
to finding the cause of the intermittent failures?


  Perhaps hack the testsuite to run the tests under gdb, setting a breakpoint
on abort() that causes it to dump core?  Then at least you'd be able to get a
backtrace and see some state post-mortem.


I put together a dejagnu configuration to run tests
using powerpc-gdb.  The intermittent test cases pass
consistently.  Looks like a simulator bug.

I've filed a bug report in gdb:
http://sourceware.org/bugzilla/show_bug.cgi?id=10066

--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

messaging

[Arthur Schwarz]

In the following code fragment:

# include 
# include 
# include 

using namespace std;
void CommandLine(int argc, char** argv);
int main(int argc, char** argv) {
   CommandLine(argc, argv[]);
   ifstream x.open(argv[1], ios:in);
   ofstream y.open(argv[1], ios::in);
   
   return 0;
};

g++-4 messaging is:
>> g++-4 x.cpp
x.cpp: In function 'int main(int, char**)':
x.cpp:8: error: expected primary-expression before ']' token
x.cpp:10: error: expected primary-expression before ':' token

A recommendation and reason for change is:
1: x.cpp:8 error: illegal to pass an array without subscript value as an 
   argument
   The given message is accurate but non-expressive of the reason
   for failure.
3: cpp:10 error: illegal scope resolution operator ':'
   From memory, there are three uses of ':' in C++
   ':'   label terminator, :
   ':'   case in a switch statement, case :
   ':'   scope resolution operator, "::"
   The given diagnostic message is deceptive. 

art

messages

[Arthur Schwarz]

Some messaging observations for the input code (below).

# include 
# include 
# include 

using namespace std;
void CommandLine(int argc, char** argv);
int main(int argc, char** argv) {
   string  a = "output.txt";
   string* b = &a;
   ofstream y;
   y.open("output.txt",   ios::in);
   y.open( a, ios::in);
   y.open( a.c_str(), ios::in);
   y.open((*b).c_str(),   ios::in);
   y.open( a.c_str,   ios::in);
   return 0;
};

g++-4 x.cpp with suggested error messages and reasoning
x.cpp: In function 'int main(int, char**)':
x.cpp:12: error: no matching function for call to 'std::basic_ofstream >::open(std::string&, const std::_Ios_Openmode&)'
/usr/lib/gcc/i686-pc-cygwin/4.3.2/include/c++/fstream:626: note: candidates 
are: void std::basic_ofstream<_CharT, _Traits>::open(const char*, 
std::_Ios_Openmode
) [with _CharT = char, _Traits = std::char_traits]
x.cpp:15: error: no matching function for call to 'std::basic_ofstream >::open(, const 
std::_I
os_Openmode&)'
/usr/lib/gcc/i686-pc-cygwin/4.3.2/include/c++/fstream:626: note: candidates 
are: void std::basic_ofstream<_CharT, _Traits>::open(const char*, 
std::_Ios_Openmode
) [with _CharT = char, _Traits = std::char_traits]
>>

1: error: open(arg1, ...) must be a C-string.
   The existing message is indecisive in it's resolution. It might be 
   an acceptable idea to analyze expected input arguments and compare
   them with actual arguments and then state a reason for failure based
   on the actual argument(s) that failed. This is a labor since for 
   (example) if arg1 is valid for some overloaded functions but arg2 is
   invalid for any functions, and then arg2 is valid for some functions
   but arg1 is invalid for any function then there is a processing 
   overhead at diagnostic generation time. My argument is that one 
   function of a compiler is show the cause of failure in unambiguous
   and clear terms.
2: error: open(arg1, ...) must be a C-string, and
   error: a.c_str not a member of 'a'
   The first failure is the inability to find a valid member of 'a'. This
   leads to the second failure of being unable to find an overloaded open.
   Nowhere is this clear from the messaging.

We have discussed the undue length of messaging before.

art

Re: messages

[Dave Korn]

Arthur Schwarz wrote:

> using namespace std;
> void CommandLine(int argc, char** argv);
> int main(int argc, char** argv) {
>string  a = "output.txt";
>string* b = &a;
>ofstream y;
>y.open("output.txt",   ios::in);
>y.open( a, ios::in);
>y.open( a.c_str(), ios::in);
>y.open((*b).c_str(),   ios::in);
>y.open( a.c_str,   ios::in);
>return 0;
> };

> 1: error: open(arg1, ...) must be a C-string.
>The existing message is indecisive in it's resolution. It might be 
>an acceptable idea to analyze expected input arguments and compare
>them with actual arguments and then state a reason for failure based
>on the actual argument(s) that failed. 

  Isn't that exactly what the compiler IS doing, as indicated by "candidates
are ... "?

>overhead at diagnostic generation time. My argument is that one 
>function of a compiler is show the cause of failure in unambiguous
>and clear terms.

  It's not always possible for the compiler to do that.  How can it know if
the problem is that you gave the wrong argument type in the function call,
rather than that you got the type wrong in the definition of the overloaded
function that was supposed to match?

> x.cpp:15: error: no matching function for call to
> 'std::basic_ofstream >::open(, const
std::_I
> os_Openmode&)' /usr/lib/gcc/i686-pc-cygwin/4.3.2/include/c++/fstream:626:
> note: candidates
are: void std::basic_ofstream<_CharT, _Traits>::open(const char*,
std::_Ios_Openmode
> ) [with _CharT = char, _Traits = std::char_traits]

> 2: error: open(arg1, ...) must be a C-string, and
>error: a.c_str not a member of 'a'
>The first failure is the inability to find a valid member of 'a'. 

  Err,  are you sure?  I think 'c_str' absolutely is a member of a, see two
lines earlier.  The actual problem is that without the brackets, that's a
function pointer that you're trying to pass when y.open() expects a string.

  BTW, have you ever tried STLfilt?  It's highly relevant to your interests:

http://www.bdsoft.com/tools/stlfilt.html

cheers,
  DaveK

Re: question on 16 bit registers with 32 bit pointers

[Michael Meissner]

On Sat, Apr 11, 2009 at 01:40:57AM +0100, Dave Korn wrote:
> Stelian Pop wrote:
> 
> >>> Do I need to define movsi3(), addsi3() etc. patterns manually or should 
> >>> GCC
> >>> figure those by itself ?
> >>   Not sure I understand you.  You always need to define movMM3 etc.  GCC 
> >> will
> >> correctly select between movhi3 and movsi3 based on your Pmode macro when
> >> handling pointers, but you still need to write the patterns.
> > 
> > The thing is that this CPU does not have any real 32 bit registers, or
> > instructions to do assignments/additions/etc to 32 bit registers. So the 32 
> > bit
> > operations (on pointers) need to be emulated using the 16 bit components, 
> > and I
> > thought that GCC can do this automatically for me ...
> 
>   Ah.  In theory GCC should move everything by pieces.  In practice, you have
> to define mov patterns for SI and DI because rtl-level CSE isn't as smart as
> it should be.  You can use expanders for these.

Though if you use expanders that need temporary registers, you may have
problems in reload, and need to delve into the mysteries of secondary reload.
I would imagine that for pointer sized things it is best if you do need to
implement multiple instructions that you hold off on splitting until after
reload is completed.

-- 
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meiss...@linux.vnet.ibm.com

Re: messages

[Arthur Schwarz]

Thanks Dave;'

Acerbic comments below.

--- On Mon, 4/13/09, Dave Korn  wrote:

> > using namespace std;
> > void CommandLine(int argc, char** argv);
> > int main(int argc, char** argv) {
> >    string  a = "output.txt";
> >    string* b = &a;
> >    ofstream y;
> >   
> y.open("output.txt",   ios::in);
> >    y.open( a,       
>      ios::in);
> >    y.open( a.c_str(), 
>    ios::in);
> >   
> y.open((*b).c_str(),   ios::in);
> >    y.open( a.c_str,   
>    ios::in);
> >    return 0;
> > };
> 
> > 1: error: open(arg1, ...) must be a C-string.
> >    The existing message is indecisive in
> it's resolution. It might be 
> >    an acceptable idea to analyze expected
> input arguments and compare
> >    them with actual arguments and then state
> a reason for failure based
> >    on the actual argument(s) that failed. 
> 
>   Isn't that exactly what the compiler IS doing, as
> indicated by "candidates
> are ... "?

  I don't think so. The compiler is directing the user to a given solution 
  and specifying what the problem is, the compiler is essentially saying
  that it found something it couldn't resolve and for the user to find out
  where and what is wrong. A clear message that arg is wrong I think
  is a better approach. The compiler provides candidate solutions, without
  guidance, and the user must search the candidates (and arguments) to
  determine where the fault lies.
> 
> >    overhead at diagnostic generation time.
> My argument is that one 
> >    function of a compiler is show the cause
> of failure in unambiguous
> >    and clear terms.
> 
>   It's not always possible for the compiler to do
> that.  How can it know if
> the problem is that you gave the wrong argument type in the
> function call,
> rather than that you got the type wrong in the definition
> of the overloaded
> function that was supposed to match?

  Even accepting your statements as accurate some of the time I think it
  a good diagnostic tool for the user for the compiler to do what it can
  when it can. If the judicious answer is that the cases where such a
  tool could be provided is an edge condition where there is small chance
  of occurrence, why then (to be forceful - ahem - needlessly vehement)
  let the user suffer. 

> 
> > x.cpp:15: error: no matching function for call to
> > 'std::basic_ofstream std::char_traits >::open( overloaded function type>, const
> std::_I
> > os_Openmode&)'
> /usr/lib/gcc/i686-pc-cygwin/4.3.2/include/c++/fstream:626:
> > note: candidates
> are: void std::basic_ofstream<_CharT,
> _Traits>::open(const char*,
> std::_Ios_Openmode
> > ) [with _CharT = char, _Traits =
> std::char_traits]
> 
> > 2: error: open(arg1, ...) must be a C-string, and
> >    error: a.c_str not a member of 'a'
> >    The first failure is the inability to
> find a valid member of 'a'. 
> 
>   Err,  are you sure?  I think 'c_str'
> absolutely is a member of a, see two
> lines earlier.  The actual problem is that without the
> brackets, that's a
> function pointer that you're trying to pass when y.open()
> expects a string.

  And I agree. My analysis is faulty in that the member function is seen,
  but the diagnostic message doesn't say what's wrong. The determination
  of what the error is is left to the casual observer.

> 
>   BTW, have you ever tried STLfilt?  It's highly
> relevant to your interests:

  No I haven't but now that I know something exists I probably will.

  Before I toodle off, let me put some kinder words around what I'm doing. I'm 
not pointing fingers or poking fun. As a result of my own lacks it was 
suggested that I volunteer to provide alternatives to diagnostic messaging for 
the gcc to consider. They are apparently directly addressing the issues 
involved with constructing user oriented diagnostic messages and asked me to 
volunteer to send what I thought could be changed for their consideration. The 
examples given are designed only to illustrate messaging and alternative 
wording for consideration. Each day I address my 'skills' in software and find 
they are more modest than first thought. There is no thought to impose myself 
on the organization or criticize anything in this product. Anything at all. 
Nada. Nothing. 

In brief, the examples are not meant to display what I don't know or seek 
resolution of my lack of skill.
> 
> http://www.bdsoft.com/tools/stlfilt.html
> 
>     cheers,
>       DaveK
> 

Thanks again. 

art


> 
>

Re: question on 16 bit registers with 32 bit pointers

[Dave Korn]

Michael Meissner wrote:
> On Sat, Apr 11, 2009 at 01:40:57AM +0100, Dave Korn wrote:
>> Stelian Pop wrote:
>> 
> Do I need to define movsi3(), addsi3() etc. patterns manually or
> should GCC figure those by itself ?
 Not sure I understand you.  You always need to define movMM3 etc.
 GCC will correctly select between movhi3 and movsi3 based on your
 Pmode macro when handling pointers, but you still need to write the
 patterns.
>>> The thing is that this CPU does not have any real 32 bit registers, or 
>>> instructions to do assignments/additions/etc to 32 bit registers. So
>>> the 32 bit operations (on pointers) need to be emulated using the 16
>>> bit components, and I thought that GCC can do this automatically for me
>>> ...
>> Ah.  In theory GCC should move everything by pieces.  In practice, you
>> have to define mov patterns for SI and DI because rtl-level CSE isn't as
>> smart as it should be.  You can use expanders for these.
> 
> Though if you use expanders that need temporary registers, you may have 
> problems in reload, and need to delve into the mysteries of secondary
> reload. I would imagine that for pointer sized things it is best if you do
> need to implement multiple instructions that you hold off on splitting
> until after reload is completed.

  Yes, you're right about the register vs reload issue; you must condition any
calls to force_reg on !reload in progress / completed.  But I don't think this
is such a problem; reload will only generate movMM instructions based on hard
regs, so you'll only run into secondary reloads if you have complex addressing
modes that need a scratch register to address, won't you?

cheers,
  DaveK

Re: messages

[Dave Korn]

Arthur Schwarz wrote:
> Thanks Dave;'
> 
> Acerbic comments below.

  G'wan, I can take it!

>>   Isn't that exactly what the compiler IS doing, as
>> indicated by "candidates are ... "?
> 
>   I don't think so. [ ... ] A clear message that arg is wrong I think
>   is a better approach. 

  But maybe arg is right and it's something else that is wrong?

>>   It's not always possible for the compiler to do
>> that.

>   Even accepting your statements as accurate some of the time I think it
>   a good diagnostic tool for the user for the compiler to do what it can
>   when it can. If the judicious answer is that the cases where such a
>   tool could be provided is an edge condition where there is small chance
>   of occurrence, why then (to be forceful - ahem - needlessly vehement)
>   let the user suffer. 

  But then we agree; the compiler should do everything it can.  I'm just not
sure it /can/ do what you're asking here.

>   And I agree. My analysis is faulty in that the member function is seen,
>   but the diagnostic message doesn't say what's wrong. The determination
>   of what the error is is left to the casual observer.
> 
>>   BTW, have you ever tried STLfilt?  It's highly
>> relevant to your interests:
> 
>   No I haven't but now that I know something exists I probably will.
> 
> Before I toodle off, let me put some kinder words around what I'm doing.

> I'm
> not pointing fingers or poking fun. As a result of my own lacks it was
> suggested that I volunteer to provide alternatives to diagnostic messaging for
> the gcc to consider. They are apparently directly addressing the issues
> involved with constructing user oriented diagnostic messages and asked me to
> volunteer to send what I thought could be changed for their consideration. The
> examples given are designed only to illustrate messaging and alternative
> wording for consideration. Each day I address my 'skills' in software and find
> they are more modest than first thought. There is no thought to impose myself
> on the organization or criticize anything in this product. Anything at all.
> Nada. Nothing.

> In brief, the examples are not meant to display what I don't know or seek
resolution of my lack of skill.

  Nonono; I didn't mean to impugn anything you're doing, just trying to point
out that it's not easy.  Your suggestions are all valid and good ideas, but
before they can be usefully incorporated into the compiler, they need to be
expressed in clearer language.  It's easy for us as humans to try and infer
the original author's intent, but much more difficult for a parser.

  What would help is, as well as suggesting a new clearer message, you could
suggest under what conditions the compiler should use this new message.
Should the compiler always assume the function prototypes are correct and the
choice of argument in the function call is wrong?  It occurs to me that that
might be a good rule of thumb for system headers, but probably not for headers
within the user's application.

cheers,
  DaveK

Re: messages

[Joe Buck]

On Mon, Apr 13, 2009 at 03:53:04PM -0700, Dave Korn wrote:
>   Nonono; I didn't mean to impugn anything you're doing, just trying to point
> out that it's not easy.  Your suggestions are all valid and good ideas, but
> before they can be usefully incorporated into the compiler, they need to be
> expressed in clearer language.  It's easy for us as humans to try and infer
> the original author's intent, but much more difficult for a parser.

One place that I think it shouldn't be too difficult to improve things
is to try to prune the case where there are a large number of overloaded
possibilities, but none match.  It makes no sense to report them all.

Consider

#include 
struct Foo { int bar;};
int main() {
  std::cerr << Foo();
}

Try it, the result is ugly, and I often encounter this one during
development.  Here we have no printing operator defined for Foo, and GCC
will happily tell us about every single operator<< declaration it knows
about, no matter how irrelevant.

One possible cleanup, in the case where there is no unique match but many
overloads, is to attempt a sort by relevance and only print the top
matches, or if every match is equally irrelevant, just say that there
are no suitable matches.

And this, of course, means we have to define relevance.  There are two
cases: the first is when we fail to choose an overload because of
ambiguity; there we can just report all of the choices that are tied for
"equally good".  The other case is where no overload matches.  There
we could try to produce a heuristic that would "score" each alternative.
Matching some but not all of the arguments would contribute some points,
likewise if the addition or removing a const qualifier would cause a
match, that would score points.  It would take some tweaking to produce
a meaningful result.

Re: align of local char array seem not work.

[Jim Wilson]

Bernd Roesch wrote:

char buf[256] __attribute__((aligned(16)));
   printf("%x\n",&buf[0]);
this short test program give no error or warning and do not align as
expect.i test with several 68k amigaos compilers (3.4.0 /4.3.2/4.4.0)


Most likely gcc did align it, but one of the assembler, linker, or OS 
program loader did not respect the alignment.  You can try looking at 
the .s file, the .o file, and the executable, to try to determine where 
the failure occurred.


There is a macro MAX_OFILE_ALIGNMENT that you can define in the target 
OS .h file to specify the OS limit.  GCC will then warn if you try to 
align a variable to a value larger than this limit.  See the docs and 
the code in varasm.c that uses it.


Jim

Re: align of local char array seem not work.

[Andrew Pinski]

On Thu, Apr 9, 2009 at 6:07 AM, Bernd Roesch  wrote:
> Hi,
>
> i see simular lines in a program.
>
> char buf[256] __attribute__((aligned(16)));
>   printf("%x\n",&buf[0]);

This is PR 16660.

Thanks,
Andrew Pinski

Re: question on 16 bit registers with 32 bit pointers

[Hans-Peter Nilsson]

On Mon, 13 Apr 2009, Dave Korn wrote:
> Michael Meissner wrote:
> > On Sat, Apr 11, 2009 at 01:40:57AM +0100, Dave Korn wrote:
> >> Stelian Pop wrote:
> >>
> > Do I need to define movsi3(), addsi3() etc. patterns manually or
> > should GCC figure those by itself ?
...
> > Though if you use expanders that need temporary registers, you may have
> > problems in reload, and need to delve into the mysteries of secondary
> > reload. I would imagine that for pointer sized things it is best if you do
> > need to implement multiple instructions that you hold off on splitting
> > until after reload is completed.
>
>   Yes, you're right about the register vs reload issue; you must condition any
> calls to force_reg on !reload in progress / completed.  But I don't think this
> is such a problem; reload will only generate movMM instructions based on hard
> regs, so you'll only run into secondary reloads if you have complex addressing
> modes that need a scratch register to address, won't you?

How about asking the documentation?  This isn't the first time
for this question.  A STFW found me
 for
context.  Bah.  I guess, it doesn't help having it documented...

Or maybe you mean "do we *still* need this, given recent
register-allocation changes"?  (I'm not interested enough though.)

brgds, H-P

Re: messages

[Arthur Schwarz]

> > Thanks Dave;'
> > 
> > Acerbic comments below.
> 
> >>   Isn't that exactly what the
> compiler IS doing, as
> >> indicated by "candidates are ... "?
> > 
> >   I don't think so. [ ... ] A clear
> message that arg is wrong I think
> >   is a better approach. 
> 
>   But maybe arg is right and it's something
> else that is wrong?
> 
> >>   It's not always possible for the
> compiler to do
> >> that.
> 

> 
>   Nonono; I didn't mean to impugn anything you're
> doing, just trying to point
> out that it's not easy.  

  Impugn away. I am terribly thin-skinned and the barbs wake me up.
> 

> Should the compiler always assume the function prototypes
> are correct and the
> choice of argument in the function call is wrong?  It
> occurs to me that that
> might be a good rule of thumb for system headers, but
> probably not for headers
> within the user's application.

  In this case the compiler detected an error and provided the correct 
  answer, but the answer lacked clarity for (really) a non-compiler
  writer. Before I say another word (let's see you deal with that one),
  if we look at the statement you have made then, I think, we are left
  nowhere. In particular your caveat on when my suggested reporting
  algorithm is inapplicable. To tear into the statement and bring you to
  a proper state of receptiveness, in absurdum you are saying that even
  though the compiler has detected an error and reported (what it thinks)
  is an error, the compiler is unable to determine that the error occurred
  in arg - the nub of the suggested diagnostic message. I would say
  that given the existing compiler message, if the compiler can't draw this
  conclusion then the message is wrong. I would then say if the compiler
  is clever enough to provide a function template as a candidate for
  correcting the fault, then the compiler has all of the information
  needed to do a comparison, argument by argument, to determine which
  argument(s) are at fault, and can do this recursively (or iteratively
  if you're going to get picky) with all candidate function solutions. 
  I believe your caveat is then moot. The existing diagnostic message
  should be sufficient to allow the compiler to perform the analysis
  necessary to provide a more 'user friendly' (according to 'art') fault
  indication.

  I would go further by saying that (especially) any time the compiler
  is able to provide a candidate solution then the compiler should be
  able to analyze it's own solution against the fault to provide a more
  meaningful message.

  I assert that in those cases where compiler fault analysis fails, then
  under the stated conditions above the compiler has provided a faulty
  initial analysis of the problem and that is a 'bug'.

  Conventional wisdom, in my youth when the Sun shone brighter, was
  that error analysis was O(n**3), so I acknowledge that this is not
  easy. My argument is that the compiler has already done the analysis
  and just fails on the messaging. 

  I believe that it is possible to generalize the analysis tool and 
  avoid case-by-case special purpose code for each 'nasty'. If not 
  completely for all cases and forever, at least for enough cases to 
  make the effort worthwhile. My reasoning is that most semnatic errors 
  fall into broad categories, call it a 'failure in semantics', and
  these broad categories can be leveraged into a generic toolset. The
  pragmatic difficulty is that that existing diagnostic messages would
  have to be reworked into a standardized framework, and I view this
  as a hard problem. (Mind you, this is all without doing a lick of
  work or seeing a line of code - obviously I'm an expert.)

  Now, whew, I may be all wrong and if so, please be gentle.

art

Re: messages

[Arthur Schwarz]

--- On Mon, 4/13/09, Joe Buck  wrote:

 them all.
> 
> Consider
> 
> #include 
> struct Foo { int bar;};
> int main() {
>   std::cerr << Foo();
> }
> 
> Try it, the result is ugly, and I often encounter this one

  (Personal opinion - not to be construed as wisdom).
  The issue with the result is:
  1: There is no end-of-line between candidates (or anywhere).
  2: The candidate template is a large, untamed, and unruly beast.
  3: The diagnostic message is not clear. I think it should say
 that the compiler can't find something because of something.
  4: Providing a full template for each candidate is (indeed)
 something of an overkill.

And so in substance I agree, in detail there are some mitigating things that 
can be done. 

art

Re: messages

[Dave Korn]

Joe Buck wrote:

> And this, of course, means we have to define relevance.  There are two
> cases: the first is when we fail to choose an overload because of
> ambiguity; there we can just report all of the choices that are tied for
> "equally good".  The other case is where no overload matches.  There
> we could try to produce a heuristic that would "score" each alternative.
> Matching some but not all of the arguments would contribute some points,
> likewise if the addition or removing a const qualifier would cause a
> match, that would score points.  It would take some tweaking to produce
> a meaningful result.

  Hmm, I'm not a language lawyer, but isn't there already a well-ordered
definition of more or less closely-matching in the whole C++ name resolution
thing?  It could be confusing if our warnings operated a significantly
different standard for what's close and what's not than that defined in the
language spec, but in terms of doing what the user meant, we'd probably want
to treat certain mismatches as more significant than others for diagnostic
purposes (e.g. the common char[] vs char * when passing a const string problem).

  So I guess, yes, I'm asking Arthur to suggest rules of relevance that would
enable the compiler to decide what kind of user error is implied by a given
syntax error.

cheers,
  DaveK

Re: messaging

[Kai Henningsen]

Arthur Schwarz schrieb:

In the following code fragment:

# include 
# include 
# include 

using namespace std;
void CommandLine(int argc, char** argv);
int main(int argc, char** argv) {
   CommandLine(argc, argv[]);
   ifstream x.open(argv[1], ios:in);
   ofstream y.open(argv[1], ios::in);
   
   return 0;

};

g++-4 messaging is:

g++-4 x.cpp

x.cpp: In function 'int main(int, char**)':
x.cpp:8: error: expected primary-expression before ']' token
x.cpp:10: error: expected primary-expression before ':' token

A recommendation and reason for change is:
1: x.cpp:8 error: illegal to pass an array without subscript value as an 
   argument

   The given message is accurate but non-expressive of the reason
   for failure.


Actually, in this case I'd say that the original message is perfectly 
fine, and your suggestion is rather confusing. However, what one could 
say here is something like "[] is only allowed in declarations".




3: cpp:10 error: illegal scope resolution operator ':'
   From memory, there are three uses of ':' in C++
   ':'   label terminator, :
   ':'   case in a switch statement, case :
   ':'   scope resolution operator, "::"
   The given diagnostic message is deceptive. 


Could perhaps say "':' is not a scope resolution operator", unless 
someone comes up with a use case where it is ...