Message ID | 83h8rlyakm.fsf@gnu.org |
---|---|
State | New, archived |
Headers |
Received: (qmail 86745 invoked by alias); 16 Jan 2018 17:31:55 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 86728 invoked by uid 89); 16 Jan 2018 17:31:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.4 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=HContent-type:plain, H*r:4.82, HContent-type:charset, HContent-type:iso-8859-1 X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 16 Jan 2018 17:31:52 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <eliz@gnu.org>) id 1ebV5P-0006FL-Ir for gdb-patches@sourceware.org; Tue, 16 Jan 2018 12:31:50 -0500 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44634) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@gnu.org>) id 1ebV5P-0006FF-Fz for gdb-patches@sourceware.org; Tue, 16 Jan 2018 12:31:47 -0500 Received: from [176.228.60.248] (port=1421 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@gnu.org>) id 1ebV5O-0004Hh-Vy for gdb-patches@sourceware.org; Tue, 16 Jan 2018 12:31:47 -0500 Date: Tue, 16 Jan 2018 19:31:37 +0200 Message-Id: <83h8rlyakm.fsf@gnu.org> From: Eli Zaretskii <eliz@gnu.org> To: gdb-patches@sourceware.org In-reply-to: <announce.20180105041805.3FC35808E9@joel.gnat.com> (message from Joel Brobecker on Fri, 5 Jan 2018 08:18:05 +0400 (+04)) Subject: Re: [ANNOUNCEMENT] GDB 8.1 release branch created! Reply-to: Eli Zaretskii <eliz@gnu.org> References: <announce.20180105041805.3FC35808E9@joel.gnat.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-IsSubscribed: yes |
Commit Message
Eli Zaretskii
Jan. 16, 2018, 5:31 p.m. UTC
> From: Joel Brobecker <brobecker@adacore.com> > Date: Fri, 5 Jan 2018 08:18:05 +0400 (+04) > > A quick message to announce that the GDB 8.1 branch has just been created. > > The prerelease snapshots will be available at: > > ftp://sourceware.org/pub/gdb/snapshots/branch/gdb.tar.xz > ftp://sourceware.org/pub/gdb/snapshots/branch/gdb.tar.gz I've built this pre-release with mingw.org's MinGW, and found a few problems. The most serious one is the following compilation error: g++ -x c++ -O2 -gdwarf-4 -g3 -I. -I. -I./common -I./config -DLOCALEDIR="\"d:/usr/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./gnulib/import -Ibuild-gnulib/import -DTUI=1 -Id:/usr/include -Id:/usr/include/guile/2.0 -Id:/usr/include -Id:/usr/Python26/include -Id:/usr/Python26/include -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized -Wno-format -fno-strict-aliasing -DNDEBUG -fwrapv -c -o python/py-arch.o -MT python/py-arch.o -MMD -MP -MF python/.deps/py-arch.Tpo python/py-arch.c In file included from d:\usr\lib\gcc\mingw32\6.3.0\include\c++\math.h:36:0, from build-gnulib/import/math.h:27, from d:/usr/Python26/include/pyport.h:235, from d:/usr/Python26/include/Python.h:58, from python/python-internal.h:94, from python/py-arch.c:24: d:\usr\lib\gcc\mingw32\6.3.0\include\c++\cmath:1157:11: error: '::hypot' has not been declared using ::hypot; ^~~~~ Makefile:1618: recipe for target `python/py-arch.o' failed Googling suggests the following solution; is it okay to push this (with the necessary logs and after doing the "paperwork" required for branch changes)? Or does someone have better ideas? (Does this work in MinGW64?) The other problems I saw are compilation warnings, see below. Some of them sound like GCC doesn't understand our TRY/CATCH blocks, but others seem like real problems, at least from the POV of a naïve reader such as myself. I wonder how come others don't see these warnings, and why weren't they fixed during development, when we use -Werror. Here are the warnings I saw: g++ -x c++ -O2 -gdwarf-4 -g3 -I. -I. -I./common -I./config -DLOCALEDIR="\"d:/usr/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./gnulib/import -Ibuild-gnulib/import -DTUI=1 -Id:/usr/include -Id:/usr/include/guile/2.0 -Id:/usr/include -Id:/usr/Python26/include -Id:/usr/Python26/include -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized -Wno-format -c -o cli/cli-cmds.o -MT cli/cli-cmds.o -MMD -MP -MF cli/.deps/cli-cmds.Tpo cli/cli-cmds.c cli/cli-cmds.c: In function 'void complete_command(const char*, int)': cli/cli-cmds.c:277:71: warning: 'word' may be used uninitialized in this function [-Wmaybe-uninitialized] = tracker->build_completion_result (word, word - arg, strlen (arg)); ^ cli/cli-cmds.c:277:71: warning: 'tracker' may be used uninitialized in this function [-Wmaybe-uninitialized] g++ -x c++ -O2 -gdwarf-4 -g3 -I. -I. -I./common -I./config -DLOCALEDIR="\"d:/usr/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./gnulib/import -Ibuild-gnulib/import -DTUI=1 -Id:/usr/include -Id:/usr/include/guile/2.0 -Id:/usr/include -Id:/usr/Python26/include -Id:/usr/Python26/include -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized -Wno-format -c -o breakpoint.o -MT breakpoint.o -MMD -MP -MF ./.deps/breakpoint.Tpo breakpoint.c breakpoint.c: In function 'void check_status_watchpoint(bpstat)': breakpoint.c:5079:4: warning: 'e' may be used uninitialized in this function [-Wmaybe-uninitialized] switch (e) ^~~~~~ breakpoint.c:5056:20: note: 'e' was declared here wp_check_result e; ^ g++ -x c++ -O2 -gdwarf-4 -g3 -I. -I. -I./common -I./config -DLOCALEDIR="\"d:/usr/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./gnulib/import -Ibuild-gnulib/import -DTUI=1 -Id:/usr/include -Id:/usr/include/guile/2.0 -Id:/usr/include -Id:/usr/Python26/include -Id:/usr/Python26/include -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized -Wno-format -c -o infrun.o -MT infrun.o -MMD -MP -MF ./.deps/infrun.Tpo infrun.c In file included from infrun.c:26:0: inferior.h: In function 'void handle_vfork_child_exec_or_exit(int)': inferior.h:537:39: warning: '*((void*)(& maybe_restore_inferior)+20).scoped_restore_current_inferior::m_saved_inf' may be used uninitialized in this function [-Wmaybe-uninitialized] { set_current_inferior (m_saved_inf); } ^ infrun.c:927:6: note: '*((void*)(& maybe_restore_inferior)+20).scoped_restore_current_inferior::m_saved_inf' was declared here maybe_restore_inferior; ^~~~~~~~~~~~~~~~~~~~~~ In file included from inferior.h:48:0, from infrun.c:26: progspace.h:285:47: warning: '*((void*)(& maybe_restore_inferior)+16).scoped_restore_current_program_space::m_saved_pspace' may be used uninitialized in this function [-Wmaybe-uninitialized] { set_current_program_space (m_saved_pspace); } ^ infrun.c:927:6: note: '*((void*)(& maybe_restore_inferior)+16).scoped_restore_current_program_space::m_saved_pspace' was declared here maybe_restore_inferior; ^~~~~~~~~~~~~~~~~~~~~~ g++ -x c++ -O2 -gdwarf-4 -g3 -I. -I. -I./common -I./config -DLOCALEDIR="\"d:/usr/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./gnulib/import -Ibuild-gnulib/import -DTUI=1 -Id:/usr/include -Id:/usr/include/guile/2.0 -Id:/usr/include -Id:/usr/Python26/include -Id:/usr/Python26/include -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized -Wno-format -c -o typeprint.o -MT typeprint.o -MMD -MP -MF ./.deps/ typeprint.Tpo typeprint.c typeprint.c: In function 'void whatis_exp(const char*, int)': typeprint.c:515:60: warning: 'val' may be used uninitialized in this function [-Wmaybe-uninitialized] real_type = value_rtti_type (val, &full, &top, &using_enc); ^ g++ -x c++ -O2 -gdwarf-4 -g3 -I. -I. -I./common -I./config -DLOCALEDIR="\"d:/usr/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./gnulib/import -Ibuild-gnulib/import -DTUI=1 -Id:/usr/include -Id:/usr/include/guile/2.0 -Id:/usr/include -Id:/usr/Python26/include -Id:/usr/Python26/include -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized -Wno-format -c -o compile/compile.o -MT compile/compile.o -MMD -MP -MF compile/.deps/compile.Tpo compile/compile.c compile/compile.c: In function 'void eval_compile_command(command_line*, const char*, compile_i_scope_types, void*)': compile/compile.c:549:20: warning: 'triplet_rx' may be used uninitialized in this function [-Wmaybe-uninitialized] argc, argv); ^ compile/compile.c:466:9: note: 'triplet_rx' was declared here char *triplet_rx; ^~~~~~~~~~
Comments
On Tuesday, January 16 2018, Eli Zaretskii wrote: > I've built this pre-release with mingw.org's MinGW, and found a few > problems. [...] > The other problems I saw are compilation warnings, see below. Some of > them sound like GCC doesn't understand our TRY/CATCH blocks, but others > seem like real problems, at least from the POV of a naïve reader such > as myself. I wonder how come others don't see these warnings, and why > weren't they fixed during development, when we use -Werror. Here are > the warnings I saw: > [...] > g++ -x c++ -O2 -gdwarf-4 -g3 -I. -I. -I./common -I./config -DLOCALEDIR="\"d:/usr/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./gnulib/import -Ibuild-gnulib/import -DTUI=1 -Id:/usr/include -Id:/usr/include/guile/2.0 -Id:/usr/include -Id:/usr/Python26/include -Id:/usr/Python26/include -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized -Wno-format -c -o infrun.o -MT infrun.o -MMD -MP -MF ./.deps/infrun.Tpo infrun.c > In file included from infrun.c:26:0: > inferior.h: In function 'void handle_vfork_child_exec_or_exit(int)': > inferior.h:537:39: warning: '*((void*)(& maybe_restore_inferior)+20).scoped_restore_current_inferior::m_saved_inf' may be used uninitialized in this function [-Wmaybe-uninitialized] > { set_current_inferior (m_saved_inf); } > ^ > infrun.c:927:6: note: '*((void*)(& maybe_restore_inferior)+20).scoped_restore_current_inferior::m_saved_inf' was declared here > maybe_restore_inferior; > ^~~~~~~~~~~~~~~~~~~~~~ > In file included from inferior.h:48:0, > from infrun.c:26: > progspace.h:285:47: warning: '*((void*)(& maybe_restore_inferior)+16).scoped_restore_current_program_space::m_saved_pspace' may be used uninitialized in this function [-Wmaybe-uninitialized] > { set_current_program_space (m_saved_pspace); } > ^ > infrun.c:927:6: note: '*((void*)(& maybe_restore_inferior)+16).scoped_restore_current_program_space::m_saved_pspace' was declared here > maybe_restore_inferior; > ^~~~~~~~~~~~~~~~~~~~~~ > > g++ -x c++ -O2 -gdwarf-4 -g3 -I. -I. -I./common -I./config -DLOCALEDIR="\"d:/usr/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./gnulib/import -Ibuild-gnulib/import -DTUI=1 -Id:/usr/include -Id:/usr/include/guile/2.0 -Id:/usr/include -Id:/usr/Python26/include -Id:/usr/Python26/include -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized -Wno-format -c -o typeprint.o -MT typeprint.o -MMD -MP -MF ./.deps/ > typeprint.Tpo typeprint.c > typeprint.c: In function 'void whatis_exp(const char*, int)': > typeprint.c:515:60: warning: 'val' may be used uninitialized in this function [-Wmaybe-uninitialized] > real_type = value_rtti_type (val, &full, &top, &using_enc); > ^ > > g++ -x c++ -O2 -gdwarf-4 -g3 -I. -I. -I./common -I./config -DLOCALEDIR="\"d:/usr/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./gnulib/import -Ibuild-gnulib/import -DTUI=1 -Id:/usr/include -Id:/usr/include/guile/2.0 -Id:/usr/include -Id:/usr/Python26/include -Id:/usr/Python26/include -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized -Wno-format -c -o compile/compile.o -MT compile/compile.o -MMD -MP -MF compile/.deps/compile.Tpo compile/compile.c > compile/compile.c: In function 'void eval_compile_command(command_line*, const char*, compile_i_scope_types, void*)': > compile/compile.c:549:20: warning: 'triplet_rx' may be used uninitialized in this function [-Wmaybe-uninitialized] > argc, argv); > ^ > compile/compile.c:466:9: note: 'triplet_rx' was declared here > char *triplet_rx; > ^~~~~~~~~~ FWIW, I've seen these warnings when preparing a Fedora GDB release. I'll take a look at them.
On Tuesday, January 16 2018, I wrote: >> g++ -x c++ -O2 -gdwarf-4 -g3 -I. -I. -I./common -I./config -DLOCALEDIR="\"d:/usr/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./gnulib/import -Ibuild-gnulib/import -DTUI=1 -Id:/usr/include -Id:/usr/include/guile/2.0 -Id:/usr/include -Id:/usr/Python26/include -Id:/usr/Python26/include -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized -Wno-format -c -o infrun.o -MT infrun.o -MMD -MP -MF ./.deps/infrun.Tpo infrun.c >> In file included from infrun.c:26:0: >> inferior.h: In function 'void handle_vfork_child_exec_or_exit(int)': >> inferior.h:537:39: warning: '*((void*)(& maybe_restore_inferior)+20).scoped_restore_current_inferior::m_saved_inf' may be used uninitialized in this function [-Wmaybe-uninitialized] >> { set_current_inferior (m_saved_inf); } >> ^ >> infrun.c:927:6: note: '*((void*)(& maybe_restore_inferior)+20).scoped_restore_current_inferior::m_saved_inf' was declared here >> maybe_restore_inferior; >> ^~~~~~~~~~~~~~~~~~~~~~ >> In file included from inferior.h:48:0, >> from infrun.c:26: >> progspace.h:285:47: warning: '*((void*)(& maybe_restore_inferior)+16).scoped_restore_current_program_space::m_saved_pspace' may be used uninitialized in this function [-Wmaybe-uninitialized] >> { set_current_program_space (m_saved_pspace); } >> ^ >> infrun.c:927:6: note: '*((void*)(& maybe_restore_inferior)+16).scoped_restore_current_program_space::m_saved_pspace' was declared here >> maybe_restore_inferior; >> ^~~~~~~~~~~~~~~~~~~~~~ I'm not sure why this one is happening. I think it has something to do with the fact that we're declaring "maybe_restore_inferior" as gdb::optional, because scoped_restore_current_inferior's constructor already takes care of initializing "m_saved_inf" (same goes for scoped_restore_current_program_space). If that is the case, then maybe we can mark the "uninitialized variable" warning for "m_saved_inf" and "m_saved_pspace". WDYT?
> From: Sergio Durigan Junior <sergiodj@redhat.com> > Cc: gdb-patches@sourceware.org > Date: Tue, 16 Jan 2018 15:36:22 -0500 > > I'm not sure why this one is happening. I think it has something to do > with the fact that we're declaring "maybe_restore_inferior" as > gdb::optional, because scoped_restore_current_inferior's constructor > already takes care of initializing "m_saved_inf" (same goes for > scoped_restore_current_program_space). > > If that is the case, then maybe we can mark the "uninitialized variable" > warning for "m_saved_inf" and "m_saved_pspace". Sorry, I'm not sure I understand what does your suggestion here mean in practice. Can you elaborate, or show a proposed patch? Thanks.
On 01/16/2018 08:36 PM, Sergio Durigan Junior wrote: > I'm not sure why this one is happening. I think it has something to do > with the fact that we're declaring "maybe_restore_inferior" as > gdb::optional, because scoped_restore_current_inferior's constructor > already takes care of initializing "m_saved_inf" (same goes for > scoped_restore_current_program_space). https://sourceware.org/ml/gdb-patches/2017-05/msg00130.html Thanks, Pedro Alves
On Wednesday, January 17 2018, Pedro Alves wrote: > On 01/16/2018 08:36 PM, Sergio Durigan Junior wrote: > >> I'm not sure why this one is happening. I think it has something to do >> with the fact that we're declaring "maybe_restore_inferior" as >> gdb::optional, because scoped_restore_current_inferior's constructor >> already takes care of initializing "m_saved_inf" (same goes for >> scoped_restore_current_program_space). > > https://sourceware.org/ml/gdb-patches/2017-05/msg00130.html Ah, there you go. Thanks, Pedro. I had missed that exchange of messages.
On Tuesday, January 16 2018, Eli Zaretskii wrote: >> From: Sergio Durigan Junior <sergiodj@redhat.com> >> Cc: gdb-patches@sourceware.org >> Date: Tue, 16 Jan 2018 15:36:22 -0500 >> >> I'm not sure why this one is happening. I think it has something to do >> with the fact that we're declaring "maybe_restore_inferior" as >> gdb::optional, because scoped_restore_current_inferior's constructor >> already takes care of initializing "m_saved_inf" (same goes for >> scoped_restore_current_program_space). >> >> If that is the case, then maybe we can mark the "uninitialized variable" >> warning for "m_saved_inf" and "m_saved_pspace". > > Sorry, I'm not sure I understand what does your suggestion here mean > in practice. Can you elaborate, or show a proposed patch? Eli, with Pedro's reply, mentioning: https://sourceware.org/ml/gdb-patches/2017-05/msg00130.html I think there's not much we can do about the warning. Thanks,
> From: Sergio Durigan Junior <sergiodj@redhat.com> > Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sourceware.org > Date: Wed, 17 Jan 2018 11:38:08 -0500 > > > https://sourceware.org/ml/gdb-patches/2017-05/msg00130.html > > Ah, there you go. Thanks, Pedro. I had missed that exchange of > messages. How about using GCC pragma to shut up this warning in that particular place?
On 01/17/2018 04:46 PM, Eli Zaretskii wrote: >> From: Sergio Durigan Junior <sergiodj@redhat.com> >> Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sourceware.org >> Date: Wed, 17 Jan 2018 11:38:08 -0500 >> >>> https://sourceware.org/ml/gdb-patches/2017-05/msg00130.html >> >> Ah, there you go. Thanks, Pedro. I had missed that exchange of >> messages. > > How about using GCC pragma to shut up this warning in that particular > place? IIRC, last I tried, it make the code exceedingly ugly. See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635#c9 Thanks, Pedro Alves
> Cc: gdb-patches@sourceware.org > From: Pedro Alves <palves@redhat.com> > Date: Wed, 17 Jan 2018 16:49:58 +0000 > > > How about using GCC pragma to shut up this warning in that particular > > place? > IIRC, last I tried, it make the code exceedingly ugly. See: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635#c9 It doesn't look too ugly to me, FWIW. Its advantage is that it documents exactly what is the problem being worked around here, and makes finding the affected places easy. By contrast, leaving the warnings around and keeping the information about the problem in some mailing list posting makes its discoverability much lower, and the probability that someone else will spend time trying to understand it higher. And the warning is quite cryptic, at least to my naïve eyes.
Ping! Is it OK to install the patch proposed below? > Date: Tue, 16 Jan 2018 19:31:37 +0200 > From: Eli Zaretskii <eliz@gnu.org> > > g++ -x c++ -O2 -gdwarf-4 -g3 -I. -I. -I./common -I./config -DLOCALEDIR="\"d:/usr/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./gnulib/import -Ibuild-gnulib/import -DTUI=1 -Id:/usr/include -Id:/usr/include/guile/2.0 -Id:/usr/include -Id:/usr/Python26/include -Id:/usr/Python26/include -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized -Wno-format -fno-strict-aliasing -DNDEBUG -fwrapv -c -o python/py-arch.o -MT python/py-arch.o -MMD -MP -MF python/.deps/py-arch.Tpo python/py-arch.c > In file included from d:\usr\lib\gcc\mingw32\6.3.0\include\c++\math.h:36:0, > from build-gnulib/import/math.h:27, > from d:/usr/Python26/include/pyport.h:235, > from d:/usr/Python26/include/Python.h:58, > from python/python-internal.h:94, > from python/py-arch.c:24: > d:\usr\lib\gcc\mingw32\6.3.0\include\c++\cmath:1157:11: error: '::hypot' has not been declared > using ::hypot; > ^~~~~ > Makefile:1618: recipe for target `python/py-arch.o' failed > > Googling suggests the following solution; is it okay to push this > (with the necessary logs and after doing the "paperwork" required for > branch changes)? Or does someone have better ideas? (Does this work > in MinGW64?) > > --- gdb/python/python-internal.h~0 2018-01-12 05:31:04.000000000 +0200 > +++ gdb/python/python-internal.h 2018-01-16 08:56:10.717759900 +0200 > @@ -85,6 +85,12 @@ > #define HAVE_SNPRINTF 1 > #endif > > +/* Another kludge to avoid compilation errors because MinGW defines > + 'hypot' to '_hypot', but the C++ headers says "using ::hypot". */ > +#if defined(__MINGW32__) && defined(__cplusplus) > +# define _hypot hypot > +#endif > + > /* Request clean size types from Python. */ > #define PY_SSIZE_T_CLEAN > >
> Date: Thu, 18 Jan 2018 17:52:53 +0200 > From: Eli Zaretskii <eliz@gnu.org> Ping! Ping! OK to push this? > Ping! Is it OK to install the patch proposed below? > > > Date: Tue, 16 Jan 2018 19:31:37 +0200 > > From: Eli Zaretskii <eliz@gnu.org> > > > > g++ -x c++ -O2 -gdwarf-4 -g3 -I. -I. -I./common -I./config -DLOCALEDIR="\"d:/usr/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./gnulib/import -Ibuild-gnulib/import -DTUI=1 -Id:/usr/include -Id:/usr/include/guile/2.0 -Id:/usr/include -Id:/usr/Python26/include -Id:/usr/Python26/include -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized -Wno-format -fno-strict-aliasing -DNDEBUG -fwrapv -c -o python/py-arch.o -MT python/py-arch.o -MMD -MP -MF python/.deps/py-arch.Tpo python/py-arch.c > > In file included from d:\usr\lib\gcc\mingw32\6.3.0\include\c++\math.h:36:0, > > from build-gnulib/import/math.h:27, > > from d:/usr/Python26/include/pyport.h:235, > > from d:/usr/Python26/include/Python.h:58, > > from python/python-internal.h:94, > > from python/py-arch.c:24: > > d:\usr\lib\gcc\mingw32\6.3.0\include\c++\cmath:1157:11: error: '::hypot' has not been declared > > using ::hypot; > > ^~~~~ > > Makefile:1618: recipe for target `python/py-arch.o' failed > > > > Googling suggests the following solution; is it okay to push this > > (with the necessary logs and after doing the "paperwork" required for > > branch changes)? Or does someone have better ideas? (Does this work > > in MinGW64?) > > > > --- gdb/python/python-internal.h~0 2018-01-12 05:31:04.000000000 +0200 > > +++ gdb/python/python-internal.h 2018-01-16 08:56:10.717759900 +0200 > > @@ -85,6 +85,12 @@ > > #define HAVE_SNPRINTF 1 > > #endif > > > > +/* Another kludge to avoid compilation errors because MinGW defines > > + 'hypot' to '_hypot', but the C++ headers says "using ::hypot". */ > > +#if defined(__MINGW32__) && defined(__cplusplus) > > +# define _hypot hypot > > +#endif > > + > > /* Request clean size types from Python. */ > > #define PY_SSIZE_T_CLEAN > > > > >
Ping! Ping! Ping! This is delaying the release of GDB 8.1. Should I just stop waiting for approval and push this? > Date: Thu, 25 Jan 2018 18:58:30 +0200 > From: Eli Zaretskii <eliz@gnu.org> > > > Date: Thu, 18 Jan 2018 17:52:53 +0200 > > From: Eli Zaretskii <eliz@gnu.org> > > Ping! Ping! OK to push this? > > > Ping! Is it OK to install the patch proposed below? > > > > > Date: Tue, 16 Jan 2018 19:31:37 +0200 > > > From: Eli Zaretskii <eliz@gnu.org> > > > > > > g++ -x c++ -O2 -gdwarf-4 -g3 -I. -I. -I./common -I./config -DLOCALEDIR="\"d:/usr/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./gnulib/import -Ibuild-gnulib/import -DTUI=1 -Id:/usr/include -Id:/usr/include/guile/2.0 -Id:/usr/include -Id:/usr/Python26/include -Id:/usr/Python26/include -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized -Wno-format -fno-strict-aliasing -DNDEBUG -fwrapv -c -o python/py-arch.o -MT python/py-arch.o -MMD -MP -MF python/.deps/py-arch.Tpo python/py-arch.c > > > In file included from d:\usr\lib\gcc\mingw32\6.3.0\include\c++\math.h:36:0, > > > from build-gnulib/import/math.h:27, > > > from d:/usr/Python26/include/pyport.h:235, > > > from d:/usr/Python26/include/Python.h:58, > > > from python/python-internal.h:94, > > > from python/py-arch.c:24: > > > d:\usr\lib\gcc\mingw32\6.3.0\include\c++\cmath:1157:11: error: '::hypot' has not been declared > > > using ::hypot; > > > ^~~~~ > > > Makefile:1618: recipe for target `python/py-arch.o' failed > > > > > > Googling suggests the following solution; is it okay to push this > > > (with the necessary logs and after doing the "paperwork" required for > > > branch changes)? Or does someone have better ideas? (Does this work > > > in MinGW64?) > > > > > > --- gdb/python/python-internal.h~0 2018-01-12 05:31:04.000000000 +0200 > > > +++ gdb/python/python-internal.h 2018-01-16 08:56:10.717759900 +0200 > > > @@ -85,6 +85,12 @@ > > > #define HAVE_SNPRINTF 1 > > > #endif > > > > > > +/* Another kludge to avoid compilation errors because MinGW defines > > > + 'hypot' to '_hypot', but the C++ headers says "using ::hypot". */ > > > +#if defined(__MINGW32__) && defined(__cplusplus) > > > +# define _hypot hypot > > > +#endif > > > + > > > /* Request clean size types from Python. */ > > > #define PY_SSIZE_T_CLEAN > > > > > > > > >
On 2018-01-26 09:18 AM, Eli Zaretskii wrote: > Ping! Ping! Ping! This is delaying the release of GDB 8.1. > > Should I just stop waiting for approval and push this? Hi Eli, I didn't reply to your pings because I don't feel qualified to review changes related to mingw (you are probably the most qualified person here, since you use it). Given the lack of response, I'd say you can go ahead with the change, tt seems relatively safe. I have one question below. >> Date: Thu, 25 Jan 2018 18:58:30 +0200 >> From: Eli Zaretskii <eliz@gnu.org> >> >>> Date: Thu, 18 Jan 2018 17:52:53 +0200 >>> From: Eli Zaretskii <eliz@gnu.org> >> >> Ping! Ping! OK to push this? >> >>> Ping! Is it OK to install the patch proposed below? >>> >>>> Date: Tue, 16 Jan 2018 19:31:37 +0200 >>>> From: Eli Zaretskii <eliz@gnu.org> >>>> >>>> g++ -x c++ -O2 -gdwarf-4 -g3 -I. -I. -I./common -I./config -DLOCALEDIR="\"d:/usr/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./gnulib/import -Ibuild-gnulib/import -DTUI=1 -Id:/usr/include -Id:/usr/include/guile/2.0 -Id:/usr/include -Id:/usr/Python26/include -Id:/usr/Python26/include -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized -Wno-format -fno-strict-aliasing -DNDEBUG -fwrapv -c -o python/py-arch.o -MT python/py-arch.o -MMD -MP -MF python/.deps/py-arch.Tpo python/py-arch.c >>>> In file included from d:\usr\lib\gcc\mingw32\6.3.0\include\c++\math.h:36:0, >>>> from build-gnulib/import/math.h:27, >>>> from d:/usr/Python26/include/pyport.h:235, >>>> from d:/usr/Python26/include/Python.h:58, >>>> from python/python-internal.h:94, >>>> from python/py-arch.c:24: >>>> d:\usr\lib\gcc\mingw32\6.3.0\include\c++\cmath:1157:11: error: '::hypot' has not been declared >>>> using ::hypot; >>>> ^~~~~ >>>> Makefile:1618: recipe for target `python/py-arch.o' failed >>>> >>>> Googling suggests the following solution; is it okay to push this >>>> (with the necessary logs and after doing the "paperwork" required for >>>> branch changes)? Or does someone have better ideas? (Does this work >>>> in MinGW64?) >>>> >>>> --- gdb/python/python-internal.h~0 2018-01-12 05:31:04.000000000 +0200 >>>> +++ gdb/python/python-internal.h 2018-01-16 08:56:10.717759900 +0200 >>>> @@ -85,6 +85,12 @@ >>>> #define HAVE_SNPRINTF 1 >>>> #endif >>>> >>>> +/* Another kludge to avoid compilation errors because MinGW defines >>>> + 'hypot' to '_hypot', but the C++ headers says "using ::hypot". */ >>>> +#if defined(__MINGW32__) && defined(__cplusplus) Do we need "defined(__cplusplus)", since we are always building GDB as a C++ program? Thanks, Simon
> From: Simon Marchi <simon.marchi@ericsson.com> > Date: Fri, 26 Jan 2018 10:36:56 -0500 > >>>> > >>>> +/* Another kludge to avoid compilation errors because MinGW defines > >>>> + 'hypot' to '_hypot', but the C++ headers says "using ::hypot". */ > >>>> +#if defined(__MINGW32__) && defined(__cplusplus) > > Do we need "defined(__cplusplus)", since we are always building GDB as a C++ program? I'm okay with dropping it.
> Date: Fri, 26 Jan 2018 20:52:56 +0200 > From: Eli Zaretskii <eliz@gnu.org> > CC: gdb-patches@sourceware.org > > > From: Simon Marchi <simon.marchi@ericsson.com> > > Date: Fri, 26 Jan 2018 10:36:56 -0500 > > >>>> > > >>>> +/* Another kludge to avoid compilation errors because MinGW defines > > >>>> + 'hypot' to '_hypot', but the C++ headers says "using ::hypot". */ > > >>>> +#if defined(__MINGW32__) && defined(__cplusplus) > > > > Do we need "defined(__cplusplus)", since we are always building GDB as a C++ program? > > I'm okay with dropping it. No further comments, so I went ahead and pushed the change, without the __cplusplus part, to master, and then cherry-picked to gdb-8.1-branch. Thanks for the feedback, Simon.
--- gdb/python/python-internal.h~0 2018-01-12 05:31:04.000000000 +0200 +++ gdb/python/python-internal.h 2018-01-16 08:56:10.717759900 +0200 @@ -85,6 +85,12 @@ #define HAVE_SNPRINTF 1 #endif +/* Another kludge to avoid compilation errors because MinGW defines + 'hypot' to '_hypot', but the C++ headers says "using ::hypot". */ +#if defined(__MINGW32__) && defined(__cplusplus) +# define _hypot hypot +#endif + /* Request clean size types from Python. */ #define PY_SSIZE_T_CLEAN