[ANNOUNCEMENT] GDB 8.1 release branch created!

  > 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;
	      ^~~~~~~~~~
  

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.