GDB 8.1 build error

GDB 8.1 build error

[Paul Koning]

I can't build GDB on Mac.  This shows up both in a native build, and a cross-build (for example target=mips-netbsdelf).  I see this error:

/Users/pkoning/Downloads/gdb-8.1/gdb/stap-probe.c:122:29: error: default
      initialization of an object of const type 'const stap_static_probe_ops'
      without a user-provided default constructor
const stap_static_probe_ops stap_static_probe_ops;

or

/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;

(same problem, different source file).

	paul

Re: GDB 8.1 build error

[Simon Marchi]

On 2018-04-26 19:48, Paul Koning wrote:
> I can't build GDB on Mac.  This shows up both in a native build, and a
> cross-build (for example target=mips-netbsdelf).  I see this error:
> 
> /Users/pkoning/Downloads/gdb-8.1/gdb/stap-probe.c:122:29: error: 
> default
>       initialization of an object of const type 'const 
> stap_static_probe_ops'
>       without a user-provided default constructor
> const stap_static_probe_ops stap_static_probe_ops;
> 
> or
> 
> /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;
> 
> (same problem, different source file).
> 
> 	paul

Hi Paul,

What is the compiler, which version, and can you share the full command 
line used to compile probe.o, for example?

Simon

Re: GDB 8.1 build error

[Paul Koning]

> On Apr 27, 2018, at 2:02 PM, Simon Marchi <simon.marchi@polymtl.ca> wrote:
> 
> On 2018-04-26 19:48, Paul Koning wrote:
>> I can't build GDB on Mac.  This shows up both in a native build, and a
>> cross-build (for example target=mips-netbsdelf).  I see this error:
>> /Users/pkoning/Downloads/gdb-8.1/gdb/stap-probe.c:122:29: error: default
>>      initialization of an object of const type 'const stap_static_probe_ops'
>>      without a user-provided default constructor
>> const stap_static_probe_ops stap_static_probe_ops;
>> or
>> /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;
>> (same problem, different source file).
>> 	paul
> 
> Hi Paul,
> 
> What is the compiler, which version, and can you share the full command line used to compile probe.o, for example?
> 
> Simon

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<char>( )

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;
                           ^
                                               {}



Paul-Konings-MacBook-Pro:buildgdb pkoning$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.3.0 (clang-703.0.31)
Target: x86_64-apple-darwin17.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Paul-Konings-MacBook-Pro:buildgdb pkoning$ head config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.64.  Invocation command line was

  $ /Users/pkoning/Downloads/gdb-8.1/configure --prefix=/usr/local/trunk --disable-build-warnings


OS is Mac OS 10.13.4.

These appear to be LLVM incompatibilities; if I feed those command lines to (real) GCC 8.0, just built yesterday from current trunk, they compile cleanly.

	paul

Re: GDB 8.1 build error

[Paul Koning]

> On Apr 27, 2018, at 2:44 PM, Paul Koning <paulkoning@comcast.net> wrote:
> 
> 
> 
>> On Apr 27, 2018, at 2:02 PM, Simon Marchi <simon.marchi@polymtl.ca> wrote:
>> 
>> On 2018-04-26 19:48, Paul Koning wrote:
>>> I can't build GDB on Mac.  This shows up both in a native build, and a
>>> cross-build (for example target=mips-netbsdelf).  I see this error:
>>> /Users/pkoning/Downloads/gdb-8.1/gdb/stap-probe.c:122:29: error: default
>>>     initialization of an object of const type 'const stap_static_probe_ops'
>>>     without a user-provided default constructor
>>> const stap_static_probe_ops stap_static_probe_ops;
>>> or
>>> /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;
>>> (same problem, different source file).
>>> 	paul
>> 
>> Hi Paul,
>> 
>> What is the compiler, which version, and can you share the full command line used to compile probe.o, for example?
>> 
>> Simon
> ...
> These appear to be LLVM incompatibilities; if I feed those command lines to (real) GCC 8.0, just built yesterday from current trunk, they compile cleanly.

To follow up on that: if I force the use of real GCC/G++ (with CC and CXX definitions in the configure command), I get a successful build for the native case.  I'm trying a cross-build now.

	paul

Re: GDB 8.1 build error

[Simon Marchi]

