Today I meet a Werror=Wcoverage_mismatch error when compiling some erlang/opt:
beam/beam_emu.c: In function 'erts_current_reductions':
beam/beam_emu.c:3150:1: error: the control flow of function 'erts_current_reductions' does not match its profile data (counter 'arcs') [-Werror=coverage-mismatch]
}
...
But I don't know what does it mean and google tells me nothing about this flag.
Below is gcc source code
if (entry->n_counts != n_counts)
warning_printed = warning_at(
DECL_SOURCE_LOCATION(current_function_decl), OPT_Wcoverage_mismatch,
"number of counters in profile data for function %qD "
"does not match "
"its profile data (counter %qs, expected %i and have %i)",
current_function_decl, ctr_names[counter], entry->n_counts, n_counts);
else
warning_printed = warning_at(
DECL_SOURCE_LOCATION(current_function_decl), OPT_Wcoverage_mismatch,
"the control flow of function %qD does not match "
"its profile data (counter %qs)",
current_function_decl, ctr_names[counter]);
See the GCC (9.2.0) manual on Warning options:
-Wno-coverage-mismatch
Warn if feedback profiles do not match when using the -fprofile-use option. If a source file is changed between compiling with -fprofile-generate and with -fprofile-use, the files with the profile feedback can fail to match the source file and GCC cannot use the profile feedback information. By default, this warning is enabled and is treated as an error. -Wno-coverage-mismatch can be used to disable the warning or -Wno-error=coverage-mismatch can be used to disable the error. Disabling the error for this warning can result in poorly optimized code and is useful only in the case of very minor changes such as bug fixes to an existing code-base. Completely disabling the warning is not recommended.
So, it appears that your source code has changed since the time when it was compiled, and this is likely to cause problems (hence the error message). Recompile and rerun the profiling.
Related
I have a open source mdnsresponder c code which is compiled with bitbake. I don't face any issues when LINKOPTS is given like below
EXTRA_OEMAKE += "LINKOPTS=''"
Here nothing is set to LINKOPTS. So if I remove LINKOPTS, GCC compiler throws error message like
error: unrecognized command line option '--hash-style=gnu'. Also it throws few warning messages like -Wtype-limits, -Wunused-but-set-variable.
Is LINKOPTS in this usage required ?
Compiler provides hashstyle=gnu by default, so disabling it again in toplevel bitbake.
I compile my project with -Werror to make sure all of my code is without recognizable warnings. However my current project has a third-party dependency that has an issue in it which causes a warning - and that warning fails my build because of the -Werror flag.
I want to use the -Werror flag and I don't want to correct the third-party package. Is there a way to ignore this warning?
package.h:126:1: error: useless storage class specifier in empty declaration [-Werror]
};
The line of code that generates the error is a struct definition with a "dangling" typedef.
typedef struct my_data_obj {
char* data;
uint32_t data_size;
};
This is obviously a mistake - but I can't find any pragma or any such mechanic to ignore the warning generated from that header file. Any ideas?
EDIT: SOLUTION
Though I'm accepting Florian Weimer's answer because it answers the question most closely it's not the actual fix I settled with. I'll describe that bellow. By including the headers as system headers I did exactly what I wanted to do - suppress the error without having to fix the package.
What I finally did was create a patch file and simply apply that patch each time the project is built.
vim package.h
# fix the file
git add package.h
git diff --cached > package.h.patch
# on build time
git apply package.h.patch
I assume that you want to include package.h from files where you want to enable -Werror.
GCC does not have a separate flag to control this warning, otherwise the compiler would have printed it. With the separate flag, you could have used #pragma GCC diagnostics ignore, as indicated in the other answers, possibly with a wrapper header file.
However, you could put the header file into a separate directory, and instead of using -I to add it to the include path, use -isystem. As a result, the header file is treated as a system header, and unless you also compile with -Wsystem-headers, warnings in system headers are suppressed.
All warnings and errors have specific names, and can be enabled or disabled on a per-warning/-error basis.
For example lets say I have an unused variable and enabled warnings about it, then I will get a message similar to
/some/path/main.cpp:18:9: warning: unused variable ‘i’ [-Wunused-variable]
That last part of the message, the one inside the square brackets, is the name of the specific warning.
With this name you can then disable warnings using the -Wno-<name of warning> option. In the case of the above warning it's disabled with -Wno-unused-variable.
Your use-case is a little different in that you want to disable a warning turned into an error. This is very similar to the above, but the general form of the option is -Wno-error=<name of warning or error>. In our example case it's -Wno-error=unused-variable.
All of this is of course in the GCC documentation, more specifically in the warning options documentation.
So what you have to do is figure out the name of the warning, so you can use it for the -Wno-error= option.
I am new to C and I am trying to compile a code that uses am external library. Therefore, I am following these steps for linking a library. But at the very first one
gcc -c -Wall -Werror -fpic PICASO_SERIAL_4DLIBRARY.C
I get this
PICASO_SERIAL_4DLIBRARY.C:1:0: error: -fpic ignored for target (all code is position independent) [-Werror]
#include <windows.h>
cc1plus.exe: all warning being treated as errors
additionally undder # there is a arrow above. I tried googling it but I could only find out that this is a Linux problem and not a Windows one (I am developing on Windows now) and the I followed these steps to install gcc. an compiling other small projects work, too.
Anyone any idea, why this doesn't work?
The mention of #include <windows.h> is incidental. That just happens to be the first line of code.
The compiler tries to associate a line of code with the error to help you find the problem. But in this case the code is irrelevant. The error is in the command line and you will get a failure no matter what the code is. But because the compiler is coded to always associate a line of code with an error, it decides, arbitrarily, to point the finger at the first line of code.
Because you use -Werror, warnings are treated as errors. The compiler therefore converts a warning about an ignored option to emit position independent code into an error. The error message states this very clearly:
PICASO_SERIAL_4DLIBRARY.C:1:0: error: -fpic ignored for target (all code is position independent) [-Werror]
I suspect you glazed over when reading the error message, and turned your attention to the line of code that was highlighted. Always read error messages carefully!
To resolve the error, remove the -fpic option from your command line.
Try to compile without -fpic. This flag is inappropriate for the mingw-w64 target.
Using avr-gcc and attempting to reduce size of binary using -ffunction-sections and -fdata-sections when compiling and linking with --gc-sections. The .lds file contains nothing:
SECTIONS
{
}
This error occurs when partial linking many .o's into a .a, which will then be used later to complete the build.
I've read through some other posts that discuss these options, but nothing that clarifies the ENTRY() issue. Their doesn't seem to be a need for it at the partial stage before trying to reduce code size(pre-existing linker script clearly doesn't use it).
Documentation states : --gc-sectionts
"This option can be set when doing a partial link (enabled with option '-r'). In this case the root of symbols kept must be explicitly specified either by an '--entry' or `--undefined' option or by a ENTRY command in the linker script."
This is where I'm lost. Would greatly appreciate some more explanation of how to use --undefined, --entry, or ENTRY cmd in linker script to resolve this issue.
I had a similar issue and gave up. I ended up compiling with the -fwhole-program option enabled which significantly reduced the size of my bootloader.
I'm writing C code and was initially using the gcc checker. Errors were reported in the C file. Lots of errors that didn't matter were being reported due to, for instance, no include directory switches on the gcc command line in the checker. Because we're using icc and it feels unwieldy to setup all of the parameters that are already setup in our makefile, I decided to switch over to using the make checker.
Upon switching to the make checker, I did not get any results. Looking at the makeprg command in make.vim, it is make -sk. I realized that our makefile was not setup to do syntax checking, so I created a new target called syntax_check that added the -fsyntax-only and -c flags. I then changed the make.vim makeprg command to make -sk clean syntax-check so that the appropriate target is run.
When I save the file I watched top in another window and saw that the build is occuring. However, I'm still getting no errors. By this, I mean I don't see the green sidebar indicating lines that did not have errors. Running :Errors does not bring up the location list.
Any ideas? And is my understanding of how to look at the generated errors in syntastic wrong (which it may very well be)?
As a side note for the question here, I've also got this question in on the Syntastic github page here.
It turns out that the errorformat was wrong for handling icc. This, of course, makes total sense.
The errorformat for icc that I've got so far is:
let errorformat = '%W%f(%l): %tarning #%n: %m,%E%f(%l): %trror: %m'
I will add more to this as I find errors that aren't covered by this format or find that I need different formatting.