head 1.1; branch 1.1.1; access; symbols netbsd-11-0-RC4:1.1.1.3 netbsd-11-0-RC3:1.1.1.3 netbsd-11-0-RC2:1.1.1.3 netbsd-11-0-RC1:1.1.1.3 gcc-14-3-0:1.1.1.3 perseant-exfatfs-base-20250801:1.1.1.3 netbsd-11:1.1.1.3.0.4 netbsd-11-base:1.1.1.3 gcc-12-5-0:1.1.1.3 netbsd-10-1-RELEASE:1.1.1.2 perseant-exfatfs-base-20240630:1.1.1.3 gcc-12-4-0:1.1.1.3 perseant-exfatfs:1.1.1.3.0.2 perseant-exfatfs-base:1.1.1.3 netbsd-8-3-RELEASE:1.1.1.1 netbsd-9-4-RELEASE:1.1.1.2 netbsd-10-0-RELEASE:1.1.1.2 netbsd-10-0-RC6:1.1.1.2 netbsd-10-0-RC5:1.1.1.2 netbsd-10-0-RC4:1.1.1.2 netbsd-10-0-RC3:1.1.1.2 netbsd-10-0-RC2:1.1.1.2 netbsd-10-0-RC1:1.1.1.2 gcc-12-3-0:1.1.1.3 gcc-10-5-0:1.1.1.2 netbsd-10:1.1.1.2.0.10 netbsd-10-base:1.1.1.2 netbsd-9-3-RELEASE:1.1.1.2 gcc-10-4-0:1.1.1.2 cjep_sun2x-base1:1.1.1.2 cjep_sun2x:1.1.1.2.0.8 cjep_sun2x-base:1.1.1.2 cjep_staticlib_x-base1:1.1.1.2 netbsd-9-2-RELEASE:1.1.1.2 cjep_staticlib_x:1.1.1.2.0.6 cjep_staticlib_x-base:1.1.1.2 gcc-10-3-0:1.1.1.2 netbsd-9-1-RELEASE:1.1.1.2 gcc-9-3-0:1.1.1.2 gcc-7-5-0:1.1.1.2 phil-wifi-20200421:1.1.1.2 phil-wifi-20200411:1.1.1.2 is-mlppp:1.1.1.2.0.4 is-mlppp-base:1.1.1.2 phil-wifi-20200406:1.1.1.2 netbsd-8-2-RELEASE:1.1.1.1 gcc-8-4-0:1.1.1.2 netbsd-9-0-RELEASE:1.1.1.2 netbsd-9-0-RC2:1.1.1.2 netbsd-9-0-RC1:1.1.1.2 phil-wifi-20191119:1.1.1.2 gcc-8-3-0:1.1.1.2 netbsd-9:1.1.1.2.0.2 netbsd-9-base:1.1.1.2 phil-wifi-20190609:1.1.1.2 netbsd-8-1-RELEASE:1.1.1.1 netbsd-8-1-RC1:1.1.1.1 pgoyette-compat-merge-20190127:1.1.1.1.28.1 pgoyette-compat-20190127:1.1.1.2 gcc-7-4-0:1.1.1.2 pgoyette-compat-20190118:1.1.1.2 pgoyette-compat-1226:1.1.1.2 pgoyette-compat-1126:1.1.1.2 gcc-6-5-0:1.1.1.2 pgoyette-compat-1020:1.1.1.1 pgoyette-compat-0930:1.1.1.1 pgoyette-compat-0906:1.1.1.1 netbsd-7-2-RELEASE:1.1.1.1 pgoyette-compat-0728:1.1.1.1 netbsd-8-0-RELEASE:1.1.1.1 phil-wifi:1.1.1.1.0.30 phil-wifi-base:1.1.1.1 pgoyette-compat-0625:1.1.1.1 netbsd-8-0-RC2:1.1.1.1 pgoyette-compat-0521:1.1.1.1 pgoyette-compat-0502:1.1.1.1 pgoyette-compat-0422:1.1.1.1 netbsd-8-0-RC1:1.1.1.1 pgoyette-compat-0415:1.1.1.1 pgoyette-compat-0407:1.1.1.1 pgoyette-compat-0330:1.1.1.1 pgoyette-compat-0322:1.1.1.1 pgoyette-compat-0315:1.1.1.1 netbsd-7-1-2-RELEASE:1.1.1.1 pgoyette-compat:1.1.1.1.0.28 pgoyette-compat-base:1.1.1.1 gcc-6-4-0:1.1.1.1 netbsd-7-1-1-RELEASE:1.1.1.1 gcc-5-5-0:1.1.1.1 matt-nb8-mediatek:1.1.1.1.0.26 matt-nb8-mediatek-base:1.1.1.1 perseant-stdc-iso10646:1.1.1.1.0.24 perseant-stdc-iso10646-base:1.1.1.1 netbsd-8:1.1.1.1.0.22 netbsd-8-base:1.1.1.1 prg-localcount2-base3:1.1.1.1 prg-localcount2-base2:1.1.1.1 prg-localcount2-base1:1.1.1.1 prg-localcount2:1.1.1.1.0.20 prg-localcount2-base:1.1.1.1 pgoyette-localcount-20170426:1.1.1.1 bouyer-socketcan-base1:1.1.1.1 pgoyette-localcount-20170320:1.1.1.1 netbsd-7-1:1.1.1.1.0.18 netbsd-7-1-RELEASE:1.1.1.1 netbsd-7-1-RC2:1.1.1.1 netbsd-7-nhusb-base-20170116:1.1.1.1 bouyer-socketcan:1.1.1.1.0.16 bouyer-socketcan-base:1.1.1.1 pgoyette-localcount-20170107:1.1.1.1 netbsd-7-1-RC1:1.1.1.1 pgoyette-localcount-20161104:1.1.1.1 netbsd-7-0-2-RELEASE:1.1.1.1 localcount-20160914:1.1.1.1 netbsd-7-nhusb:1.1.1.1.0.14 netbsd-7-nhusb-base:1.1.1.1 pgoyette-localcount-20160806:1.1.1.1 pgoyette-localcount-20160726:1.1.1.1 pgoyette-localcount:1.1.1.1.0.12 pgoyette-localcount-base:1.1.1.1 gcc-5-4-0:1.1.1.1 netbsd-7-0-1-RELEASE:1.1.1.1 gcc-5-3-0:1.1.1.1 netbsd-7-0:1.1.1.1.0.10 netbsd-7-0-RELEASE:1.1.1.1 gcc-4-8-5-pre-gcc-old-import:1.1.1.1 netbsd-7-0-RC3:1.1.1.1 netbsd-7-0-RC2:1.1.1.1 post-gcc-4-8-5-merge:1.1.1.1 gcc-4-8-5:1.1.1.1 netbsd-7-0-RC1:1.1.1.1 gcc-4-8-4:1.1.1.1 gcc-4-8-20141009:1.1.1.1 tls-maxphys-base:1.1.1.1 tls-maxphys:1.1.1.1.0.8 netbsd-7:1.1.1.1.0.6 netbsd-7-base:1.1.1.1 gcc-4-8-3:1.1.1.1 yamt-pagecache:1.1.1.1.0.4 yamt-pagecache-base9:1.1.1.1 tls-earlyentropy:1.1.1.1.0.2 tls-earlyentropy-base:1.1.1.1 riastradh-xf86-video-intel-2-7-1-pre-2-21-15:1.1.1.1 riastradh-drm2-base3:1.1.1.1 gcc-4-8-3-pre-r208254:1.1.1.1 gcc-4-8-3-pre-r206687:1.1.1.1 FSF:1.1.1; locks; strict; comment @# @; 1.1 date 2014.03.01.08.41.30; author mrg; state Exp; branches 1.1.1.1; next ; commitid TtaB91QNTknAoYqx; 1.1.1.1 date 2014.03.01.08.41.30; author mrg; state Exp; branches 1.1.1.1.4.1 1.1.1.1.8.1 1.1.1.1.28.1 1.1.1.1.30.1; next 1.1.1.2; commitid TtaB91QNTknAoYqx; 1.1.1.2 date 2018.11.04.00.12.37; author mrg; state Exp; branches; next 1.1.1.3; commitid bulspy67pMB6EyYA; 1.1.1.3 date 2023.07.30.05.21.21; author mrg; state Exp; branches; next ; commitid tk6nV4mbc9nVEMyE; 1.1.1.1.4.1 date 2014.03.01.08.41.30; author yamt; state dead; branches; next 1.1.1.1.4.2; commitid DX8bafDLmqEbpyBx; 1.1.1.1.4.2 date 2014.05.22.16.37.45; author yamt; state Exp; branches; next ; commitid DX8bafDLmqEbpyBx; 1.1.1.1.8.1 date 2014.03.01.08.41.30; author tls; state dead; branches; next 1.1.1.1.8.2; commitid jTnpym9Qu0o4R1Nx; 1.1.1.1.8.2 date 2014.08.19.23.54.46; author tls; state Exp; branches; next ; commitid jTnpym9Qu0o4R1Nx; 1.1.1.1.28.1 date 2018.11.26.01.50.57; author pgoyette; state Exp; branches; next ; commitid Zj4q5SspGdKXto1B; 1.1.1.1.30.1 date 2019.06.10.21.54.48; author christos; state Exp; branches; next ; commitid jtc8rnCzWiEEHGqB; desc @@ 1.1 log @Initial revision @ text @
A program that uses the C++ standard library correctly
will maintain the same semantics under debug mode as it had with
the normal (release) library. All functional and exception-handling
guarantees made by the normal library also hold for the debug mode
library, with one exception: performance guarantees made by the
normal library may not hold in the debug mode library. For
instance, erasing an element in a std::list is a
constant-time operation in normal library, but in debug mode it is
linear in the number of iterators that reference that particular
list. So while your (correct) program won't change its results, it
is likely to execute more slowly.
libstdc++ includes many extensions to the C++ standard library. In
some cases the extensions are obvious, such as the hashed
associative containers, whereas other extensions give predictable
results to behavior that would otherwise be undefined, such as
throwing an exception when a std::basic_string is
constructed from a NULL character pointer. This latter category also
includes implementation-defined and unspecified semantics, such as
the growth rate of a vector. Use of these extensions is not
considered incorrect, so code that relies on them will not be
rejected by debug mode. However, use of these extensions may affect
the portability of code to other implementations of the C++ standard
library, and is therefore somewhat hazardous. For this reason, the
libstdc++ debug mode offers a "pedantic" mode (similar to
GCC's -pedantic compiler flag) that attempts to emulate
the semantics guaranteed by the C++ standard. For
instance, constructing a std::basic_string with a NULL
character pointer would result in an exception under normal mode or
non-pedantic debug mode (this is a libstdc++ extension), whereas
under pedantic debug mode libstdc++ would signal an error. To enable
the pedantic debug mode, compile your program with
both -D_GLIBCXX_DEBUG
and -D_GLIBCXX_DEBUG_PEDANTIC .
(N.B. In GCC 3.4.x and 4.0.0, due to a bug,
-D_GLIBXX_DEBUG_PEDANTIC was also needed. The problem has
been fixed in GCC 4.0.1 and later versions.)
The following library components provide extra debugging capabilities in debug mode:
std::basic_string (no safe iterators and see note below)
std::bitset
std::deque
std::list
std::map
std::multimap
std::multiset
std::set
std::vector
std::unordered_map
std::unordered_multimap
std::unordered_set
std::unordered_multiset
N.B. although there are precondition checks for some string operations,
e.g. operator[],
they will not always be run when using the char and
wchar_t specialisations (std::string and
std::wstring). This is because libstdc++ uses GCC's
extern template extension to provide explicit instantiations
of std::string and std::wstring, and those
explicit instantiations don't include the debug-mode checks. If the
containing functions are inlined then the checks will run, so compiling
with -O1 might be enough to enable them. Alternatively
-D_GLIBCXX_EXTERN_TEMPLATE=0 will suppress the declarations
of the explicit instantiations and cause the functions to be instantiated
with the debug-mode checks included, but this is unsupported and not
guaranteed to work. For full debug-mode support you can use the
__gnu_debug::basic_string debugging container directly,
which always works correctly.
@ 1.1.1.1.28.1 log @Sync with HEAD, resolve a couple of conflicts @ text @d2 1 a2 1
@ 1.1.1.2 log @import GCC 6.5.0. this is largely a maint release with no particularly features listed here: http://gcc.gnu.org/gcc-6/changes.html this fixes over 250 PRs in the GCC bugzilla: https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=6.5 @ text @d2 1 a2 1
@ 1.1.1.3 log @initial import of GCC 12.3.0. major changes in GCC 11 included: - The default mode for C++ is now -std=gnu++17 instead of -std=gnu++14. - When building GCC itself, the host compiler must now support C++11, rather than C++98. - Some short options of the gcov tool have been renamed: -i to -j and -j to -H. - ThreadSanitizer improvements. - Introduce Hardware-assisted AddressSanitizer support. - For targets that produce DWARF debugging information GCC now defaults to DWARF version 5. This can produce up to 25% more compact debug information compared to earlier versions. - Many optimisations. - The existing malloc attribute has been extended so that it can be used to identify allocator/deallocator API pairs. A pair of new -Wmismatched-dealloc and -Wmismatched-new-delete warnings are added. - Other new warnings: -Wsizeof-array-div, enabled by -Wall, warns about divisions of two sizeof operators when the first one is applied to an array and the divisor does not equal the size of the array element. -Wstringop-overread, enabled by default, warns about calls to string functions reading past the end of the arrays passed to them as arguments. -Wtsan, enabled by default, warns about unsupported features in ThreadSanitizer (currently std::atomic_thread_fence). - Enchanced warnings: -Wfree-nonheap-object detects many more instances of calls to deallocation functions with pointers not returned from a dynamic memory allocation function. -Wmaybe-uninitialized diagnoses passing pointers or references to uninitialized memory to functions taking const-qualified arguments. -Wuninitialized detects reads from uninitialized dynamically allocated memory. -Warray-parameter warns about functions with inconsistent array forms. -Wvla-parameter warns about functions with inconsistent VLA forms. - Several new features from the upcoming C2X revision of the ISO C standard are supported with -std=c2x and -std=gnu2x. - Several C++20 features have been implemented. - The C++ front end has experimental support for some of the upcoming C++23 draft. - Several new C++ warnings. - Enhanced Arm, AArch64, x86, and RISC-V CPU support. - The implementation of how program state is tracked within -fanalyzer has been completely rewritten with many enhancements. see https://gcc.gnu.org/gcc-11/changes.html for a full list. major changes in GCC 12 include: - An ABI incompatibility between C and C++ when passing or returning by value certain aggregates containing zero width bit-fields has been discovered on various targets. x86-64, ARM and AArch64 will always ignore them (so there is a C ABI incompatibility between GCC 11 and earlier with GCC 12 or later), PowerPC64 ELFv2 always take them into account (so there is a C++ ABI incompatibility, GCC 4.4 and earlier compatible with GCC 12 or later, incompatible with GCC 4.5 through GCC 11). RISC-V has changed the handling of these already starting with GCC 10. As the ABI requires, MIPS takes them into account handling function return values so there is a C++ ABI incompatibility with GCC 4.5 through 11. - STABS: Support for emitting the STABS debugging format is deprecated and will be removed in the next release. All ports now default to emit DWARF (version 2 or later) debugging info or are obsoleted. - Vectorization is enabled at -O2 which is now equivalent to the original -O2 -ftree-vectorize -fvect-cost-model=very-cheap. - GCC now supports the ShadowCallStack sanitizer. - Support for __builtin_shufflevector compatible with the clang language extension was added. - Support for attribute unavailable was added. - Support for __builtin_dynamic_object_size compatible with the clang language extension was added. - New warnings: -Wbidi-chars warns about potentially misleading UTF-8 bidirectional control characters. -Warray-compare warns about comparisons between two operands of array type. - Some new features from the upcoming C2X revision of the ISO C standard are supported with -std=c2x and -std=gnu2x. - Several C++23 features have been implemented. - Many C++ enhancements across warnings and -f options. see https://gcc.gnu.org/gcc-12/changes.html for a full list. @ text @d38 1 a38 1 capabilities in debug mode:
std::array (no safe iterators)
std::basic_string (no safe iterators and see note below)
std::bitset
std::deque
std::list
std::map
std::multimap
std::multiset
std::set
std::vector
std::unordered_map
std::unordered_multimap
std::unordered_set
std::unordered_multiset
N.B. although there are precondition checks for some string operations,
d41 1
a41 1
wchar_t specializations (std::string and
@
1.1.1.1.8.1
log
@file debug_mode_semantics.html was added on branch tls-maxphys on 2014-08-19 23:54:46 +0000
@
text
@d1 54
@
1.1.1.1.8.2
log
@Rebase to HEAD as of a few days ago.
@
text
@a0 54
A program that uses the C++ standard library correctly
will maintain the same semantics under debug mode as it had with
the normal (release) library. All functional and exception-handling
guarantees made by the normal library also hold for the debug mode
library, with one exception: performance guarantees made by the
normal library may not hold in the debug mode library. For
instance, erasing an element in a std::list is a
constant-time operation in normal library, but in debug mode it is
linear in the number of iterators that reference that particular
list. So while your (correct) program won't change its results, it
is likely to execute more slowly.
libstdc++ includes many extensions to the C++ standard library. In
some cases the extensions are obvious, such as the hashed
associative containers, whereas other extensions give predictable
results to behavior that would otherwise be undefined, such as
throwing an exception when a std::basic_string is
constructed from a NULL character pointer. This latter category also
includes implementation-defined and unspecified semantics, such as
the growth rate of a vector. Use of these extensions is not
considered incorrect, so code that relies on them will not be
rejected by debug mode. However, use of these extensions may affect
the portability of code to other implementations of the C++ standard
library, and is therefore somewhat hazardous. For this reason, the
libstdc++ debug mode offers a "pedantic" mode (similar to
GCC's -pedantic compiler flag) that attempts to emulate
the semantics guaranteed by the C++ standard. For
instance, constructing a std::basic_string with a NULL
character pointer would result in an exception under normal mode or
non-pedantic debug mode (this is a libstdc++ extension), whereas
under pedantic debug mode libstdc++ would signal an error. To enable
the pedantic debug mode, compile your program with
both -D_GLIBCXX_DEBUG
and -D_GLIBCXX_DEBUG_PEDANTIC .
(N.B. In GCC 3.4.x and 4.0.0, due to a bug,
-D_GLIBXX_DEBUG_PEDANTIC was also needed. The problem has
been fixed in GCC 4.0.1 and later versions.)
The following library components provide extra debugging capabilities in debug mode:
std::basic_string (no safe iterators and see note below)
std::bitset
std::deque
std::list
std::map
std::multimap
std::multiset
std::set
std::vector
std::unordered_map
std::unordered_multimap
std::unordered_set
std::unordered_multiset
N.B. although there are precondition checks for some string operations,
e.g. operator[],
they will not always be run when using the char and
wchar_t specialisations (std::string and
std::wstring). This is because libstdc++ uses GCC's
extern template extension to provide explicit instantiations
of std::string and std::wstring, and those
explicit instantiations don't include the debug-mode checks. If the
containing functions are inlined then the checks will run, so compiling
with -O1 might be enough to enable them. Alternatively
-D_GLIBCXX_EXTERN_TEMPLATE=0 will suppress the declarations
of the explicit instantiations and cause the functions to be instantiated
with the debug-mode checks included, but this is unsupported and not
guaranteed to work. For full debug-mode support you can use the
__gnu_debug::basic_string debugging container directly,
which always works correctly.
A program that uses the C++ standard library correctly
will maintain the same semantics under debug mode as it had with
the normal (release) library. All functional and exception-handling
guarantees made by the normal library also hold for the debug mode
library, with one exception: performance guarantees made by the
normal library may not hold in the debug mode library. For
instance, erasing an element in a std::list is a
constant-time operation in normal library, but in debug mode it is
linear in the number of iterators that reference that particular
list. So while your (correct) program won't change its results, it
is likely to execute more slowly.
libstdc++ includes many extensions to the C++ standard library. In
some cases the extensions are obvious, such as the hashed
associative containers, whereas other extensions give predictable
results to behavior that would otherwise be undefined, such as
throwing an exception when a std::basic_string is
constructed from a NULL character pointer. This latter category also
includes implementation-defined and unspecified semantics, such as
the growth rate of a vector. Use of these extensions is not
considered incorrect, so code that relies on them will not be
rejected by debug mode. However, use of these extensions may affect
the portability of code to other implementations of the C++ standard
library, and is therefore somewhat hazardous. For this reason, the
libstdc++ debug mode offers a "pedantic" mode (similar to
GCC's -pedantic compiler flag) that attempts to emulate
the semantics guaranteed by the C++ standard. For
instance, constructing a std::basic_string with a NULL
character pointer would result in an exception under normal mode or
non-pedantic debug mode (this is a libstdc++ extension), whereas
under pedantic debug mode libstdc++ would signal an error. To enable
the pedantic debug mode, compile your program with
both -D_GLIBCXX_DEBUG
and -D_GLIBCXX_DEBUG_PEDANTIC .
(N.B. In GCC 3.4.x and 4.0.0, due to a bug,
-D_GLIBXX_DEBUG_PEDANTIC was also needed. The problem has
been fixed in GCC 4.0.1 and later versions.)
The following library components provide extra debugging capabilities in debug mode:
std::basic_string (no safe iterators and see note below)
std::bitset
std::deque
std::list
std::map
std::multimap
std::multiset
std::set
std::vector
std::unordered_map
std::unordered_multimap
std::unordered_set
std::unordered_multiset
N.B. although there are precondition checks for some string operations,
e.g. operator[],
they will not always be run when using the char and
wchar_t specialisations (std::string and
std::wstring). This is because libstdc++ uses GCC's
extern template extension to provide explicit instantiations
of std::string and std::wstring, and those
explicit instantiations don't include the debug-mode checks. If the
containing functions are inlined then the checks will run, so compiling
with -O1 might be enough to enable them. Alternatively
-D_GLIBCXX_EXTERN_TEMPLATE=0 will suppress the declarations
of the explicit instantiations and cause the functions to be instantiated
with the debug-mode checks included, but this is unsupported and not
guaranteed to work. For full debug-mode support you can use the
__gnu_debug::basic_string debugging container directly,
which always works correctly.