On 11/25/20 11:36 AM, Maciej W. Rozycki wrote:
On Fri, 20 Nov 2020, Maciej W. Rozycki wrote:
These changes have been regression-tested throughout development with the
`vax-netbsdelf' target running NetBSD 9.0, using said VAXstation 4000/60,
which uses the Mariah implemementation of the VAX architecture. The host
used was `powerpc64le-linux-gnu' and occasionally `x86_64-linux-gnu' as
well; changes outside the VAX backend were all natively bootstrapped and
regression-tested with both these hosts.
I forgot to note that I have been going through this final verification
with the native compiler and the `vax-netbsdelf' cross-compiler built with
it both configured with `--disable-werror'. This is due to a recent
regression with the Go frontend causing a build error otherwise:
.../gcc/go/gofrontend/go-diagnostics.cc: In function 'std::string
expand_message(const char*, va_list)':
.../gcc/go/gofrontend/go-diagnostics.cc:110:61: error: '<anonymous>' may be
used uninitialized [-Werror=maybe-uninitialized]
110 | "memory allocation failed in vasprintf");
| ^
In file included from
.../prev-powerpc64le-linux-gnu/libstdc++-v3/include/string:55,
from .../gcc/go/go-system.h:34,
from .../gcc/go/gofrontend/go-linemap.h:10,
from .../gcc/go/gofrontend/go-diagnostics.h:10,
from .../gcc/go/gofrontend/go-diagnostics.cc:7:
.../prev-powerpc64le-linux-gnu/libstdc++-v3/include/bits/basic_string.h:525:7: note: by argument 3 of type 'const
std::allocator<char>&' to 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*,
const _Alloc&) [with <template-parameter-2-1> = std::allocator<char>; _CharT = char; _Traits =
std::char_traits<char>; _Alloc = std::allocator<char>]' declared here
525 | basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
| ^~~~~~~~~~~~
.../gcc/go/gofrontend/go-diagnostics.cc:110:61: note: '<anonymous>' declared
here
110 | "memory allocation failed in vasprintf");
| ^
cc1plus: all warnings being treated as errors
make[3]: *** [.../gcc/go/Make-lang.in:242: go/go-diagnostics.o] Error 1
the cause for which I decided I could not afford the time to track down.
Perhaps it has been fixed since, but mentioning it in case it has not.
I wouldn't expect to see this warning after r11-5073. If it persists,
can you please open a bug and attach the translation unit to it?
Thanks
Martin
Earlier verification iterations were done with `--enable-werror-always'.
Maciej
