https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642
Marek Polacek <mpolacek at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
Last reconfirmed| |2023-04-28
Status|UNCONFIRMED |ASSIGNED
--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(In reply to Carlos Galvez from comment #4)
> While I can do that on my own code, I cannot add that suppression on
> third-party code, like Eigen (which I also get a lot of false positives in
> similar code), even if I include the header via -isystem - since the
> warnings are on the client side.
>
> Is this really the expected behavior of a warning belonging to -Wall? Has
> this warning been tested on large projects to evaluate the false positive
> rate?
Yes, we've compiled a whole distro and the false positive rate was actually
surprisingly low, except now that GCC 13 was released it seems the
std::span-like false positives are actually a big deal. :( So...
> Would you consider perhaps reducing the scope of the warning in order to
> reduce the false positive rate, alternatively move it out of Wall?
...I think I'll have to move it to -Wextra (for GCC 13.2). Considering any
class with a T* member a std::span-like class would probably diminish the
warning too much. Maybe we need a [[gcc::whatever]] attribute to mark a class
as a reference-wrapper-like.
> It's sad that a lot of work and effort was put into creating this warning
> and it will just probably be disabled on most projects. When a tool produces
> a lot of false positives, there is high risk that developers stop trusting
> the tool and true positives are ignored.
Indeed. I'm sorry about the trouble you've had with the warning. I can
certainly understand why it's frustrating.