On 2018-04-27 14:44, Paul Koning wrote:
> 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;
>                            ^
>                                                {}
> 
> 
> 
> Paul-Konings-MacBook-Pro:buildgdb pkoning$ gcc --version
> Configured with:
> --prefix=/Applications/Xcode.app/Contents/Developer/usr
> --with-gxx-include-dir=/usr/include/c++/4.2.1
> Apple LLVM version 7.3.0 (clang-703.0.31)
> Target: x86_64-apple-darwin17.5.0
> Thread model: posix
> InstalledDir:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
> Paul-Konings-MacBook-Pro:buildgdb pkoning$ head config.log
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
> 
> It was created by configure, which was
> generated by GNU Autoconf 2.64.  Invocation command line was
> 
>   $ /Users/pkoning/Downloads/gdb-8.1/configure
> --prefix=/usr/local/trunk --disable-build-warnings
> 
> 
> OS is Mac OS 10.13.4.
> 
> These appear to be LLVM incompatibilities; if I feed those command
> lines to (real) GCC 8.0, just built yesterday from current trunk, they
> compile cleanly.
> 
> 	paul

This seems to be a bogus error that was fixed in clang 3.9:

https://stackoverflow.com/questions/7411515/why-does-c-require-a-user-provided-default-constructor-to-default-construct-a?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa

You Apple LLVM 7.3.0 seems to map to upstream clang 3.8.0:

https://en.wikipedia.org/wiki/Xcode#Latest_versions

I indeed get the same error if I try building the file with clang 3.8 on 
Linux:

$ clang++-3.8 -x c++ -std=gnu++11 -g3 -O0 <snip> 
/home/emaisin/src/binutils-gdb/gdb/probe.c
/home/emaisin/src/binutils-gdb/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;
                            ^

If compatibility with clang 3.8 is really important to you, we could 
always add an empty constructor to that class.  Otherwise, if it's easy 
for you to update your Xcode, I'd say try that first.

Simon

Re: GDB 8.1 build error

[Pedro Alves]

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<char>( )

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

Re: GDB 8.1 build error

[Simon Marchi]

On 2018-04-27 14:44, 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<char>( )

For that problem, this warning should have been inhibited by 
-Wno-narrowing as defined in gdb/warning.m4.  I notice that you seem to 
have no warning flags at all on your command line.  That's probably 
because when --disable-build-warnings is passed, we don't append any of 
the -W* -Wno-* flags.  But in that case, we should still append the 
-Wno-* flags...  So it sounds like an issue that should be fixed in 
warning.m4.  I'd suggest using --disable-werror instead: you'll see 
warnings, but they'll be non-fatal.

Simon

Re: GDB 8.1 build error

[Paul Koning]

> On Apr 27, 2018, at 3:01 PM, Simon Marchi <simon.marchi@polymtl.ca> wrote:
> 
> ...
> This seems to be a bogus error that was fixed in clang 3.9:
> 
> https://stackoverflow.com/questions/7411515/why-does-c-require-a-user-provided-default-constructor-to-default-construct-a?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa
> 
> You Apple LLVM 7.3.0 seems to map to upstream clang 3.8.0:
> 
> https://en.wikipedia.org/wiki/Xcode#Latest_versions
> 
> I indeed get the same error if I try building the file with clang 3.8 on Linux:
> 
> $ clang++-3.8 -x c++ -std=gnu++11 -g3 -O0 <snip> /home/emaisin/src/binutils-gdb/gdb/probe.c
> /home/emaisin/src/binutils-gdb/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;
>                           ^
> 
> If compatibility with clang 3.8 is really important to you, we could always add an empty constructor to that class.  Otherwise, if it's easy for you to update your Xcode, I'd say try that first.

I foolishly assumed that the Apple updater would update Apple stuff.  And indeed it has given me bugfix updates to Xcode Command Line in the past.  But it doesn't do Xcode version updates.  

You're right, I'm way out of date, and that was unintentional.  I'm getting the latest now.  Will try with that and report.

	paul

Re: GDB 8.1 build error

[Simon Marchi]

On 2018-04-27 15:08, Pedro Alves wrote:
> Oh, wait....  Your build line has no "-W" at all, it has "-w" instead??
> How did that happen?

When --disable-build-warnings is used, we don't put any -W/-Wno- flags:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/warning.m4;h=f176a3291aa68acf0122609531abb4652425525b;hb=HEAD#l62

> 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 = {};

In the stackoverflow answer I pointed to in my other messages talks 
about a defect in the standard that was fixed. And it seems like the 
compilers aligned with the new behavior.  So is it really a GDB bug?  In 
any case, I have no problem adding the explicit initialization to be 
friendly with older compilers.

