From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53189 invoked by alias); 26 Sep 2018 14:05:06 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 53168 invoked by uid 89); 26 Sep 2018 14:05:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=237A, 7628, 0287, 31F4 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 26 Sep 2018 14:04:59 +0000 Received: from smtp.corp.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 071CCA457A; Wed, 26 Sep 2018 14:04:58 +0000 (UTC) Received: from localhost (unused-10-15-17-196.yyz.redhat.com [10.15.17.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id CE1948CB9D; Wed, 26 Sep 2018 14:04:57 +0000 (UTC) From: Sergio Durigan Junior To: Rainer Orth Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Provide Solaris 11 buildbots References: <874lelw9r3.fsf@redhat.com> <877ejguuo0.fsf@redhat.com> <87fty4teps.fsf@redhat.com> <871s9ote89.fsf@redhat.com> <875zyuq5pr.fsf@redhat.com> <87sh1wwg9z.fsf@redhat.com> Date: Wed, 26 Sep 2018 14:05:00 -0000 In-Reply-To: (Rainer Orth's message of "Wed, 26 Sep 2018 15:32:52 +0200") Message-ID: <87lg7owe0m.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg00851.txt.bz2 On Wednesday, September 26 2018, Rainer Orth wrote: > Hi Sergio, > >>> On Monday, September 24 2018, Rainer Orth wrote: >>>> it seems we managed to mess up the configure flags badly here: right n= ow >>>> the buildbots are configured with just CFLAGS/CXXFLAGS=3D-m64, nothing >>>> more. I hope the following patch should fix things: >>> >>> Ah, OK. I may have misunderstood the patch/requirements. I've now >>> simplified the configuration. >>> >>>> * There's no need for disable_default_compilation_flags =3D True: the >>>> default works just fine, we only need to add -O at the moment. Isn't >>>> it enough to do this once in RunTestGDBSolaris_Common? >>> >>> Yeah, it should be. >>> >>>> * Obviously the -m64 needs to be appended in RunTestGDBPlainSolaris_c64 >>>> to both CFLAGS and CXXFLAGS to avoid losing the -O above. >>> >>> Yeah. >>> >>>> * Not in the patch, but wouldn't it be enough to set enable_targets_al= l, >>>> make_command, and run_testsuite only once in RunTestGDBSolaris_Commo= n? >>> >>> It turned out to be a bit more complicated. I'm in a hurry right now, >>> so I did a quick hack to make it work. I'll monitor the next builds. >> >> After this, the builds started to pass. Thanks for bringing this to my >> attention, Rainer. >> >> I'll enable the email notifications for both builders later today. > > excellent, thanks. > > I had a look at the current set of build warnings and wondered what (if > any) to do about them: > > ../../binutils-gdb/libiberty/pex-unix.c:612:7: warning: =E2=80=98vfork=E2= =80=99 is deprecated [-Wdeprecated-declarations] > > Solaris 11 has deprecated vfork. vfork(2) suggests to replace uses by > posix_spawn or posix_spawnp, but this is something to take up with the > libiberty maintainers. Yes, you should get in touch with the GCC/libiberty maintainers. > checking whether a statically linked program can dlopen itself... Setting= warning flags =3D -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshad= ow -Wstack-usage=3D262144 -Werror > Setting warning flags =3D -W -Wall -Wstrict-prototypes -Wmissing-prototyp= es -Wshadow -Wstack-usage=3D262144 -Werror > checking compiler warning flags... -Wall -Wpointer-arith -Wno-unused > -Wunused-value -Wunused-variable -Wunused-function -Wno-switch > -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter > -Wunused-but-set-variable -Wno-sign-compare > -Wno-error=3Dmaybe-uninitialized -Wsuggest-override > -Wimplicit-fallthrough=3D3 -Wduplicated-cond -Wno-unknown-pragmas > -Wno-deprecated-declarations -Werror > > Those are all spurious, sometimes two different lines running into each > other. This happens because of the parallel build. > They are also present on Fedora, e.g. > > /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/= ../../binutils-gdb/gdb/c-exp.y: warning: 42 shift/reduce conflicts [-Wconfl= icts-sr] > /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/= ../../binutils-gdb/gdb/c-exp.y: warning: 53 reduce/reduce conflicts [-Wconf= licts-rr] > /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/= ../../binutils-gdb/gdb/m2-exp.y: warning: 34 shift/reduce conflicts [-Wconf= licts-sr] > /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/= ../../binutils-gdb/gdb/m2-exp.y:301.25-44: warning: rule useless in parser = due to conflicts [-Wother] > > Those are from the bundled bison 3.0.4 and again also present on > Fedora. One could silence them with -Wno-conflicts-sr if need be, but > that would require testing if the yacc/bison used supports those > options. > > bison 2.4.2 only emits > > conflicts: 42 shift/reduce, 53 reduce/reduce > conflicts: 34 shift/reduce They happen on pretty much every builder. I personally don't think these should be silenced. > ../../binutils-gdb/gdb/coffread.c:1104:36: warning: =E2=80=98newobj=E2=80= =99 may be used uninitialized in this function [-Wmaybe-uninitialized] > > Seems legit. Should be easy to fix. > ../../binutils-gdb/gdb/inferior.h:567:26: warning: =E2=80=98*((void*)(& > maybe_restore_inferior)+40).scoped_restore_current_inferior::m_saved_inf= =E2=80=99 > may be used uninitialized in this function [-Wmaybe-uninitialized] > ../../binutils-gdb/gdb/progspace.h:285:31: warning: =E2=80=98*((void*)(& > maybe_restore_inferior)+32).scoped_restore_current_program_space::m_saved= _pspace=E2=80=99 > may be used uninitialized in this function [-Wmaybe-uninitialized] > ../../binutils-gdb/gdb/ui-out.h:197:18: warning: =E2=80=98asm_list.ui_out= _emit_type<(ui_out_type)1>::m_uiout=E2=80=99 may be used uninitialized in t= his function [-Wmaybe-uninitialized] > > Those three could be legit, but I cannot tell. I suspect they don't > occur on other builders because they use older gcc versions (e.g. gcc > 4.8) while the Solaris builders use gcc 7.3. ISTR seeing these in other builders as well. If I'm not mistaken, they have to do with a GCC issue about std::optional or some such. --=20 Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/