Shortening GCC error messages - c++

Whenever gcc can't find a matching overload for a function with multiple overloads, it gives lines and lines of errors, explaining which overload was tried and why it was not used.
While often it is useful, it is also often not, as the problem as a simple typo at the call site. And in this particular case, it is not even helpful, because it will take considerable time to even find out which line is ultimately responsible for this issue.
Is there any command line switch to GCC to shorten the output and only include the actual triggering line? For example:
#include <string>
#include <iostream>
struct Z{};
void foo() {
std::string s;
Z z;
std::cout << z; // typo - meant s
}
See error output: https://godbolt.org/g/wz5vL2
Small addition: third party solutions (STLFilt, gccfilter, etc) do not fit the bill, because a) my work environment is not welcoming towards installing 3rd party apps and b) they tend to become unmaintained and stop working with the next compiler upgrade

One way is to use -Wfatal-errors. It changes the error message from
<source>: In function 'void foo()':
<source>:11:15: error: no match for 'operator<<' (operand types are 'std::ostream {aka std::basic_ostream<char>}' and 'Z')
std::cout << z; // typo - meant s
~~~~~~~~~~^~~~
In file included from /opt/compiler-explorer/gcc-7.3.0/include/c++/7.3.0/iostream:39:0,
from <source>:2:
/opt/compiler-explorer/gcc-7.3.0/include/c++/7.3.0/ostream:108:7: note: candidate: std::basic_ostream<_CharT, _Traits>::__ostream_type& std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_ostream<_CharT, _Traits>::__ostream_type& (*)(std::basic_ostream<_CharT, _Traits>::__ostream_type&)) [with _CharT = char; _Traits = std::char_traits<char>; std::basic_ostream<_CharT, _Traits>::__ostream_type = std::basic_ostream<char>]
operator<<(__ostream_type& (*__pf)(__ostream_type&))
many more lines of errors
to
<source>: In function 'void foo()':
<source>:11:15: error: no match for 'operator<<' (operand types are 'std::ostream {aka std::basic_ostream<char>}' and 'Z')
std::cout << z; // typo - meant s
~~~~~~~~~~^~~~
compilation terminated due to -Wfatal-errors.
Compiler returned: 1
The only downside is you will only get the first error. If your compile times are long then this isn't the greatest as you wouldn't be able to fix any other errors until you fix that first one and recompile.

Related

How to debug //tensorflow/compiler/xla/tests:array_elementwise_ops_test_cpu_parallel test failure on ppc64le

In TensorFlow 1.3.1, IsFiniteScalarF32 test is failing with error :
"expected:false vs actual:true". at line 100 https://github.com/tensorflow/tensorflow/blob/v1.3.1/tensorflow/compiler/xla/tests/array_elementwise_ops_test.cc#L100, for command bazel test -c opt //tensorflow/compiler/xla/tests:array_elementwise_ops_test_cpu_parallel
Currently I am debugging the failure, and want to check the output of auto result = builder.IsFinite(builder.ConstantR0<float>(NAN));
Tried to display the output using std::cout << "value is ***** \n" << result;, however getting following error :
tensorflow/compiler/xla/tests/array_elementwise_ops_test.cc:67:13: error: cannot bind 'std::basic_ostream<char>' lvalue to 'std::basic_ostream<char>&&'
std::cout << "value is ***** \n" << result;
^
In file included from /usr/lib/gcc/ppc64le-redhat-linux/4.8.5/../../../../include/c++/4.8.5/iostream:39:0,
from tensorflow/compiler/xla/tests/array_elementwise_ops_test.cc:21:
/usr/lib/gcc/ppc64le-redhat-linux/4.8.5/../../../../include/c++/4.8.5/ostream:602:5: error: initializing argument 1 of 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&&, const _Tp&) [with _CharT = char; _Traits = std::char_traits<char>; _Tp = xla::ComputationDataHandle]'
operator<<(basic_ostream<_CharT, _Traits>&& __os, const _Tp& __x)
How can I print the value of result variable?
The type of result is a protocol buffer defined here.
The error you are seeing is because there is no operator<< defined for protocol buffers. Here is an explanation for such an error: std::vector : cannot bind 'std::ostream {aka std::basic_ostream<char>}' lvalue to 'std::basic_ostream<char>&&'
To print the value of the protocol buffer you can use cout << result.DebugString().
Having said this, the value will be some random number - probably not very useful - because it is simply a handle to a value to be computed in XLA computation graph.

