public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/107015] New: __debug::bitset has different ABI for -std=c++98
@ 2022-09-23 11:26 redi at gcc dot gnu.org
  2022-09-23 11:32 ` [Bug libstdc++/107015] " redi at gcc dot gnu.org
  2022-09-23 11:33 ` redi at gcc dot gnu.org
  0 siblings, 2 replies; 3+ messages in thread
From: redi at gcc dot gnu.org @ 2022-09-23 11:26 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107015

            Bug ID: 107015
           Summary: __debug::bitset has different ABI for -std=c++98
           Product: gcc
           Version: 12.2.1
            Status: UNCONFIRMED
          Keywords: ABI
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

g:17e3f4aa17624af245bae5408b6e5c1fdf90c9ec and the
g:c5589aa7e1e8bf1e56d3c46d952675e1087be311 follow-up changed <debug/bitset> to
not use the debug base container in C++11 mode, because that non-literal base
class means that __debug::bitset is non-literal too.

But that means that __debug::bitset is not ABI compatible between -std=c++98
and later modes.

We should either remove the _Safe_sequence_base class unconditionally (and at
that point, we might as well just get rid of <debug/bitset> and make it an
alias for the normal one), or we should use the base unconditionally and give
up the literal class property.

The standard doesn't actually require is_literal_v<bitset<N>> to be true,
although maybe it should.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug libstdc++/107015] __debug::bitset has different ABI for -std=c++98
  2022-09-23 11:26 [Bug libstdc++/107015] New: __debug::bitset has different ABI for -std=c++98 redi at gcc dot gnu.org
@ 2022-09-23 11:32 ` redi at gcc dot gnu.org
  2022-09-23 11:33 ` redi at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: redi at gcc dot gnu.org @ 2022-09-23 11:32 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107015

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
In C++11 and later (when bitset<N>::reference doesn't use the debug mode
iterator validity checks) the only benefit to __debug::bitset is that we check
the argument to operator[] is in range, using __glibcxx_check_subscript. But we
could just move that into std::bitset anyway. It's a cheap check that is
enabled with _GLIBCXX_ASSERTIONS.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug libstdc++/107015] __debug::bitset has different ABI for -std=c++98
  2022-09-23 11:26 [Bug libstdc++/107015] New: __debug::bitset has different ABI for -std=c++98 redi at gcc dot gnu.org
  2022-09-23 11:32 ` [Bug libstdc++/107015] " redi at gcc dot gnu.org
@ 2022-09-23 11:33 ` redi at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: redi at gcc dot gnu.org @ 2022-09-23 11:33 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107015

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
And we don't even do that check for the const overload, even in debug mode!

      // _GLIBCXX_RESOLVE_LIB_DEFECTS
      // 11. Bitset minor problems
      _GLIBCXX_CONSTEXPR bool
      operator[](size_t __pos) const
      {
#if __cplusplus < 201103L
        // TODO: Check in debug-mode too.
        __glibcxx_check_subscript(__pos);
#endif
        return _Base::operator[](__pos);
      }

I think we should just scrap <debug/bitset>.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-09-23 11:33 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-23 11:26 [Bug libstdc++/107015] New: __debug::bitset has different ABI for -std=c++98 redi at gcc dot gnu.org
2022-09-23 11:32 ` [Bug libstdc++/107015] " redi at gcc dot gnu.org
2022-09-23 11:33 ` redi at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).