* [Bug libstdc++/86843] Allow separating debug mode into ABI-changing part and rest
[not found] <bug-86843-4@http.gcc.gnu.org/bugzilla/>
@ 2024-01-17 12:05 ` redi at gcc dot gnu.org
2024-01-17 17:58 ` sjames at gcc dot gnu.org
` (4 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2024-01-17 12:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86843
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=111250
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #2)
> These don't depend on debug mode iterators:
>
> // Verify that [_First, _Last) forms a non-empty iterator range.
> #define __glibcxx_check_non_empty_range(_First,_Last) \
This is never actually used, but __glibcxx_requires_non_empty_range is and
that's already enabled by _GLIBCXX_ASSERTIONS.
> // Verify that the subscript _N is less than the container's size.
> #define __glibcxx_check_subscript(_N) \
Ditto, for __glibcxx_requires_subscript.
> // Verify that the bucket _N is less than the container's buckets count.
> #define __glibcxx_check_bucket_index(_N) \
> _GLIBCXX_DEBUG_VERIFY(_N < this->bucket_count(), \
This should probably be enabled for _GLIBCXX_ASSERTIONS.
> // Verify that the container is nonempty
> #define __glibcxx_check_nonempty() \
> _GLIBCXX_DEBUG_VERIFY(! this->empty(), \
__glibcxx_requires_nonempty is already enabled by _GLIBCXX_ASSERTIONS.
> // Verify that load factor is positive
> #define __glibcxx_check_max_load_factor(_F) \
> _GLIBCXX_DEBUG_VERIFY(_F > 0.0f, \
This should probably be enabled for _GLIBCXX_ASSERTIONS.
> #define __glibcxx_check_equal_allocs(_This, _Other) \
> _GLIBCXX_DEBUG_VERIFY(_This.get_allocator() == _Other.get_allocator(), \
This should probably be enabled for _GLIBCXX_ASSERTIONS.
That just leaves:
> // Verify that a predicate is irreflexive
> #define __glibcxx_check_irreflexive(_First,_Last) \
> _GLIBCXX_DEBUG_VERIFY(_First == _Last || !(*_First < *_First), \
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug libstdc++/86843] Allow separating debug mode into ABI-changing part and rest
[not found] <bug-86843-4@http.gcc.gnu.org/bugzilla/>
2024-01-17 12:05 ` [Bug libstdc++/86843] Allow separating debug mode into ABI-changing part and rest redi at gcc dot gnu.org
@ 2024-01-17 17:58 ` sjames at gcc dot gnu.org
2024-01-17 21:19 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-01-17 17:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86843
--- Comment #4 from Sam James <sjames at gcc dot gnu.org> ---
libcxx has started working towards this, see
https://discourse.llvm.org/t/rfc-hardening-in-libc/73925 and
https://libcxx.llvm.org/Hardening.html.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug libstdc++/86843] Allow separating debug mode into ABI-changing part and rest
[not found] <bug-86843-4@http.gcc.gnu.org/bugzilla/>
2024-01-17 12:05 ` [Bug libstdc++/86843] Allow separating debug mode into ABI-changing part and rest redi at gcc dot gnu.org
2024-01-17 17:58 ` sjames at gcc dot gnu.org
@ 2024-01-17 21:19 ` redi at gcc dot gnu.org
2024-01-17 21:19 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2024-01-17 21:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86843
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
It's a shame they're using "debug mode" to mean "debug the library impl itself"
when that's a term we have been using with completely different meaning for
many years.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug libstdc++/86843] Allow separating debug mode into ABI-changing part and rest
[not found] <bug-86843-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2024-01-17 21:19 ` redi at gcc dot gnu.org
@ 2024-01-17 21:19 ` redi at gcc dot gnu.org
2024-07-12 15:56 ` cvs-commit at gcc dot gnu.org
2024-07-19 13:54 ` cvs-commit at gcc dot gnu.org
5 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2024-01-17 21:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86843
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Oh I think I misread it ... it does enable some internal assertions, but is
mostly the same meaning as our debug mode.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug libstdc++/86843] Allow separating debug mode into ABI-changing part and rest
[not found] <bug-86843-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2024-01-17 21:19 ` redi at gcc dot gnu.org
@ 2024-07-12 15:56 ` cvs-commit at gcc dot gnu.org
2024-07-19 13:54 ` cvs-commit at gcc dot gnu.org
5 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-07-12 15:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86843
--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:
https://gcc.gnu.org/g:08776bef53835ff6318ecfeade8f6c6896ffd81f
commit r15-2009-g08776bef53835ff6318ecfeade8f6c6896ffd81f
Author: Daniel Bertalan <dani@danielbertalan.dev>
Date: Tue Jul 9 23:34:46 2024 +0200
Fix Xcode 16 build break with NULL != nullptr
As of Xcode 16 beta 2 with the macOS 15 SDK, each re-inclusion of the
stddef.h header causes the NULL macro in C++ to be re-defined to an
integral constant (__null). This makes the workaround in d59a576b8
("Redefine NULL to nullptr") ineffective, as other headers that are
typically included after system.h (such as obstack.h) do include
stddef.h too.
This can be seen by running the sample below through `clang++ -E`
#include <stddef.h>
#define NULL nullptr
#include <stddef.h>
NULL
The relevant libc++ change is here:
https://github.com/llvm/llvm-project/commit/2950283dddab03c183c1be2d7de9d4999cc86131
Filed as FB14261859 to Apple and added a comment about it on LLVM PR
86843.
This fixes the cases in --enable-languages=c,c++,objc,obj-c++,rust build
where NULL being an integral constant instead of a null pointer literal
(therefore no longer implicitly converting to a pointer when used as a
template function's argument) caused issues.
gcc/value-pointer-equiv.cc:65:43: error: no viable conversion from
`pair<typename __unwrap_ref_decay<long>::type, typename
__unwrap_ref_decay<long>::type>' to 'const pair<tree, tree>'
65 | const std::pair <tree, tree> m_marker = std::make_pair (NULL,
NULL);
|
^~~~~~~~~~~~~~~~~~~~~~~~~~~
As noted in the previous commit though, the proper solution would be to
phase out the usages of NULL in GCC's C++ source code.
gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (saved_diagnostic::saved_diagnostic):
Change NULL to nullptr.
(struct null_assignment_sm_context): Likewise.
* infinite-loop.cc: Likewise.
* infinite-recursion.cc: Likewise.
* varargs.cc (va_list_state_machine::on_leak): Likewise.
gcc/rust/ChangeLog:
* metadata/rust-imports.cc (Import::try_package_in_directory):
Change NULL to nullptr.
gcc/ChangeLog:
* value-pointer-equiv.cc: Change NULL to nullptr.
Signed-off-by: Daniel Bertalan <dani@danielbertalan.dev>
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug libstdc++/86843] Allow separating debug mode into ABI-changing part and rest
[not found] <bug-86843-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2024-07-12 15:56 ` cvs-commit at gcc dot gnu.org
@ 2024-07-19 13:54 ` cvs-commit at gcc dot gnu.org
5 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-07-19 13:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86843
--- Comment #8 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-14 branch has been updated by Iain D Sandoe
<iains@gcc.gnu.org>:
https://gcc.gnu.org/g:187eec8a2f7ae79e0a087988a5323eccdb312775
commit r14-10474-g187eec8a2f7ae79e0a087988a5323eccdb312775
Author: Daniel Bertalan <dani@danielbertalan.dev>
Date: Tue Jul 9 23:34:46 2024 +0200
Fix Xcode 16 build break with NULL != nullptr
As of Xcode 16 beta 2 with the macOS 15 SDK, each re-inclusion of the
stddef.h header causes the NULL macro in C++ to be re-defined to an
integral constant (__null). This makes the workaround in d59a576b8
("Redefine NULL to nullptr") ineffective, as other headers that are
typically included after system.h (such as obstack.h) do include
stddef.h too.
This can be seen by running the sample below through `clang++ -E`
#include <stddef.h>
#define NULL nullptr
#include <stddef.h>
NULL
The relevant libc++ change is here:
https://github.com/llvm/llvm-project/commit/2950283dddab03c183c1be2d7de9d4999cc86131
Filed as FB14261859 to Apple and added a comment about it on LLVM PR
86843.
This fixes the cases in --enable-languages=c,c++,objc,obj-c++,rust build
where NULL being an integral constant instead of a null pointer literal
(therefore no longer implicitly converting to a pointer when used as a
template function's argument) caused issues.
gcc/value-pointer-equiv.cc:65:43: error: no viable conversion from
`pair<typename __unwrap_ref_decay<long>::type, typename
__unwrap_ref_decay<long>::type>' to 'const pair<tree, tree>'
65 | const std::pair <tree, tree> m_marker = std::make_pair (NULL,
NULL);
|
^~~~~~~~~~~~~~~~~~~~~~~~~~~
As noted in the previous commit though, the proper solution would be to
phase out the usages of NULL in GCC's C++ source code.
gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (saved_diagnostic::saved_diagnostic):
Change NULL to nullptr.
(struct null_assignment_sm_context): Likewise.
* infinite-loop.cc: Likewise.
* infinite-recursion.cc: Likewise.
* varargs.cc (va_list_state_machine::on_leak): Likewise.
gcc/rust/ChangeLog:
* metadata/rust-imports.cc (Import::try_package_in_directory):
Change NULL to nullptr.
gcc/ChangeLog:
* value-pointer-equiv.cc: Change NULL to nullptr.
Signed-off-by: Daniel Bertalan <dani@danielbertalan.dev>
(cherry picked from commit 08776bef53835ff6318ecfeade8f6c6896ffd81f)
^ permalink raw reply [flat|nested] 6+ messages in thread