C++ writing to file error in Linux/Ubuntu?

I have been trying to learn C++ recently, but I have stumbled across some errors. For example, when I try to run this code to ask the user what they want outputted to a file:
#include <iostream>
#include <cstdio>
using namespace std;
main() {
string output; //Declare variables before starting
FILE * file = fopen("newfile.txt","w"); //creates file
cout << "Entire something that you want to be written to the file: " << endl;
cin.getline(output, 256); //Asks what you want to put into file
fprintf(file, output); //Puts output into file
fclose(file); //closes file
return 0;
}
using
g++ -o main test.cpp
I get this error:
test.cpp: In function ‘int main()’:
test.cpp:10:25: error: no matching function for call to ‘std::basic_istream<char>::getline(std::string&, int)’
cin.getline(output, 256);
^
test.cpp:10:25: note: candidates are:
In file included from /usr/include/c++/4.8/iostream:40:0,
from test.cpp:1:
/usr/include/c++/4.8/istream:618:5: note: std::basic_istream<_CharT, _Traits>& std::basic_istream<_CharT, _Traits>::getline(std::basic_istream<_CharT, _Traits>::char_type*, std::streamsize, std::basic_istream<_CharT, _Traits>::char_type) [with _CharT = char; _Traits = std::char_traits<char>; std::basic_istream<_CharT, _Traits>::char_type = char; std::streamsize = long int]
basic_istream<char>::
^
/usr/include/c++/4.8/istream:618:5: note: candidate expects 3 arguments, 2 provided
/usr/include/c++/4.8/istream:427:7: note: std::basic_istream<_CharT, _Traits>::__istream_type& std::basic_istream<_CharT, _Traits>::getline(std::basic_istream<_CharT, _Traits>::char_type*, std::streamsize) [with _CharT = char; _Traits = std::char_traits<char>; std::basic_istream<_CharT, _Traits>::__istream_type = std::basic_istream<char>; std::basic_istream<_CharT, _Traits>::char_type = char; std::streamsize = long int]
getline(char_type* __s, streamsize __n)
^
/usr/include/c++/4.8/istream:427:7: note: no known conversion for argument 1 from ‘std::string {aka std::basic_string<char>}’ to ‘std::basic_istream<char>::char_type* {aka char*}’
test.cpp:11:22: error: cannot convert ‘std::string {aka std::basic_string<char>}’ to ‘const char*’ for argument ‘2’ to ‘int fprintf(FILE*, const char*, ...)’
fprintf(file, output);
^
Could someone please help me? And please forgive me if this is something that can be easily solved, I am fairly new to C++ and do not quite understand it yet.
The header for string is missing:
#include <string>
Without it, sring isn't defined, and everywhere you use output, you'll have errors
With the include you'll have a lot less errors. But this line has another issue (as πάντα ῥεῖ already pointed out):
cin.getline(output, 256);
because cin.getline() expects a char* and the length. If you want to use a string, you have to use the function getline(), without size (limited to strings maximume size) and on an istream:
getline(cin, output);
Last remark: you are of course free to mix c-style io and streams. But you could win from getting used to streams for all your file io.
The error occurs at the line
cin.getline(output, 256);
According to the documentation for std::istream::getline, the first argument for cin.getline() should be a char * and not a std::string as you have declared it.
Try changing the declaration of output to a char * like so
char[256] output;
Edit: Using std::getline as the others have said would be a better idea though.

Compile header file and two .cpp files in Unix/Linux (Ubuntu)

