[ was: Re: [gdb/build] Fix Werror=nonnull-compare build breaker with gcc
12 ]

On 7/29/21 12:32 AM, Tom de Vries wrote:
> [ quote-copied from
> https://sourceware.org/pipermail/gdb-patches/2021-July/181173.html. I
> didn't get this email in either my inbox or gdb-patches folder. ]
> 
>> Tom> I managed now to reproduce, and wrote a patch along these lines.
>>
>> Tom> Any comments?
>>
>> Tom> In particular, any suggestion where to put ignore_nonnull?
>>
>> Tom> Or, is it perhaps a better idea to have a gdb_assert_nonnull and
>> Tom> implement things there?
>>
> 
> Thanks for giving your take on this.
> 
>> How about we either drop the nonnull attribute
> 
> That's a possibility indeed.
> 
>> or we use
>> -fno-delete-null-pointer-checks?
>>
> 
> Unfortunately, that doesn't work (and it took me some hours today to
> realize and understand).  I've submitted a patch to improved the nonnull
> documentation (
> https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576218.html ),
> hopefully it should be clear from there that
> -fno-delete-null-pointer-checks doesn't disable the optimization we're
> having trouble with.
> 
>> I personally feel that the gcc approach in this area is
>> counter-productive, at least for our purposes.  My view is that the
>> point of this stuff is to help us detect programming errors -- and we're
>> uninterested in using non-null-ness as some kind of optimization hint.
>> gcc seems to want it both ways, which seems bizarre.
> 
> I think they just implemented two attributes: assume_nonnull and
> verify_nonnull as a single attribute nonnull.  Then still that could be
> workable, but eventually the problem is that you can't switch the two
> interpretations on and off in a reasonable manner.
> 
>> But, given that
>> this is how the compiler works, IMO we should choose reliability
>> whichever way we best can.
> 
> Yes, I hope to get some reasonable feedback, but I'm not holding my
> breath.  So we could possibly end up with dropping nonnull.
> 

How about this patch (currently building) for master and gdb-11-branch,
to have a reliable solution right now for both master and gdb-11-branch,
and if and when the discussion at gcc-patches brings further insight, we
can improve master?

Thanks,
- Tom