aboutsummaryrefslogtreecommitdiff
path: root/gdb/warning.m4
AgeCommit message (Collapse)AuthorFilesLines
2018-05-10Fix the clang buildTom Tromey1-1/+1
Simon pointed out that gdb would not build with clang, due to the addition of -Wimplicit-fallthrough. This patch fixes the problem by using -Wimplicit-fallthrough=3 -- this does not work with clang, bypassing the issue. Tested by rebuilding with both gcc and clang; and also by verifying that -Wimplicit-fallthrough=3 is used in the gcc build. I will file a follow-up bug to convert the fall-through comments to a form that can be used by both clang and gcc. gdb/ChangeLog 2018-05-10 Tom Tromey <tom@tromey.com> * configure: Rebuild. * warning.m4 (AM_GDB_WARNINGS): Use -Wimplicit-fallthrough=3. gdb/gdbserver/ChangeLog 2018-05-10 Tom Tromey <tom@tromey.com> * configure: Rebuild.
2018-05-07Add -Wduplicated-condTom Tromey1-1/+2
This adds -Wduplicated-cond to warnings.m4. This caught one bug. I tried adding -Wduplicated-branches as well, but it results in some spurious failures from code like this in cgen.h: #define CGEN_ATTR_TYPE(n) \ struct { unsigned int bool_; \ CGEN_ATTR_VALUE_TYPE nonbool[(n) ? (n) : 1]; } This will trigger a warning if passed n==1, which seems like a perfectly valid thing to do; and there were other issues like this as well. ChangeLog 2018-05-07 Tom Tromey <tom@tromey.com> * configure: Rebuild. * warning.m4 (AM_GDB_WARNINGS): Add -Wduplicated-cond. gdbserver/ChangeLog 2018-05-07 Tom Tromey <tom@tromey.com> * configure: Rebuild.
2018-05-04Add -Wimplicit-fallthroughTom Tromey1-1/+2
This adds -Wimplicit-fallthrough to the set of default warnings. 2018-05-04 Tom Tromey <tom@tromey.com> * configure: Rebuild. * warning.m4 (AM_GDB_WARNINGS): Add -Wimplicit-fallthrough. gdbserver/ChangeLog 2018-05-04 Tom Tromey <tom@tromey.com> * configure: Rebuild.
2018-04-27Enable -Wsuggest-overrideTom Tromey1-1/+2
I noticed the existence of -Wsuggest-override and so this patch enables it for gdb. It found a few spots that could use "override". Also I went ahead and removed all uses of the "OVERRIDE" macro. Using override is beneficial because it makes it harder to change a base class and then forget to change a derived class. Tested by the buildbot. ChangeLog 2018-04-27 Tom Tromey <tom@tromey.com> * configure: Rebuild. * warning.m4 (AM_GDB_WARNINGS): Add -Wsuggest-override. * dwarf2loc.c (class dwarf_evaluate_loc_desc): Use "override", not "OVERRIDE". (class symbol_needs_eval_context): Likewise. * dwarf2read.c (mock_mapped_index::symbol_name_count) (mock_mapped_index::symbol_name_at): Use "override". Remove "virtual". * dwarf2-frame.c (dwarf_expr_executor::get_addr_index): Use "override". (class dwarf_expr_executor): Use "override", not "OVERRIDE". * aarch64-tdep.c (instruction_reader::read): Use "override". (instruction_reader_test::read): Likewise. * arm-tdep.c (instruction_reader::read): Use "override". (instruction_reader_thumb::read): Likewise. gdbserver/ChangeLog 2018-04-27 Tom Tromey <tom@tromey.com> * configure: Rebuild.
2018-04-06Add -Wno-error=deprecated-register to gdb build flagsSimon Marchi1-1/+2
As shown in PR 23022, building with clang-6 and Python 2 trips on the fact that the Python 2 headers use the "register" keyword: /usr/include/python2.7/unicodeobject.h:534:5: error: 'register' storage class specifier is deprecated and incompatible with C++17 [-Werror,-Wdeprecated-register] register PyObject *obj, /* Object */ ^~~~~~~~~ This patch adds -Wno-error=deprecated-register to our flags, so that we can still see this class of warnings, but they don't cause a build failure. gdb/ChangeLog: PR gdb/23022 * warning.m4: Add -Wno-error=deprecated-register. * configure: Re-generate.
2018-01-02Update copyright year range in all GDB filesJoel Brobecker1-1/+1
gdb/ChangeLog: Update copyright year range in all GDB files
2017-09-22Fix gdb 8.1 Solaris compilationRainer Orth1-3/+10
I just tried to compile gdb trunk on Solaris 11.4 (formerly 12), and failed for a couple of reasons: * In file included from /usr/include/python2.7/Python.h:128:0, from /vol/src/gnu/gdb/gdb/dist/gdb/python/python-internal.h:94, from /vol/src/gnu/gdb/gdb/dist/gdb/python/py-instruction.h:23, from /vol/src/gnu/gdb/gdb/dist/gdb/python/py-instruction.c:21: /usr/include/python2.7/ceval.h:67:0: error: ignoring #pragma no_inline [-Werror=unknown-pragmas] #pragma no_inline(PyEval_EvalFrameEx) ^ New in Solaris 11.4: <python2.7/ceval.h> uses a Studio-only #pragma. I've disabled the warning in warnings.m4. * /vol/src/gnu/gdb/gdb/dist/gdb/ser-pipe.c: In function ‘int pipe_open(serial*, const char*)’: /vol/src/gnu/gdb/gdb/dist/gdb/ser-pipe.c:77:9: error: ‘pid_t vfork()’ is deprecated (declared at /usr/include/unistd.h:659) [-Werror=deprecated-declarations] pid = vfork (); ^ /vol/src/gnu/gdb/gdb/dist/gdb/ser-pipe.c:77:16: error: ‘pid_t vfork()’ is deprecated (declared at /usr/include/unistd.h:659) [-Werror=deprecated-declarations] pid = vfork (); ^ Since Solaris 11, vfork () is marked deprecated in <unistd.h>. cf. vfork(2): The vfork() and vforkx() functions are deprecated. Their sole legiti- mate use as a prelude to an immediate call to a function from the exec family can be achieved safely by posix_spawn(3C) or posix_spawnp(3C). Again, I've disabled the warning. * /vol/src/gnu/gdb/gdb/dist/gdb/cli/cli-cmds.c: In function ‘void shell_escape(const char*, int)’: /vol/src/gnu/gdb/gdb/dist/gdb/cli/cli-cmds.c:750:14: error: ‘pid_t vfork()’ is deprecated (declared at /usr/include/unistd.h:659) [-Werror=deprecated-declarations] if ((pid = vfork ()) == 0) ^ /vol/src/gnu/gdb/gdb/dist/gdb/cli/cli-cmds.c:750:21: error: ‘pid_t vfork()’ is deprecated (declared at /usr/include/unistd.h:659) [-Werror=deprecated-declarations] if ((pid = vfork ()) == 0) ^ Same problem. * /vol/src/gnu/gdb/gdb/dist/gdb/procfs.c: In function ‘void procfs_init_inferior(target_ops*, int)’: /vol/src/gnu/gdb/gdb/dist/gdb/procfs.c:4380:30: error: ‘START_INFERIOR_TRAPS_EXPECTED’ was not declared in this scope gdb_startup_inferior (pid, START_INFERIOR_TRAPS_EXPECTED); ^ defined in nat/fork-inferior.h, need to include that header /vol/src/gnu/gdb/gdb/dist/gdb/procfs.c: In function ‘void procfs_create_inferior(target_ops*, const char*, const string&, char**, int)’: /vol/src/gnu/gdb/gdb/dist/gdb/procfs.c:4605:38: error: ‘fork_inferior’ was not declared in this scope NULL, NULL, shell_file, NULL); ^ likewise /vol/src/gnu/gdb/gdb/dist/gdb/procfs.c: In function ‘void procfs_info_proc(target_ops*, const char*, info_proc_what)’: /vol/src/gnu/gdb/gdb/dist/gdb/procfs.c:5124:20: error: ‘argv’ was not declared in this scope for (char *arg : argv) ^ Typo, should be built_argv instead! * Undefined first referenced symbol in file fork_inferior(char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char**, void (*)(), void (*)(int), void (*)(), char const*, void (*)(char const*, char* const*, char* const*)) procfs.o startup_inferior(int, int, target_waitstatus*, ptid_t*) fork-child.o ld: fatal: symbol referencing errors collect2: error: ld returned 1 exit status make[2]: *** [Makefile:2249: gdb] Error 1 Need to add fork-inferior.o to NATDEPFILES. With the changes below, I can build gdb on sparcv9-sun-solaris2.11 and amd64-pc-solaris2.11 and a simple smoke test (gdb/gdb gdb/gdb) works.
2017-06-17gdb: Add -Wno-mismatched-tagsSimon Marchi1-1/+2
clang complains that for some types, we use both the class and struct keywords in different places. It's not really a problem, so I think we can safely turn this warning off. gdb/ChangeLog: * configure: Re-generate. * warning.m4 (build_warnings): Add -Wno-mismatched-tags. gdb/gdbserver/ChangeLog: * configure: Re-generate.
2017-06-17gdb: Use -Werror when checking for (un)supported warning flagsSimon Marchi1-2/+2
In warning.m4, we pass all the warning flags one by one to the compiler to test if they are supported by this particular compiler. If the compiler exits with an error, we conclude that this warning flag is not supported and exclude it. This allows us to use warning flags without having to worry about which versions of which compilers support each flag. clang, by default, only emits a warning if an unknown flag is passed: warning: unknown warning option '-Wfoo' [-Wunknown-warning-option] The result is that we think that all the warning flags we use are supported by clang (they are not), and the compilation fails later when building with -Werror, since the aforementioned warning becomes an error. The fix is to also pass -Werror when probing for supported flags, then we'll correctly get an error when using an unknown warning, and we'll exclude it: error: unknown warning option '-Wfoo' [-Werror,-Wunknown-warning-option] I am not sure why there is a change in a random comment in gdbserver/configure, but I suppose it's a leftfover from a previous patch, so I included it. gdb/ChangeLog: * configure: Re-generate. * warning.m4: Pass -Werror to compiler when checking for supported warning flags. gdb/gdbserver/ChangeLog: * configure: Re-generate.
2017-05-05gdb: Disable -Werror for -Wmaybe-uninitializedPedro Alves1-1/+1
Newer GCCs are triggering false-positive -Wmaybe-uninitialized warnings around code that uses gdb::optional: https://sourceware.org/ml/gdb-patches/2017-05/msg00118.html Using std::optional wouldn't help, it triggers the same warnings: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 Initializing the variables to quiet the warning would defeat the purpose of gdb::optional. Making the optional ctor memset its storage would be a pessimization. Wrapping gdb::optional's internals with "#pragma GCC diagnostic push/ignored/pop" doesn't work, we'd have to wrap uses of gdb::optional instead, which I think would get unwieldy and ugly as we start using gdb::optional more and more. The -Wmaybe-uninitialized warning is documented as producing false positives (unlike -Wuninialized), so until we find a better workaround, disable -Werror for this warning. You'll still see the warning when building gdb, but it won't cause a build failure. Tested by building with gcc 4.8.5, 5.3.1, and gcc trunk (20170428). gdb/ChangeLog: 2017-05-05 Pedro Alves <palves@redhat.com> * warning.m4 (build_warnings): Add -Wno-error=maybe-uninitialized. * configure: Regenerate. gdb/gdbserver/ChangeLog: 2017-05-05 Pedro Alves <palves@redhat.com> * configure: Regenerate.
2017-04-05-Wwrite-strings: Remove -Wno-write-stringsPedro Alves1-1/+1
AFAIK GDB is now free from -Wwrite-strings warnings. A few warnings may be left behind in some host-specific code, but those should be few and easy to fix. gdb/ChangeLog: 2017-04-05 Pedro Alves <palves@redhat.com> * warning.m4 (build_warnings): Remove -Wno-write-strings. * configure: Regenerate. gdb/gdbserver/ChangeLog: 2017-04-05 Pedro Alves <palves@redhat.com> * configure: Regenerate.
2017-01-01update copyright year range in GDB filesJoel Brobecker1-1/+1
This applies the second part of GDB's End of Year Procedure, which updates the copyright year range in all of GDB's files. gdb/ChangeLog: Update copyright year range in all GDB files.
2016-09-05gdb/: Require a C++ compilerPedro Alves1-18/+5
This removes all support for building gdb & gdbserver with a C compiler from gdb & gdbserver's build machinery. gdb/ChangeLog: 2016-09-05 Pedro Alves <palves@redhat.com> * NEWS: Mention that a C++ compiler is now required. * Makefile.in (COMPILER, COMPILER_CFLAGS): Remove. (COMPILE.pre, CC_LD): Use CXX directly. (INTERNAL_CFLAGS_BASE): Use CXXFLAGS directly. * acinclude.m4: Don't include build-with-cxx.m4. * build-with-cxx.m4: Delete file. * configure.ac: Remove GDB_AC_BUILD_WITH_CXX call. * warning.m4: Assume $enable_build_with_cxx is yes. * configure: Regenerate. gdb/gdbserver/ChangeLog: 2016-09-05 Pedro Alves <palves@redhat.com> * Makefile.in (COMPILER, COMPILER_CFLAGS): Remove. (COMPILE.pre, CC_LD): Use CXX directly. (INTERNAL_CFLAGS_BASE): Use CXXFLAGS directly. * acinclude.m4: Don't include build-with-cxx.m4. * configure.ac: Remove GDB_AC_BUILD_WITH_CXX call. * configure: Regenerate.
2016-07-21Add -Wunused-but-set-* to buildTom Tromey1-1/+1
This adds -Wunused-but-set-variable and -Wunused-but-set-parameter to configure. 2016-07-21 Tom Tromey <tom@tromey.com> * configure: Rebuild. * warning.m4 (AM_GDB_WARNINGS) <build_warnings>: Add -Wunused-but-set-parameter, -Wunused-but-set-variable. 2016-07-21 Tom Tromey <tom@tromey.com> * configure: Rebuild.
2016-01-11gdb: split out warnings helpersMike Frysinger1-0/+133
This will allow the sim tree to use the same set of warnings. The new code in warning.m4 is exactly the same (other than the AC_DEFUN wrapping).