From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78418 invoked by alias); 27 Apr 2018 19:08:21 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 78407 invoked by uid 89); 27 Apr 2018 19:08:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=pod X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 27 Apr 2018 19:08:19 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 811B6402613B; Fri, 27 Apr 2018 19:08:17 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id B3C9A2026985; Fri, 27 Apr 2018 19:08:16 +0000 (UTC) Subject: Re: GDB 8.1 build error To: Paul Koning , Simon Marchi References: <214C80CC-1173-41F6-AAA1-39C9D39E28B2@comcast.net> <454707570722fc0220074c0eca015a8f@polymtl.ca> Cc: "gdb@sourceware.org" From: Pedro Alves Message-ID: Date: Fri, 27 Apr 2018 19:10:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-04/txt/msg00029.txt.bz2 On 04/27/2018 07:44 PM, Paul Koning wrote: > I had deleted the build test directory, so I repeated the operation. Got a failure again but a completely different one: > > g++ -x c++ -std=gnu++11 -g -O2 -I. -I/Users/pkoning/Downloads/gdb-8.1/gdb -I/Users/pkoning/Downloads/gdb-8.1/gdb/common -I/Users/pkoning/Downloads/gdb-8.1/gdb/config -DLOCALEDIR="\"/usr/local/trunk/share/locale\"" -DHAVE_CONFIG_H -I/Users/pkoning/Downloads/gdb-8.1/gdb/../include/opcode -I/Users/pkoning/Downloads/gdb-8.1/gdb/../opcodes/.. -I/Users/pkoning/Downloads/gdb-8.1/gdb/../readline/.. -I/Users/pkoning/Downloads/gdb-8.1/gdb/../zlib -I../bfd -I/Users/pkoning/Downloads/gdb-8.1/gdb/../bfd -I/Users/pkoning/Downloads/gdb-8.1/gdb/../include -I../libdecnumber -I/Users/pkoning/Downloads/gdb-8.1/gdb/../libdecnumber -I/Users/pkoning/Downloads/gdb-8.1/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -w -c -o completer.o -MT completer.o -MMD -MP -MF ./.deps/completer.Tpo /Users/pkoning/Downloads/gdb-8.1/gdb/completer.c > > /Users/pkoning/Downloads/gdb-8.1/gdb/completer.c:2041:23: error: > non-constant-expression cannot be narrowed from type 'int' to 'char' in > initializer list [-Wc++11-narrowing] > char buf[2] = { quote_char () }; > ^~~~~~~~~~~~~ > /Users/pkoning/Downloads/gdb-8.1/gdb/completer.c:2041:23: note: insert an > explicit cast to silence this issue > char buf[2] = { quote_char () }; > ^~~~~~~~~~~~~ > static_cast( ) We silence those currently for gcc with "-Wno-narrowing" (in gdb/warning.m4). Looks like clang uses a different spelling for that warning [-Wc++11-narrowing]. Or ... does it? This: https://clang.llvm.org/docs/DiagnosticsReference.html#wnarrowing says that -Wnarrowing is synonym for -Wc++11-narrowing. So is that a clang bug? Adding that to gdb/warning.m4 (and regenerating gdb/configure gdb/gdbserver/configure should fix it). That is, until we actual fix the code to not require silencing the warning (https://sourceware.org/bugzilla/show_bug.cgi?id=23087), but that's a larger chunk of work. Oh, wait.... Your build line has no "-W" at all, it has "-w" instead?? How did that happen? > > I then asked specifically for probe.o ("cd gdb && make probe.o"): > > g++ -x c++ -std=gnu++11 -g -O2 -I. -I/Users/pkoning/Downloads/gdb-8.1/gdb -I/Users/pkoning/Downloads/gdb-8.1/gdb/common -I/Users/pkoning/Downloads/gdb-8.1/gdb/config -DLOCALEDIR="\"/usr/local/trunk/share/locale\"" -DHAVE_CONFIG_H -I/Users/pkoning/Downloads/gdb-8.1/gdb/../include/opcode -I/Users/pkoning/Downloads/gdb-8.1/gdb/../opcodes/.. -I/Users/pkoning/Downloads/gdb-8.1/gdb/../readline/.. -I/Users/pkoning/Downloads/gdb-8.1/gdb/../zlib -I../bfd -I/Users/pkoning/Downloads/gdb-8.1/gdb/../bfd -I/Users/pkoning/Downloads/gdb-8.1/gdb/../include -I../libdecnumber -I/Users/pkoning/Downloads/gdb-8.1/gdb/../libdecnumber -I/Users/pkoning/Downloads/gdb-8.1/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -w -c -o probe.o -MT probe.o -MMD -MP -MF ./.deps/probe.Tpo /Users/pkoning/Downloads/gdb-8.1/gdb/probe.c > /Users/pkoning/Downloads/gdb-8.1/gdb/probe.c:63:28: error: default > initialization of an object of const type 'const any_static_probe_ops' > without a user-provided default constructor > const any_static_probe_ops any_static_probe_ops; > ^ > {} Right, that's ill-formed, thus a gdb bug. A const POD must either be initialized, or have a user-declared default constructor. So adding an explicit initializer like clang is suggesting should fix it: const any_static_probe_ops any_static_probe_ops = {}; Thanks, Pedro Alves