Re: GDB 9.1 release 2019-12-23 update

[Andrew Burgess <andrew.burgess@embecosm.com>]

* Joel Brobecker <brobecker@adacore.com> [2019-12-24 07:46:52 +0400]:

> > > So, as far as I know, the only issues that are still open are
> > > the issues that Eli found with the pre-release.
> > 
> > Sorry about that.
> 
> Not your fault!
> 
> > >   - [EliZ] readline/colors.c build failure
> > > 
> > >         Caused by S_IXGRP and S_IXOTH not being defined on MinGW.
> > >         Patch sent to readline, and should be applied to our local
> > >         tree soon.
> > 
> > Will do soon.
> 
> Nice.
> 
> > >   - [EliZ] configure warning when checking for pthread-config
> > > 
> > >         Problem understood, but EliZ blocked because he doesn't have
> > >         the correct auto-tools version. Hopefully building those
> > >         from source is an option.
> > 
> > I believe this was already fixed.
> 
> Double Nice.
> 
> > >   - [Eliz] libtcf fails to build on MinGW
> > >         https://sourceware.org/bugzilla/show_bug.cgi?id=25155
> > > 
> > >         Problem reported to binutils on Dec 17th, but so far
> > >         no answer as far as I can tell.
> > >         https://sourceware.org/ml/binutils/2019-12/msg00277.html
> > > 
> > >         If we don't get an answer after the end of year holidays,
> > >         I suggest we send in a patch, which will likely help move
> > >         things along.  From Eli's message on bugzilla, we shouldn't
> > >         be far from having one.
> > 
> > I already have a patch, so I can apply it whenever you say so.
> 
> Let's try to have it reviewed by the binutils folks if we can.
> It seems relatively straightforward, but I tend to avoid fixing
> things in a branch before it gets fixed in master. Maybe send
> the patch to binutils with an RFA? If that doesn't work, then
> we'll consider the option of just patching our branch so
> we can release.
> 
> > > Are there other issues that I may have missed for which we should
> > > wait until we can release GDB 9.1?
> > 
> > What about the compilation warning in record-btrace.c I reported in
> > https://sourceware.org/ml/gdb-patches/2019-12/msg00706.html?  Do we
> > want to fix it?
> 
> We can, but (IMO) not super critical. FWIW, I don't get the warning
> when buidling on GNU/Linux.

I can reproduce the warning on GNU/Linux, but it only crops up at some
optimisation levels, -O0 doesn't warn for me, while -O1 and -O2 do.
I've tested with GCC 8.3, 9.2, and a 10.??.  This is all on a Fedora
27 system (yes, I really should update).

That said, I had a look at the code in question and I suspect the
warning is incorrect, unless I'm missing some clever C++ corner case,
which is quite possible. So, we have one of these:

  gdb::optional<ui_out_emit_list> asm_list;

The "uninitialised" variable is a member of the ui_out_emit_list,
being used during its destructor.  But the destructor is only called
if the ui_out_emit_list is initialised, which requires the member
variable to be set....

Currently I would be happy to release with the warning present.

Thanks,
Andrew