On Fri, Feb 25, 2022 at 08:11:40AM +0100, Richard Biener via Gcc-patches wrote:
> On Thu, 24 Feb 2022, Qing Zhao wrote:
>
> > I briefly checked all the usages of suppress_warning within the current
> > gcc,
> > and see that most of them are not guarded by any condition.
> >
> > So, the current change should be fine without introducing new issues. -:)
> >
> > Another thing is, if we use “warning_enable_at” to guard, I just checked,
> > this routine is not used by any routine right now, so it might be possible
> > that this
> > routine has some bug itself. And now it’s the stage 4, we might need to be
> > conservative.
> >
> > Based on this, I think that it might be better to put the change in as it
> > right now.
> > If we think that all the “suppress_warning” need to be guarded by a specific
> > condition, we can do it in gcc13 earlier stage.
> >
> > What’s your opinion?
>
> I would agree here. Maybe a compromise would be to simply
> set gimple_set_no_warning () on the actual stmt. That shouldn't
I think it is set_no_warning_bit but it isn't exported from
warning-control.cc.
One can still use TREE_NO_WARNING though, but seems Martin converted
all usages of that to the suppress_warning APIs.
I thought the hash tables warning-control.cc use are based on the gimple *
and tree pointers, but apparently they aren't, they are location_t based.
So if we keep using suppress_warning (tmp_dst, OPT_Wuninitialized);
there, it actually means just that one entry will be added to the hash table
because all loads in one clear_padding_flush use the same buf->loc.
It is true that every suppress_warning will need to look it up in the hash
table.
But you're right that because the tmp_dst we've created is artificial, I
don't see a reason for any warning. Unfortunately, even with
suppress_warning (tmp_dst, all_warnings); it looks up the hash tables
and notes stuff in there rather than just making sure the TREE_NO_WARNING
bit is set.
So let's go with the unconditional
suppress_warning (tmp_dst, OPT_Wuninitialized);
for now.
Jakub