Simon

Re: GDB 8.1 build error

[Pedro Alves]

On 04/27/2018 08:18 PM, Simon Marchi wrote:
> On 2018-04-27 15:08, Pedro Alves wrote:
>> Oh, wait....  Your build line has no "-W" at all, it has "-w" instead??
>> How did that happen?
> 
> When --disable-build-warnings is used, we don't put any -W/-Wno- flags:
> 
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/warning.m4;h=f176a3291aa68acf0122609531abb4652425525b;hb=HEAD#l62
> 
>> 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 = {};
> 
> In the stackoverflow answer I pointed to in my other messages talks about a defect in the standard that was fixed. 

Oh, I had run into this in the past in context of an
empty struct and thought that the bug fix was for that
case only?

 http://open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#253

Oh geez, I assumed that any_static_probe_ops was a POD with
function pointers, but now that I look, I see virtual
methods...

Anyhow.

And it seems like the compilers aligned with the new behavior.  So is it really a GDB bug?  In any case, I have no problem adding the explicit initialization to be friendly with older compilers.

Not sure anymore.  But in any case I have no problems with
the explicit initialization either.

Thanks,
Pedro Alves

Re: GDB 8.1 build error

[Pedro Alves]

On 04/27/2018 08:18 PM, Simon Marchi wrote:
> On 2018-04-27 15:08, Pedro Alves wrote:
>> Oh, wait....  Your build line has no "-W" at all, it has "-w" instead??
>> How did that happen?
> 
> When --disable-build-warnings is used, we don't put any -W/-Wno- flags:
> 
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/warning.m4;h=f176a3291aa68acf0122609531abb4652425525b;hb=HEAD#l62

But then, we add "-w", and I'm surprised that "-w" did not disable
all warnings, including "-Wc++11-narrowing".  "-w" is supposed to mean
disable all warnings.  At least, that's how GCC behaves.
Could that be a clang bug?

Thanks,
Pedro Alves

Re: GDB 8.1 build error

[Simon Marchi]

On 2018-04-27 16:00, Pedro Alves wrote:
> On 04/27/2018 08:18 PM, Simon Marchi wrote:
>> On 2018-04-27 15:08, Pedro Alves wrote:
>>> Oh, wait....  Your build line has no "-W" at all, it has "-w" 
>>> instead??
>>> How did that happen?
>> 
>> When --disable-build-warnings is used, we don't put any -W/-Wno- 
>> flags:
>> 
>> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/warning.m4;h=f176a3291aa68acf0122609531abb4652425525b;hb=HEAD#l62
> 
> But then, we add "-w", and I'm surprised that "-w" did not disable
> all warnings, including "-Wc++11-narrowing".  "-w" is supposed to mean
> disable all warnings.  At least, that's how GCC behaves.
> Could that be a clang bug?

On clang at least, -Wnarrowing seems to generate an error by default, so 
-w doesn't affect it.  You get:

   no flag: error
   -Wno-error=narrowing: warning
   -Wno-error=narrowing -w: silent

So in this case, we would still need either -Wno-error=narrowing or 
-Wno-narrowing.

We can test if gcc behaves the same, we just need something that is an 
error by default but we can downgrade to a warning.  Do you have an idea 
of such diagnostic?

Simon

Re: GDB 8.1 build error

[Paul Koning]

> On Apr 27, 2018, at 3:01 PM, Simon Marchi <simon.marchi@polymtl.ca> wrote:
> 
> ...                          ^
> 
> If compatibility with clang 3.8 is really important to you, we could always add an empty constructor to that class.  Otherwise, if it's easy for you to update your Xcode, I'd say try that first.
> 
> Simon

With the current Xcode (9.3) I get "Apple LLVM version 9.1.0 (clang-902.0.39.1)" and now GDB builds cleanly.

Thanks for the help and sorry about the confusion.

	paul

Re: GDB 8.1 build error

[Pedro Alves]

On 04/27/2018 09:16 PM, Simon Marchi wrote:

> On clang at least, -Wnarrowing seems to generate an error by default, so -w doesn't affect it.  You get:
> 
>   no flag: error
>   -Wno-error=narrowing: warning
>   -Wno-error=narrowing -w: silent
> 
> So in this case, we would still need either -Wno-error=narrowing or -Wno-narrowing.
> 
> We can test if gcc behaves the same, we just need something that is an error by default but we can downgrade to a warning.  Do you have an idea of such diagnostic?

