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

[Jan Beulich]

On 24.04.2023 12:33, Alan Modra wrote:
> 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.

After having experimented a little with godbolt.org's help (before making
the patch that you're now about to revert), I found that gcc12 is giving
this warning, too (at least in simple cases). So it may really have been
the removal of the unconditional OPCODES_SIGSETJMP() which has triggered
the warning to appear - in my playing, any unconditional function call
between the setting of the field and returning ended up masking the
warning.

Jan

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