☠ Buildbot (Sourceware): binutils-gdb - failed compile (failure) (master)

[Alan Modra]

On Mon, Apr 24, 2023 at 08:04:35AM +0200, Jan Beulich via Binutils wrote:
> On 24.04.2023 02:31, builder--- via Binutils wrote:
> > - 4: make ( failure )
> >     Logs:
> >         - stdio: https://builder.sourceware.org/buildbot/#builders/77/builds/1931/steps/4/logs/stdio
> >         - warnings (8): https://builder.sourceware.org/buildbot/#builders/77/builds/1931/steps/4/logs/warnings__8_
> 
> ../../binutils-gdb/opcodes/i386-dis.c: In function ‘print_insn’:
> ../../binutils-gdb/opcodes/i386-dis.c:9865:22: error: storing the address of local variable ‘priv’ in ‘*info.private_data’ [-Werror=dangling-pointer=]
>  9865 |   info->private_data = &priv;
>       |   ~~~~~~~~~~~~~~~~~~~^~~~~~~
> ../../binutils-gdb/opcodes/i386-dis.c:9739:22: note: ‘priv’ declared here
>  9739 |   struct dis_private priv;
>       |                      ^~~~
> ../../binutils-gdb/opcodes/i386-dis.c:9739:22: note: ‘info’ declared here
> cc1: all warnings being treated as errors
> make[3]: *** [Makefile:1071: i386-dis.lo] Error 1
> 
> Which, given that this hasn't changed in a while, makes me think that a
> new compiler was recently installed, which now diagnoses this supposed

gcc-13, I expect.

> issue (and, btw, mis-diagnoses where "info" is declared). We can't do
> away with the assignment; it's unclear to me whether overwriting the
> field with NULL before returning would make a difference.

It does.  See my other email.

> Dynamically
> allocating "priv" would be a theoretical option, but I don't view this as
> a good one in practice.
> 
> Thoughts, anyone?
> 
> Jan

-- 
Alan Modra
Australia Development Lab, IBM