-Wnarrowing is on by default on gcc, and -w disables it.

Thanks,
Pedro Alves

Re: GDB 8.1 build error

[Simon Marchi]

On 2018-04-27 16:24, Pedro Alves wrote:
> -Wnarrowing is on by default on gcc, and -w disables it.

But it's a warning by default, not an error (like clang).  I think 
that's the important distinction.

Simon

Re: GDB 8.1 build error

[Pedro Alves]

On 04/27/2018 09:41 PM, Simon Marchi wrote:
> On 2018-04-27 16:24, Pedro Alves wrote:
>> -Wnarrowing is on by default on gcc, and -w disables it.
> 
> But it's a warning by default, not an error (like clang).  I think that's the important distinction.

OK, That suggests to me that clang has -Werror=narrowing enabled by
default, instead of -Wnarrowing.

But I still think that the real issue is that gcc and clang
behave differently wrt "-w" precedence.

Note, with:

 $ cat narrow.cc 
 int return_int () { return 42; }
 char buf[2] = { return_int () };

#1 - even if you make gcc error out with -Werror=narrowing, a subsequent "-w"
cancels the error/warning, not so with clang:

 $ g++ -std=gnu++17 narrow.cc -c -Werror=narrowing -w
 $ clang++ -std=gnu++17 narrow.cc -c -Werror=narrowing -w
 narrow.cc:2:17: error: non-constant-expression cannot be narrowed from type 'int' to 'char' in initializer list [-Wc++11-narrowing]

#2 - If you put "-Wno-error=narrowing", after the "-w", then both compilers
suppress the warning/error:

 $ clang++ -std=gnu++17 narrow.cc -c -Werror=narrowing -w -Wno-error=narrowing
 $ g++ -std=gnu++17 narrow.cc -c -Werror=narrowing -w -Wno-error=narrowing

#3 - For completeness, adding "-Werror=narrowing" after the -w, shows #1 again:

 $ g++ -std=gnu++17 narrow.cc -c -w -Werror=narrowing
 $ clang++ -std=gnu++17 narrow.cc -c -w -Werror=narrowing
 narrow.cc:2:17: error: non-constant-expression cannot be narrowed from type 'int' to 'char' in initializer list [-Wc++11-narrowing]

 $ g++ -std=gnu++17 narrow.cc -c -Werror=narrowing -w -Werror=narrowing
 $ clang++ -std=gnu++17 narrow.cc -c -Werror=narrowing -w -Werror=narrowing
 narrow.cc:2:17: error: non-constant-expression cannot be narrowed from type 'int' to 'char' in initializer list [-Wc++11-narrowing]

So it seems to be the issue here is more about "-w" precedence over all
warning switches than about what is enabled by default.

To confirm this, we can see the same thing with any other warning:

 ~~~~~~~~~~~~
 $ gcc  unused.c -c -Werror=unused-variable 
 unused.c: In function ‘function’:
 unused.c:1:23: error: unused variable ‘i’ [-Werror=unused-variable]
  int function () { int i; return 42; }
                       ^
 cc1: some warnings being treated as errors
 ~~~~~~~~~~~~

 ~~~~~~~~~~~~
 $ clang unused.c -c -Werror=unused-variable
 unused.c:1:23: error: unused variable 'i' [-Werror,-Wunused-variable]
 int function () { int i; return 42; }
                      ^
 1 error generated.
 ~~~~~~~~~~~~

vs

 $ gcc unused.c -c -Werror=unused-variable -w
 $ clang unused.c -c -Werror=unused-variable -w
 unused.c:1:23: error: unused variable 'i' [-Werror,-Wunused-variable]

So seems like we could handle this my making --disable-build-warnings
use "-Wno-error -w" instead of just "-w".  But I'd suggest checking with
clang and/or gcc folks to confirm the difference is intentional too.

Thanks,
Pedro Alves

Re: GDB 8.1 build error

[Pedro Alves]

On 05/02/2018 10:41 AM, Pedro Alves wrote:

> So seems like we could handle this my making --disable-build-warnings
> use "-Wno-error -w" instead of just "-w".  But I'd suggest checking with
> clang and/or gcc folks to confirm the difference is intentional too.

A gcc maintainer told me that gcc has behaved like this since forever.
So it could be that the difference in clang may be unintentional.

Thanks,
Pedro Alves