Re: [PATCH] Add type-generic clz/ctz/clrsb/ffs/parity/popcount builtins [PR111309]
On Fri, Dec 15, 2023 at 09:51:10PM -0800, Andrew Pinski wrote:
> I was looking into improving __builtin_popcountg for __int128 on
> aarch64 (when CSSC is not implemented which right now is almost all
> cores) but this patch forces __builtin_popcountg to expand into 2
> __builtin_popcountll (and add) before it could optimize into an
> internal function for the popcount and have the backend a possibility
> of using implementing something better.
> This is due to the code in fold_builtin_bit_query, what might be the
> best way of disabling that for this case?
>
> Basically right now popcount is implemented using the SIMD instruction
> cnt which can be used either 8x1 or 16x1 wide. Using the 16x1 improves
> both the code size and performance (on almost all cores I know of). So
> instead of 2 cnt instructions, we only would need one.
The reason for lowering those 2 * wordsize cases early is that there
is no __builtin_{clz,ctz,clrsb,ffs,parity,popcount}* for those cases (so we
can't expect expansion to say libgcc routines as fallback) and
IFN_{CLZ,CTZ,CLRSB,FFS,PARITY,POPCOUNT} are still direct optab ifns
(now with the extension that large/huge _BitInt is ok for those as operands
because we are guaranteed to lower that during bitint lowering).
Anything else won't make it through the direct optab checks and won't be
guaranteed to expand.
You can always define optabs for those and handle them in md files if it
results in better code.
Jakub
Re: [committed] libstdc++: Implement C++23 header [PR107760]
On Fri, 15 Dec 2023 at 14:49, Tim Song wrote:
>
>
>
> On Fri, Dec 15, 2023 at 4:43 AM Jonathan Wakely wrote:
>>
>> On Fri, 15 Dec 2023 at 01:17, Tim Song wrote:
>> >
>> > On Thu, Dec 14, 2023 at 6:05 PM Jonathan Wakely wrote:
>> >> + inline void
>> >> + vprint_unicode(ostream& __os, string_view __fmt, format_args __args)
>> >> + {
>> >> +ostream::sentry __cerb(__os);
>> >> +if (__cerb)
>> >> + {
>> >> +
>> >> + const streamsize __w = __os.width();
>> >> + const bool __left
>> >> + = (__os.flags() & ios_base::adjustfield) == ios_base::left;
>> >
>> >
>> > I'm pretty sure - when I wrote this wording anyway - that the intent was
>> > that it was just an unformatted write at the end. The wording in
>> > [ostream.formatted.print] doesn't use the "determines padding" words of
>> > power that would invoke [ostream.formatted.reqmts]/3.
>>
>> Ah, OK. I misunderstood "formatted output function" as implying
>> padding, failing to notice that we need those words of power to be
>> present. My thinking was that if the stream has padding set in its
>> format flags, it could be surprising if they're ignored by a formatted
>> output function. And padding in the format string applies to
>> individual replacement fields, not the whole string, and it's hard to
>> use the stream's fill character and alignment.
>
>
> But we would get none of the Unicode-aware padding logic we
> do in format, which puts it in a very weird place.
>
> And for cases where Unicode is not a problem, it's easy to get padding
> with just os << std::format(...);
Yes, good point.
>>
>> You can do this to use the ostream's width:
>>
>> std::print("{0:{1}}", std::format(...), os.width());
>>
>> But to reuse its fill char and adjustfield you need to do something
>> awful like I did in the committed code:
>>
>> std::string_view align;
>> if (os.flags() & ios::adjustfield) == ios::right)
>> align = ">"
>> auto fs = std::format("{{:{}{}{}}}", os.fill(), align, os.width());
>> std::vprint_nonunicode(os, fs, std::make_args(std::format(...)));
>>
>>
>> And now you have to hardcode a choice between vprint_unicode and
>> vprint_nonunicode, instead of letting std::print decide it. Let's hope
>> nobody ever needs to do any of that ;-)
>
>
> At least the upcoming runtime_format alleviates that :)
Right, that's on my list to implement "soon"!
>>
>>
>> I'll remove the code for padding the padding, thanks for checking the patch.
>>
Re: [PATCH] libstdc++: Make __gnu_debug::vector usable in constant expressions [PR109536]
On Sat, 16 Dec 2023 at 00:27, Patrick Palka wrote:
>
> On Wed, 6 Dec 2023, Jonathan Wakely wrote:
>
> > Any comments on this approach?
> >
> > -- >8 --
> >
> > This makes constexpr std::vector (mostly) work in Debug Mode. All safe
> > iterator instrumentation and checking is disabled during constant
> > evaluation, because it requires mutex locks and calls to non-inline
> > functions defined in libstdc++.so. It should be OK to disable the safety
> > checks, because most UB should be detected during constant evaluation
> > anyway.
> >
> > We could try to enable the full checking in constexpr, but it would mean
> > wrapping all the non-inline functions like _M_attach with an inline
> > _M_constexpr_attach that does the iterator housekeeping inline without
> > mutex locks when calling for constant evaluation, and calls the
> > non-inline function at runtime. That could be done in future if we find
> > that we've lost safety or useful checking by disabling the safe
> > iterators.
> >
> > There are a few test failures in C++20 mode, which I'm unable to
> > explain. The _Safe_iterator::operator++() member gives errors for using
> > non-constexpr functions during constant evaluation, even though those
> > functions are guarded by std::is_constant_evaluated() checks. The same
> > code works fine for C++23 and up.
>
> AFAICT these C++20 test failures are really due to the variable
> definition of non-literal type
>
> 381__gnu_cxx::__scoped_lock __l(this->_M_get_mutex());
>
> which were prohibited in a constexpr function (even if that code was
> never executed) until C++23's P2242R3.
Ah, I figured it was a core change but I couldn't recall which one. Thanks.
> We can use an immediately invoked lambda to work around this:
>
> 381[this] {
> 382 __gnu_cxx::__scoped_lock __l(this->_M_get_mutex());
> 383 ++base();
> 384}();
> 385return *this;
We'd need some #if as this code has to work for C++98. But that's doable.
> >
> > libstdc++-v3/ChangeLog:
> >
> > PR libstdc++/109536
> > * include/bits/c++config (__glibcxx_constexpr_assert): Remove
> > macro.
> > * include/bits/stl_algobase.h (__niter_base, __copy_move_a)
> > (__copy_move_backward_a, __fill_a, __fill_n_a, __equal_aux)
> > (__lexicographical_compare_aux): Add constexpr to overloads for
> > debug mode iterators.
> > * include/debug/helper_functions.h (__unsafe): Add constexpr.
> > * include/debug/macros.h (_GLIBCXX_DEBUG_VERIFY_COND_AT): Remove
> > macro, folding it into ...
> > (_GLIBCXX_DEBUG_VERIFY_AT_F): ... here. Do not use
> > __glibcxx_constexpr_assert.
> > * include/debug/safe_base.h (_Safe_iterator_base): Add constexpr
> > to some member functions. Omit attaching, detaching and checking
> > operations during constant evaluation.
> > * include/debug/safe_container.h (_Safe_container): Likewise.
> > * include/debug/safe_iterator.h (_Safe_iterator): Likewise.
> > * include/debug/safe_iterator.tcc (__niter_base, __copy_move_a)
> > (__copy_move_backward_a, __fill_a, __fill_n_a, __equal_aux)
> > (__lexicographical_compare_aux): Add constexpr.
> > * include/debug/vector (_Safe_vector, vector): Add constexpr.
> > Omit safe iterator operations during constant evaluation.
> > * testsuite/23_containers/vector/bool/capacity/constexpr.cc:
> > Remove dg-xfail-if for debug mode.
> > * testsuite/23_containers/vector/bool/cmp_c++20.cc: Likewise.
> > * testsuite/23_containers/vector/bool/cons/constexpr.cc:
> > Likewise.
> > * testsuite/23_containers/vector/bool/element_access/1.cc:
> > Likewise.
> > * testsuite/23_containers/vector/bool/element_access/constexpr.cc:
> > Likewise.
> > * testsuite/23_containers/vector/bool/modifiers/assign/constexpr.cc:
> > Likewise.
> > * testsuite/23_containers/vector/bool/modifiers/constexpr.cc:
> > Likewise.
> > * testsuite/23_containers/vector/bool/modifiers/swap/constexpr.cc:
> > Likewise.
> > * testsuite/23_containers/vector/capacity/constexpr.cc:
> > Likewise.
> > * testsuite/23_containers/vector/cmp_c++20.cc: Likewise.
> > * testsuite/23_containers/vector/cons/constexpr.cc: Likewise.
> > * testsuite/23_containers/vector/data_access/constexpr.cc:
> > Likewise.
> > * testsuite/23_containers/vector/element_access/constexpr.cc:
> > Likewise.
> > * testsuite/23_containers/vector/modifiers/assign/constexpr.cc:
> > Likewise.
> > * testsuite/23_containers/vector/modifiers/constexpr.cc:
> > Likewise.
> > * testsuite/23_containers/vector/modifiers/swap/constexpr.cc:
> > Likewise.
> > ---
> > libstdc++-v3/include/bits/c++config | 9 -
> > libstdc++-v3/include/bits/stl_algobase.h | 15 ++
> > libstdc++-v3/include/debug/helper_functions.h | 1 +
> > libstdc++-v3/include/debug/macros.h |
Re: [PATCH] libstdc++: Make __gnu_debug::vector usable in constant expressions [PR109536]
On Sat, 16 Dec 2023 at 09:14, Jonathan Wakely wrote:
>
> On Sat, 16 Dec 2023 at 00:27, Patrick Palka wrote:
> >
> > On Wed, 6 Dec 2023, Jonathan Wakely wrote:
> >
> > > Any comments on this approach?
> > >
> > > -- >8 --
> > >
> > > This makes constexpr std::vector (mostly) work in Debug Mode. All safe
> > > iterator instrumentation and checking is disabled during constant
> > > evaluation, because it requires mutex locks and calls to non-inline
> > > functions defined in libstdc++.so. It should be OK to disable the safety
> > > checks, because most UB should be detected during constant evaluation
> > > anyway.
> > >
> > > We could try to enable the full checking in constexpr, but it would mean
> > > wrapping all the non-inline functions like _M_attach with an inline
> > > _M_constexpr_attach that does the iterator housekeeping inline without
> > > mutex locks when calling for constant evaluation, and calls the
> > > non-inline function at runtime. That could be done in future if we find
> > > that we've lost safety or useful checking by disabling the safe
> > > iterators.
> > >
> > > There are a few test failures in C++20 mode, which I'm unable to
> > > explain. The _Safe_iterator::operator++() member gives errors for using
> > > non-constexpr functions during constant evaluation, even though those
> > > functions are guarded by std::is_constant_evaluated() checks. The same
> > > code works fine for C++23 and up.
> >
> > AFAICT these C++20 test failures are really due to the variable
> > definition of non-literal type
> >
> > 381__gnu_cxx::__scoped_lock __l(this->_M_get_mutex());
> >
> > which were prohibited in a constexpr function (even if that code was
> > never executed) until C++23's P2242R3.
>
> Ah, I figured it was a core change but I couldn't recall which one. Thanks.
>
> > We can use an immediately invoked lambda to work around this:
> >
> > 381[this] {
> > 382 __gnu_cxx::__scoped_lock __l(this->_M_get_mutex());
> > 383 ++base();
> > 384}();
> > 385return *this;
>
> We'd need some #if as this code has to work for C++98. But that's doable.
The attached patch seems simpler, I'm testing it now.
commit 5d70c6c2965647077749a869e9cdbf7e91dba4c7
Author: Jonathan Wakely
Date: Sat Dec 16 09:31:40 2023
libstdc++: Fix errors for constexpr __gnu_debug::vector in C++23 [PR109536]
In the commit log for r14-6553-g7d00a59229ee17 I noted some tests FAIL
in C++20 mode. Patrick identified that they were due to the variable
definitions of non-literal type __scoped_lock, which were prohibited in
a constexpr function (even if that code was never executed) until
C++23's P2242R3.
We can move the problematic code into new non-constexpr functions that
are not called during constant evaluation.
There's also a warning about a constexpr _M_swap function which is never
defined. That's simply because I added the _GLIBCXX20_CONSTEXPR macro on
a member that doesn't need it.
libstdc++-v3/ChangeLog:
PR libstdc++/109536
* include/debug/safe_base.h (_Safe_sequence_base::_M_swap):
Remove _GLIBCXX20_CONSTEXPR from non-inline member function.
* include/debug/safe_iterator.h (_Safe_iterator::_M_move_assign)
diff --git a/libstdc++-v3/include/debug/safe_base.h
b/libstdc++-v3/include/debug/safe_base.h
index d9c17b52b48..1519ad809a4 100644
--- a/libstdc++-v3/include/debug/safe_base.h
+++ b/libstdc++-v3/include/debug/safe_base.h
@@ -268,7 +268,6 @@ namespace __gnu_debug
* operation is complete all iterators that originally referenced
* one container now reference the other container.
*/
-_GLIBCXX20_CONSTEXPR
void
_M_swap(_Safe_sequence_base& __x) _GLIBCXX_USE_NOEXCEPT;
diff --git a/libstdc++-v3/include/debug/safe_iterator.h
b/libstdc++-v3/include/debug/safe_iterator.h
index 26f008982f8..bde34e1f99c 100644
--- a/libstdc++-v3/include/debug/safe_iterator.h
+++ b/libstdc++-v3/include/debug/safe_iterator.h
@@ -295,7 +295,13 @@ namespace __gnu_debug
base() = __x.base();
return *this;
}
+ _M_move_assign(std::move(__x));
+ return *this;
+ }
+ void
+ _M_move_assign(_Safe_iterator&& __x) noexcept
+ {
_GLIBCXX_DEBUG_VERIFY(!__x._M_singular()
|| __x._M_value_initialized(),
_M_message(__msg_copy_singular)
@@ -303,7 +309,7 @@ namespace __gnu_debug
._M_iterator(__x, "other"));
if (std::__addressof(__x) == this)
- return *this;
+ return;
if (this->_M_sequence && this->_M_sequence == __x._M_sequence)
{
@@ -320,7 +326,6 @@ namespace __gnu_debug
__x._M_detach();
__x.base() = _Iterator();
- return *this;
}
#endif
@@ -370,17 +375,20 @@ namespace __gnu_debug
operator++() _GLIBCXX_NOEXCEPT
{
if (std::__is_constant
Re: [PATCH] c++/modules: seed namespaces for bindings [PR106363]
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636159.html
On Sun, Nov 12, 2023 at 12:59:36PM +1100, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu. I don't have write
> access.
>
> -- >8 --
>
> Currently the first depset for an EK_BINDING is not seeded. This breaks
> the attached testcase as then the namespace is not considered referenced
> yet during streaming, but we've already finished importing.
>
> There doesn't seem to be any particular reason I could find for skipping
> the first depset for bindings, and removing the condition doesn't appear
> to cause any test failures, so this patch removes that check.
>
> PR c++/106363
>
> gcc/cp/ChangeLog:
>
> * module.cc (module_state::write_cluster): Don't skip first
> depset for bindings.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/modules/pr106363_a.C: New test.
> * g++.dg/modules/pr106363_b.C: New test.
>
> Signed-off-by: Nathaniel Shead
> ---
> gcc/cp/module.cc | 4 +---
> gcc/testsuite/g++.dg/modules/pr106363_a.C | 9 +
> gcc/testsuite/g++.dg/modules/pr106363_b.C | 10 ++
> 3 files changed, 20 insertions(+), 3 deletions(-)
> create mode 100644 gcc/testsuite/g++.dg/modules/pr106363_a.C
> create mode 100644 gcc/testsuite/g++.dg/modules/pr106363_b.C
>
> diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> index c1c8c226bc1..411a3b9411c 100644
> --- a/gcc/cp/module.cc
> +++ b/gcc/cp/module.cc
> @@ -14741,9 +14741,7 @@ module_state::write_cluster (elf_out *to, depset
> *scc[], unsigned size,
>for (unsigned ix = 0; ix != size; ix++)
> {
>depset *b = scc[ix];
> - for (unsigned jx = (b->get_entity_kind () == depset::EK_BINDING
> - || b->is_special ()) ? 1 : 0;
> -jx != b->deps.length (); jx++)
> + for (unsigned jx = b->is_special (); jx != b->deps.length (); jx++)
> {
> depset *dep = b->deps[jx];
>
> diff --git a/gcc/testsuite/g++.dg/modules/pr106363_a.C
> b/gcc/testsuite/g++.dg/modules/pr106363_a.C
> new file mode 100644
> index 000..c18d2eef1c8
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/modules/pr106363_a.C
> @@ -0,0 +1,9 @@
> +// PR c++/106363
> +// { dg-additional-options "-fmodules-ts" }
> +// { dg-module-cmi pr106363.a }
> +
> +export module pr106363.a;
> +
> +namespace ns {
> + export int x;
> +}
> diff --git a/gcc/testsuite/g++.dg/modules/pr106363_b.C
> b/gcc/testsuite/g++.dg/modules/pr106363_b.C
> new file mode 100644
> index 000..0508c0d6193
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/modules/pr106363_b.C
> @@ -0,0 +1,10 @@
> +// PR c++/106363
> +// { dg-additional-options "-fmodules-ts" }
> +// { dg-module-cmi pr106363.b }
> +
> +export module pr106363.b;
> +import pr106363.a;
> +
> +namespace ns {
> + export using ns::x;
> +}
> --
> 2.42.0
>
[PATCH] c++/modules: Prevent overwriting arguments when merging duplicates [PR112588]
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637768.html.
(I've changed the summary message a little from that email but the patch
is otherwise unchanged.)
On Wed, Nov 22, 2023 at 10:33:15PM +1100, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu. I don't have write
> access.
>
> -- >8 --
>
> When merging duplicate instantiations of function templates, currently
> read_function_def overwrites the arguments with that of the existing
> duplicate. This is problematic, however, since this means that the
> PARM_DECLs in the body of the function definition no longer match with
> the PARM_DECLs in the argument list, which causes issues when it comes
> to generating RTL.
>
> There doesn't seem to be any reason to do this replacement, so this
> patch removes that logic.
>
> PR c++/112588
>
> gcc/cp/ChangeLog:
>
> * module.cc (trees_in::read_function_def): Don't overwrite
> arguments.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/modules/merge-16.h: New test.
> * g++.dg/modules/merge-16_a.C: New test.
> * g++.dg/modules/merge-16_b.C: New test.
>
> Signed-off-by: Nathaniel Shead
> ---
> gcc/cp/module.cc | 2 --
> gcc/testsuite/g++.dg/modules/merge-16.h | 10 ++
> gcc/testsuite/g++.dg/modules/merge-16_a.C | 7 +++
> gcc/testsuite/g++.dg/modules/merge-16_b.C | 5 +
> 4 files changed, 22 insertions(+), 2 deletions(-)
> create mode 100644 gcc/testsuite/g++.dg/modules/merge-16.h
> create mode 100644 gcc/testsuite/g++.dg/modules/merge-16_a.C
> create mode 100644 gcc/testsuite/g++.dg/modules/merge-16_b.C
>
> diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> index 4f5b6e2747a..2520ab659cc 100644
> --- a/gcc/cp/module.cc
> +++ b/gcc/cp/module.cc
> @@ -11665,8 +11665,6 @@ trees_in::read_function_def (tree decl, tree
> maybe_template)
>DECL_RESULT (decl) = result;
>DECL_INITIAL (decl) = initial;
>DECL_SAVED_TREE (decl) = saved;
> - if (maybe_dup)
> - DECL_ARGUMENTS (decl) = DECL_ARGUMENTS (maybe_dup);
>
>if (context)
> SET_DECL_FRIEND_CONTEXT (decl, context);
> diff --git a/gcc/testsuite/g++.dg/modules/merge-16.h
> b/gcc/testsuite/g++.dg/modules/merge-16.h
> new file mode 100644
> index 000..fdb38551103
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/modules/merge-16.h
> @@ -0,0 +1,10 @@
> +// PR c++/112588
> +
> +void f(int*);
> +
> +template
> +struct S {
> + void g(int n) { f(&n); }
> +};
> +
> +template struct S;
> diff --git a/gcc/testsuite/g++.dg/modules/merge-16_a.C
> b/gcc/testsuite/g++.dg/modules/merge-16_a.C
> new file mode 100644
> index 000..c243224c875
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/modules/merge-16_a.C
> @@ -0,0 +1,7 @@
> +// PR c++/112588
> +// { dg-additional-options "-fmodules-ts" }
> +// { dg-module-cmi merge16 }
> +
> +module;
> +#include "merge-16.h"
> +export module merge16;
> diff --git a/gcc/testsuite/g++.dg/modules/merge-16_b.C
> b/gcc/testsuite/g++.dg/modules/merge-16_b.C
> new file mode 100644
> index 000..8c7b1f0511f
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/modules/merge-16_b.C
> @@ -0,0 +1,5 @@
> +// PR c++/112588
> +// { dg-additional-options "-fmodules-ts" }
> +
> +#include "merge-16.h"
> +import merge16;
> --
> 2.42.0
>
[PATCH v2] c++: Follow module grammar more closely [PR110808]
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638089.html
On Fri, Nov 24, 2023 at 10:32:13PM +1100, Nathaniel Shead wrote:
> On Thu, Nov 23, 2023 at 12:11:58PM -0500, Nathan Sidwell wrote:
> > On 11/14/23 01:24, Nathaniel Shead wrote:
> > > I'll also note that the comments above the parsing functions here no
> > > longer exactly match with the grammar in the standard, should they be
> > > updated as well?
> >
> > please.
> >
>
> As I was attempting to rewrite the comments I ended up splitting up the
> work that was being done by cp_parser_module_name a lot to better match
> the grammar, and also caught a few other segfaults that were occurring
> along the way.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> This patch cleans up the parsing of module-declarations and
> import-declarations to more closely follow the grammar defined by the
> standard.
>
> For instance, currently we allow declarations like 'import A:B', even
> from an unrelated source file (not part of module A), which causes
> errors in merging declarations. However, the syntax in [module.import]
> doesn't even allow this form of import, so this patch prevents this from
> parsing at all and avoids the error that way.
>
> Additionally, we sometimes allow statements like 'import :X' or
> 'module :X' even when not in a named module, and this causes segfaults,
> so we disallow this too.
>
> PR c++/110808
>
> gcc/cp/ChangeLog:
>
> * parser.cc (cp_parser_module_name): Rewrite to handle
> module-names and module-partitions independently.
> (cp_parser_module_partition): New function.
> (cp_parser_module_declaration): Parse module partitions
> explicitly. Don't change state if parsing module decl failed.
> (cp_parser_import_declaration): Handle different kinds of
> import-declarations locally.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/modules/part-hdr-1_c.C: Fix syntax.
> * g++.dg/modules/part-mac-1_c.C: Likewise.
> * g++.dg/modules/mod-invalid-1.C: New test.
> * g++.dg/modules/part-8_a.C: New test.
> * g++.dg/modules/part-8_b.C: New test.
> * g++.dg/modules/part-8_c.C: New test.
>
> Signed-off-by: Nathaniel Shead
> ---
> gcc/cp/parser.cc | 100 ---
> gcc/testsuite/g++.dg/modules/mod-invalid-1.C | 7 ++
> gcc/testsuite/g++.dg/modules/part-8_a.C | 6 ++
> gcc/testsuite/g++.dg/modules/part-8_b.C | 6 ++
> gcc/testsuite/g++.dg/modules/part-8_c.C | 8 ++
> gcc/testsuite/g++.dg/modules/part-hdr-1_c.C | 2 +-
> gcc/testsuite/g++.dg/modules/part-mac-1_c.C | 2 +-
> 7 files changed, 95 insertions(+), 36 deletions(-)
> create mode 100644 gcc/testsuite/g++.dg/modules/mod-invalid-1.C
> create mode 100644 gcc/testsuite/g++.dg/modules/part-8_a.C
> create mode 100644 gcc/testsuite/g++.dg/modules/part-8_b.C
> create mode 100644 gcc/testsuite/g++.dg/modules/part-8_c.C
>
> diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
> index f6d088bc73f..20bd8d45a08 100644
> --- a/gcc/cp/parser.cc
> +++ b/gcc/cp/parser.cc
> @@ -14853,58 +14853,64 @@ cp_parser_already_scoped_statement (cp_parser*
> parser, bool *if_p,
>
> /* Modules */
>
> -/* Parse a module-name,
> - identifier
> - module-name . identifier
> - header-name
> +/* Parse a module-name or module-partition.
>
> - Returns a pointer to module object, NULL. */
> + module-name:
> + module-name-qualifier [opt] identifier
>
> -static module_state *
> -cp_parser_module_name (cp_parser *parser)
> -{
> - cp_token *token = cp_lexer_peek_token (parser->lexer);
> - if (token->type == CPP_HEADER_NAME)
> -{
> - cp_lexer_consume_token (parser->lexer);
> + module-partition:
> + : module-name-qualifier [opt] identifier
>
> - return get_module (token->u.value);
> -}
> + module-name-qualifier:
> + identifier .
> + module-name-qualifier identifier .
>
> - module_state *parent = NULL;
> - bool partitioned = false;
> - if (token->type == CPP_COLON && named_module_p ())
> -{
> - partitioned = true;
> - cp_lexer_consume_token (parser->lexer);
> -}
> + Returns a pointer to the module object, or NULL on failure.
> + For PARTITION_P, PARENT is the module this is a partition of. */
> +
> +static module_state *
> +cp_parser_module_name (cp_parser *parser, bool partition_p = false,
> +module_state *parent = NULL)
> +{
> + if (partition_p
> + && cp_lexer_consume_token (parser->lexer)->type != CPP_COLON)
> +return NULL;
>
>for (;;)
> {
>if (cp_lexer_peek_token (parser->lexer)->type != CPP_NAME)
> {
> - cp_parser_error (parser, "expected module-name");
> - break;
> + if (partition_p)
> + cp_parser_error (parser, "expected module-partition");
> + else
> + cp_parser_error (parser, "expected module-name");
> + return NULL;
> }
Re: [PATCH v7 5/5] OpenMP/OpenACC: Reorganise OMP map clause handling in gimplify.cc
On Fri, 18 Aug 2023 15:47:51 -0700
Julian Brown wrote:
> This patch has been separated out from the C++ "declare mapper"
> support patch. It contains just the gimplify.cc rearrangement
> work, mostly moving gimplification from gimplify_scan_omp_clauses
> to gimplify_adjust_omp_clauses for map clauses.
Here's a rebased version of this one. A few changes were needed due to
post-review fixes for earlier patches in the series.
Re-tested with offloading to NVPTX & bootstrapped.
Thanks,
Julian
commit 310ee8849722f131bc0a05becc99d3fb74b0748d
Author: Julian Brown
Date: Tue May 23 09:37:00 2023 +
OpenMP/OpenACC: Reorganise OMP map clause handling in gimplify.cc
This patch has been separated out from the C++ "declare mapper"
support patch. It contains just the gimplify.cc rearrangement
work, mostly moving gimplification from gimplify_scan_omp_clauses
to gimplify_adjust_omp_clauses for map clauses.
The motivation for doing this was that we don't know if we need to
instantiate mappers implicitly until the body of an offload region has
been scanned, i.e. in gimplify_adjust_omp_clauses, but we also need the
un-gimplified form of clauses to sort by base-pointer dependencies after
mapper instantiation has taken place.
The patch also reimplements the "present" clause sorting code to avoid
another sorting pass on mapping nodes.
This version of the patch is based on the version posted for og13, and
additionally incorporates a follow-on fix for DECL_VALUE_EXPR handling
in gimplify_adjust_omp_clauses:
"OpenMP/OpenACC: Reorganise OMP map clause handling in gimplify.cc"
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/63.html
Parts of:
"OpenMP: OpenMP 5.2 semantics for pointers with unmapped target"
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623351.html
2023-12-16 Julian Brown
gcc/
* gimplify.cc (omp_segregate_mapping_groups): Handle "present" groups.
(gimplify_scan_omp_clauses): Use mapping group functionality to
iterate through mapping nodes. Remove most gimplification of
OMP_CLAUSE_MAP nodes from here, but still populate ctx->variables
splay tree.
(gimplify_adjust_omp_clauses): Move most gimplification of
OMP_CLAUSE_MAP nodes here.
gcc/testsuite/
* gfortran.dg/gomp/map-12.f90: Adjust scan output.
libgomp/
* testsuite/libgomp.fortran/target-enter-data-6.f90: Remove XFAIL.
diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index a6bdceab45d..fa6ddd546f8 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -10077,10 +10077,15 @@ omp_tsort_mapping_groups (vec *groups,
return outlist;
}
-/* Split INLIST into two parts, moving groups corresponding to
- ALLOC/RELEASE/DELETE mappings to one list, and other mappings to another.
- The former list is then appended to the latter. Each sub-list retains the
- order of the original list.
+/* Split INLIST into four parts:
+
+ - "present" to/from groups
+ - "present" alloc groups
+ - other to/from groups
+ - other alloc/release/delete groups
+
+ These sub-lists are then concatenated together to form the final list.
+ Each sub-list retains the order of the original list.
Note that ATTACH nodes are later moved to the end of the list in
gimplify_adjust_omp_clauses, for target regions. */
@@ -10088,7 +10093,9 @@ static omp_mapping_group *
omp_segregate_mapping_groups (omp_mapping_group *inlist)
{
omp_mapping_group *ard_groups = NULL, *tf_groups = NULL;
+ omp_mapping_group *pa_groups = NULL, *ptf_groups = NULL;
omp_mapping_group **ard_tail = &ard_groups, **tf_tail = &tf_groups;
+ omp_mapping_group **pa_tail = &pa_groups, **ptf_tail = &ptf_groups;
for (omp_mapping_group *w = inlist; w;)
{
@@ -10107,6 +10114,20 @@ omp_segregate_mapping_groups (omp_mapping_group *inlist)
ard_tail = &w->next;
break;
+ case GOMP_MAP_PRESENT_ALLOC:
+ *pa_tail = w;
+ w->next = NULL;
+ pa_tail = &w->next;
+ break;
+
+ case GOMP_MAP_PRESENT_FROM:
+ case GOMP_MAP_PRESENT_TO:
+ case GOMP_MAP_PRESENT_TOFROM:
+ *ptf_tail = w;
+ w->next = NULL;
+ ptf_tail = &w->next;
+ break;
+
default:
*tf_tail = w;
w->next = NULL;
@@ -10118,8 +10139,10 @@ omp_segregate_mapping_groups (omp_mapping_group *inlist)
/* Now splice the lists together... */
*tf_tail = ard_groups;
+ *pa_tail = tf_groups;
+ *ptf_tail = pa_groups;
- return tf_groups;
+ return ptf_groups;
}
/* Given a list LIST_P containing groups of mappings given by GROUPS, reorder
@@ -11922,119 +11945,30 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq *pre_p,
break;
}
- if (code == OMP_TARGET
- || code == OMP_TARGET_DATA
- || code == OMP_TARGET_ENTER_DATA
- || code == OMP_TARGET_EXIT_DATA)
-{
- vec *groups;
- groups = omp_gather_mapping_
[pushed] analyzer: use bit-level granularity for concrete bounds-checking [PR112792]
PR analyzer/112792 reports false positives from -fanalyzer's
bounds-checking on certain packed structs containing bitfields e.g.
in the Linux kernel's drivers/dma/idxd/device.c:
union msix_perm {
struct {
u32 rsvd2 : 8;
u32 pasid : 20;
};
u32 bits;
} __attribute__((__packed__));
The root cause is that the bounds-checking is done using byte offsets
and ranges; in the above, an access of "pasid" is treated as a 32-bit
access starting one byte inside the union, thus accessing byte offsets
1-4 when only offsets 0-3 are valid.
This patch updates the bounds-checking to use bit offsets and ranges
wherever possible - for concrete offsets and capacities. In the above
accessing "pasid" is treated as bits 8-27 of a 32-bit region, fixing the
false positive.
Symbolic offsets and ranges are still handled at byte granularity.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r14-6622-g5f1bed2a7af828.
gcc/analyzer/ChangeLog:
PR analyzer/112792
* bounds-checking.cc
(out_of_bounds::oob_region_creation_event_capacity): Rename
"capacity" to "byte_capacity". Layout fix.
(out_of_boundsadd_region_creation_events): Rename
"capacity" to "byte_capacity".
(class concrete_out_of_bounds): Rename m_out_of_bounds_range to
m_out_of_bounds_bits and convert from a byte_range to a bit_range.
(concrete_out_of_bounds::get_out_of_bounds_bytes): New.
(concrete_past_the_end::concrete_past_the_end): Rename param
"byte_bound" to "bit_bound". Initialize m_byte_bound.
(concrete_past_the_end::subclass_equal_p): Update for renaming
of m_byte_bound to m_bit_bound.
(concrete_past_the_end::m_bit_bound): New field.
(concrete_buffer_overflow::concrete_buffer_overflow): Convert
param "range" from byte_range to bit_range. Rename param
"byte_bound" to "bit_bound".
(concrete_buffer_overflow::emit): Update for bits vs bytes.
(concrete_buffer_overflow::describe_final_event): Split
into...
(concrete_buffer_overflow::describe_final_event_as_bytes): ...this
(concrete_buffer_overflow::describe_final_event_as_bits): ...and
this.
(concrete_buffer_over_read::concrete_buffer_over_read): Convert
param "range" from byte_range to bit_range. Rename param
"byte_bound" to "bit_bound".
(concrete_buffer_over_read::emit): Update for bits vs bytes.
(concrete_buffer_over_read::describe_final_event): Split into...
(concrete_buffer_over_read::describe_final_event_as_bytes):
...this
(concrete_buffer_over_read::describe_final_event_as_bits): ...and
this.
(concrete_buffer_underwrite::concrete_buffer_underwrite): Convert
param "range" from byte_range to bit_range.
(concrete_buffer_underwrite::describe_final_event): Split into...
(concrete_buffer_underwrite::describe_final_event_as_bytes):
...this
(concrete_buffer_underwrite::describe_final_event_as_bits): ...and
this.
(concrete_buffer_under_read::concrete_buffer_under_read): Convert
param "range" from byte_range to bit_range.
(concrete_buffer_under_read::describe_final_event): Split into...
(concrete_buffer_under_read::describe_final_event_as_bytes):
...this
(concrete_buffer_under_read::describe_final_event_as_bits): ...and
this.
(region_model::check_region_bounds): Use bits for concrete values,
and rename locals to indicate whether we're dealing with bits or
bytes. Specifically, replace "num_bytes_sval" with
"num_bits_sval", and get it from reg's "get_bit_size_sval".
Replace "num_bytes_tree" with "num_bits_tree". Rename "capacity"
to "byte_capacity". Rename "cst_capacity_tree" to
"cst_byte_capacity_tree". Replace "offset" and
"num_bytes_unsigned" with "bit_offset" and "num_bits_unsigned"
respectively, converting from byte_offset_t to bit_offset_t.
Replace "out" and "read_bytes" with "bits_outside" and "read_bits"
respectively, converting from byte_range to bit_range. Convert
"buffer" from byte_range to bit_range. Replace "byte_bound" with
"bit_bound".
* region.cc (region::get_bit_size_sval): New.
(offset_region::get_bit_offset): New.
(offset_region::get_bit_size_sval): New.
(sized_region::get_bit_size_sval): New.
(bit_range_region::get_bit_size_sval): New.
* region.h (region::get_bit_size_sval): New vfunc.
(offset_region::get_bit_offset): New decl.
(offset_region::get_bit_size_sval): New decl.
(sized_region::get_bit_size_sval): New decl.
(bit_range_region::get_bit_size_sval): New decl.
* store.cc (bit_range::intersects_p): New, based on
byte_ran
[PATCH] x86: Get the previous shadow stack pointer from the restore token
Linux CET kernel places a restore token on shadow stack followed by
optional additional information for signal handler to enhance security.
The restore token is the previous shadow stack pointer with bit 63 set.
It is usually transparent to user programs since kernel will pop the
restore token and additional information when signal handler returns.
But when an exception is thrown from a signal handler, now we need to
pop the restore token and additional information from shadow stack.
For x86-64, we just need to get the previous shadow stack pointer from
the restore token. For i386, shadow stack is unsupported.
To be compatible with the old unwinder which doesn't use the restore
token to skip shadow stack frames used by signal handler, Linux kernel
won't put additional information after the restore token by default.
Define __cet_features to 1 to indicate that unwinder uses the restore
token to skip shadow stack frames used by signal handler. It can be
checked by glibc before enabling additional information in shadow stack
for signal handler.
* config/i386/libgcc-glibc.ver: Add __cet_features to
GCC_CET_FEATURES.
* config/i386/shadow-stack-unwind.h (_Unwind_Frames_Increment):
Only define for x86-64. Get the previous shadow stack pointer
from the restore token and skip to the previous frame.
(__cet_features): New.
---
libgcc/config/i386/libgcc-glibc.ver | 4 ++
libgcc/config/i386/shadow-stack-unwind.h | 84 +++-
2 files changed, 29 insertions(+), 59 deletions(-)
diff --git a/libgcc/config/i386/libgcc-glibc.ver
b/libgcc/config/i386/libgcc-glibc.ver
index 1c4665719da..9a8525757a4 100644
--- a/libgcc/config/i386/libgcc-glibc.ver
+++ b/libgcc/config/i386/libgcc-glibc.ver
@@ -152,6 +152,10 @@ GCC_4.8.0 {
__cpu_model
__cpu_indicator_init
}
+
+GCC_CET_FEATURES {
+ __cet_features
+}
%else
GCC_4.4.0 {
__addtf3
diff --git a/libgcc/config/i386/shadow-stack-unwind.h
b/libgcc/config/i386/shadow-stack-unwind.h
index e07ab4a10e4..afcce4b482d 100644
--- a/libgcc/config/i386/shadow-stack-unwind.h
+++ b/libgcc/config/i386/shadow-stack-unwind.h
@@ -43,18 +43,15 @@ see the files COPYING3 and COPYING.RUNTIME respectively.
If not, see
} \
while (0)
-/* Linux CET kernel places a restore token on shadow stack for signal
- handler to enhance security. The restore token is 8 byte and aligned
- to 8 bytes. It is usually transparent to user programs since kernel
- will pop the restore token when signal handler returns. But when an
- exception is thrown from a signal handler, now we need to pop the
- restore token from shadow stack. For x86-64, we just need to treat
- the signal frame as normal frame. For i386, we need to search for
- the restore token to check if the original shadow stack is 8 byte
- aligned. If the original shadow stack is 8 byte aligned, we just
- need to pop 2 slots, one restore token, from shadow stack. Otherwise,
- we need to pop 3 slots, one restore token + 4 byte padding, from
- shadow stack.
+/* Linux CET kernel places a restore token on shadow stack followed by
+ additional information for signal handler to enhance security. The
+ restore token is the previous shadow stack pointer with bit 63 set.
+ It is usually transparent to user programs since kernel will pop the
+ restore token and additional information when signal handler returns.
+ But when an exception is thrown from a signal handler, now we need to
+ pop the restore token and additional information from shadow stack.
+ For x86-64, we just need to get the previous shadow stack pointer from
+ the restore token. For i386, shadow stack is unsupported.
When popping a stack frame, we compare the return address on normal
stack against the return address on shadow stack. If they don't match,
@@ -66,65 +63,34 @@ see the files COPYING3 and COPYING.RUNTIME respectively.
If not, see
3. Signal stack frame since kernel puts a restore token on shadow
stack.
*/
-#undef _Unwind_Frames_Increment
#ifdef __x86_64__
+#undef _Unwind_Frames_Increment
#define _Unwind_Frames_Increment(exc, context, frames) \
{ \
frames++;\
- if (exc->exception_class != 0\
- && _Unwind_GetIP (context) != 0 \
- && !_Unwind_IsSignalFrame (context)) \
+ _Unwind_Word ssp = _get_ssp (); \
+ if (ssp != 0)\
{ \
- _Unwind_Word ssp = _get_ssp (); \
- if (ssp != 0) \
+ ssp += 8 * frames;\
+ if (_Unwind_IsSignalFrame (context)) \
{ \
-
Re: [PATCH] libstdc++: Make __gnu_debug::vector usable in constant expressions [PR109536]
On Sat, 16 Dec 2023, Jonathan Wakely wrote:
> On Sat, 16 Dec 2023 at 09:14, Jonathan Wakely wrote:
> >
> > On Sat, 16 Dec 2023 at 00:27, Patrick Palka wrote:
> > >
> > > On Wed, 6 Dec 2023, Jonathan Wakely wrote:
> > >
> > > > Any comments on this approach?
> > > >
> > > > -- >8 --
> > > >
> > > > This makes constexpr std::vector (mostly) work in Debug Mode. All safe
> > > > iterator instrumentation and checking is disabled during constant
> > > > evaluation, because it requires mutex locks and calls to non-inline
> > > > functions defined in libstdc++.so. It should be OK to disable the safety
> > > > checks, because most UB should be detected during constant evaluation
> > > > anyway.
> > > >
> > > > We could try to enable the full checking in constexpr, but it would mean
> > > > wrapping all the non-inline functions like _M_attach with an inline
> > > > _M_constexpr_attach that does the iterator housekeeping inline without
> > > > mutex locks when calling for constant evaluation, and calls the
> > > > non-inline function at runtime. That could be done in future if we find
> > > > that we've lost safety or useful checking by disabling the safe
> > > > iterators.
> > > >
> > > > There are a few test failures in C++20 mode, which I'm unable to
> > > > explain. The _Safe_iterator::operator++() member gives errors for using
> > > > non-constexpr functions during constant evaluation, even though those
> > > > functions are guarded by std::is_constant_evaluated() checks. The same
> > > > code works fine for C++23 and up.
> > >
> > > AFAICT these C++20 test failures are really due to the variable
> > > definition of non-literal type
> > >
> > > 381__gnu_cxx::__scoped_lock __l(this->_M_get_mutex());
> > >
> > > which were prohibited in a constexpr function (even if that code was
> > > never executed) until C++23's P2242R3.
> >
> > Ah, I figured it was a core change but I couldn't recall which one. Thanks.
Yeah the diagnostic blaming the non-constexpr call to _M_incrementable
was outright wrong and misleading, I filed PR113041 about that.
> >
> > > We can use an immediately invoked lambda to work around this:
> > >
> > > 381[this] {
> > > 382 __gnu_cxx::__scoped_lock __l(this->_M_get_mutex());
> > > 383 ++base();
> > > 384}();
> > > 385return *this;
> >
> > We'd need some #if as this code has to work for C++98. But that's doable.
>
> The attached patch seems simpler, I'm testing it now.
Would the operator+=, operator-= and the copy assign operator= also need
adjustment?
We could somewhat cleanly encapsulate the lambda workaround with a pair
of macros surrounding the problematic variable, something like:
diff --git a/libstdc++-v3/include/debug/safe_iterator.h
b/libstdc++-v3/include/debug/safe_iterator.h
index 26f008982f8..df3b4d33f04 100644
--- a/libstdc++-v3/include/debug/safe_iterator.h
+++ b/libstdc++-v3/include/debug/safe_iterator.h
@@ -360,6 +360,14 @@ namespace __gnu_debug
return base().operator->();
}
+#if __cplusplus >= 202002L && __cpp_constexpr < 202110L
+# define _GLIBCXX20_CONSTEXPR_NON_LITERAL_SCOPE_BEGIN [&] { do
+# define _GLIBCXX20_CONSTEXPR_NON_LITERAL_SCOPE_END while(false); }()
+#else
+# define _GLIBCXX20_CONSTEXPR_NON_LITERAL_SCOPE_BEGIN do
+# define _GLIBCXX20_CONSTEXPR_NON_LITERAL_SCOPE_END while(false)
+#endif
+
// -- Input iterator requirements --
/**
* @brief Iterator preincrement
@@ -378,8 +386,10 @@ namespace __gnu_debug
_GLIBCXX_DEBUG_VERIFY(this->_M_incrementable(),
_M_message(__msg_bad_inc)
._M_iterator(*this, "this"));
- __gnu_cxx::__scoped_lock __l(this->_M_get_mutex());
- ++base();
+ _GLIBCXX20_CONSTEXPR_NON_LITERAL_SCOPE_BEGIN {
+ __gnu_cxx::__scoped_lock __l(this->_M_get_mutex());
+ ++base();
+ } _GLIBCXX20_CONSTEXPR_NON_LITERAL_SCOPE_END;
return *this;
}
Re: [PATCH] libstdc++: Make __gnu_debug::vector usable in constant expressions [PR109536]
On Sat, 16 Dec 2023 at 16:26, Patrick Palka wrote:
>
> On Sat, 16 Dec 2023, Jonathan Wakely wrote:
>
> > On Sat, 16 Dec 2023 at 09:14, Jonathan Wakely wrote:
> > >
> > > On Sat, 16 Dec 2023 at 00:27, Patrick Palka wrote:
> > > >
> > > > On Wed, 6 Dec 2023, Jonathan Wakely wrote:
> > > >
> > > > > Any comments on this approach?
> > > > >
> > > > > -- >8 --
> > > > >
> > > > > This makes constexpr std::vector (mostly) work in Debug Mode. All safe
> > > > > iterator instrumentation and checking is disabled during constant
> > > > > evaluation, because it requires mutex locks and calls to non-inline
> > > > > functions defined in libstdc++.so. It should be OK to disable the
> > > > > safety
> > > > > checks, because most UB should be detected during constant evaluation
> > > > > anyway.
> > > > >
> > > > > We could try to enable the full checking in constexpr, but it would
> > > > > mean
> > > > > wrapping all the non-inline functions like _M_attach with an inline
> > > > > _M_constexpr_attach that does the iterator housekeeping inline without
> > > > > mutex locks when calling for constant evaluation, and calls the
> > > > > non-inline function at runtime. That could be done in future if we
> > > > > find
> > > > > that we've lost safety or useful checking by disabling the safe
> > > > > iterators.
> > > > >
> > > > > There are a few test failures in C++20 mode, which I'm unable to
> > > > > explain. The _Safe_iterator::operator++() member gives errors for
> > > > > using
> > > > > non-constexpr functions during constant evaluation, even though those
> > > > > functions are guarded by std::is_constant_evaluated() checks. The same
> > > > > code works fine for C++23 and up.
> > > >
> > > > AFAICT these C++20 test failures are really due to the variable
> > > > definition of non-literal type
> > > >
> > > > 381__gnu_cxx::__scoped_lock __l(this->_M_get_mutex());
> > > >
> > > > which were prohibited in a constexpr function (even if that code was
> > > > never executed) until C++23's P2242R3.
> > >
> > > Ah, I figured it was a core change but I couldn't recall which one.
> > > Thanks.
>
> Yeah the diagnostic blaming the non-constexpr call to _M_incrementable
> was outright wrong and misleading, I filed PR113041 about that.
>
> > >
> > > > We can use an immediately invoked lambda to work around this:
> > > >
> > > > 381[this] {
> > > > 382 __gnu_cxx::__scoped_lock __l(this->_M_get_mutex());
> > > > 383 ++base();
> > > > 384}();
> > > > 385return *this;
> > >
> > > We'd need some #if as this code has to work for C++98. But that's doable.
> >
> > The attached patch seems simpler, I'm testing it now.
>
> Would the operator+=, operator-= and the copy assign operator= also need
> adjustment?
Maybe ... which suggest we have missing tests for constexpr vector
(which is probably the case).
>
> We could somewhat cleanly encapsulate the lambda workaround with a pair
> of macros surrounding the problematic variable, something like:
>
> diff --git a/libstdc++-v3/include/debug/safe_iterator.h
> b/libstdc++-v3/include/debug/safe_iterator.h
> index 26f008982f8..df3b4d33f04 100644
> --- a/libstdc++-v3/include/debug/safe_iterator.h
> +++ b/libstdc++-v3/include/debug/safe_iterator.h
> @@ -360,6 +360,14 @@ namespace __gnu_debug
> return base().operator->();
>}
>
> +#if __cplusplus >= 202002L && __cpp_constexpr < 202110L
> +# define _GLIBCXX20_CONSTEXPR_NON_LITERAL_SCOPE_BEGIN [&] { do
> +# define _GLIBCXX20_CONSTEXPR_NON_LITERAL_SCOPE_END while(false); }()
> +#else
> +# define _GLIBCXX20_CONSTEXPR_NON_LITERAL_SCOPE_BEGIN do
> +# define _GLIBCXX20_CONSTEXPR_NON_LITERAL_SCOPE_END while(false)
I think for the limited uses in this file, we don't even need the
do-while, as the code we're enclosing is not a single statement
anyway.
> +#endif
> +
>// -- Input iterator requirements --
>/**
> * @brief Iterator preincrement
> @@ -378,8 +386,10 @@ namespace __gnu_debug
> _GLIBCXX_DEBUG_VERIFY(this->_M_incrementable(),
> _M_message(__msg_bad_inc)
> ._M_iterator(*this, "this"));
> - __gnu_cxx::__scoped_lock __l(this->_M_get_mutex());
> - ++base();
> + _GLIBCXX20_CONSTEXPR_NON_LITERAL_SCOPE_BEGIN {
> + __gnu_cxx::__scoped_lock __l(this->_M_get_mutex());
> + ++base();
> + } _GLIBCXX20_CONSTEXPR_NON_LITERAL_SCOPE_END;
> return *this;
>}
>
Yeah, I'll check if other operators need it, and if it's more than
just the two places in my patch I'll go with that.
If I don't get around to it (as I'm meant to have stopped work for the
year yesterday) then feel free to do that.
Re: [PATCH v26 00/23] Optimize type traits compilation performance
On Sun, 10 Dec 2023 at 18:19, Jason Merrill wrote: > > On 12/7/23 00:11, Ken Matsui wrote: > > This patch series optimizes type traits compilation performance by > > implementing built-in type traits and using them in libstdc++. > > > > Changes in v26: > > > > * Rebased on top of trunk. > > * Moved is_function_v under is_const_v. > > * Isolated patches for is_const, is_volatile, is_pointer, and > > is_unbounded_array, which contain performance regression, from > > this patch series since they are not ready for review yet. > > I've applied all the compiler patches, with a few small tweaks, > including this one as a separate commit. One other was a formatting > fix, the lats was using TYPE_PTRDATAMEM_P for CPTK_IS_MEMBER_OBJECT_POINTER. > > I'm leaving the library patches for library folks to apply. I've reviewed all the library patches in v26 and they are all OK for trunk. Please push (or Patrick can do so). Thanks, Ken! Great work, I'm really happy to see this land in GCC trunk. +Reviewed-by: Jonathan Wakely
Re: [PATCH] x86: Get the previous shadow stack pointer from the restore token
> Am 16.12.2023 um 16:56 schrieb H.J. Lu :
>
> Linux CET kernel places a restore token on shadow stack followed by
> optional additional information for signal handler to enhance security.
> The restore token is the previous shadow stack pointer with bit 63 set.
> It is usually transparent to user programs since kernel will pop the
> restore token and additional information when signal handler returns.
> But when an exception is thrown from a signal handler, now we need to
> pop the restore token and additional information from shadow stack.
> For x86-64, we just need to get the previous shadow stack pointer from
> the restore token. For i386, shadow stack is unsupported.
>
> To be compatible with the old unwinder which doesn't use the restore
> token to skip shadow stack frames used by signal handler, Linux kernel
> won't put additional information after the restore token by default.
> Define __cet_features to 1 to indicate that unwinder uses the restore
> token to skip shadow stack frames used by signal handler. It can be
> checked by glibc before enabling additional information in shadow stack
> for signal handler.
Doesn’t the check need to be two ways
To support kernels not doing this? Or
Not do it if the high bit isn’t set?
Richard
>* config/i386/libgcc-glibc.ver: Add __cet_features to
>GCC_CET_FEATURES.
>* config/i386/shadow-stack-unwind.h (_Unwind_Frames_Increment):
>Only define for x86-64. Get the previous shadow stack pointer
>from the restore token and skip to the previous frame.
>(__cet_features): New.
> ---
> libgcc/config/i386/libgcc-glibc.ver | 4 ++
> libgcc/config/i386/shadow-stack-unwind.h | 84 +++-
> 2 files changed, 29 insertions(+), 59 deletions(-)
>
> diff --git a/libgcc/config/i386/libgcc-glibc.ver
> b/libgcc/config/i386/libgcc-glibc.ver
> index 1c4665719da..9a8525757a4 100644
> --- a/libgcc/config/i386/libgcc-glibc.ver
> +++ b/libgcc/config/i386/libgcc-glibc.ver
> @@ -152,6 +152,10 @@ GCC_4.8.0 {
> __cpu_model
> __cpu_indicator_init
> }
> +
> +GCC_CET_FEATURES {
> + __cet_features
> +}
> %else
> GCC_4.4.0 {
> __addtf3
> diff --git a/libgcc/config/i386/shadow-stack-unwind.h
> b/libgcc/config/i386/shadow-stack-unwind.h
> index e07ab4a10e4..afcce4b482d 100644
> --- a/libgcc/config/i386/shadow-stack-unwind.h
> +++ b/libgcc/config/i386/shadow-stack-unwind.h
> @@ -43,18 +43,15 @@ see the files COPYING3 and COPYING.RUNTIME respectively.
> If not, see
> }\
> while (0)
>
> -/* Linux CET kernel places a restore token on shadow stack for signal
> - handler to enhance security. The restore token is 8 byte and aligned
> - to 8 bytes. It is usually transparent to user programs since kernel
> - will pop the restore token when signal handler returns. But when an
> - exception is thrown from a signal handler, now we need to pop the
> - restore token from shadow stack. For x86-64, we just need to treat
> - the signal frame as normal frame. For i386, we need to search for
> - the restore token to check if the original shadow stack is 8 byte
> - aligned. If the original shadow stack is 8 byte aligned, we just
> - need to pop 2 slots, one restore token, from shadow stack. Otherwise,
> - we need to pop 3 slots, one restore token + 4 byte padding, from
> - shadow stack.
> +/* Linux CET kernel places a restore token on shadow stack followed by
> + additional information for signal handler to enhance security. The
> + restore token is the previous shadow stack pointer with bit 63 set.
> + It is usually transparent to user programs since kernel will pop the
> + restore token and additional information when signal handler returns.
> + But when an exception is thrown from a signal handler, now we need to
> + pop the restore token and additional information from shadow stack.
> + For x86-64, we just need to get the previous shadow stack pointer from
> + the restore token. For i386, shadow stack is unsupported.
>
>When popping a stack frame, we compare the return address on normal
>stack against the return address on shadow stack. If they don't match,
> @@ -66,65 +63,34 @@ see the files COPYING3 and COPYING.RUNTIME respectively.
> If not, see
>3. Signal stack frame since kernel puts a restore token on shadow
> stack.
> */
> -#undef _Unwind_Frames_Increment
> #ifdef __x86_64__
> +#undef _Unwind_Frames_Increment
> #define _Unwind_Frames_Increment(exc, context, frames)\
> {\
> frames++;\
> - if (exc->exception_class != 0\
> - && _Unwind_GetIP (context) != 0\
> - && !_Unwind_IsSignalFrame (context))\
> + _Unwind_Word ssp = _get_ssp ();\
> + if (ssp != 0)\
>{\
> - _Unwind_Word ssp = _get_ssp ();\
> - if (ssp != 0)\
> + ssp +=
Re: [PATCH] x86: Get the previous shadow stack pointer from the restore token
On Sat, Dec 16, 2023 at 8:41 AM Richard Biener
wrote:
>
>
>
> > Am 16.12.2023 um 16:56 schrieb H.J. Lu :
> >
> > Linux CET kernel places a restore token on shadow stack followed by
> > optional additional information for signal handler to enhance security.
> > The restore token is the previous shadow stack pointer with bit 63 set.
> > It is usually transparent to user programs since kernel will pop the
> > restore token and additional information when signal handler returns.
> > But when an exception is thrown from a signal handler, now we need to
> > pop the restore token and additional information from shadow stack.
> > For x86-64, we just need to get the previous shadow stack pointer from
> > the restore token. For i386, shadow stack is unsupported.
> >
> > To be compatible with the old unwinder which doesn't use the restore
> > token to skip shadow stack frames used by signal handler, Linux kernel
> > won't put additional information after the restore token by default.
> > Define __cet_features to 1 to indicate that unwinder uses the restore
> > token to skip shadow stack frames used by signal handler. It can be
> > checked by glibc before enabling additional information in shadow stack
> > for signal handler.
>
> Doesn’t the check need to be two ways
> To support kernels not doing this? Or
> Not do it if the high bit isn’t set?
The updated unwinder works with and without additional information
after the restore token on signal handler shadow stack. By default,
kernel won't put anything after the restore token. Glibc will issue a
syscall to enable additional information for the updated unwinder. If
the syscall fails because of the older kernel, the updated unwinder
still works. The updated kernel may put additional information after
the restore token for the updated unwinder.
Here is the prototype glibc patch:
https://gitlab.com/x86-glibc/glibc/-/commit/45b26655c775e8f23408c38d2432d0c72720ba42
> Richard
>
> >* config/i386/libgcc-glibc.ver: Add __cet_features to
> >GCC_CET_FEATURES.
> >* config/i386/shadow-stack-unwind.h (_Unwind_Frames_Increment):
> >Only define for x86-64. Get the previous shadow stack pointer
> >from the restore token and skip to the previous frame.
> >(__cet_features): New.
> > ---
> > libgcc/config/i386/libgcc-glibc.ver | 4 ++
> > libgcc/config/i386/shadow-stack-unwind.h | 84 +++-
> > 2 files changed, 29 insertions(+), 59 deletions(-)
> >
> > diff --git a/libgcc/config/i386/libgcc-glibc.ver
> > b/libgcc/config/i386/libgcc-glibc.ver
> > index 1c4665719da..9a8525757a4 100644
> > --- a/libgcc/config/i386/libgcc-glibc.ver
> > +++ b/libgcc/config/i386/libgcc-glibc.ver
> > @@ -152,6 +152,10 @@ GCC_4.8.0 {
> > __cpu_model
> > __cpu_indicator_init
> > }
> > +
> > +GCC_CET_FEATURES {
> > + __cet_features
> > +}
> > %else
> > GCC_4.4.0 {
> > __addtf3
> > diff --git a/libgcc/config/i386/shadow-stack-unwind.h
> > b/libgcc/config/i386/shadow-stack-unwind.h
> > index e07ab4a10e4..afcce4b482d 100644
> > --- a/libgcc/config/i386/shadow-stack-unwind.h
> > +++ b/libgcc/config/i386/shadow-stack-unwind.h
> > @@ -43,18 +43,15 @@ see the files COPYING3 and COPYING.RUNTIME
> > respectively. If not, see
> > }\
> > while (0)
> >
> > -/* Linux CET kernel places a restore token on shadow stack for signal
> > - handler to enhance security. The restore token is 8 byte and aligned
> > - to 8 bytes. It is usually transparent to user programs since kernel
> > - will pop the restore token when signal handler returns. But when an
> > - exception is thrown from a signal handler, now we need to pop the
> > - restore token from shadow stack. For x86-64, we just need to treat
> > - the signal frame as normal frame. For i386, we need to search for
> > - the restore token to check if the original shadow stack is 8 byte
> > - aligned. If the original shadow stack is 8 byte aligned, we just
> > - need to pop 2 slots, one restore token, from shadow stack. Otherwise,
> > - we need to pop 3 slots, one restore token + 4 byte padding, from
> > - shadow stack.
> > +/* Linux CET kernel places a restore token on shadow stack followed by
> > + additional information for signal handler to enhance security. The
> > + restore token is the previous shadow stack pointer with bit 63 set.
> > + It is usually transparent to user programs since kernel will pop the
> > + restore token and additional information when signal handler returns.
> > + But when an exception is thrown from a signal handler, now we need to
> > + pop the restore token and additional information from shadow stack.
> > + For x86-64, we just need to get the previous shadow stack pointer from
> > + the restore token. For i386, shadow stack is unsupported.
> >
> >When popping a stack frame, we compare the return address on normal
> >stack against the return address on shadow stack. If they don't match,
> > @@ -6
Re: [PATCH v26 00/23] Optimize type traits compilation performance
On Sat, Dec 16, 2023 at 8:40 AM Jonathan Wakely wrote: > > On Sun, 10 Dec 2023 at 18:19, Jason Merrill wrote: > > > > On 12/7/23 00:11, Ken Matsui wrote: > > > This patch series optimizes type traits compilation performance by > > > implementing built-in type traits and using them in libstdc++. > > > > > > Changes in v26: > > > > > > * Rebased on top of trunk. > > > * Moved is_function_v under is_const_v. > > > * Isolated patches for is_const, is_volatile, is_pointer, and > > > is_unbounded_array, which contain performance regression, from > > > this patch series since they are not ready for review yet. > > > > I've applied all the compiler patches, with a few small tweaks, > > including this one as a separate commit. One other was a formatting > > fix, the lats was using TYPE_PTRDATAMEM_P for CPTK_IS_MEMBER_OBJECT_POINTER. > > > > I'm leaving the library patches for library folks to apply. > > I've reviewed all the library patches in v26 and they are all OK for > trunk. Please push (or Patrick can do so). > > Thanks, Ken! Great work, I'm really happy to see this land in GCC trunk. > > +Reviewed-by: Jonathan Wakely > Thank you so much for taking the time to review my patches and for your kind support! I will push :)
[PATCH] Fortran: fix argument passing to CONTIGUOUS,TARGET dummy [PR97592]
Dear all,
the attached simple patch fixes a (9+) regression for passing
to a CONTIGUOUS,TARGET dummy an *effective argument* that is
contiguous, although the actual argument is not simply-contiguous
(it is a pointer without the CONTIGOUS attribute in the PR).
Since a previous attempt for a patch lead to regressions in
gfortran.dg/bind-c-contiguous-3.f90, which is rather dense,
I decided to enhance the current testcase with various
combinations of actual and dummy arguments that allow to
study whether a _gfortran_internal_pack is generated in
places where we want to. (_gfortran_internal_pack does not
create a temporary when no packing is needed).
Regtested on x86_64-pc-linux-gnu. OK for mainline?
I would like to backport this - after a grace period - to
at least 13-branch. Any objections here?
Thanks,
Harald
From d8765bd669e501781672c0bec976b2f5fd7acff6 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 16 Dec 2023 19:14:55 +0100
Subject: [PATCH] Fortran: fix argument passing to CONTIGUOUS,TARGET dummy
[PR97592]
gcc/fortran/ChangeLog:
PR fortran/97592
* trans-expr.cc (gfc_conv_procedure_call): For a contiguous dummy
with the TARGET attribute, the effective argument may still be
contiguous even if the actual argument is not simply-contiguous.
Allow packing to be decided at runtime by _gfortran_internal_pack.
gcc/testsuite/ChangeLog:
PR fortran/97592
* gfortran.dg/contiguous_15.f90: New test.
---
gcc/fortran/trans-expr.cc | 4 +-
gcc/testsuite/gfortran.dg/contiguous_15.f90 | 234
2 files changed, 237 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/contiguous_15.f90
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index f4185db5b7f..218fede6a82 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -7124,7 +7124,9 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
INTENT_IN, fsym->attr.pointer);
}
else if (fsym && fsym->attr.contiguous
- && !gfc_is_simply_contiguous (e, false, true)
+ && (fsym->attr.target
+ ? gfc_is_not_contiguous (e)
+ : !gfc_is_simply_contiguous (e, false, true))
&& gfc_expr_is_variable (e))
{
gfc_conv_subref_array_arg (&parmse, e, nodesc_arg,
diff --git a/gcc/testsuite/gfortran.dg/contiguous_15.f90 b/gcc/testsuite/gfortran.dg/contiguous_15.f90
new file mode 100644
index 000..424eb080fd1
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/contiguous_15.f90
@@ -0,0 +1,234 @@
+! { dg-do run }
+! { dg-additional-options "-fdump-tree-original" }
+!
+! PR fortran/97592 - fix argument passing to CONTIGUOUS,TARGET dummy
+!
+! { dg-final { scan-tree-dump-times "_gfortran_internal_pack \\(&b_2d" 1 "original" } }
+! { dg-final { scan-tree-dump-times "_gfortran_internal_pack \\(&p1" 3 "original" } }
+!
+! N.B.: there is no reliable count of _gfortran_internal_pack on temporaries parm.*
+
+program pr97592
+ implicit none
+ integer :: i, k
+ integer, target :: a(10)
+ integer, pointer :: p1(:), p2(:), tgt(:), expect(:)
+ integer, pointer, contiguous :: cp(:)
+ integer, allocatable, target :: b(:)
+
+ !--
+ ! Code from original PR
+ !--
+ call RemappingTest ()
+
+ !-
+ ! Additional 1-d tests
+ !-
+ a = [(i, i=1,size(a))]
+ b = a
+
+ ! Set p1 to an actually contiguous pointer
+ p1(13:) => a(3::2)
+ print *, lbound (p1), ubound (p1), is_contiguous (p1)
+
+ ! non-contiguous pointer actual argument
+ expect => p1
+ call chk_cont (p1)
+
+ expect => p1
+ call chk_tgt_cont (p1)
+
+ expect => p1
+ call chk_ptr (p1, p2)
+ if (any (p2 /= p1)) stop 1
+
+ expect => p1
+ call chk_tgt (p1, p2)
+ if (any (p2 /= p1)) stop 2
+
+ ! non-contiguous target actual argument
+ expect => b(3::2)
+ call chk_tgt_cont (b(3::2))
+
+ expect => b(3::2)
+ call chk_tgt (b(3::2), p2)
+ if (any (p2 /= p1)) stop 3
+
+ expect => b(3::2)
+ call chk_ptr (b(3::2), p2)
+ if (any (p2 /= p1)) stop 4
+
+ ! Set p1 to an actually contiguous pointer
+ cp(17:) => a(3:9:1)
+ p1 => cp
+ print *, lbound (cp), ubound (cp), is_contiguous (cp)
+ print *, lbound (p1), ubound (p1), is_contiguous (p1)
+
+ expect => p1
+ call chk_tgt (p1, p2)
+ if (any (p2 /= cp)) stop 31
+
+ expect => cp
+ call chk_tgt (cp, p2)
+ if (any (p2 /= cp)) stop 32
+
+ expect => cp
+ call chk_tgt_cont (cp, p2)
+ if (any (p2 /= cp)) stop 33
+
+ expect => cp
+ call chk_tgt_expl (cp, p2, size (cp))
+ if (any (p2 /= cp)) stop 34
+
+ ! See F2018:15.5.2.4 and F2018:C.10.4
+ expect => p1
+ call chk_tgt_cont (p1, p2)
+! print *, p2
+ if (any (p2 /= cp)) stop 35
+
+ expect => p1
+ call chk_tgt_expl (p1, p2, size (p1))
+ if (any (p2 /= cp)) stop 36
+
+ expect => cp
+ call chk_ptr_cont (cp, p2)
+ if (any (p2 /= cp)) stop 37
+
+ ! Pass array section which is actually contigous
+ k = 1
+ expect => cp(::k)
+ call chk
[PATCH] libstdc++: Update some baseline_symbols.txt (x32)
* config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt: Updated. --- .../x86_64-linux-gnu/x32/baseline_symbols.txt | 111 +- 1 file changed, 110 insertions(+), 1 deletion(-) diff --git a/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt b/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt index b00ab2c7496..dc69c47f4d7 100644 --- a/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt +++ b/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt @@ -475,6 +475,7 @@ FUNC:_ZNKSt10moneypunctIwLb1EE8groupingEv@@GLIBCXX_3.4 FUNC:_ZNKSt10ostrstream5rdbufEv@@GLIBCXX_3.4 FUNC:_ZNKSt10ostrstream6pcountEv@@GLIBCXX_3.4 FUNC:_ZNKSt11__timepunctIcE15_M_am_pm_formatEPKc@@GLIBCXX_3.4 +FUNC:_ZNKSt11__timepunctIcE15_M_am_pm_formatEPPKc@@GLIBCXX_3.4.30 FUNC:_ZNKSt11__timepunctIcE15_M_date_formatsEPPKc@@GLIBCXX_3.4 FUNC:_ZNKSt11__timepunctIcE15_M_time_formatsEPPKc@@GLIBCXX_3.4 FUNC:_ZNKSt11__timepunctIcE19_M_days_abbreviatedEPPKc@@GLIBCXX_3.4 @@ -485,6 +486,7 @@ FUNC:_ZNKSt11__timepunctIcE7_M_daysEPPKc@@GLIBCXX_3.4 FUNC:_ZNKSt11__timepunctIcE8_M_am_pmEPPKc@@GLIBCXX_3.4 FUNC:_ZNKSt11__timepunctIcE9_M_monthsEPPKc@@GLIBCXX_3.4 FUNC:_ZNKSt11__timepunctIwE15_M_am_pm_formatEPKw@@GLIBCXX_3.4 +FUNC:_ZNKSt11__timepunctIwE15_M_am_pm_formatEPPKw@@GLIBCXX_3.4.30 FUNC:_ZNKSt11__timepunctIwE15_M_date_formatsEPPKw@@GLIBCXX_3.4 FUNC:_ZNKSt11__timepunctIwE15_M_time_formatsEPPKw@@GLIBCXX_3.4 FUNC:_ZNKSt11__timepunctIwE19_M_days_abbreviatedEPPKw@@GLIBCXX_3.4 @@ -496,6 +498,10 @@ FUNC:_ZNKSt11__timepunctIwE8_M_am_pmEPPKw@@GLIBCXX_3.4 FUNC:_ZNKSt11__timepunctIwE9_M_monthsEPPKw@@GLIBCXX_3.4 FUNC:_ZNKSt11logic_error4whatEv@@GLIBCXX_3.4 FUNC:_ZNKSt12__basic_fileIcE7is_openEv@@GLIBCXX_3.4 +FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31 +FUNC:_ZNKSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31 +FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31 +FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31 FUNC:_ZNKSt12bad_weak_ptr4whatEv@@GLIBCXX_3.4.15 FUNC:_ZNKSt12future_error4whatEv@@GLIBCXX_3.4.14 FUNC:_ZNKSt12strstreambuf6pcountEv@@GLIBCXX_3.4 @@ -666,6 +672,13 @@ FUNC:_ZNKSt5ctypeIwE8do_widenEPKcS2_Pw@@GLIBCXX_3.4 FUNC:_ZNKSt5ctypeIwE8do_widenEc@@GLIBCXX_3.4 FUNC:_ZNKSt5ctypeIwE9do_narrowEPKwS2_cPc@@GLIBCXX_3.4 FUNC:_ZNKSt5ctypeIwE9do_narrowEwc@@GLIBCXX_3.4 +FUNC:_ZNKSt6chrono4tzdb11locate_zoneESt17basic_string_viewIcSt11char_traitsIcEE@@GLIBCXX_3.4.31 +FUNC:_ZNKSt6chrono4tzdb12current_zoneEv@@GLIBCXX_3.4.31 +FUNC:_ZNKSt6chrono9time_zone15_M_get_sys_infoENS_10time_pointINS_3_V212system_clockENS_8durationIxSt5ratioILx1ELx1EE@@GLIBCXX_3.4.31 +FUNC:_ZNKSt6chrono9time_zone17_M_get_local_infoENS_10time_pointINS_7local_tENS_8durationIxSt5ratioILx1ELx1EE@@GLIBCXX_3.4.31 +FUNC:_ZNKSt6chrono9tzdb_list14const_iteratordeEv@@GLIBCXX_3.4.31 +FUNC:_ZNKSt6chrono9tzdb_list5beginEv@@GLIBCXX_3.4.31 +FUNC:_ZNKSt6chrono9tzdb_list5frontEv@@GLIBCXX_3.4.31 FUNC:_ZNKSt6locale2id5_M_idEv@@GLIBCXX_3.4 FUNC:_ZNKSt6locale4nameB5cxx11Ev@@GLIBCXX_3.4.21 FUNC:_ZNKSt6locale4nameEv@@GLIBCXX_3.4 @@ -954,6 +967,7 @@ FUNC:_ZNKSt7__cxx118time_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14do_ FUNC:_ZNKSt7__cxx118time_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE15_M_extract_nameES4_S4_RiPPKcjRSt8ios_baseRSt12_Ios_Iostate@@GLIBCXX_3.4.21 FUNC:_ZNKSt7__cxx118time_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE16do_get_monthnameES4_S4_RSt8ios_baseRSt12_Ios_IostateP2tm@@GLIBCXX_3.4.21 FUNC:_ZNKSt7__cxx118time_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE21_M_extract_via_formatES4_S4_RSt8ios_baseRSt12_Ios_IostateP2tmPKc@@GLIBCXX_3.4.21 +FUNC:_ZNKSt7__cxx118time_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE21_M_extract_via_formatES4_S4_RSt8ios_baseRSt12_Ios_IostateP2tmPKcRSt16__time_get_state@@GLIBCXX_3.4.30 FUNC:_ZNKSt7__cxx118time_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE24_M_extract_wday_or_monthES4_S4_RiPPKcjRSt8ios_baseRSt12_Ios_Iostate@@GLIBCXX_3.4.21 FUNC:_ZNKSt7__cxx118time_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE3getES4_S4_RSt8ios_baseRSt12_Ios_IostateP2tmPKcSD_@@GLIBCXX_3.4.21 FUNC:_ZNKSt7__cxx118time_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE3getES4_S4_RSt8ios_baseRSt12_Ios_IostateP2tmcc@@GLIBCXX_3.4.21 @@ -973,6 +987,7 @@ FUNC:_ZNKSt7__cxx118time_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14do_ FUNC:_ZNKSt7__cxx118time_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE15_M_extract_nameES4_S4_RiPPKwjRSt8ios_baseRSt12_Ios_Iostate@@GLIBCXX_3.4.21 FUNC:_ZNKSt7__cxx118time_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE16do_get_monthnameES4_S4_RSt8ios_baseRSt12_Ios_IostateP2tm@@GLIBCXX_3.4.21
Re: [PATCH] RISC-V: Don't make Ztso imply A
On 12/15/23 17:14, Andrew Waterman wrote:
On Fri, Dec 15, 2023 at 1:38 PM Jeff Law wrote:
On 12/12/23 20:54, Palmer Dabbelt wrote:
I can't actually find anything in the ISA manual that makes Ztso imply
A. In theory the memory ordering is just a different thing that the set
of availiable instructions (ie, Ztso without A would still imply TSO for
loads and stores). It also seems like a configuration that could be
sane to build: without A it's all but impossible to write any meaningful
multi-core code, and TSO is really cheap for a single core.
That said, I think it's kind of reasonable to provide A to users asking
for Ztso. So maybe even if this was a mistake it's the right thing to
do?
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_implied_info):
Remove {"ztso", "a"}.
I'd tend to think step #1 is to determine what the ISA intent is,
meaning engagement with RVI.
We've got time for that engagement and to adjust based on the result.
So I'd tend to defer until we know if Ztso should imply A or not.
Palmer is correct. There is no coupling between Ztso and A. (And
there are uncontrived examples of such systems: e.g. embedded
processors without caches that don't support the LR/SC instructions,
but happen to be TSO.)
Thanks for the confirmation. Palmer, commit whenever is convenient for you.
jeff
[PATCH] PR libstdc++/112682 More efficient std::basic_string move
A few places in bits/basic_string.h use `traits_type::copy` to copy
`__str.length() + 1` bytes.
Despite the knowledge that `__str.length()` is not greater than 15 the
compiler emits (and sometimes inlines) a `memcpy` call. That results
in a quite big set of instructions https://godbolt.org/z/j35MMfxzq
Replacing `__str.length() + 1` with `_S_local_capacity + 1` explicitly
forces the compiler to copy the whole `__str._M_local_buf`. As a
result the assembly becomes almost 5 times shorter and without any
function calls or multiple conditional jumps
https://godbolt.org/z/bfq8bxra9
This patch always copies `_S_local_capacity + 1` if working with
`std::char_traits`.
PR libstdc++/112682:
* include/bits/basic_string.h: Optimize string moves.
P.S.: still not sure that this optimization is not an UB or fine for
libstdc++. However, the assembly looks much better with it.
--
Best regards,
Antony Polukhin
diff --git a/libstdc++-v3/include/bits/basic_string.h
b/libstdc++-v3/include/bits/basic_string.h
index 1b8ebca7dad..7a5e348280c 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -188,6 +188,23 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
: basic_string(__svw._M_sv.data(), __svw._M_sv.size(), __a) { }
#endif
+ _GLIBCXX17_CONSTEXPR
+ static bool
+ _S_permit_copying_indeterminate() noexcept
+ {
+ // Copying compile-time known _S_local_capacity + 1 bytes is much more
+ // efficient than copying runtime known __str.length() + 1. This
+ // function returns true, if such initialization is permitted even if
+ // the right side has indeterminate values.
+ //
+ // [dcl.init] permits initializing with indeterminate value of unsigned
+ // narrow character type.
+ //
+ // Library users should not specialize char_traits so this is
+ // not observable for user.
+ return is_same >::value;
+ }
+
// Use empty-base optimization: http://www.cantrip.org/emptyopt.html
struct _Alloc_hider : allocator_type // TODO check __is_final
{
@@ -672,8 +689,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
{
if (__str._M_is_local())
{
- traits_type::copy(_M_local_buf, __str._M_local_buf,
- __str.length() + 1);
+ size_type __copy_count = _S_local_capacity + 1;
+ if _GLIBCXX17_CONSTEXPR (!_S_permit_copying_indeterminate())
+ __copy_count = __str.length() + 1;
+ traits_type::copy(_M_local_buf, __str._M_local_buf, __copy_count);
}
else
{
@@ -711,8 +730,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
{
if (__str._M_is_local())
{
- traits_type::copy(_M_local_buf, __str._M_local_buf,
- __str.length() + 1);
+ size_type __copy_count = _S_local_capacity + 1;
+ if _GLIBCXX17_CONSTEXPR (!_S_permit_copying_indeterminate())
+ __copy_count = __str.length() + 1;
+ traits_type::copy(_M_local_buf, __str._M_local_buf, __copy_count);
_M_length(__str.length());
__str._M_set_length(0);
}
[pushed] json: fix escaping of object keys
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r14-6634-g30d9a3a69841b1.
gcc/ChangeLog:
* json.cc (print_escaped_json_string): New, taken from
string::print.
(object::print): Use it for printing keys.
(string::print): Move implementation to
print_escaped_json_string.
(selftest::test_writing_objects): Add a key containing
quote, backslash, and control characters.
Signed-off-by: David Malcolm
---
gcc/json.cc | 94 ++---
1 file changed, 54 insertions(+), 40 deletions(-)
diff --git a/gcc/json.cc b/gcc/json.cc
index 90ddd7ab3b15..350917af5df1 100644
--- a/gcc/json.cc
+++ b/gcc/json.cc
@@ -28,6 +28,52 @@ along with GCC; see the file COPYING3. If not see
using namespace json;
+/* Print a JSON string to PP, escaping '"', control characters,
+ and embedded null bytes.
+ The string is required to be UTF-8 encoded. */
+
+static void
+print_escaped_json_string (pretty_printer *pp,
+ const char *utf8_str,
+ size_t len)
+{
+ pp_character (pp, '"');
+ for (size_t i = 0; i != len; ++i)
+{
+ char ch = utf8_str[i];
+ switch (ch)
+ {
+ case '"':
+ pp_string (pp, "\\\"");
+ break;
+ case '\\':
+ pp_string (pp, "");
+ break;
+ case '\b':
+ pp_string (pp, "\\b");
+ break;
+ case '\f':
+ pp_string (pp, "\\f");
+ break;
+ case '\n':
+ pp_string (pp, "\\n");
+ break;
+ case '\r':
+ pp_string (pp, "\\r");
+ break;
+ case '\t':
+ pp_string (pp, "\\t");
+ break;
+ case '\0':
+ pp_string (pp, "\\0");
+ break;
+ default:
+ pp_character (pp, ch);
+ }
+}
+ pp_character (pp, '"');
+}
+
/* class json::value. */
/* Dump this json::value tree to OUTF.
@@ -85,9 +131,7 @@ object::print (pretty_printer *pp, bool formatted) const
}
map_t &mut_map = const_cast (m_map);
value *value = *mut_map.get (key);
- pp_doublequote (pp);
- pp_string (pp, key); // FIXME: escaping?
- pp_doublequote (pp);
+ print_escaped_json_string (pp, key, strlen (key));
pp_string (pp, ": ");
const int indent = strlen (key) + 4;
if (formatted)
@@ -284,41 +328,7 @@ void
string::print (pretty_printer *pp,
bool formatted ATTRIBUTE_UNUSED) const
{
- pp_character (pp, '"');
- for (size_t i = 0; i != m_len; ++i)
-{
- char ch = m_utf8[i];
- switch (ch)
- {
- case '"':
- pp_string (pp, "\\\"");
- break;
- case '\\':
- pp_string (pp, "");
- break;
- case '\b':
- pp_string (pp, "\\b");
- break;
- case '\f':
- pp_string (pp, "\\f");
- break;
- case '\n':
- pp_string (pp, "\\n");
- break;
- case '\r':
- pp_string (pp, "\\r");
- break;
- case '\t':
- pp_string (pp, "\\t");
- break;
- case '\0':
- pp_string (pp, "\\0");
- break;
- default:
- pp_character (pp, ch);
- }
-}
- pp_character (pp, '"');
+ print_escaped_json_string (pp, m_utf8, m_len);
}
/* class json::literal, a subclass of json::value. */
@@ -388,13 +398,17 @@ test_writing_objects ()
object obj;
obj.set_string ("foo", "bar");
obj.set_string ("baz", "quux");
+ obj.set_string ("\"\\\b\f\n\r\t", "value for awkward key");
+
/* This test relies on json::object writing out key/value pairs
in key-insertion order. */
ASSERT_PRINT_EQ (obj, true,
"{\"foo\": \"bar\",\n"
- " \"baz\": \"quux\"}");
+ " \"baz\": \"quux\",\n"
+ " \"\\\"\\b\\f\\n\\r\\t\": \"value for awkward key\"}");
ASSERT_PRINT_EQ (obj, false,
- "{\"foo\": \"bar\", \"baz\": \"quux\"}");
+ "{\"foo\": \"bar\", \"baz\": \"quux\""
+ ", \"\\\"\\b\\f\\n\\r\\t\": \"value for awkward key\"}");
}
/* Verify that JSON arrays are written correctly. */
--
2.26.3
[pushed] analyzer: add sarif properties for bounds checking diagnostics
As a followup to r14-6057-g12b67d1e13b3cf, add SARIF property bags
for -Wanalyzer-out-of-bounds, to help with debugging these warnings.
This was very helpful with PR analyzer/112792.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r14-6635-g7abc7aae564e63.
gcc/analyzer/ChangeLog:
* analyzer.cc: Include "tree-pretty-print.h" and
"diagnostic-event-id.h".
(tree_to_json): New.
(diagnostic_event_id_to_json): New.
(bit_offset_to_json): New.
(byte_offset_to_json): New.
* analyzer.h (tree_to_json): New decl.
(diagnostic_event_id_to_json): New decl.
(bit_offset_to_json): New decl.
(byte_offset_to_json): New decl.
* bounds-checking.cc: Include "diagnostic-format-sarif.h".
(out_of_bounds::maybe_add_sarif_properties): New.
(concrete_out_of_bounds::maybe_add_sarif_properties): New.
(concrete_past_the_end::maybe_add_sarif_properties): New.
(symbolic_past_the_end::maybe_add_sarif_properties): New.
* region-model.cc (region_to_value_map::to_json): New.
(region_model::to_json): New.
* region-model.h (region_to_value_map::to_json): New decl.
(region_model::to_json): New decl.
* store.cc (bit_range::to_json): New.
(byte_range::to_json): New.
* store.h (bit_range::to_json): New decl.
(byte_range::to_json): New decl.
Signed-off-by: David Malcolm
---
gcc/analyzer/analyzer.cc| 59 +
gcc/analyzer/analyzer.h | 12 +++
gcc/analyzer/bounds-checking.cc | 58
gcc/analyzer/region-model.cc| 41 +++
gcc/analyzer/region-model.h | 4 +++
gcc/analyzer/store.cc | 30 +
gcc/analyzer/store.h| 4 +++
7 files changed, 208 insertions(+)
diff --git a/gcc/analyzer/analyzer.cc b/gcc/analyzer/analyzer.cc
index 9d4bc788f316..c9d725424e2e 100644
--- a/gcc/analyzer/analyzer.cc
+++ b/gcc/analyzer/analyzer.cc
@@ -29,6 +29,8 @@ along with GCC; see the file COPYING3. If not see
#include "diagnostic.h"
#include "intl.h"
#include "analyzer/analyzer.h"
+#include "tree-pretty-print.h"
+#include "diagnostic-event-id.h"
#if ENABLE_ANALYZER
@@ -216,6 +218,63 @@ get_diagnostic_tree_for_gassign (const gassign
*assign_stmt)
return get_diagnostic_tree_for_gassign_1 (assign_stmt, &visited);
}
+/* Generate a JSON value for NODE, which can be NULL_TREE.
+ This is intended for debugging the analyzer rather than serialization and
+ thus is a string (or null, for NULL_TREE). */
+
+json::value *
+tree_to_json (tree node)
+{
+ if (!node)
+return new json::literal (json::JSON_NULL);
+
+ pretty_printer pp;
+ dump_generic_node (&pp, node, 0, TDF_VOPS|TDF_MEMSYMS, false);
+ return new json::string (pp_formatted_text (&pp));
+}
+
+/* Generate a JSON value for EVENT_ID.
+ This is intended for debugging the analyzer rather than serialization and
+ thus is a string matching those seen in event messags (or null,
+ for unknown). */
+
+json::value *
+diagnostic_event_id_to_json (const diagnostic_event_id_t &event_id)
+{
+ if (event_id.known_p ())
+{
+ pretty_printer pp;
+ pp_printf (&pp, "%@", &event_id);
+ return new json::string (pp_formatted_text (&pp));
+}
+ else
+return new json::literal (json::JSON_NULL);
+}
+
+/* Generate a JSON value for OFFSET.
+ This is intended for debugging the analyzer rather than serialization and
+ thus is a string. */
+
+json::value *
+bit_offset_to_json (const bit_offset_t &offset)
+{
+ pretty_printer pp;
+ pp_wide_int_large (&pp, offset, SIGNED);
+ return new json::string (pp_formatted_text (&pp));
+}
+
+/* Generate a JSON value for OFFSET.
+ This is intended for debugging the analyzer rather than serialization and
+ thus is a string. */
+
+json::value *
+byte_offset_to_json (const byte_offset_t &offset)
+{
+ pretty_printer pp;
+ pp_wide_int_large (&pp, offset, SIGNED);
+ return new json::string (pp_formatted_text (&pp));
+}
+
} // namespace ana
/* Helper function for checkers. Is the CALL to the given function name,
diff --git a/gcc/analyzer/analyzer.h b/gcc/analyzer/analyzer.h
index 3115f878573a..7d3984839560 100644
--- a/gcc/analyzer/analyzer.h
+++ b/gcc/analyzer/analyzer.h
@@ -415,6 +415,18 @@ extern void log_stashed_constants (logger *logger);
extern FILE *get_or_create_any_logfile ();
+extern json::value *
+tree_to_json (tree node);
+
+extern json::value *
+diagnostic_event_id_to_json (const diagnostic_event_id_t &);
+
+extern json::value *
+bit_offset_to_json (const bit_offset_t &offset);
+
+extern json::value *
+byte_offset_to_json (const byte_offset_t &offset);
+
} // namespace ana
extern bool is_special_named_call_p (const gcall *call, const char *funcname,
diff --git a/gcc/analyzer/bounds-checking.cc b/gcc/anal
Re: [committed] libstdc++: Implement C++23 header [PR107760]
Hi, Jonathan
Unfortunately this patch broke bootstrap on AIX.
In file included from /tmp/GCC/gcc/include-fixed/wchar.h:64,
from
/tmp/GCC/powerpc-ibm-aix7.2.5.0/libstdc++-v3/include/cwchar:44,
from
/tmp/GCC/powerpc-ibm-aix7.2.5.0/libstdc++-v3/include/bits/postypes.h:40,
from
/tmp/GCC/powerpc-ibm-aix7.2.5.0/libstdc++-v3/include/bits/char_traits.h:42,
from
/tmp/GCC/powerpc-ibm-aix7.2.5.0/libstdc++-v3/include/string:42,
from
/nasfarm/edelsohn/src/src/libstdc++-v3/src/c++23/print.cc:26:
/nasfarm/edelsohn/src/src/libstdc++-v3/src/c++23/print.cc: In function
'void* std::__open_terminal(FILE*)':
/nasfarm/edelsohn/src/src/libstdc++-v3/src/c++23/print.cc:78:24: error:
expected id-expression before '(' token
78 | if (int fd = ::fileno(f); fd >= 0 && ::isatty(fd))
|^~
make[6]: *** [Makefile:747: print.lo] Error 1
AIX stdio.h defines fileno as a macro although there is a symbol in libc.
I think that print.cc at least needs to
#undef fileno
before the usage.
Thanks, David
Re: [committed] libstdc++: Implement C++23 header [PR107760]
On Sat, Dec 16, 2023 at 04:24:13PM -0500, David Edelsohn wrote: > AIX stdio.h defines fileno as a macro although there is a symbol in libc. > > I think that print.cc at least needs to > > > #undef fileno > > > before the usage. Or (::fileno)(f) ? Jakub
[wwwdocs] Document std::print and std::ranges::to for C++23
Pushed to wwwdocs. -- >8 -- --- htdocs/gcc-14/changes.html | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 346785a0..eb14e09d 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gcc-14/changes.html @@ -209,8 +209,14 @@ a work-in-progress. Improved experimental support for C++23, including: +The std::ranges::to function for converting + ranges to containers. + Theheader is supported by default. +std::print and std::println + (requires linking with -lstdc++exp on Windows). + Formatters for std::thread::id and std::stacktrace. @@ -237,12 +243,12 @@ a work-in-progress. std::numeric_limits<_Float64> are now defined for all standard modes, not only for C++23. - Using the std::setfill manipulator with -std::istream is deprecated. - Added missing functions for float and long double to . + Using the std::setfill manipulator with +std::istream is deprecated. + -- 2.43.0
[wwwdocs] Update notes on libstdc++ header dependency changes in GCC 14
Pushed to wwwdocs. -- >8 -- --- htdocs/gcc-14/porting_to.html | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html index dea9ac80..3e4cedc3 100644 --- a/htdocs/gcc-14/porting_to.html +++ b/htdocs/gcc-14/porting_to.html @@ -38,10 +38,14 @@ be included explicitly when compiling with GCC 14:- (for std::copy_n, std::lower_bound, + (for std::copy_n, std::find_if, + std::lower_bound, std::remove, std::reverse, std::sort etc.) + + (for std::int8_t, std::int32_t etc.) + -- 2.43.0
Re: [committed] libstdc++: Implement C++23 header [PR107760]
On Sat, Dec 16, 2023 at 4:44 PM Jakub Jelinek wrote: > On Sat, Dec 16, 2023 at 04:24:13PM -0500, David Edelsohn wrote: > > AIX stdio.h defines fileno as a macro although there is a symbol in libc. > > > > I think that print.cc at least needs to > > > > > > #undef fileno > > > > > > before the usage. > > Or (::fileno)(f) ? > Yes, that also avoids the error. Thanks, David > > Jakub > >
Re: [PATCH] c++/modules: seed namespaces for bindings [PR106363]
On 12/16/23 05:31, Nathaniel Shead wrote:
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636159.html
ok
On Sun, Nov 12, 2023 at 12:59:36PM +1100, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu. I don't have write
access.
-- >8 --
Currently the first depset for an EK_BINDING is not seeded. This breaks
the attached testcase as then the namespace is not considered referenced
yet during streaming, but we've already finished importing.
There doesn't seem to be any particular reason I could find for skipping
the first depset for bindings, and removing the condition doesn't appear
to cause any test failures, so this patch removes that check.
PR c++/106363
gcc/cp/ChangeLog:
* module.cc (module_state::write_cluster): Don't skip first
depset for bindings.
gcc/testsuite/ChangeLog:
* g++.dg/modules/pr106363_a.C: New test.
* g++.dg/modules/pr106363_b.C: New test.
Signed-off-by: Nathaniel Shead
---
gcc/cp/module.cc | 4 +---
gcc/testsuite/g++.dg/modules/pr106363_a.C | 9 +
gcc/testsuite/g++.dg/modules/pr106363_b.C | 10 ++
3 files changed, 20 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/modules/pr106363_a.C
create mode 100644 gcc/testsuite/g++.dg/modules/pr106363_b.C
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index c1c8c226bc1..411a3b9411c 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -14741,9 +14741,7 @@ module_state::write_cluster (elf_out *to, depset
*scc[], unsigned size,
for (unsigned ix = 0; ix != size; ix++)
{
depset *b = scc[ix];
- for (unsigned jx = (b->get_entity_kind () == depset::EK_BINDING
- || b->is_special ()) ? 1 : 0;
- jx != b->deps.length (); jx++)
+ for (unsigned jx = b->is_special (); jx != b->deps.length (); jx++)
{
depset *dep = b->deps[jx];
diff --git a/gcc/testsuite/g++.dg/modules/pr106363_a.C b/gcc/testsuite/g++.dg/modules/pr106363_a.C
new file mode 100644
index 000..c18d2eef1c8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/pr106363_a.C
@@ -0,0 +1,9 @@
+// PR c++/106363
+// { dg-additional-options "-fmodules-ts" }
+// { dg-module-cmi pr106363.a }
+
+export module pr106363.a;
+
+namespace ns {
+ export int x;
+}
diff --git a/gcc/testsuite/g++.dg/modules/pr106363_b.C
b/gcc/testsuite/g++.dg/modules/pr106363_b.C
new file mode 100644
index 000..0508c0d6193
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/pr106363_b.C
@@ -0,0 +1,10 @@
+// PR c++/106363
+// { dg-additional-options "-fmodules-ts" }
+// { dg-module-cmi pr106363.b }
+
+export module pr106363.b;
+import pr106363.a;
+
+namespace ns {
+ export using ns::x;
+}
--
2.42.0
--
Nathan Sidwell
Re: [committed] libstdc++: Implement C++23 header [PR107760]
On Sat, 16 Dec 2023 at 23:06, David Edelsohn wrote: > > On Sat, Dec 16, 2023 at 4:44 PM Jakub Jelinek wrote: >> >> On Sat, Dec 16, 2023 at 04:24:13PM -0500, David Edelsohn wrote: >> > AIX stdio.h defines fileno as a macro although there is a symbol in libc. >> > >> > I think that print.cc at least needs to >> > >> > >> > #undef fileno >> > >> > >> > before the usage. >> >> Or (::fileno)(f) ? > > > Yes, that also avoids the error. Yup, I've just tested it. I'll push that change in the morning. > > Thanks, David > >> >> >> Jakub >>
[committed] libstdc++: Fix bootstrap on AIX due to fileno macro
Tested x86_64-linux (and built on AIX). Pushed to trunk. -- >8 -- On AIX fileno is a function-like macro, so enclose the name in parentheses to ensure we use the real function. libstdc++-v3/ChangeLog: * src/c++23/print.cc (__open_terminal(FILE*)): Avoid fileno macro. --- libstdc++-v3/src/c++23/print.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libstdc++-v3/src/c++23/print.cc b/libstdc++-v3/src/c++23/print.cc index d72ab856017..be9762bbfdc 100644 --- a/libstdc++-v3/src/c++23/print.cc +++ b/libstdc++-v3/src/c++23/print.cc @@ -76,7 +76,7 @@ namespace if (int fd = ::_fileno(f); fd >= 0) return check_for_console((void*)_get_osfhandle(fd)); #elifdef _GLIBCXX_HAVE_UNISTD_H - if (int fd = ::fileno(f); fd >= 0 && ::isatty(fd)) + if (int fd = (::fileno)(f); fd >= 0 && ::isatty(fd)) return f; #endif } -- 2.43.0
Re: [committed] libstdc++: Implement C++23 header [PR107760]
On Sun, 17 Dec 2023 at 00:02, Jonathan Wakely wrote: > > On Sat, 16 Dec 2023 at 23:06, David Edelsohn wrote: > > > > On Sat, Dec 16, 2023 at 4:44 PM Jakub Jelinek wrote: > >> > >> On Sat, Dec 16, 2023 at 04:24:13PM -0500, David Edelsohn wrote: > >> > AIX stdio.h defines fileno as a macro although there is a symbol in libc. > >> > > >> > I think that print.cc at least needs to > >> > > >> > > >> > #undef fileno > >> > > >> > > >> > before the usage. > >> > >> Or (::fileno)(f) ? > > > > > > Yes, that also avoids the error. > > Yup, I've just tested it. I'll push that change in the morning. Actually I just pushed it now. The functions in that file are only actually used on Windows, so if they build on linux and AIX, that's good enough.
Re: [committed] libstdc++: Implement C++23 header [PR107760]
On Sat, Dec 16, 2023 at 7:04 PM Jonathan Wakely wrote: > On Sun, 17 Dec 2023 at 00:02, Jonathan Wakely wrote: > > > > On Sat, 16 Dec 2023 at 23:06, David Edelsohn wrote: > > > > > > On Sat, Dec 16, 2023 at 4:44 PM Jakub Jelinek > wrote: > > >> > > >> On Sat, Dec 16, 2023 at 04:24:13PM -0500, David Edelsohn wrote: > > >> > AIX stdio.h defines fileno as a macro although there is a symbol in > libc. > > >> > > > >> > I think that print.cc at least needs to > > >> > > > >> > > > >> > #undef fileno > > >> > > > >> > > > >> > before the usage. > > >> > > >> Or (::fileno)(f) ? > > > > > > > > > Yes, that also avoids the error. > > > > Yup, I've just tested it. I'll push that change in the morning. > > Actually I just pushed it now. The functions in that file are only > actually used on Windows, so if they build on linux and AIX, that's > good enough. > Thanks. I had tested and was just about to push it myself. Thanks, David
[pushed] doc: Remove references to buildstat.html
After addressing the references to the stale information Thomas pointed
out on our web pages, this addresses our documentation.
(I can't believe we still had a reference to SuSE, more than twenty years
after the name changed to SUSE.)
Gerald
gcc:
PR other/69374
* doc/install.texi (Installing GCC): Remove reference to
buildstat.html.
(Testing): Ditto.
(Final install): Remove section on submitting information for
buildstat.html. Adjust the request for feedback.
---
gcc/doc/install.texi | 53 +---
1 file changed, 1 insertion(+), 52 deletions(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index fffad700af7..5ec81098d47 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -158,10 +158,6 @@ package-specific installation instructions.
We recommend you browse the entire generic installation instructions before
you proceed.
-Lists of successful builds for released versions of GCC are
-available at @uref{https://gcc.gnu.org/buildstat.html}.
-These lists are updated as new information becomes available.
-
The installation procedure itself is broken into five steps.
@ifinfo
@@ -3286,9 +3282,6 @@ Before you install GCC, we encourage you to run the
testsuites and to
compare your results with results from a similar configuration that have
been submitted to the
@uref{https://gcc.gnu.org/ml/gcc-testresults/,,gcc-testresults mailing list}.
-Some of these archived results are linked from the build status lists
-at @uref{https://gcc.gnu.org/buildstat.html}, although not everyone who
-reports a successful build runs the testsuites and submits the results.
This step is optional and may require you to download additional software,
but it can give you confidence in your new GCC installation or point out
problems before you install and start using your new GCC@.
@@ -3593,51 +3586,7 @@ Alternatively, there are prebuilt online versions of the
manuals for
released versions of GCC on
@uref{https://gcc.gnu.org/onlinedocs/,,the GCC web site}.
-If you are bootstrapping a released version of GCC then please
-quickly review the build status page for your release, available from
-@uref{https://gcc.gnu.org/buildstat.html}.
-If your system is not listed for the version of GCC that you built,
-send a note to
-@email{gcc@@gcc.gnu.org} indicating
-that you successfully built and installed GCC@.
-Include the following information:
-
-@itemize @bullet
-@item
-Output from running @file{@var{srcdir}/config.guess}. Do not send
-that file itself, just the one-line output from running it.
-
-@item
-The output of @samp{gcc -v} for your newly installed @command{gcc}.
-This tells us which version of GCC you built and the options you passed to
-configure.
-
-@item
-If the build was for GNU/Linux, also include:
-@itemize @bullet
-@item
-The distribution name and version (e.g., Red Hat 7.1 or Debian 2.2.3);
-this information should be available from @file{/etc/issue}.
-
-@item
-The version of the Linux kernel, available from @samp{uname --version}
-or @samp{uname -a}.
-
-@item
-The version of glibc you used; for RPM-based systems like Red Hat,
-Mandrake, and SuSE type @samp{rpm -q glibc} to get the glibc version,
-and on systems like Debian and Progeny use @samp{dpkg -l libc6}.
-@end itemize
-For other systems, you can include similar information if you think it is
-relevant.
-
-@item
-Any other information that you think would be useful to people building
-GCC on the same configuration. The new entry in the build status list
-will include a link to the archived copy of your message.
-@end itemize
-
-We'd also like to know if the
+If you built GCC yourself we would like to know if the
@ifnothtml
@ref{Specific, host/target specific installation notes}
@end ifnothtml
--
2.43.0
[PATCH] install: Streamline the hppa*-hp-hpux* section
John, Jeff,
I suggest to streamline the hppa*-hp-hpux* installation instructions as
follows. Okay?
In fact in the following sections there is even more, and more specific
material, which would be great could you have a look at and help trim.
Gerald
>From 52149282c3a77ccda6385f06f36323c71b26491a Mon Sep 17 00:00:00 2001
From: Gerald Pfeifer
Date: Sun, 17 Dec 2023 09:33:40 +0800
Subject: [PATCH] install: Streamline the hppa*-hp-hpux* section
gcc:
PR target/69374
* doc/install.texi (Specific) : Remove a note on
GCC 4.3.
Remove details on how the HP assembler, which we document as not
working, breaks.
---
gcc/doc/install.texi | 17 -
1 file changed, 17 deletions(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 5ec81098d47..70d46feabf6 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -4121,8 +4121,6 @@ longer a multiple of 2 bytes.
@end html
@anchor{hppa-hp-hpux}
@heading hppa*-hp-hpux*
-Support for HP-UX version 9 and older was discontinued in GCC 3.4.
-
We require using gas/binutils on all hppa platforms. Version 2.19 or
later is recommended.
@@ -4130,21 +4128,6 @@ It may be helpful to configure GCC with the
@uref{./configure.html#with-gnu-as,,@option{--with-gnu-as}} and
@option{--with-as=@dots{}} options to ensure that GCC can find GAS@.
-The HP assembler should not be used with GCC. It is rarely tested and may
-not work. It shouldn't be used with any languages other than C due to its
-many limitations.
-
-Specifically, @option{-g} does not work (HP-UX uses a peculiar debugging
-format which GCC does not know about). It also inserts timestamps
-into each object file it creates, causing the 3-stage comparison test to
-fail during a bootstrap. You should be able to continue by saying
-@samp{make all-host all-target} after getting the failure from @samp{make}.
-
-Various GCC features are not supported. For example, it does not support weak
-symbols or alias definitions. As a result, explicit template instantiations
-are required when using C++. This makes it difficult if not impossible to
-build many C++ applications.
-
There are two default scheduling models for instructions. These are
PROCESSOR_7100LC and PROCESSOR_8000. They are selected from the pa-risc
architecture specified for the target machine when configuring.
--
2.43.0
Re: [PATCH] install: Streamline the hppa*-hp-hpux* section
Hi Gerald,
I have one comment. The only target currently supported is hppa64-hp-hpux11*.
While gas is required, only the HP ld works.
Otherwise, the change looks fine.
Dave
On 2023-12-16 8:35 p.m., Gerald Pfeifer wrote:
John, Jeff,
I suggest to streamline the hppa*-hp-hpux* installation instructions as
follows. Okay?
In fact in the following sections there is even more, and more specific
material, which would be great could you have a look at and help trim.
Gerald
>From 52149282c3a77ccda6385f06f36323c71b26491a Mon Sep 17 00:00:00 2001
From: Gerald Pfeifer
Date: Sun, 17 Dec 2023 09:33:40 +0800
Subject: [PATCH] install: Streamline the hppa*-hp-hpux* section
gcc:
PR target/69374
* doc/install.texi (Specific) : Remove a note on
GCC 4.3.
Remove details on how the HP assembler, which we document as not
working, breaks.
---
gcc/doc/install.texi | 17 -
1 file changed, 17 deletions(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 5ec81098d47..70d46feabf6 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -4121,8 +4121,6 @@ longer a multiple of 2 bytes.
@end html
@anchor{hppa-hp-hpux}
@heading hppa*-hp-hpux*
-Support for HP-UX version 9 and older was discontinued in GCC 3.4.
-
We require using gas/binutils on all hppa platforms. Version 2.19 or
later is recommended.
@@ -4130,21 +4128,6 @@ It may be helpful to configure GCC with the
@uref{./configure.html#with-gnu-as,,@option{--with-gnu-as}} and
@option{--with-as=@dots{}} options to ensure that GCC can find GAS@.
-The HP assembler should not be used with GCC. It is rarely tested and may
-not work. It shouldn't be used with any languages other than C due to its
-many limitations.
-
-Specifically, @option{-g} does not work (HP-UX uses a peculiar debugging
-format which GCC does not know about). It also inserts timestamps
-into each object file it creates, causing the 3-stage comparison test to
-fail during a bootstrap. You should be able to continue by saying
-@samp{make all-host all-target} after getting the failure from @samp{make}.
-
-Various GCC features are not supported. For example, it does not support weak
-symbols or alias definitions. As a result, explicit template instantiations
-are required when using C++. This makes it difficult if not impossible to
-build many C++ applications.
-
There are two default scheduling models for instructions. These are
PROCESSOR_7100LC and PROCESSOR_8000. They are selected from the pa-risc
architecture specified for the target machine when configuring.
--
John David Anglin dave.ang...@bell.net
Re: [PATCH 2/3] LoongArch: Fix instruction costs [PR112936]
在 2023/12/15 下午3:56, chenglulu 写道: 在 2023/12/14 上午9:16, chenglulu 写道: 在 2023/12/13 下午9:20, Xi Ruoyao 写道: On Wed, 2023-12-13 at 20:22 +0800, chenglulu wrote: 在 2023/12/10 上午1:03, Xi Ruoyao 写道: Replace the instruction costs in loongarch_rtx_cost_data constructor based on micro-benchmark results on LA464 and LA664. This allows optimizations like "x * 17" to alsl, and "x * 68" to alsl and slli. gcc/ChangeLog: PR target/112936 * config/loongarch/loongarch-def.cc (loongarch_rtx_cost_data::loongarch_rtx_cost_data): Update instruction costs per micro-benchmark results. (loongarch_rtx_cost_optimize_size): Set all instruction costs to (COSTS_N_INSNS (1) + 1). * config/loongarch/loongarch.cc (loongarch_rtx_costs): Remove special case for multiplication when optimizing for size. Adjust division cost when TARGET_64BIT && !TARGET_DIV32. Account the extra cost when TARGET_CHECK_ZERO_DIV and optimizing for speed. gcc/testsuite/ChangeLog PR target/112936 * gcc.target/loongarch/mul-const-reduction.c: New test. --- gcc/config/loongarch/loongarch-def.cc | 39 ++- gcc/config/loongarch/loongarch.cc | 22 +-- .../loongarch/mul-const-reduction.c | 11 ++ 3 files changed, 43 insertions(+), 29 deletions(-) create mode 100644 gcc/testsuite/gcc.target/loongarch/mul-const-reduction.c Well, I'm curious about how the value of this cost is obtained. I just make a loop containing 1000 mul.w instructions, then run the loop 100 times and compare the time usage with running another loop containing 1000 addi.w instructions iterated 100 times too. Likewise for other instructions... Ok. I need to do a performance comparison of the spec here. Probably tomorrow the results will be available. Thanks! Sorry, there is a problem with my test environment, so the results may not be available until tomorrow. The SPEC2006 test was without problems, and the 483 had a 2.7 percent performance improvement. Thanks!
RFC -- targets with unsigned bifields
So mcore-elf is the slowest target to test with a simulator. Not because it's simulator is particularly bad, but because some tests timeout as they've gotten into infinite loops. This causes the mcore-elf port to take about 2X longer than most other gdbsim ports. I tracked this down to the port unconditionally adding -funsigned-bitfields to CC1_SPEC. According to the comment it's how the ABI is defined for the mcore targets. It'd be nice to get reasonable results from mcore-elf in a reasonable amount of time. The question is how. I *could* just disable the -funsigned-bitfields within the tester. We certainly have the ability to carry forward patches like this which exist only to help the testing effort. Another approach would be to add an explicit -fsigned-bifields to the arguments for the affected tests. I'd guess it's on the order of around 35 distinct tests that would need to be updated. A third approach would be to grub around and see if there's a way to add a -fsigned-bitfields using dejagnu, perhaps in the baseboards file. Looking for suggestions/recommendations here. Jeff
Re: [PATCH] install: Streamline the hppa*-hp-hpux* section
On Sat, 16 Dec 2023, John David Anglin wrote:
> I have one comment. The only target currently supported is
> hppa64-hp-hpux11*. While gas is required, only the HP ld works.
>
> Otherwise, the change looks fine.
Thank you, Dave!
I updated the patch accordingly, referring to gas (not gas/binutils) and
being explicit around the flavor of ld to use, and pushed it.
Any further comments or suggestions, let me know.
Gerald
commit da70c5b17123b7c81155ef03fb4591b71a681344
Author: Gerald Pfeifer
Date: Sun Dec 17 15:13:39 2023 +0800
install: Streamline the hppa*-hp-hpux* section
gcc:
PR target/69374
* doc/install.texi (Specific) : Remove a note on
GCC 4.3.
Remove details on how the HP assembler, which we document as not
working, breaks.
: Note that only the HP linker is supported.
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 5ec81098d47..84d8834a9b5 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -4121,30 +4121,13 @@ longer a multiple of 2 bytes.
@end html
@anchor{hppa-hp-hpux}
@heading hppa*-hp-hpux*
-Support for HP-UX version 9 and older was discontinued in GCC 3.4.
-
-We require using gas/binutils on all hppa platforms. Version 2.19 or
+We require using gas on all hppa platforms. Version 2.19 or
later is recommended.
It may be helpful to configure GCC with the
@uref{./configure.html#with-gnu-as,,@option{--with-gnu-as}} and
@option{--with-as=@dots{}} options to ensure that GCC can find GAS@.
-The HP assembler should not be used with GCC. It is rarely tested and may
-not work. It shouldn't be used with any languages other than C due to its
-many limitations.
-
-Specifically, @option{-g} does not work (HP-UX uses a peculiar debugging
-format which GCC does not know about). It also inserts timestamps
-into each object file it creates, causing the 3-stage comparison test to
-fail during a bootstrap. You should be able to continue by saying
-@samp{make all-host all-target} after getting the failure from @samp{make}.
-
-Various GCC features are not supported. For example, it does not support weak
-symbols or alias definitions. As a result, explicit template instantiations
-are required when using C++. This makes it difficult if not impossible to
-build many C++ applications.
-
There are two default scheduling models for instructions. These are
PROCESSOR_7100LC and PROCESSOR_8000. They are selected from the pa-risc
architecture specified for the target machine when configuring.
@@ -4269,9 +4252,7 @@ options, including program core dumps. Binutils 2.14
corrects a
problem on the 64-bit port resulting from HP's non-standard use of
the .init and .fini sections for array initializers and finalizers.
-Although the HP and GNU linkers are both supported for the
-@samp{hppa64-hp-hpux11*} target, it is strongly recommended that the
-HP linker be used for link editing on this target.
+Only the HP linker is supported for the @samp{hppa64-hp-hpux11*} target.
At this time, the GNU linker does not support the creation of long
branch stubs. As a result, it cannot successfully link binaries
[PATCH,doc] install: Drop hppa*-hp-hpux10, remove old notes on hppa*-hp-hpux11
Hi Dave,
based on our earlier e-mail, I understand we don't support hppa*-hp-hpux10
any longer, so let's remove them from the installation docs.
On the way remove references to GCC 2.95 and 3.0 from hppa*-hp-hpux11.
Okay?
(I believe it would be great if you could have a look at that part of the
installation docs. I'm pretty confident there is quite a bit more we can
garbage collect or simplify.)
Gerald
gcc:
PR target/69374
* doc/install.texi (Specific) : Remove section.
(Specific) : Remove references to GCC 2.95 and 3.0.
---
gcc/doc/install.texi | 18 --
1 file changed, 18 deletions(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 84d8834a9b5..17cef5a2bae 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -3742,8 +3742,6 @@ information have to.
@item
@uref{#hppa-hp-hpux,,hppa*-hp-hpux*}
@item
-@uref{#hppa-hp-hpux10,,hppa*-hp-hpux10}
-@item
@uref{#hppa-hp-hpux11,,hppa*-hp-hpux11}
@item
@uref{#x-x-linux-gnu,,*-*-linux-gnu}
@@ -4152,27 +4150,11 @@ a list of the predefines used with each standard.
More specific information to @samp{hppa*-hp-hpux*} targets follows.
-@html
-
-@end html
-@anchor{hppa-hp-hpux10}
-@heading hppa*-hp-hpux10
-For hpux10.20, we @emph{highly} recommend you pick up the latest sed patch
-@code{PHCO_19798} from HP@.
-
-The C++ ABI has changed incompatibly in GCC 4.0. COMDAT subspaces are
-used for one-only code and data. This resolves many of the previous
-problems in using C++ on this target. However, the ABI is not compatible
-with the one implemented under HP-UX 11 using secondary definitions.
-
@html
@end html
@anchor{hppa-hp-hpux11}
@heading hppa*-hp-hpux11
-GCC 3.0 and up support HP-UX 11. GCC 2.95.x is not supported and cannot
-be used to compile GCC 3.0 and up.
-
The libffi library haven't been ported to 64-bit HP-UX@ and doesn't build.
Refer to @uref{binaries.html,,binaries} for information about obtaining
--
2.43.0
