On Thu, 12 Sept 2024 at 21:51, Jason Merrill <ja...@redhat.com> wrote:
>
> Tested x86_64-pc-linux-gnu. Thoughts about the remaining warnings discussed
> below? Any other comments?
>
> -- 8< --
>
> The use of #pragma GCC system_header in libstdc++ has led to bugs going
> undetected for a while due to the silencing of compiler warnings that would
> have revealed them promptly, and also interferes with warnings about
> problematic template instantiations induced by user code.
>
> But removing it, or even compiling with -Wsystem-header, is also problematic
> due to warnings about deliberate uses of extensions.
>
> So this patch adds #pragma GCC diagnostic as needed to suppress these
> warnings.
>
> The change to acinclude.m4 changes -Wabi to warn only in comparison to ABI
> 19, to avoid lots of warnings that we now mangle concept requirements, which
> are in any case still experimental.
>
> It also enables -Wsystem-headers while building the library, so we see any
> warnings not silenced by these #pragmas. After this patch, the remaining
> warnings I see are:
>
> ios_base_init.h:12: warning about reserved init_priority
> I'll add a warning flag to silence this.
>
> exception_ptr.h:155: warning about useless attribute((const)) on void fn.
> Should we remove the attribute?
Yes, I'll do that.
> cxx11-ios_failure.cc:98: warning about overriding the two-parameter
> __do_upcast that isn't overridden in __si_class_type_info, rather than the
> three-parameter form that is overridden in __si_class_type_info.
> I suppose this must be working, and changing the signature would be an ABI
> break, so maybe we just want to silence the warning?
OK, I'll add:
--- a/libstdc++-v3/src/c++11/cxx11-ios_failure.cc
+++ b/libstdc++-v3/src/c++11/cxx11-ios_failure.cc
@@ -94,6 +94,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
~__iosfail_type_info();
+ using __si_class_type_info::__do_upcast;
+
bool
__do_upcast (const __class_type_info *dst_type,
void **obj_ptr) const override;
> It's also unclear that -Woverloaded-virtuals=1 is supposed to warn when the
> function is in fact an override; it warns in this case because it's
> overriding a function that its direct base didn't also override.
Hmm ... the other virtual function is still hidden and only accessible
via the base class. Maybe it's helpful to warn.
> I have a follow-up patch to #ifdef out all the #pragma system_header, but
> want that to be considered separately.
Sounds good - this one looks fine, thanks.
