I upgraded today from Ubuntu 12.04 which I think had g++-4.6 to Ubuntu 12.10 with g++-4.7.2. In my code I had a few functions marked as __attribute__((always_inline)). The reason for this was simply that profiling showed me that it increased the performance of the code significantly. It worked fine with g++ 4.6 but now with g++ 4.7 I get the error message:
error: inlining failed in call to always_inline 'void func_name(args)': function body can be overwritten at link time
I can't share my actual code, I've tried to narrow it down but when I change too much the error goes away, so that's not helpful. I'm interested in the root cause of this error message.
It wasn't my intention to answer this myself, but I accidentally found the answer a few minutes after I had posted.
The reason for this (cryptic) error message was that the function was not marked as inline, only __attribute((always_inline)).
For us, the issue was that we failed to also declare the function "static". "attribute((always_inline))" means, in plain text, "inline this and never include a function body" and the error message means "the compiler had to include a function body". In our case, since the function wasn't "static", it needed to be available for an external reference.
Related
I am working through some example code from Lazar and Penea, Mastreing Qt5:
https://github.com/PacktPublishing/Mastering-Qt-5
I think I am starting to understand the code, but I am stuck with a compilation error in the method "addAlbum" in the class "AlbumModel", The offending line is
unique_ptr<Album> newAlbum(new Album(album));
which yields the error message
error: use of deleted function ‘Album::Album(const Album&)’
unique_ptr<Album> newAlbum(new Album(album));
^
I am using CMake 3.10.2 and cpp 7.5.0. I presume the github code is correct, so this error is a bit puzzling. Although there are a lot of "use of deleted function" discussions here on stackoverflow, I have not been able to determine the cause of the error.
I was able to temporarily get some legacy Fortran code running (I was able to step through it with the debugger) in Visual Studio 2017 with the Intel Fortran compiler, until it stopped working apparently for no reason.
At the very start I was getting the error below when trying to get the code to run.
error #6633: The type of the actual argument differs from the type of the dummy argument.
That error went away after a post-installation reboot and I was able to test the code for a few weeks, but now it's back.
I don't think I've changed any of the code.
You're using Intel Fortran and it has a feature called "Generated Interface Checking". The way this works is when you compile a source that declares a subroutine or function that isn't in a module, it generates an INTERFACE block and saves a compiled module for it. Then when you compile a source that calls a routine for which you have not provided an explicit interface, it looks to see if there's a generated one and compares it. If you have an argument type mismatch you'll get an error such as this.
However, to work properly the called routine must be compiled before the caller. If this doesn't happen, the interface can't be checked and you'll not get an error. The error is still there, and you may be able to see it if you do a rebuild of the project. Pay attention to the message and fix the problem it describes. A mismatched argument type is a common cause of run-time errors that come and go.
I have a __forceinline function that cannot be inlined when compiled as CLI (probably due to the specific restrictions to inlining that apply with .NET).
In debug, it is a warning and does not prevent me from building. But in release, it comes up as an error:
error C4714: function '...' marked as __forceinline not inlined
In the project configuration, Treat Warnings As Errors is set to No (/WX-), Treat Specific Warnings As Errors is empty (no value and no inherited value) and there is no /We option in the Command Line of the C/C++ section.
Thus, I don't understand why this warning comes up as an error.
And as it is an error it prevents me from building the project in release.
Do you have any clue on why this comes up as an error?
Any idea of how I could get rid of it, considering I cannot change the function nor its use (it comes from a library I'm using and I'd like not to alter)?
Thank you very much!
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.
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.