What's the closest GCC equivalent to this MSVC preprocessor code?
#pragma warning( push ) // Save the current warning state.
#pragma warning( disable : 4723 ) // C4723: potential divide by 0
// Code which would generate warning 4723.
#pragma warning( pop ) // Restore warnings to previous state.
We have code in commonly included headers which we do not want to generate a specific warning for. However, we want files which include those headers to continue to generate that warning (if the project has that warning enabled).
This is possible in GCC since version 4.6, or around June 2010 in the trunk.
Here's an example:
#pragma GCC diagnostic push
#pragma GCC diagnostic error "-Wuninitialized"
foo(a); /* error is given for this one */
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wuninitialized"
foo(b); /* no diagnostic for this one */
#pragma GCC diagnostic pop
foo(c); /* error is given for this one */
#pragma GCC diagnostic pop
foo(d); /* depends on command line options */
The closest thing is the GCC diagnostic pragma, #pragma GCC diagnostic [warning|error|ignored] "-Wwhatever". It isn't very close to what you want, and see the link for details and caveats.
I've done something similar. For third-party code, I didn't want to see any warnings at all. So, rather than specify -I/path/to/libfoo/include, I used -isystem /path/to/libfoo/include. This makes the compiler treat those header files as "system headers" for the purpose of warnings, and so long as you don't enable -Wsystem-headers, you're mostly safe. I've still seen a few warnings leak out of there, but it cuts down on most of the junk.
Note that this only helps you if you can isolate the offending code by include-directory. If it's just a subset of your own project, or intermixed with other code, you're out of luck.
This is an expansion to Matt Joiner's answer.
If you don't want to spawn pragmas all over your code, you can use the _Pragma operator:
#ifdef __GNUC__
# define DIAGNOSTIC_ERROR(w) _Pragma("GCC diagnostic error \"" w "\"")
# define DIAGNOSTIC_IGNORE(w) _Pragma("GCC diagnostic ignore \"" w "\"")
# define DIAGNOSTIC_PUSH _Pragma("GCC diagnostic push")
# define DIAGNOSTIC_POP _Pragma("GCC diagnostic pop")
#endif
// (...)
DIAGNOSTIC_ERROR("-Wuninitialized")
foo(a); // Error
DIAGNOSTIC_PUSH
DIAGNOSTIC_IGNORE("-Wuninitialized")
foo(a); // No error
DIAGNOSTIC_POP
foo(a); // Error
Related
I have a C++ project and I want to test the compatibility of library headers with different compiler versions. I have a simple source file (that includes said headers) and I want to change the compiler argument to std=gnu++11 for this one target. How do I do that?
executable('old_compiler_test', ['octest.cxx']
# override ARGS here ??? how
)
Note that I have
add_global_arguments(
['-std=gnu++17',
....
rather than the dedicated option for this, in spite of the warning to prefer the special option, because the special option simply doesn't work. (Why is a question I've never tracked down)
update
To clarify: I'm not trying to make additional configurations in the same way that debug and release are configurations. I want a different compiler argument to be applied to a single target within the configuration.
From the Meson documentation, you can use the argument <languagename>_args to pass additional compiler arguments. In your case, since you use C++, it would give something like
executable('old_compiler_test', ['octest.cxx'],
cpp_args: ['std=gnu++11']
)
However the documentation also specify that there are no way to disable an argument added by add_global_argument(), so you will end up with both -std=gnu++17 and -std=gnu++11 passed to the compiler. I don't know how your compiler will behave, but I tried to pass both arguments to GCC 10.2 and it uses c++17 (not what you want).
Workaround
It seems that if you define the C++ version in the project() statement, Meson will removes it if an other version is specified in compiler arguments, giving the behaviour you expect.
Here is the sample I used:
meson.build
project('project-name', 'cpp',
default_options: ['cpp_std=c++17']
)
executable('old_compiler_test', ['octest.cxx'],
cpp_args: ['-std=gnu++11']
)
octest.cxx
#include <iostream>
int main() {
std::cout << __cplusplus << std::endl;
}
After compilation, running the executable will print 201103, which means that the compiler used c++11 as desired.
I've got some tests that test that clang's address sanitizer catch particular errors. (I want to ensure my understanding of the types of error it can catch is correct, and that future versions continue to catch the type of errors I'm expecting them to.) This means I have several tests that fail by crapping out with an OTHER_FAULT, which appears to be the fixed way that clang's runtime reports an error.
I've set the WILL_FAIL flag to TRUE for these tests, but this only seems to check the return value from a successful, exception-free failure. If the process terminates with an exception, cmake still classes it as a failure.
I've also tried using PASS_REGULAR_EXPRESSION to watch for the distinguishing messages that are printed out when this error occurs, but again, cmake seems to class the test as a failure if it terminates with an exception.
Is there anything I can do to get around this?
(clang-specific answers are also an option! - but I doubt this will be the last time I need to test something like this, so I'd prefer to know how to do it with cmake generally, if it's possible)
CTest provides only basic, commonly used interpretators for result of test programs. For implement other interpretators you can write simple program/script, which wraps the test and interpret its result as needed. E.g. C program (for Linux):
test_that_crash.c:
#include <unistd.h>
#include <stdlib.h>
#include <sys/types.h>
int main(int argc, char** argv)
{
pid_t pid = fork();
if(pid == -1)
{
// fork fails
return 1;
}
else if(pid)
{
// Parent - wait child and interpret its result
int status = 0;
wait(&status);
if(WIFSIGNALED(status)) return 0; // Signal-terminated means success
else return 1;
}
else
{
// Child - execute wrapped command
execvp(argv[1], argv + 1);
exit(1);
}
}
This program can be used in CMake as follows:
CMakeLists.txt:
# Compile our wrapper
add_executable(test_that_crash test_that_crash.c)
# Similar to add_test(name command), but test is assumed successfull only if it is crashed(signalled)
macro(add_test_crashed name command)
# Use generic flow of add_test() command for automatically recognize our executable target
add_test(NAME ${name} COMMAND test_that_crash ${command} ${ARGN})
endmacro(add_test_crashed)
# ...
# Add some test, which should crash
add_test_crashed(clang.crash.1 <clang-executable> <clang-args>)
There is also a clang-specific solution: configure its manner of exit using the ASAN_OPTIONS environment variable. (See https://github.com/google/sanitizers/wiki/AddressSanitizerFlags.) To do this, set the ASAN_OPTIONS environment variable to abort_on_error=0. When the address sanitizer detects a problem, the process will then do _exit(1) rather than (presumably) abort(), and will thus appear to have terminated cleanly. You can then pick this up using cmake's WILL_FAIL mechanism. (It's still not clear why OS X and Linux differ in this respect - but there you go.)
As a bonus, the test fails much more quickly.
(Another handy option that can improve turnaround time when running through cmake is to set ASAN_SYMBOLIZER_PATH to an empty value, which stops the address sanitizer symbolizing the stack traces. Symbolizing takes a moment, but there's no point doing it when running through cmake, since you can't see the output.)
Rather than do this by hand, I made a Python script that sets the environment appropriately on OS X (doing nothing on Linux), and invokes the test. I then add each asan test using a macro, along the lines of Tsyvarev's answer.
macro(add_asan_test basename)
add_executable(${basename} ${basename}.c)
add_test(NAME test/${basename} COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/wrap_clang_sanitizer_test.py -a $<TARGET_FILE:${basename}>)
set_tests_properties(test/${basename} PROPERTIES WILL_FAIL TRUE)
endmacro()
This gives a simple pass/fail as quickly as possible. I'm in the habit of investigating failures by running the test in question from the shell by hand and examining the output, in which case I get the stack trace as normal (and the fact exiting by abort is a bit slow is less of a problem).
(There are similar options for the other sanitizers, but I haven't investigated them.)
I recently had a case where someone added a parameter to an init method and broke another project that shared the code. Since it's only a warning, nobody realized the app was broken, so I'm trying to turn only this warning into an error:
warning: instance method '-someMethod' not found (return type defaults to 'id')
I've found that you can pass -Werror=foo in Other C Flags to the compiler in Xcode to turn a warning into the error, but I can't seem to find what 'foo' should be. I've tried 'undeclared-selectors' but that only catches #selector cases. I've tried -Werror-implicit-function-declaration but that doesn't seem to catch that case either.
I tried 'inst-method-not-found' and 'instance-method-not-found' after finding 'warn_inst_method_not_found' during a casual search of the huge clang source code.
Help ... ?
Update:
Here's an example you can compile (e.g. in CodeRunner) to see the warning: https://gist.github.com/4045701
The option you're looking for is -Werror=objc-method-access. Clang explicitly tells you this right in the warning message, if you download and compile that gist you posted:
% clang test.m -c
test.m:13:21: warning: instance method '-initWithNum:' not found (return type
defaults to 'id') [-Wobjc-method-access]
...theObj = [[MyClass alloc] initWithNum: [NSNumber numberWithInt: 15]];
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
% clang test.m -Werror=objc-method-access -c // ta-da!
But in real-world situations I agree with all the commenters above: You should fix or suppress all compiler warnings. Your build should build cleanly all the time. Otherwise, as you so rightly observed, you won't be able to distinguish real bugs from "the usual spam".
FWIW, here's the version of Clang I'm using:
$ clang --version
clang version 3.2 (http://llvm.org/git/llvm 1503aba4a036f5394c7983417bc1e64613b2fc77)
Target: x86_64-apple-darwin12.2.0
Thread model: posix
I have this Objective-C istruction:
NSRange range = NSMakeRange(i, MIN(a, b));
where a and bare NSUIntegers.
MIN() is the macro defined in the standard NSObjCRuntime.hheader file as:
#if !defined(MIN)
#define MIN(A,B) ({ __typeof__(A) __a = (A); __typeof__(B) __b = (B); __a < __b ? __a : __b; })
#endif
During the compilation, the LLVM Compiler 4.1 highlights my instruction showing the warning: "Use of GNU statement expression extension".
What does this mean? Is it my fault? If yes, how can I fix it? If not, how can I remove the compiler warning?
It’s a late answer, I know, but you can avoid this message by adding -Wno-gnu to your compiler flags.
(In Xcode 5 I believe you can change this by going to your project’s Build Settings and adding -Wno-gnu to the “Other C Flags”, which are in the “Apple LLVM 5.0 – Custom Compiler Flags” section.)
"Statement expressions" is an extension of the GNU C compiler and allows you to execute a group of statements, returning the value of the last statement:
x = ({
statement1;
statement2;
statement3;
});
In the above example, x will have the value returned by statement3.
It is a convenient feature that enables you to have multi-statement macros that can be nested easily into other expressions. It is not, however, defined by any C standard.
Don't use -Wno-gnu, that shuts down too many warnings. Instead, use:
-Wno-gnu-statement-expression
Statement expressions have been declared.
You can selectively ignore the warning by using pragma codes without changing project settings.
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wgnu"
NSRange range = NSMakeRange(i, MIN(a, b));
#pragma GCC diagnostic pop
I have tested a bit of assembler on Linux using the AT&T syntax. One thing that struck me was that the book I was reading was written from a 32-bit standpoint. Thus, all sizes would have to be changed to the correct 64-bit versions for me. Or I could (which I did) assemble the code using the --32 flag for as and the -melf_i386 flag for ld when linking. I have also adapted some of the code and to run on Windows under Cygwin.
But that got me thinking. Is there a way to do ifdef like checks in assembler to do one thing if I'm on Windows and another under Linux and also handle 32 vs 64 bit that way? For example to have a .globl _start under Linux and a .globl _main under Windows.
Or is this handled by checking before assembling and having different source files to assemble based on the result of the checks?
I.e. foo_linux.s and foo_windows.s
If so, how do you overcome that fact that you will not know which .s files you will use, and thus have to include, when you are creating your program?
For example, say that we have a socket_linux.s and a socket_windows.s. They both present an identical interface but do the OS specific work associated to sockets. But when I work with the sockets in my program I will not know if I need the Windows or Linux version included. So I would be kinda screwed :)
So how is this handled in Assembler? In C++ for example I could include my socket.h and socket.cpp and wrap all the Linux and Windows specific code in #ifdef statements.
If you use GCC to compile your files and name them .S (with uppercase S) or .sx, it will pass them through the preprocessor before invoking the assembler.
From the docs:
file.s
Assembler code.
file.S
file.sx
Assembler code which must be preprocessed.
You can add -v to the command line to see how the various sub-processes are invoked.
in MASM (.asm), you can use ifdef, ifndef and the likes, as:
ifdef X64
endif
When writing for different platforms you can define some macro for loading target specific files:
FILE target.h
#if defined(__arm__)
#define target "arm"
#elif defined(__x86_64__)
#if defined(_WIN64)
#define target "win64"
#else
#define target "linux64" // all non-Win share the same calling convention
#endif
#else
// 32bit defs
#endif
Then you can include target specific files with the macro, two string literals successively get one single literal:
#include "target.h"
#include "target_specific_code_" target ".h"
It includes one of these files:
target_specific_code_arm.h
target_specific_code_win64.h
target_specific_code_linux64.h
...
EDIT:
Like this, you can also define target specific assembler instructions for later use in inline assembly:
#ifdef ...
#define ASM_PP_LOAD_WORD "movi "
#else
#define ASM_PP_LOAD_WORD "mov "
#endif
or as macro
#ifdef ...
// when using intel assembler there is a different
// order of parameters
#define ASM_PP_LOAD_WORD(a, b) "movi " #b ", " #a
#else
#define ASM_PP_LOAD_WORD(a, b) "mov " #a ", " #b
#endif