* Re: GDB 8.1 build error
2018-04-27 18:57 ` Paul Koning
@ 2018-04-27 19:01 ` Paul Koning
2018-04-27 19:08 ` Simon Marchi
` (2 subsequent siblings)
3 siblings, 0 replies; 17+ messages in thread
From: Paul Koning @ 2018-04-27 19:01 UTC (permalink / raw)
To: Simon Marchi; +Cc: gdb
> 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
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: GDB 8.1 build error
2018-04-27 18:57 ` Paul Koning
2018-04-27 19:01 ` Paul Koning
@ 2018-04-27 19:08 ` Simon Marchi
2018-04-27 19:18 ` Paul Koning
2018-04-27 20:41 ` Paul Koning
2018-04-27 19:10 ` Pedro Alves
2018-04-27 19:10 ` Simon Marchi
3 siblings, 2 replies; 17+ messages in thread
From: Simon Marchi @ 2018-04-27 19:08 UTC (permalink / raw)
To: Paul Koning; +Cc: gdb
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
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: GDB 8.1 build error
2018-04-27 19:08 ` Simon Marchi
@ 2018-04-27 19:18 ` Paul Koning
2018-04-27 20:41 ` Paul Koning
1 sibling, 0 replies; 17+ messages in thread
From: Paul Koning @ 2018-04-27 19:18 UTC (permalink / raw)
To: Simon Marchi; +Cc: gdb
> 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB 8.1 build error
2018-04-27 19:08 ` Simon Marchi
2018-04-27 19:18 ` Paul Koning
@ 2018-04-27 20:41 ` Paul Koning
1 sibling, 0 replies; 17+ messages in thread
From: Paul Koning @ 2018-04-27 20:41 UTC (permalink / raw)
To: Simon Marchi; +Cc: gdb
> 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB 8.1 build error
2018-04-27 18:57 ` Paul Koning
2018-04-27 19:01 ` Paul Koning
2018-04-27 19:08 ` Simon Marchi
@ 2018-04-27 19:10 ` Pedro Alves
2018-04-27 19:39 ` Simon Marchi
2018-04-27 19:10 ` Simon Marchi
3 siblings, 1 reply; 17+ messages in thread
From: Pedro Alves @ 2018-04-27 19:10 UTC (permalink / raw)
To: Paul Koning, Simon Marchi; +Cc: gdb
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
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: GDB 8.1 build error
2018-04-27 19:10 ` Pedro Alves
@ 2018-04-27 19:39 ` Simon Marchi
2018-04-27 20:00 ` Pedro Alves
2018-04-27 20:16 ` Pedro Alves
0 siblings, 2 replies; 17+ messages in thread
From: Simon Marchi @ 2018-04-27 19:39 UTC (permalink / raw)
To: Pedro Alves; +Cc: Paul Koning, gdb
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
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: GDB 8.1 build error
2018-04-27 19:39 ` Simon Marchi
@ 2018-04-27 20:00 ` Pedro Alves
2018-04-27 20:16 ` Pedro Alves
1 sibling, 0 replies; 17+ messages in thread
From: Pedro Alves @ 2018-04-27 20:00 UTC (permalink / raw)
To: Simon Marchi; +Cc: Paul Koning, gdb
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
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: GDB 8.1 build error
2018-04-27 19:39 ` Simon Marchi
2018-04-27 20:00 ` Pedro Alves
@ 2018-04-27 20:16 ` Pedro Alves
2018-04-27 20:24 ` Simon Marchi
1 sibling, 1 reply; 17+ messages in thread
From: Pedro Alves @ 2018-04-27 20:16 UTC (permalink / raw)
To: Simon Marchi; +Cc: Paul Koning, gdb
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB 8.1 build error
2018-04-27 20:16 ` Pedro Alves
@ 2018-04-27 20:24 ` Simon Marchi
2018-04-27 20:41 ` Pedro Alves
0 siblings, 1 reply; 17+ messages in thread
From: Simon Marchi @ 2018-04-27 20:24 UTC (permalink / raw)
To: Pedro Alves; +Cc: Paul Koning, gdb
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB 8.1 build error
2018-04-27 20:24 ` Simon Marchi
@ 2018-04-27 20:41 ` Pedro Alves
2018-04-27 20:48 ` Simon Marchi
0 siblings, 1 reply; 17+ messages in thread
From: Pedro Alves @ 2018-04-27 20:41 UTC (permalink / raw)
To: Simon Marchi; +Cc: Paul Koning, gdb
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB 8.1 build error
2018-04-27 20:41 ` Pedro Alves
@ 2018-04-27 20:48 ` Simon Marchi
2018-05-02 9:42 ` Pedro Alves
0 siblings, 1 reply; 17+ messages in thread
From: Simon Marchi @ 2018-04-27 20:48 UTC (permalink / raw)
To: Pedro Alves; +Cc: Paul Koning, gdb
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB 8.1 build error
2018-04-27 20:48 ` Simon Marchi
@ 2018-05-02 9:42 ` Pedro Alves
2018-05-02 10:13 ` Pedro Alves
0 siblings, 1 reply; 17+ messages in thread
From: Pedro Alves @ 2018-05-02 9:42 UTC (permalink / raw)
To: Simon Marchi; +Cc: Paul Koning, gdb
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
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: GDB 8.1 build error
2018-05-02 9:42 ` Pedro Alves
@ 2018-05-02 10:13 ` Pedro Alves
0 siblings, 0 replies; 17+ messages in thread
From: Pedro Alves @ 2018-05-02 10:13 UTC (permalink / raw)
To: Simon Marchi; +Cc: Paul Koning, gdb
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB 8.1 build error
2018-04-27 18:57 ` Paul Koning
` (2 preceding siblings ...)
2018-04-27 19:10 ` Pedro Alves
@ 2018-04-27 19:10 ` Simon Marchi
3 siblings, 0 replies; 17+ messages in thread
From: Simon Marchi @ 2018-04-27 19:10 UTC (permalink / raw)
To: Paul Koning; +Cc: gdb
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
^ permalink raw reply [flat|nested] 17+ messages in thread