I am trying to compile 3 files total and can not get it to. The code works in visual++. I have uploaded all 3 files in the same dir and used the following command.
g++ -o edit Album.cpp lab8.cpp
My file names are listed below
Album.cpp
Album.h
lab8.cpp
Note the code was written in visual studio C++ and compiled just fine there.
Results in the following
lab8.cpp: In function ‘std::vector read_album_file(std::string)’:
lab8.cpp:142:25: error: no matching function for call to ‘std::basic_ifstream::basic_ifstream(std::string&)’
ifstream read (filename);// the ifstream is used to read from the file
^
lab8.cpp:142:25: note: candidates are:
In file included from lab8.cpp:38:0:
/usr/include/c++/4.8/fstream:467:7: note: std::basic_ifstream<_CharT, _Traits>::basic_ifstream(const char*, std::ios_base::openmode) [with _CharT = char; _Traits = std::char_traits; std::ios_base::openmode = std::_Ios_Openmode]
basic_ifstream(const char* __s, ios_base::openmode __mode = ios_base::in)
^
/usr/include/c++/4.8/fstream:467:7: note: no known conversion for argument 1 from ‘std::string {aka std::basic_string}’ to ‘const char*’
/usr/include/c++/4.8/fstream:453:7: note: std::basic_ifstream<_CharT, _Traits>::basic_ifstream() [with _CharT = char; _Traits = std::char_traits]
basic_ifstream() : __istream_type(), _M_filebuf()
^
/usr/include/c++/4.8/fstream:453:7: note: candidate expects 0 arguments, 1 provided
/usr/include/c++/4.8/fstream:427:11: note: std::basic_ifstream::basic_ifstream(const std::basic_ifstream&)
class basic_ifstream : public basic_istream<_CharT, _Traits>
^
/usr/include/c++/4.8/fstream:427:11: note: no known conversion for argument 1 from ‘std::string {aka std::basic_string}’ to ‘const std::basic_ifstream&’
Look at the constructor prototype of ifstream. It takes a const char * and a optional argument, soyou need to write filename.c_str()

gmp_int Boost errors

Here is my simple test code:
#include <boost/multiprecision/gmp.hpp>
using namespace boost::multiprecision;
int main()
{
gmp_int v = 1;
std::cout << v << std::endl;
return 0;
}
When I try to build and run, I get the following errors:
error: there are no arguments to 'mp_get_memory_functions' that depend on a template parameter, so a declaration of 'mp_get_memory_functions' must be available [-fpermissive]
note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)
error: 'mp_get_memory_functions' was not declared in this scope
error: 'mpz_combit' was not declared in this scope
error: 'mp_get_memory_functions' was not declared in this scope|
error: invalid conversion from 'int' to 'const __mpz_struct*' [-fpermissive]
error: cannot bind 'std::ostream {aka std::basic_ostream<char>}' lvalue to 'std::basic_ostream<char>&&'
error: initializing argument 1 of 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&&, const _Tp&) [with _CharT = char; _Traits = std::char_traits<char>; _Tp = boost::multiprecision::backends::gmp_int]'
I am using Code::Blocks. I used precompiled GMP libraries for windows. In code::Blocks I have gmp\lib\libgmp.ain the linker, gmp\include in compiler directories and gmp\lib in linker directories.
Any help would be appreciated in getting GMP to work. I think that I did not install GMP correctly, but it might be a simple issue.
You forgot to use a number adaptor with your gmp_int backend type:
number<gmp_int> v = 1;
See it Live On Coliru:
#include <boost/multiprecision/gmp.hpp>
#include <iostream>
using namespace boost::multiprecision;
int main()
{
number<gmp_int> v = 1;
std::cout << v << std::endl;
}
I have solved the issue. I was not linking all my header and library files correctly.

Clang vs GCC for my Linux Development project

