| Message ID | 20240710065938.35838-1-dani@danielbertalan.dev |
|---|---|
| State | New |
| Headers | show |
| Series | Fix Xcode 16 build break with NULL != nullptr | expand |
On Wed, 2024-07-10 at 06:59 +0000, dani@danielbertalan.dev wrote: > diff --git a/gcc/value-pointer-equiv.cc b/gcc/value-pointer-equiv.cc > index bfc940ec9915..f8564536c308 100644 > --- a/gcc/value-pointer-equiv.cc > +++ b/gcc/value-pointer-equiv.cc > @@ -62,7 +62,7 @@ public: > private: > auto_vec<std::pair <tree, tree>> m_stack; > auto_vec<tree> m_replacements; > - const std::pair <tree, tree> m_marker = std::make_pair (NULL, NULL); > + const std::pair<tree, tree> m_marker = std::make_pair(nullptr, nullptr); > }; AFAIK we prefer NULL_TREE for this.
On Wed, Jul 10, 2024 at 9:00 AM <dani@danielbertalan.dev> wrote: > > From: Daniel Bertalan <dani@danielbertalan.dev> > > 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. Hmm, that's arguably a bug. I think for submodules we do not control like libiberty we have to go the C++ standard library include way and amend the INCLUDE_* macros in system.h or include those unconditionally. I also see that libcpp line-map.h includes <utility> though that's unconditionally included via system.h as well. I also wonder as macOS 15 SDK is still in beta if it's possible to fix its stddef.h behavior? > 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 > > This commit fixes the instances where NULL being an integral constant > instead of a null pointer literal (such as no longer implicitly > converting to a pointer when used as a template function's argument). > > 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/ChangeLog: > > * value-pointer-equiv.cc: Change NULL to nullptr. > --- > gcc/analyzer/diagnostic-manager.cc | 18 +++++++++--------- > gcc/analyzer/infinite-loop.cc | 2 +- > gcc/analyzer/infinite-recursion.cc | 2 +- > gcc/analyzer/varargs.cc | 2 +- > gcc/value-pointer-equiv.cc | 2 +- > 5 files changed, 13 insertions(+), 13 deletions(-) > > diff --git a/gcc/analyzer/diagnostic-manager.cc b/gcc/analyzer/diagnostic-manager.cc > index fe943ac61c9e..51304b0795b6 100644 > --- a/gcc/analyzer/diagnostic-manager.cc > +++ b/gcc/analyzer/diagnostic-manager.cc > @@ -679,12 +679,12 @@ saved_diagnostic::saved_diagnostic (const state_machine *sm, > m_stmt (ploc.m_stmt), > /* stmt_finder could be on-stack; we want our own copy that can > outlive that. */ > - m_stmt_finder (ploc.m_finder ? ploc.m_finder->clone () : NULL), > + m_stmt_finder (ploc.m_finder ? ploc.m_finder->clone () : nullptr), > m_loc (ploc.m_loc), > m_var (var), m_sval (sval), m_state (state), > - m_d (std::move (d)), m_trailing_eedge (NULL), > + m_d (std::move (d)), m_trailing_eedge (nullptr), > m_idx (idx), > - m_best_epath (NULL), m_problem (NULL), > + m_best_epath (nullptr), m_problem (nullptr), > m_notes () > { > /* We must have an enode in order to be able to look for paths > @@ -1800,10 +1800,10 @@ public: > stmt, > stack_depth, > sm, > - NULL, > + nullptr, > src_sm_val, > dst_sm_val, > - NULL, > + nullptr, > dst_state, > src_node)); > return false; > @@ -1993,9 +1993,9 @@ struct null_assignment_sm_context : public sm_context > m_sm, > var_new_sval, > from, to, > - NULL, > + nullptr, > *m_new_state, > - NULL)); > + nullptr)); > } > > void set_next_state (const gimple *stmt, > @@ -2019,9 +2019,9 @@ struct null_assignment_sm_context : public sm_context > m_sm, > sval, > from, to, > - NULL, > + nullptr, > *m_new_state, > - NULL)); > + nullptr)); > } > > void warn (const supernode *, const gimple *, > diff --git a/gcc/analyzer/infinite-loop.cc b/gcc/analyzer/infinite-loop.cc > index 8ba8e70acffc..6ac0a5b373d8 100644 > --- a/gcc/analyzer/infinite-loop.cc > +++ b/gcc/analyzer/infinite-loop.cc > @@ -240,7 +240,7 @@ public: > enode->get_function ()->decl, > enode->get_stack_depth ()), > enode, > - NULL, NULL, NULL)); > + nullptr, nullptr, nullptr)); > > logger *logger = emission_path->get_logger (); > > diff --git a/gcc/analyzer/infinite-recursion.cc b/gcc/analyzer/infinite-recursion.cc > index ef8ae90ab08e..885f9a8a9417 100644 > --- a/gcc/analyzer/infinite-recursion.cc > +++ b/gcc/analyzer/infinite-recursion.cc > @@ -196,7 +196,7 @@ public: > m_callee_fndecl, > m_new_entry_enode->get_stack_depth ()), > enode, > - NULL, NULL, NULL)); > + nullptr, nullptr, nullptr)); > } > > /* Reject paths in which conjured svalues have affected control flow > diff --git a/gcc/analyzer/varargs.cc b/gcc/analyzer/varargs.cc > index c197883673d6..734323e6f789 100644 > --- a/gcc/analyzer/varargs.cc > +++ b/gcc/analyzer/varargs.cc > @@ -631,7 +631,7 @@ va_list_state_machine::on_va_end (sm_context &sm_ctxt, > std::unique_ptr<pending_diagnostic> > va_list_state_machine::on_leak (tree var) const > { > - return make_unique<va_list_leak> (*this, NULL, var); > + return make_unique<va_list_leak> (*this, nullptr, var); > } > > } // anonymous namespace > diff --git a/gcc/value-pointer-equiv.cc b/gcc/value-pointer-equiv.cc > index bfc940ec9915..f8564536c308 100644 > --- a/gcc/value-pointer-equiv.cc > +++ b/gcc/value-pointer-equiv.cc > @@ -62,7 +62,7 @@ public: > private: > auto_vec<std::pair <tree, tree>> m_stack; > auto_vec<tree> m_replacements; > - const std::pair <tree, tree> m_marker = std::make_pair (NULL, NULL); > + const std::pair<tree, tree> m_marker = std::make_pair(nullptr, nullptr); > }; > > ssa_equiv_stack::ssa_equiv_stack () > -- > 2.45.2 > >
diff --git a/gcc/analyzer/diagnostic-manager.cc b/gcc/analyzer/diagnostic-manager.cc index fe943ac61c9e..51304b0795b6 100644 --- a/gcc/analyzer/diagnostic-manager.cc +++ b/gcc/analyzer/diagnostic-manager.cc @@ -679,12 +679,12 @@ saved_diagnostic::saved_diagnostic (const state_machine *sm, m_stmt (ploc.m_stmt), /* stmt_finder could be on-stack; we want our own copy that can outlive that. */ - m_stmt_finder (ploc.m_finder ? ploc.m_finder->clone () : NULL), + m_stmt_finder (ploc.m_finder ? ploc.m_finder->clone () : nullptr), m_loc (ploc.m_loc), m_var (var), m_sval (sval), m_state (state), - m_d (std::move (d)), m_trailing_eedge (NULL), + m_d (std::move (d)), m_trailing_eedge (nullptr), m_idx (idx), - m_best_epath (NULL), m_problem (NULL), + m_best_epath (nullptr), m_problem (nullptr), m_notes () { /* We must have an enode in order to be able to look for paths @@ -1800,10 +1800,10 @@ public: stmt, stack_depth, sm, - NULL, + nullptr, src_sm_val, dst_sm_val, - NULL, + nullptr, dst_state, src_node)); return false; @@ -1993,9 +1993,9 @@ struct null_assignment_sm_context : public sm_context m_sm, var_new_sval, from, to, - NULL, + nullptr, *m_new_state, - NULL)); + nullptr)); } void set_next_state (const gimple *stmt, @@ -2019,9 +2019,9 @@ struct null_assignment_sm_context : public sm_context m_sm, sval, from, to, - NULL, + nullptr, *m_new_state, - NULL)); + nullptr)); } void warn (const supernode *, const gimple *, diff --git a/gcc/analyzer/infinite-loop.cc b/gcc/analyzer/infinite-loop.cc index 8ba8e70acffc..6ac0a5b373d8 100644 --- a/gcc/analyzer/infinite-loop.cc +++ b/gcc/analyzer/infinite-loop.cc @@ -240,7 +240,7 @@ public: enode->get_function ()->decl, enode->get_stack_depth ()), enode, - NULL, NULL, NULL)); + nullptr, nullptr, nullptr)); logger *logger = emission_path->get_logger (); diff --git a/gcc/analyzer/infinite-recursion.cc b/gcc/analyzer/infinite-recursion.cc index ef8ae90ab08e..885f9a8a9417 100644 --- a/gcc/analyzer/infinite-recursion.cc +++ b/gcc/analyzer/infinite-recursion.cc @@ -196,7 +196,7 @@ public: m_callee_fndecl, m_new_entry_enode->get_stack_depth ()), enode, - NULL, NULL, NULL)); + nullptr, nullptr, nullptr)); } /* Reject paths in which conjured svalues have affected control flow diff --git a/gcc/analyzer/varargs.cc b/gcc/analyzer/varargs.cc index c197883673d6..734323e6f789 100644 --- a/gcc/analyzer/varargs.cc +++ b/gcc/analyzer/varargs.cc @@ -631,7 +631,7 @@ va_list_state_machine::on_va_end (sm_context &sm_ctxt, std::unique_ptr<pending_diagnostic> va_list_state_machine::on_leak (tree var) const { - return make_unique<va_list_leak> (*this, NULL, var); + return make_unique<va_list_leak> (*this, nullptr, var); } } // anonymous namespace diff --git a/gcc/value-pointer-equiv.cc b/gcc/value-pointer-equiv.cc index bfc940ec9915..f8564536c308 100644 --- a/gcc/value-pointer-equiv.cc +++ b/gcc/value-pointer-equiv.cc @@ -62,7 +62,7 @@ public: private: auto_vec<std::pair <tree, tree>> m_stack; auto_vec<tree> m_replacements; - const std::pair <tree, tree> m_marker = std::make_pair (NULL, NULL); + const std::pair<tree, tree> m_marker = std::make_pair(nullptr, nullptr); }; ssa_equiv_stack::ssa_equiv_stack ()
From: Daniel Bertalan <dani@danielbertalan.dev> 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 This commit fixes the instances where NULL being an integral constant instead of a null pointer literal (such as no longer implicitly converting to a pointer when used as a template function's argument). 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/ChangeLog: * value-pointer-equiv.cc: Change NULL to nullptr. --- gcc/analyzer/diagnostic-manager.cc | 18 +++++++++--------- gcc/analyzer/infinite-loop.cc | 2 +- gcc/analyzer/infinite-recursion.cc | 2 +- gcc/analyzer/varargs.cc | 2 +- gcc/value-pointer-equiv.cc | 2 +- 5 files changed, 13 insertions(+), 13 deletions(-)