Discussion:
build failure in aarch64-opc.c on macOS
Tom Tromey
2018-10-05 14:30:35 UTC
Permalink
Hi. A recent patch caused opcodes to fail to build on macOS (High
Sierra) using the version of clang I have installed (Apple's clang-902).

libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../binutils-gdb/opcodes -I. -I../../binutils-gdb/opcodes -I../bfd -I../../binutils-gdb/opcodes/../include -I../../binutils-gdb/opcodes/../bfd -I./../intl -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT aarch64-opc.lo -MD -MP -MF .deps/aarch64-opc.Tpo -c ../../binutils-gdb/opcodes/aarch64-opc.c -o aarch64-opc.o
../../binutils-gdb/opcodes/aarch64-opc.c:4674:35: error: missing field
'qualifier' initializer [-Werror,-Wmissing-field-initializers]
aarch64_opnd_info blk_pred = {0}, inst_pred = {0};
^
../../binutils-gdb/opcodes/aarch64-opc.c:4674:52: error: missing field
'qualifier' initializer [-Werror,-Wmissing-field-initializers]
aarch64_opnd_info blk_pred = {0}, inst_pred = {0};
^

thanks,
Tom
Andrew Pinski
2018-10-05 16:28:50 UTC
Permalink
Post by Tom Tromey
Hi. A recent patch caused opcodes to fail to build on macOS (High
Sierra) using the version of clang I have installed (Apple's clang-902).
This looks like a clang bug ... {0} should have silienced the
-Wmissing-field-initializers warning. {0} has always been a way to
"0" out a structure without warning.

Thanks,
Andrew
Post by Tom Tromey
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../binutils-gdb/opcodes -I. -I../../binutils-gdb/opcodes -I../bfd -I../../binutils-gdb/opcodes/../include -I../../binutils-gdb/opcodes/../bfd -I./../intl -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT aarch64-opc.lo -MD -MP -MF .deps/aarch64-opc.Tpo -c ../../binutils-gdb/opcodes/aarch64-opc.c -o aarch64-opc.o
../../binutils-gdb/opcodes/aarch64-opc.c:4674:35: error: missing field
'qualifier' initializer [-Werror,-Wmissing-field-initializers]
aarch64_opnd_info blk_pred = {0}, inst_pred = {0};
^
../../binutils-gdb/opcodes/aarch64-opc.c:4674:52: error: missing field
'qualifier' initializer [-Werror,-Wmissing-field-initializers]
aarch64_opnd_info blk_pred = {0}, inst_pred = {0};
^
thanks,
Tom
Tom Tromey
2018-10-05 19:20:39 UTC
Permalink
Post by Tom Tromey
Hi. A recent patch caused opcodes to fail to build on macOS (High
Sierra) using the version of clang I have installed (Apple's clang-902).
Andrew> This looks like a clang bug ... {0} should have silienced the
Andrew> -Wmissing-field-initializers warning. {0} has always been a way to
Andrew> "0" out a structure without warning.

Either way, the build used to work, and now does not.

Tom
Szabolcs Nagy
2018-10-08 09:45:17 UTC
Permalink
Post by Tom Tromey
Post by Tom Tromey
Hi. A recent patch caused opcodes to fail to build on macOS (High
Sierra) using the version of clang I have installed (Apple's clang-902).
Andrew> This looks like a clang bug ... {0} should have silienced the
Andrew> -Wmissing-field-initializers warning. {0} has always been a way to
Andrew> "0" out a structure without warning.
Either way, the build used to work, and now does not.
please report the bug against the compiler
(gcc had a similar issue long time ago)
this really should be fixed, otherwise users will
turn idiomatic c code into awkward workarounds.

(this is a core part of the c99 initializer design to
allow {0} as a universal initializer for any object type,
using memset is not guaranteed to be the same, and trying
to guess the number of fields is wrong for opaque types.)

ideally binutils should be fixed too to detect broken
compilers at configure time and turn off the warning.
(but that's not trivial to do in a general way)
for now you can work it around by using

CC=3D'clang -Wno-missing-field-initializers'

otoh, the particular code can be written in a better
way that avoids the issue entirely (using an operand
info pointer instead of a copy), but that's not a
good excuse to let the compiler bug slide.
Tamar Christina
2018-10-08 09:48:13 UTC
Permalink
Forwarding to list as well.
-----Original Message-----
From: Szabolcs Nagy
Sent: Monday, October 8, 2018 10:43
Subject: Re: build failure in aarch64-opc.c on macOS
Post by Tom Tromey
Post by Tom Tromey
Hi. A recent patch caused opcodes to fail to build on macOS (High
Sierra) using the version of clang I have installed (Apple's clang-902).
Andrew> This looks like a clang bug ... {0} should have silienced
Andrew> the -Wmissing-field-initializers warning. {0} has always
Andrew> been a way to "0" out a structure without warning.
Either way, the build used to work, and now does not.
please report the bug against the compiler (gcc had a similar issue
long time
ago) this really should be fixed, otherwise users will turn idiomatic
c code into awkward workarounds.
(this is a core part of the c99 initializer design to allow {0} as a
universal initializer for any object type, using memset is not
guaranteed to be the same, and trying to guess the number of fields is
wrong for opaque types.)
They have a bug [1] and has been open for years. They however refuse to fix
it claiming that it'll make -Wmissing-field-initializers less useful. It seems
looking at the rest of the code that binutils uses memset here, which at least
gcc will inline and produce the same code at -O2.

So I'll change it to that.

[1] https://bugs.llvm.org/show_bug.cgi?id=21689
ideally binutils should be fixed too to detect broken compilers at
configure time and turn off the warning.
(but that's not trivial to do in a general way) for now you can work
it around by using
CC='clang -Wno-missing-field-initializers'
otoh, the particular code can be written in a better way that avoids
the issue entirely (using an operand info pointer instead of a copy),
but that's not a good excuse to let the compiler bu
Tom Tromey
2018-10-08 19:30:20 UTC
Permalink
Tamar> They have a bug [1] and has been open for years. They however
Tamar> refuse to fix it claiming that it'll make
Tamar> -Wmissing-field-initializers less useful. It seems looking at the
Tamar> rest of the code that binutils uses memset here, which at least
Tamar> gcc will inline and produce the same code at -O2.

Tamar> So I'll change it to that.

Thank you, I can confirm that the fix works here.

Tom

Loading...