How do you make the warning come up that has the words 'suspicious' and '-Wmain' in it? - c++

It's a simple question really, and refers to Linux (as opposed to Windows or Mac).
How do you generate a warning message from the C or C++ compiler that must have the word 'suspicious' in it, and must refer to (-Wmain).
(update)
Thanks Boann - I got some of those Warnings, but I also got Error - error: ‘::main’ must return ‘int’.
The reason I'm asking this question is that a week ago my compiler (GCC 4.8.1) came out with this warning saying 'suspicious' and that it was caused by Wmain. So I put -Wno-main and the warning went away and it compiled fine. Just recently it has started complaining making it an actual Error and not compiling. So I'm kind of worried that somehow the mother ship has covertly updated my compiler over the internet, without me knowing, and changed it to treat it as error. (I was probably using 'int4' as the return type which I forever have typedef'd as signed long int.
I note there's -Wmain referenced in g++ man page so it must be for something, but what warning is there that isn't overruled by an error??
At offset 557284 (decimal) of the g++ executable I found "Warn about suspicious declarations of "main".

For what it's worth,
struct suspicious {};
int main(suspicious) {}
Output with g++ -Wall, GCC 4.8.2:
warning: first argument of 'int main(suspicious)' should be 'int' [-Wmain]

If you refer to the -Wmain parameter of GCC, you get the warning by giving main odd arguments, an odd return type, or giving it static linkage. This will do it:
static float main(float x) {
return 0;
}
Compiled with gcc -Wmain, it displays these warnings; they do not actually contain the word 'suspicious' though:
warning: return type of 'main' is not 'int'
warning: first argument of 'main' should be 'int'
warning: 'main' takes only zero or two arguments
warning: 'main' is normally a non-static function

I just downloaded the sources for gcc 4.8.1 and searched all relevant files for the word "suspicious".
There are a number of occurrences, but as far as I can tell, there's no way an error message for a C or C++ source file can contain the word "suspicious". It's possible but unlikely that there was a local modification.
Is it possible that you're mistaken about what the error message said? If you have a log containing the error message, please update your question to show the exact message your received.
If you're concerned that your compiler may have been updated without your knowledge, you might check the timestamp of the compiler executable and of any programs it invokes (use gcc -v to check that). But gcc itself doesn't automatically update itself. If you're using it on a system administered by someone else, automatic updates are to be expected. If you administer the system yourself, you may have configured it to update software without manual intervention; if so, that's not a gcc issue. I don't know what "mother ship" you're referring to.

Related

Brace-initialization of an array of structs in c++11

Here is my code:
#include <string>
struct A
{
int a;
std::string sa;
};
int main()
{
A arr[3]{};
}
When I compile it with gcc 4.8.2 (on Ubuntu 14.04) with -std=gnu++11 option I get the following error:
example.cpp: In function ‘int main()’:
example.cpp:11:14: internal compiler error: in gimplify_init_constructor, at gimplify.c:4271
A arr[3]{};
^
Why does it throw an internal compiler error? Is it a compiler bug?
An internal compiler error is always a compiler bug, and says nothing about whether the code is valid.
If the code is invalid, the compiler is supposed to give an error message telling you what's wrong with the code. An internal compiler error only tells you what's wrong with the compiler.
Given that this internal compiler error still exists in later versions (I just checked 4.9.2, as well as current sources as of January 29th), I would normally strongly encourage reporting this as a bug to the GCC developers, but a quick search reveals that it's already known to them.
You can work around it by writing A arr[3]{{}};, which means the same thing. It contains the same initialiser for the first element of arr that it would already get by default.
I encountered the same issue right out of blue with gcc 4.8.5 when I added an std::string to a content of the array struct. Adding extra {} as suggested above helped. Maybe this can give a clue why this compiler error happens.

Compile in c++14

So in my CSE course we are given a header file to use right now for our programs that we're writing.
Unfortunately I can't get terminal to compile using that header, it gives quite a few errors (compiling with just 'g++'). Also, when I'm at my university and I'm using PuTTY I get the same errors while using this header. However, I don't get the errors when I compile with 'g++ -std=c++14'.
I've tried compiling with this command on terminal on my mac, but it says it doesn't recognize the c++14 part.
dhcp-10-202-147-243:hw1pr1 Admin$ g++ -std=c++14 hw1pr1.cpp
error: invalid value 'c++14' in '-std=c++14'
Any help on how I could get this to work would be greatly appreciated. Hopefully this all made some sort of sense.
Here's the error I get when I compile with the header file I'm talking about in terminal with just g++.
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/ext/hash_map:212:5: warning:
Use of the header <ext/hash_map> is deprecated. Migrate to <unordered_map>
[-W#warnings]
# warning Use of the header <ext/hash_map> is deprecated. Migrate to ...
^
In file included from read_first_name.cpp:1:
./std_lib_facilities_4.h:43:20: error: no matching function for call to object
of type 'hash<char *>'
return hash<char*>()(s.c_str());
^~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/ext/__hash:39:12: note:
candidate function not viable: 1st argument ('const value_type *'
(aka 'const char *')) would lose const qualifier
size_t operator()(char *__c) const _NOEXCEPT
^
In file included from read_first_name.cpp:1:
./std_lib_facilities_4.h:112:8: warning: comparison of unsigned expression < 0
is always false [-Wtautological-compare]
if (i<0||size()<=i) throw Range_error(i);
~^~
./std_lib_facilities_4.h:118:8: warning: comparison of unsigned expression < 0
is always false [-Wtautological-compare]
if (i<0||size()<=i) throw Range_error(i);
~^~
3 warnings and 1 error generated.
This error doesn't happen and the program will compile fully when I use PuTTY and 'g++ std=c++14'
There's lots of change between C++ standards, so what is valid in one revision need not be in another.
g++ defaults to -std=gnu++98 for C++, which is the decades old C++98-standard enhanced with GNU extensions (most of which are conformant).
Choose the proper revision: -std=c++1y -pedantic is a very close approximation to C++14.
What changes introduced in C++14 can potentially break a program written in C++11?
Looking at what you say you're having to use and the name format of that .cpp file, I think I'm in the same class. A year later, looks like, but here's my solution for archive's sake:
The std_lib_facilities.h header comes with the Bjarne Stroustrup textbook, "Programming: Principles and Practices Using C++". For those unaware, Bjarne Stroustrup invented C++ (he has a pretty good idea what he's talking about). Incidentally, the book is a fantastic way to learn C++, if one takes the time to actually read it. The std_lib_facilities.h header is just a convenient header file for beginners in C++, containing links to all the major standard libraries used in the textbook, as well as some helper functions that help account for potential mistakes or errors, or are just convenient for learning (such as an error() function that handles simple exception throwing for the student, or adding an "out of bounds" check for vectors). It's ultimately just a way to allow students to hop right into code without having to learn specifics about the header.
Stroustrup keeps updated with C++ and thus includes several libraries that require the c++11 standard. The CSCE department wants its students (at least in this early class) to connect to the department's Unix system and compile from there, in order to avoid confusion with downloading and updating compilers.
I happened to already have had a couple C++ classes beforehand, and thus already had g++ set up on my Ubuntu laptop. I avoided including the std_lib_facilities for as long as possible since I was getting the same error as Topic Creator Joe, where g++ didn't recognize the "c++11" part (manually including the required libraries worked fine until we had to use a class from the textbook that used one of the header's helper functions) . Eventually, I found a help topic online that advised me simply to update my g++ compiler to 4.7 or higher, since 4.6 and lower doesn't have support for C++11 (or, of course, C++14). It was oddly rather involved compared to updates one might be used to on Mac or Windows, and I doubt the exact process would apply, but that is (was?) likely the problem: it's just an older version of g++, and it needs an update to compile C++11 and later. I recommend searching for ways to update g++/gcc for Mac.
Should, y'know, anyone else with this problem stumble upon this and not have their problem solved yet.

How to fix "error: no previous declaration for void awn::vala_array_destroy"?

I'm on Ubuntu 13.04 32 platform. I'm trying to compile awn with latest vala. I get following error message.
vala-utils.cc: In function 'void awn::vala_array_destroy(gpointer, gint, GDestroyNotify)':
vala-utils.cc:358:6: error: no previous declaration for 'void awn::vala_array_destroy(gpointer, gint, GDestroyNotify)' [-Werror=missing-declarations]
cc1plus: some warnings being treated as errors
How can I fix that error?
At the top of vala-utils.cc insert the function prototype:
void vala_array_destroy(gpointer array, gint array_length, GDestroyNotify destroy_func);
This will silence the warning which is causing the build to fail due to -Werror defined in the Makefile. Consider raising a pull request for the benefit of the maintainers.
Alternatively modify ln.89 in configure.ac and remove the -Werror to stop the warning failing the build.
This actually a warning, and a rather pedantic one at that.
It's saying that the global function awn::vala_array_destroy has not been declared beforehand. Usually this is a sign of a programmer's mistake, but from the source it seems to me that:
this function is only supposed to be used by awn::vala_array_free directly below it (in which case it should really have been given internal linkage), or
a declaration is available in some header elsewhere (in which case it's probably in the wrong header, as it ought to be in vala-utils.h).
The long and short of it is that the code is probably fine, if a little strangely designed. This case is being treated as an error because you have -Werror turned on for this warning, turning it into an error.
I don't know how you're building the library, but you could adjust the compiler flags to avoid this; by default, GCC does not emit this warning, nor turn it into an error. Alternatively, you could add the function declaration into vala-utils.h yourself. You should also take up the issue with the library's maintainers.
Update: I found the culprit on line 89 of AWN's configure.ac. You should definitely take this up with the library maintainers. I'd be amazed if this had not already been reported as a bug; I believe it was introduced in this revision.

GCC- Invalid use of Register

I am compiling a project under VS2012 and GCC (CodeBlocks) for Windows.
On VS2012 everything works perfect. Under GCC I am obtaining the following compiling error:
C:\Users\Piotrek\AppData\Local\Temp\ccfdl0Ye.s|164|Error: invalid use of register|
C:\Users\Piotrek\AppData\Local\Temp\ccfdl0Ye.s|166|Error: invalid use of register|
C:\Users\Piotrek\AppData\Local\Temp\ccfdl0Ye.s|221|Error: invalid use of register|
||=== Build finished: 3 errors, 14 warnings (0 minutes, 0 seconds) ===|
I am using the compiler option -fpermissive - It should have nothing to do with the error.
I just can't understand why is it pointing to a temporary file under the Local Temp folder, and saying that I am using a wrong register??
Does anybody have any idea on what's happening?
It looks like you've encountered a bug in the compiler. The
error messages (judging from the "source" file name) are from
the assembler. The only time the assembler should generate an
error message is when there is something illegal in the
assembler, and the C++ compiler should never generate illegal
assembler; if it can't generate legal assembler, it should
output an error message and fail.
The real problem, when you get this sort of message, is to
figure out what in your code is triggering it. g++ has an
option which tells it to not delete any of the intermediate
files. Use this, then try and see what is going on in the
assember files at these lines. (When you ask g++ to output
assembler, it puts nice comments in to help finding the
corresponding source. I don't know if it also does this when
generating assembler as an intermediate file.) And then try
cutting code (if worse comes to worse, using binary search)
until you can get the error for a program of one or two lines.
Try to guess what's special about them, and change them to do
the same thing, in a different way.
And don't fail to report the error to g++.
Thanks to James Kanze's recommendation, I decided to tell to the compiler not to delete temporary files. This is done by the flag:
-save-temps
As James said, the assembler generates some nice comments which inform exactly which line on our C++ code is throwing the error. In my case, it looks like it is not accepting such instruction:
asm
(
".intel_syntax noprefix\n"
"lock dec [DWORD PTR eax]\n"
".att_syntax \n"
:
: "a" (data)
:
);
I don't know why he is not accepting Intel Syntax anymore, since it was working with previous GCC version, and now that I updated it it doesn't anymore.
Anyway, the solution for such problems is the one mentioned by James: Just dont delete intermediate files so that you can spy directly into Assembly code what's wrong.
About the problem of the INTEL syntax, any idea why it doesn't work anymore?

compiling zthreads

I downloaded zthreads (found here: http://zthread.sourceforge.net/) and tried to compile but I get this error from make:
MutexImpl.h:156: error: there are no arguments to 'ownerAcquired' that depend on a template parameter, so a declaration of 'ownerAcquired' must be available
MutexImpl.h:156: error: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)
and then after that for every function in that source file I get this kind of error:
MutexImpl.h:167: error: there are no arguments to 'function' that depend on a template parameter, so a declaration of 'function' must be available
So I'm guessing it's a makefile error but I'm not for sure how to tell make to tell g++ to compile the files with -fpermissive. Does anyone know how to put that into the makefile (if that is the problem)?
CXXFLAGS += -fpermissive
Standard gmake convention is to use the CXXFLAGS variable to pass options to the C++ compiler. You can take advantage of that fact as well as a feature called "command-line overrides" to get your extra flag tacked onto the flags passed to g++ by invoking gmake this way:
make CXXFLAGS+=-fpermissive
I downloaded the source myself to verify that this works and found that it does, although there are still a bunch of other warnings emitted. You may wish to log a bug for these issues if you intend to continue using the library.
Hope this helps,
Eric Melski
I got rid of all these errors changing the code: for each line with that mistake, add this-> to the function that provokes the error. In the line you quote:
ownerAcquired must be changed by this->ownerAcquired
I hope this helps