I'm in college, and for a project we're using C. We've explored GCC and Clang, and Clang appears to be much more user friendly than GCC. As a result, I'm wondering what the advantages or disadvantages are to using clang, as opposed to GCC, for developing in C and C++ on Linux?
In my case this would be used for student level programs, not production.
If I use Clang, should I debug with GDB and use GNU Make, or use another debugger and make utility?
EDIT:
The gcc guys really improved the diagnosis experience in gcc (ah competition). They created a wiki page to showcase it here. gcc 4.8 now has quite good diagnostics as well (gcc 4.9x added color support). Clang is still in the lead, but the gap is closing.
Original:
For students, I would unconditionally recommend Clang.
The performance in terms of generated code between gcc and Clang is now unclear (though I think that gcc 4.7 still has the lead, I haven't seen conclusive benchmarks yet), but for students to learn it does not really matter anyway.
On the other hand, Clang's extremely clear diagnostics are definitely easier for beginners to interpret.
Consider this simple snippet:
#include <string>
#include <iostream>
struct Student {
std::string surname;
std::string givenname;
}
std::ostream& operator<<(std::ostream& out, Student const& s) {
return out << "{" << s.surname << ", " << s.givenname << "}";
}
int main() {
Student me = { "Doe", "John" };
std::cout << me << "\n";
}
You'll notice right away that the semi-colon is missing after the definition of the Student class, right :) ?
Well, gcc notices it too, after a fashion:
prog.cpp:9: error: expected initializer before ‘&’ token
prog.cpp: In function ‘int main()’:
prog.cpp:15: error: no match for ‘operator<<’ in ‘std::cout << me’
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:112: note: candidates are: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_ostream<_CharT, _Traits>& (*)(std::basic_ostream<_CharT, _Traits>&)) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:121: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_ios<_CharT, _Traits>& (*)(std::basic_ios<_CharT, _Traits>&)) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:131: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(std::ios_base& (*)(std::ios_base&)) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:169: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(long int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:173: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(long unsigned int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:177: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(bool) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/bits/ostream.tcc:97: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(short int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:184: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(short unsigned int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/bits/ostream.tcc:111: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:195: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(unsigned int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:204: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(long long int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:208: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(long long unsigned int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:213: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(double) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:217: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(float) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:225: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(long double) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:229: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(const void*) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/bits/ostream.tcc:125: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_streambuf<_CharT, _Traits>*) [with _CharT = char, _Traits = std::char_traits<char>]
And Clang is not exactly starring here either, but still:
/tmp/webcompile/_25327_1.cc:9:6: error: redefinition of 'ostream' as different kind of symbol
std::ostream& operator<<(std::ostream& out, Student const& s) {
^
In file included from /tmp/webcompile/_25327_1.cc:1:
In file included from /usr/include/c++/4.3/string:49:
In file included from /usr/include/c++/4.3/bits/localefwd.h:47:
/usr/include/c++/4.3/iosfwd:134:33: note: previous definition is here
typedef basic_ostream<char> ostream; ///< #isiosfwd
^
/tmp/webcompile/_25327_1.cc:9:13: error: expected ';' after top level declarator
std::ostream& operator<<(std::ostream& out, Student const& s) {
^
;
2 errors generated.
I purposefully choose an example which triggers an unclear error message (coming from an ambiguity in the grammar) rather than the typical "Oh my god Clang read my mind" examples. Still, we notice that Clang avoids the flood of errors. No need to scare students away.
As of right now, GCC has much better and more complete support for C++11 features than Clang. Also, the code generator for GCC performs better optimisation than the one in Clang (in my experience, I have not seen any exhaustive tests).
On the other hand, Clang often compiles code more quickly than GCC, and produces better error messages when there is something wrong with your code.
The choice of which one to use really depends on what things are important to you. I value C++11 support and code generation quality more than I value convenience of compilation. Because of this, I use GCC. For you, the trade-offs could be different.
I use both because sometimes they give different, useful error messages.
The Python project was able to find and fix a number of small buglets when one of the core developers first tried compiling with clang.
I use both Clang and GCC, I find Clang has some useful warnings, but for my own ray-tracing benchmarks - its consistently 5-15% slower then GCC (take that with grain of salt of course, but attempted to use similar optimization flags for both).
So for now I use Clang static analysis and its warnings with complex macros: (though now GCC's warnings are pretty much as good - gcc4.8 - 4.9).
Some considerations:
Clang has no OpenMP support, only matters if you take advantage of that but since I do, its a limitation for me. (*****)
Cross compilation may not be as well supported (FreeBSD 10 for example still use GCC4.x for ARM), gcc-mingw for example is available on Linux... (YMMV).
Some IDE's don't yet support parsing Clangs output (QtCreator for example *****). EDIT: QtCreator now supports Clang's output
Some aspects of GCC are better documented and since GCC has been around for longer and is widely used, you might find it easier to get help with warnings / error messages.
***** - these areas are in active development and may soon be supported
For student level programs, Clang has the benefit that it is, by default, stricter wrt. the C standard. For example, the following K&R version of Hello World is accepted without warning by GCC, but rejected by Clang with some pretty descriptive error messages:
main()
{
puts("Hello, world!");
}
With GCC, you have to give it -Werror to get it to really make a point about this not being a valid C89 program. Also, you still need to use c99 or gcc -std=c99 to get the C99 language.
I think clang could be an alternative.
GCC and clang have some differences on expressions like a+++++a, and I've got many different answers with my peer who use clang on Mac while I use gcc.
GCC has become the standard, and clang could be an alternative. Because GCC is very stable and clang is still under developing.