Message ID | yddftxz55f2.fsf@CeBiTec.Uni-Bielefeld.DE |
---|---|
State | New, archived |
Headers |
Received: (qmail 26108 invoked by alias); 24 Sep 2018 14:43:39 -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 26086 invoked by uid 89); 24 Sep 2018 14:43:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-19.8 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_2, GIT_PATCH_3, KAM_LAZY_DOMAIN_SECURITY autolearn=ham version=3.3.2 spammy=losing, managed, H*a:set, H*a:sender X-HELO: smtp.CeBiTec.Uni-Bielefeld.DE Received: from smtp.CeBiTec.Uni-Bielefeld.DE (HELO smtp.CeBiTec.Uni-Bielefeld.DE) (129.70.160.84) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 24 Sep 2018 14:43:36 +0000 Received: from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 97FD2DE2; Mon, 24 Sep 2018 16:36:06 +0200 (CEST) Received: from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (malfoy.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0E4JnGBouNoA; Mon, 24 Sep 2018 16:36:04 +0200 (CEST) Received: from lokon.CeBiTec.Uni-Bielefeld.DE (lokon.CeBiTec.Uni-Bielefeld.DE [129.70.161.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPS id B0F05DE0; Mon, 24 Sep 2018 16:36:03 +0200 (CEST) Received: (from ro@localhost) by lokon.CeBiTec.Uni-Bielefeld.DE (8.15.2+Sun/8.15.2/Submit) id w8OEa152029176; Mon, 24 Sep 2018 16:36:01 +0200 (MEST) From: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> To: Sergio Durigan Junior <sergiodj@redhat.com> Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Provide Solaris 11 buildbots References: <ydda7odk9ye.fsf@CeBiTec.Uni-Bielefeld.DE> <874lelw9r3.fsf@redhat.com> <yddfty48hz9.fsf@CeBiTec.Uni-Bielefeld.DE> <877ejguuo0.fsf@redhat.com> <87fty4teps.fsf@redhat.com> <yddbm8s8bza.fsf@CeBiTec.Uni-Bielefeld.DE> <871s9ote89.fsf@redhat.com> <ydd7ejggikj.fsf@CeBiTec.Uni-Bielefeld.DE> Date: Mon, 24 Sep 2018 16:36:01 +0200 In-Reply-To: <ydd7ejggikj.fsf@CeBiTec.Uni-Bielefeld.DE> (Rainer Orth's message of "Thu, 20 Sep 2018 19:55:08 +0200") Message-ID: <yddftxz55f2.fsf@CeBiTec.Uni-Bielefeld.DE> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (usg-unix-v) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-IsSubscribed: yes |
Commit Message
Rainer Orth
Sept. 24, 2018, 2:36 p.m. UTC
Hi Sergio, >>>> So, there were a few problems in the master.cfg file which prevented the >>>> builders to actually build GDB. I fixed them, and they're now >>>> processing the queue. However, the builds are failing. For example: >>>> >>>> https://gdb-build.sergiodj.net/builders/Solaris11-sparcv9-m64/builds/3/steps/compile%20gdb/logs/stdio >>>> >>>> This seems to be the problem you were talking about, regarding >>>> unittests/string_view-selftests.o. You mentioned that this breakage >>>> shouldn't happen if we don't use -D_GLIBCXX_DEBUG, right? Can you >>>> please take a look at this? >>> >>> until your --enable-unit-tests patch is in (when we can keep the default >>> options and just add --disable-unit-tests to the configure line), we'd >>> need to build with CFLAGS/CXXFLAGS=-g -O -D_GLIBCXX_DEBUG until PR >>> build/23676 is resolved. That's what worked for me locally. >> >> Ah, I thought that if we didn't use "-g -D_GLIBCXX_DEBUG", then the >> build would be OK. > > That's what I tried first when I encountered the problem here. However, > even the minimal testcase in the PR fails with just -g alone. > > Could you please try if the following patch allows the build to succeed? it seems we managed to mess up the configure flags badly here: right now the buildbots are configured with just CFLAGS/CXXFLAGS=-m64, nothing more. I hope the following patch should fix things: * There's no need for disable_default_compilation_flags = 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? * Obviously the -m64 needs to be appended in RunTestGDBPlainSolaris_c64 to both CFLAGS and CXXFLAGS to avoid losing the -O above. * Not in the patch, but wouldn't it be enough to set enable_targets_all, make_command, and run_testsuite only once in RunTestGDBSolaris_Common? Thanks. Rainer
Comments
On Monday, September 24 2018, Rainer Orth wrote: > Hi Sergio, > >>>>> So, there were a few problems in the master.cfg file which prevented the >>>>> builders to actually build GDB. I fixed them, and they're now >>>>> processing the queue. However, the builds are failing. For example: >>>>> >>>>> https://gdb-build.sergiodj.net/builders/Solaris11-sparcv9-m64/builds/3/steps/compile%20gdb/logs/stdio >>>>> >>>>> This seems to be the problem you were talking about, regarding >>>>> unittests/string_view-selftests.o. You mentioned that this breakage >>>>> shouldn't happen if we don't use -D_GLIBCXX_DEBUG, right? Can you >>>>> please take a look at this? >>>> >>>> until your --enable-unit-tests patch is in (when we can keep the default >>>> options and just add --disable-unit-tests to the configure line), we'd >>>> need to build with CFLAGS/CXXFLAGS=-g -O -D_GLIBCXX_DEBUG until PR >>>> build/23676 is resolved. That's what worked for me locally. >>> >>> Ah, I thought that if we didn't use "-g -D_GLIBCXX_DEBUG", then the >>> build would be OK. >> >> That's what I tried first when I encountered the problem here. However, >> even the minimal testcase in the PR fails with just -g alone. >> >> Could you please try if the following patch allows the build to succeed? > > it seems we managed to mess up the configure flags badly here: right now > the buildbots are configured with just CFLAGS/CXXFLAGS=-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 = 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_all, > make_command, and run_testsuite only once in RunTestGDBSolaris_Common? 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. Thanks,
On Monday, September 24 2018, I wrote: > On Monday, September 24 2018, Rainer Orth wrote: >> it seems we managed to mess up the configure flags badly here: right now >> the buildbots are configured with just CFLAGS/CXXFLAGS=-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 = 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_all, >> make_command, and run_testsuite only once in RunTestGDBSolaris_Common? > > 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. Thanks,
Hi Sergio, >> On Monday, September 24 2018, Rainer Orth wrote: >>> it seems we managed to mess up the configure flags badly here: right now >>> the buildbots are configured with just CFLAGS/CXXFLAGS=-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 = 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_all, >>> make_command, and run_testsuite only once in RunTestGDBSolaris_Common? >> >> 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: ‘vfork’ 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. checking whether a statically linked program can dlopen itself... Setting warning flags = -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror Setting warning flags = -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -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=maybe-uninitialized -Wsuggest-override -Wimplicit-fallthrough=3 -Wduplicated-cond -Wno-unknown-pragmas -Wno-deprecated-declarations -Werror Those are all spurious, sometimes two different lines running into each other. 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 [-Wconflicts-sr] /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/c-exp.y: warning: 53 reduce/reduce conflicts [-Wconflicts-rr] /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/m2-exp.y: warning: 34 shift/reduce conflicts [-Wconflicts-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 ../../binutils-gdb/gdb/coffread.c:1104:36: warning: ‘newobj’ may be used uninitialized in this function [-Wmaybe-uninitialized] Seems legit. ../../binutils-gdb/gdb/inferior.h:567:26: warning: ‘*((void*)(& maybe_restore_inferior)+40).scoped_restore_current_inferior::m_saved_inf’ may be used uninitialized in this function [-Wmaybe-uninitialized] ../../binutils-gdb/gdb/progspace.h:285:31: warning: ‘*((void*)(& maybe_restore_inferior)+32).scoped_restore_current_program_space::m_saved_pspace’ may be used uninitialized in this function [-Wmaybe-uninitialized] ../../binutils-gdb/gdb/ui-out.h:197:18: warning: ‘asm_list.ui_out_emit_type<(ui_out_type)1>::m_uiout’ may be used uninitialized in this 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. Rainer
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 now >>>> the buildbots are configured with just CFLAGS/CXXFLAGS=-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 = 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_all, >>>> make_command, and run_testsuite only once in RunTestGDBSolaris_Common? >>> >>> 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: ‘vfork’ 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 = -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror > Setting warning flags = -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -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=maybe-uninitialized -Wsuggest-override > -Wimplicit-fallthrough=3 -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 [-Wconflicts-sr] > /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/c-exp.y: warning: 53 reduce/reduce conflicts [-Wconflicts-rr] > /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/m2-exp.y: warning: 34 shift/reduce conflicts [-Wconflicts-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: ‘newobj’ may be used uninitialized in this function [-Wmaybe-uninitialized] > > Seems legit. Should be easy to fix. > ../../binutils-gdb/gdb/inferior.h:567:26: warning: ‘*((void*)(& > maybe_restore_inferior)+40).scoped_restore_current_inferior::m_saved_inf’ > may be used uninitialized in this function [-Wmaybe-uninitialized] > ../../binutils-gdb/gdb/progspace.h:285:31: warning: ‘*((void*)(& > maybe_restore_inferior)+32).scoped_restore_current_program_space::m_saved_pspace’ > may be used uninitialized in this function [-Wmaybe-uninitialized] > ../../binutils-gdb/gdb/ui-out.h:197:18: warning: ‘asm_list.ui_out_emit_type<(ui_out_type)1>::m_uiout’ may be used uninitialized in this 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.
Hi Sergio, >>> I'll enable the email notifications for both builders later today. >> >> excellent, thanks. it would be great if you could do this: last night Tom's series of -Wshadow=local patches broke the Solaris build, which didn't trigger a gdb-patches mail, thus easily going unnoticed. >> 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: ‘vfork’ 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. I certainly will. >> checking whether a statically linked program can dlopen itself... Setting >> warning flags = -W -Wall -Wstrict-prototypes -Wmissing-prototypes >> -Wshadow -Wstack-usage=262144 -Werror >> Setting warning flags = -W -Wall -Wstrict-prototypes -Wmissing-prototypes >> -Wshadow -Wstack-usage=262144 -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=maybe-uninitialized -Wsuggest-override >> -Wimplicit-fallthrough=3 -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. True, but even so the 'Setting warning flags' line counts as a warning ;-) >> /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/c-exp.y: >> warning: 42 shift/reduce conflicts [-Wconflicts-sr] >> /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/c-exp.y: >> warning: 53 reduce/reduce conflicts [-Wconflicts-rr] >> /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/m2-exp.y: >> warning: 34 shift/reduce conflicts [-Wconflicts-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. Probably not, though if the conflicts are as expected it would be nice they didn't trigger a warning. >> ../../binutils-gdb/gdb/coffread.c:1104:36: warning: ‘newobj’ may be used >> uninitialized in this function [-Wmaybe-uninitialized] >> >> Seems legit. > > Should be easy to fix. Indeed: Tom already beat me to it. >> ../../binutils-gdb/gdb/inferior.h:567:26: warning: ‘*((void*)(& >> maybe_restore_inferior)+40).scoped_restore_current_inferior::m_saved_inf’ >> may be used uninitialized in this function [-Wmaybe-uninitialized] >> ../../binutils-gdb/gdb/progspace.h:285:31: warning: ‘*((void*)(& >> maybe_restore_inferior)+32).scoped_restore_current_program_space::m_saved_pspace’ >> may be used uninitialized in this function [-Wmaybe-uninitialized] >> ../../binutils-gdb/gdb/ui-out.h:197:18: warning: >> ‘asm_list.ui_out_emit_type<(ui_out_type)1>::m_uiout’ may be used >> uninitialized in this 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. Right: this is under discussion in another thread right now. Thanks. Rainer
On Friday, October 05 2018, Rainer Orth wrote: > Hi Sergio, > >>>> I'll enable the email notifications for both builders later today. >>> >>> excellent, thanks. > > it would be great if you could do this: last night Tom's series of > -Wshadow=local patches broke the Solaris build, which didn't trigger a > gdb-patches mail, thus easily going unnoticed. Hey Rainer, Ops, sorry, I kind of forgot about this. We've had face-to-face meetings, and then I left on vacation. It is enabled now. >>> checking whether a statically linked program can dlopen itself... Setting >>> warning flags = -W -Wall -Wstrict-prototypes -Wmissing-prototypes >>> -Wshadow -Wstack-usage=262144 -Werror >>> Setting warning flags = -W -Wall -Wstrict-prototypes -Wmissing-prototypes >>> -Wshadow -Wstack-usage=262144 -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=maybe-uninitialized -Wsuggest-override >>> -Wimplicit-fallthrough=3 -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. > > True, but even so the 'Setting warning flags' line counts as a warning ;-) Ah, that's because of BuildBot's algorithm to detect warnings. I honestly never go to the "warnings" page because of that; I prefer looking directly at the logs. I don't know if BuildBot has improved its warning detection in newer releases. >>> /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/c-exp.y: >>> warning: 42 shift/reduce conflicts [-Wconflicts-sr] >>> /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/c-exp.y: >>> warning: 53 reduce/reduce conflicts [-Wconflicts-rr] >>> /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/m2-exp.y: >>> warning: 34 shift/reduce conflicts [-Wconflicts-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. > > Probably not, though if the conflicts are as expected it would be nice > they didn't trigger a warning. Yeah. I don't remember seeing a discussion about these conflicts; I guess they've been ignored for a long time, now. Thanks,
diff --git a/master.cfg b/master.cfg --- a/master.cfg +++ b/master.cfg @@ -1293,23 +1293,18 @@ class RunTestGDBSolaris_Common (BuildAnd # build/23676. This can be avoided either by performing a -g # -O build or with --disable-unit-tests from Sergio's proposed # patch. - self.disable_default_compilation_flags = True + self.extra_CFLAGS = [ '-O' ] + self.extra_CXXFLAGS = self.extra_CFLAGS BuildAndTestGDBFactory.__init__ (self, **kwargs) class RunTestGDBPlainSolaris_c64 (RunTestGDBSolaris_Common): """Compiling for Solaris""" def __init__ (self, **kwargs): - self.extra_CFLAGS = [ '-m64' ] - self.extra_CXXFLAGS = self.extra_CFLAGS self.enable_targets_all = False self.make_command = 'gmake' self.run_testsuite = False - # While a regular gdb build succeeds, a -g -D_GLIBCXX_DEBUG - # build as used by the buildbot fails as reported in PR - # build/23676. This can be avoided either by performing a -g - # -O build or with --disable-unit-tests from Sergio's proposed - # patch. - self.disable_default_compilation_flags = True + self.extra_CFLAGS.append ('-m64') + self.extra_CXXFLAGS.append ('-m64') BuildAndTestGDBFactory.__init__ (self, **kwargs) # All branches that are going to be watched.