[COMMITTED] [PR107130] range-ops: Separate out ffs and popcount optimizations.
__builtin_popcount and __builtin_ffs were sharing the same range-ops
entry, but the nonzero mask optimization is not valid for ffs.
Separate them out into two entries.
PR tree-optimization/107130
gcc/ChangeLog:
* gimple-range-op.cc (class cfn_popcount): Call op_cfn_ffs.
(class cfn_ffs): New.
(gimple_range_op_handler::maybe_builtin_call): Separate out
CASE_CFN_FFS into its own case.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr107130.c: New test.
---
gcc/gimple-range-op.cc | 37 +---
gcc/testsuite/gcc.dg/tree-ssa/pr107130.c | 19
2 files changed, 46 insertions(+), 10 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr107130.c
diff --git a/gcc/gimple-range-op.cc b/gcc/gimple-range-op.cc
index 3a7c9074659..5b71d1cce6d 100644
--- a/gcc/gimple-range-op.cc
+++ b/gcc/gimple-range-op.cc
@@ -387,8 +387,8 @@ cfn_toupper_tolower::fold_range (irange , tree type,
const irange ,
return true;
}
-// Implement range operator for CFN_BUILT_IN_FFS and CFN_BUILT_IN_POPCOUNT.
-class cfn_popcount : public range_operator
+// Implement range operator for CFN_BUILT_IN_FFS.
+class cfn_ffs : public range_operator
{
public:
using range_operator::fold_range;
@@ -397,14 +397,6 @@ public:
{
if (lh.undefined_p ())
return false;
-// Calculating the popcount of a singleton is trivial.
-if (lh.singleton_p ())
- {
- wide_int nz = lh.get_nonzero_bits ();
- wide_int pop = wi::shwi (wi::popcount (nz), TYPE_PRECISION (type));
- r.set (type, pop, pop);
- return true;
- }
// __builtin_ffs* and __builtin_popcount* return [0, prec].
int prec = TYPE_PRECISION (lh.type ());
// If arg is non-zero, then ffs or popcount are non-zero.
@@ -420,6 +412,26 @@ public:
r.set (build_int_cst (type, mini), build_int_cst (type, maxi));
return true;
}
+} op_cfn_ffs;
+
+// Implement range operator for CFN_BUILT_IN_POPCOUNT.
+class cfn_popcount : public cfn_ffs
+{
+public:
+ using range_operator::fold_range;
+ virtual bool fold_range (irange , tree type, const irange ,
+ const irange , relation_kind rel) const
+ {
+// Calculating the popcount of a singleton is trivial.
+if (lh.singleton_p ())
+ {
+ wide_int nz = lh.get_nonzero_bits ();
+ wide_int pop = wi::shwi (wi::popcount (nz), TYPE_PRECISION (type));
+ r.set (type, pop, pop);
+ return true;
+ }
+return cfn_ffs::fold_range (r, type, lh, rh, rel);
+ }
} op_cfn_popcount;
// Implement range operator for CFN_BUILT_IN_CLZ
@@ -734,6 +746,11 @@ gimple_range_op_handler::maybe_builtin_call ()
break;
CASE_CFN_FFS:
+ m_op1 = gimple_call_arg (call, 0);
+ m_int = _cfn_ffs;
+ m_valid = true;
+ break;
+
CASE_CFN_POPCOUNT:
m_op1 = gimple_call_arg (call, 0);
m_int = _cfn_popcount;
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr107130.c
b/gcc/testsuite/gcc.dg/tree-ssa/pr107130.c
new file mode 100644
index 000..11fb816ad71
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr107130.c
@@ -0,0 +1,19 @@
+// { dg-do compile }
+// { dg-options "-Os -fno-tree-ccp -fno-tree-forwprop -fno-tree-fre
-fdump-tree-vrp1" }
+
+static inline int
+foo (int i)
+{
+ return __builtin_ffsl (i);
+}
+
+int
+main (void)
+{
+ int x = foo (41);
+ if (x != 1)
+__builtin_abort ();
+ return 0;
+}
+
+// { dg-final { scan-tree-dump-not "builtin_abort" "vrp1" } }
--
2.37.1
Re: [PATCH RFC] c++: fix broken conversion in coroutines
On 9/30/22 18:50, Iain Sandoe wrote: Hi Jason, On 30 Sep 2022, at 23:06, Jason Merrill wrote: You can't use CONVERT_EXPR to convert between two class types, and it was breaking copy elision. Unfortunately, this patch breaks symmetric-transfer-00-basic.C, where susp_type is Loopy::handle_type. How is this supposed to work? We are trying to save a type-erased handle (which the symmetric transfer makes and indirect call through, nothing else). The problem is you're treating one class directly as another class here, without the indirection involved in usual type-erasure idioms. It does seem that the gimplifier handles this fine, but it doesn't correspond to anything in the language and much of the front end assumes that CONVERT_EXPR is only used for scalars. VIEW_CONVERT_EXPR would better express that we're not doing anything to the value, just cheating the type system. That's still dodgy from a language perspective, but probably safe enough in this case. Note that I was wrong to mention copy elision above; it's irrelevant to codegen here since the handle type returns in a register. so, I suppose the equivalent could be: conthand = coroutine_handle::from_address (suspend.address()) That sounds more correct, yes. Jason
[PATCH] libstdc++: Implement ranges::join_with_view from P2441R2
Tested on x86_64-pc-linux-gnu, does this look OK for trunk? FWIW using
variant<_PatternIter, _InnerIter> in the implementation means we need to
include from , which increases the preprocessed size
of by 3% (51.5k vs 53k). I suppose that's an acceptable cost?
libstdc++-v3/ChangeLog:
* include/std/ranges: Include .
(__detail::__compatible_joinable_ranges): Define.
(__detail::__bidirectional_common): Define.
(join_with_view): Define.
(join_with_view::_Iterator): Define.
(join_with_view::_Sentinel): Define.
(views::__detail::__can_join_with_view): Define.
(views::_JoinWith, views::join_with): Define.
* testsuite/std/ranges/adaptors/join_with/1.cc: New test.
---
libstdc++-v3/include/std/ranges | 458 ++
.../std/ranges/adaptors/join_with/1.cc| 80 +++
2 files changed, 538 insertions(+)
create mode 100644 libstdc++-v3/testsuite/std/ranges/adaptors/join_with/1.cc
diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index c2eacdebe28..50198865b18 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -44,6 +44,9 @@
#include
#include
#include
+#if __cplusplus > 202002L
+#include
+#endif
#include
#include
@@ -6873,6 +6876,461 @@ namespace views::__adaptor
inline constexpr _ChunkBy chunk_by;
}
+
+ namespace __detail
+ {
+template
+ concept __compatible_joinable_ranges
+ = common_with, range_value_t<_Pattern>>
+ && common_reference_with,
+ range_reference_t<_Pattern>>
+ && common_reference_with,
+ range_rvalue_reference_t<_Pattern>>;
+
+template
+ concept __bidirectional_common = bidirectional_range<_Range> &&
common_range<_Range>;
+ }
+
+ template
+requires view<_Vp> && view<_Pattern>
+ && input_range>
+ && __detail::__compatible_joinable_ranges,
_Pattern>
+ class join_with_view : public view_interface>
+ {
+using _InnerRange = range_reference_t<_Vp>;
+
+_Vp _M_base = _Vp();
+__detail::__non_propagating_cache> _M_inner;
+_Pattern _M_pattern = _Pattern();
+
+template using _Base = __detail::__maybe_const_t<_Const, _Vp>;
+template using _InnerBase = range_reference_t<_Base<_Const>>;
+template using _PatternBase =
__detail::__maybe_const_t<_Const, _Pattern>;
+
+template using _OuterIter = iterator_t<_Base<_Const>>;
+template using _InnerIter = iterator_t<_InnerBase<_Const>>;
+template using _PatternIter =
iterator_t<_PatternBase<_Const>>;
+
+template
+ static constexpr bool _S_ref_is_glvalue =
is_reference_v<_InnerBase<_Const>>;
+
+template
+struct __iter_cat
+{ };
+
+template
+ requires _S_ref_is_glvalue<_Const>
+ && forward_range<_Base<_Const>>
+ && forward_range<_InnerBase<_Const>>
+struct __iter_cat<_Const>
+{
+ private:
+ static auto
+ _S_iter_cat()
+ {
+ using _OuterIter = join_with_view::_OuterIter<_Const>;
+ using _InnerIter = join_with_view::_InnerIter<_Const>;
+ using _PatternIter = join_with_view::_PatternIter<_Const>;
+ using _OuterCat = typename
iterator_traits<_OuterIter>::iterator_category;
+ using _InnerCat = typename
iterator_traits<_InnerIter>::iterator_category;
+ using _PatternCat = typename
iterator_traits<_PatternIter>::iterator_category;
+ if constexpr
(!is_lvalue_reference_v,
+
iter_reference_t<_PatternIter>>>)
+ return input_iterator_tag{};
+ else if constexpr (derived_from<_OuterCat, bidirectional_iterator_tag>
+&& derived_from<_InnerCat,
bidirectional_iterator_tag>
+&& derived_from<_PatternCat,
bidirectional_iterator_tag>
+&& common_range<_InnerBase<_Const>>
+&& common_range<_PatternBase<_Const>>)
+ return bidirectional_iterator_tag{};
+ else if constexpr (derived_from<_OuterCat, forward_iterator_tag>
+&& derived_from<_InnerCat, forward_iterator_tag>
+&& derived_from<_PatternCat, forward_iterator_tag>)
+ return forward_iterator_tag{};
+ else
+ return input_iterator_tag{};
+ }
+ public:
+ using iterator_category = decltype(_S_iter_cat());
+};
+
+template struct _Iterator;
+template struct _Sentinel;
+
+ public:
+join_with_view() requires (default_initializable<_Vp>
+ && default_initializable<_Pattern>)
+ = default;
+
+constexpr
+join_with_view(_Vp __base, _Pattern __pattern)
+: _M_base(std::move(__base)), _M_pattern(std::move(__pattern))
+{ }
+
+template
+ requires constructible_from<_Vp, views::all_t<_Range>>
+
Re: [PATCH] diagnostics: Add test for fixed _Pragma location issue [PR91669]
On 10/3/22 16:32, Lewis Hyatt via Gcc-patches wrote: This PR related to _Pragma locations and diagnostic pragmas was fixed by a combination of r10-325 and r13-1596. Add missing test coverage. gcc/testsuite/ChangeLog: PR c/91669 * c-c++-common/pr91669.c: New test. OK. jeff
[PATCH] c++: install cp-trait.def as part of plugin headers [PR107136]
This is apparently needed since we include cp-trait.def from cp-tree.h (in order to define the cp_trait_kind enum), as with operators.def. Tested on x86_64-pc-linux-gnu by doing make install and verifying cp-trait.def appears in $prefix/lib/gcc/x86_64-pc-linux-gnu/13.0.0/plugin/include/cp/ Does this look OK for trunk? PR c++/107136 gcc/cp/ChangeLog: * Make-lang.in (CP_PLUGIN_HEADERS): Add cp-trait.def. --- gcc/cp/Make-lang.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in index 38d8eeed1f0..aa84d6827be 100644 --- a/gcc/cp/Make-lang.in +++ b/gcc/cp/Make-lang.in @@ -39,7 +39,7 @@ CXX_INSTALL_NAME := $(shell echo c++|sed '$(program_transform_name)') GXX_INSTALL_NAME := $(shell echo g++|sed '$(program_transform_name)') CXX_TARGET_INSTALL_NAME := $(target_noncanonical)-$(shell echo c++|sed '$(program_transform_name)') GXX_TARGET_INSTALL_NAME := $(target_noncanonical)-$(shell echo g++|sed '$(program_transform_name)') -CP_PLUGIN_HEADERS := cp-tree.h cxx-pretty-print.h name-lookup.h type-utils.h operators.def +CP_PLUGIN_HEADERS := cp-tree.h cxx-pretty-print.h name-lookup.h type-utils.h operators.def cp-trait.def # # Define the names for selecting c++ in LANGUAGES. -- 2.38.0.rc2
[PATCH] diagnostics: Add test for fixed _Pragma location issue [PR91669]
This PR related to _Pragma locations and diagnostic pragmas was fixed by a
combination of r10-325 and r13-1596. Add missing test coverage.
gcc/testsuite/ChangeLog:
PR c/91669
* c-c++-common/pr91669.c: New test.
---
Notes:
Hello-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91669#c4
The above PR was already fixed, but I'd like to add missing test coverage
before closing it. Does this look OK please? Thanks!
-Lewis
gcc/testsuite/c-c++-common/pr91669.c | 28
1 file changed, 28 insertions(+)
create mode 100644 gcc/testsuite/c-c++-common/pr91669.c
diff --git a/gcc/testsuite/c-c++-common/pr91669.c
b/gcc/testsuite/c-c++-common/pr91669.c
new file mode 100644
index 000..1070751ed2e
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/pr91669.c
@@ -0,0 +1,28 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-Wreturn-type" } */
+
+/* The location of the right brace within the macro expansion can be an adhoc
+ location, because the frontend attached custom data to it. In order for the
+ diagnostic pragma to correctly understand that the diagnostic pop occurs
+ after the function and not before, linemap_location_before_p needs to handle
+ adhoc locations within a macro map, which was broken until fixed by r10-325.
+ Verify that we get it right, both when the brace is a macro token and when
it
+ is part of the macro expansion. */
+
+#define ENDFUNC1 \
+ _Pragma("GCC diagnostic push") \
+ _Pragma("GCC diagnostic ignored \"-Wreturn-type\"") \
+ } /* { dg-bogus {-Wreturn-type} } */ \
+ _Pragma("GCC diagnostic pop")
+
+int f1 () {
+ENDFUNC1 /* { dg-bogus {in expansion of macro 'ENDFUNC1' } } */
+
+#define ENDFUNC2(term) \
+ _Pragma("GCC diagnostic push") \
+ _Pragma("GCC diagnostic ignored \"-Wreturn-type\"") \
+ term /* { dg-bogus {in definition of macro 'ENDFUNC2'} } */ \
+ _Pragma("GCC diagnostic pop")
+
+int f2 () {
+ENDFUNC2(}) /* { dg-bogus {-Wreturn-type} } */
[PATCH] aarch64: fix off-by-one in reading cpuinfo
Fixes: 341573406b39 Don't subtract one from the result of strnlen() when trying to point to the first character after the current string. This issue would cause individual characters (where the 128 byte buffers are stitched together) to be lost. gcc/ChangeLog: * config/aarch64/driver-aarch64.cc (readline): Fix off-by-one. Signed-off-by: Philipp Tomsich --- gcc/config/aarch64/driver-aarch64.cc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gcc/config/aarch64/driver-aarch64.cc b/gcc/config/aarch64/driver-aarch64.cc index 52ff537908e..48250e68034 100644 --- a/gcc/config/aarch64/driver-aarch64.cc +++ b/gcc/config/aarch64/driver-aarch64.cc @@ -203,9 +203,9 @@ readline (FILE *f) return std::string (); /* If we're not at the end of the line then override the \0 added by fgets. */ - last = strnlen (buf, size) - 1; + last = strnlen (buf, size); } - while (!feof (f) && buf[last] != '\n'); + while (!feof (f) && (last > 0 && buf[last - 1] != '\n')); std::string result (buf); free (buf); -- 2.34.1
[PATCH] aarch64: update Ampere-1 core definition
This brings the extensions detected by -mcpu=native on Ampere-1 systems
in sync with the defaults generated for -mcpu=ampere1.
Note that some kernel versions may misreport the presence of PAUTH and
PREDRES (i.e., -mcpu=native will add 'nopauth' and 'nopredres').
gcc/ChangeLog:
* config/aarch64/aarch64-cores.def (AARCH64_CORE): Update
Ampere-1 core entry.
Signed-off-by: Philipp Tomsich
---
Ok for backport?
gcc/config/aarch64/aarch64-cores.def | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/aarch64/aarch64-cores.def
b/gcc/config/aarch64/aarch64-cores.def
index 60299160bb6..9090f80b4b7 100644
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -69,7 +69,7 @@ AARCH64_CORE("thunderxt81", thunderxt81, thunderx, V8A,
(CRC, CRYPTO), thu
AARCH64_CORE("thunderxt83", thunderxt83, thunderx, V8A, (CRC, CRYPTO),
thunderx, 0x43, 0x0a3, -1)
/* Ampere Computing ('\xC0') cores. */
-AARCH64_CORE("ampere1", ampere1, cortexa57, V8_6A, (), ampere1, 0xC0, 0xac3,
-1)
+AARCH64_CORE("ampere1", ampere1, cortexa57, V8_6A, (F16, RCPC, RNG, AES,
SHA3), ampere1, 0xC0, 0xac3, -1)
/* Do not swap around "emag" and "xgene1",
this order is required to handle variant correctly. */
AARCH64_CORE("emag",emag, xgene1,V8A, (CRC, CRYPTO), emag,
0x50, 0x000, 3)
--
2.34.1
Re: [PATCH] rs6000: Rework option -mpowerpc64 handling [PR106680]
On Fri, Sep 30, 2022 at 08:15:37PM +0800, Kewen.Lin wrote: > on 2022/9/30 01:11, Segher Boessenkool wrote: > >> +#ifdef OS_MISSING_POWERPC64 > >> + else if (OS_MISSING_POWERPC64) > >> + /* It's unexpected to have OPTION_MASK_POWERPC64 on for OSes which > >> + miss powerpc64 support, so disable it. */ > >> + rs6000_isa_flags &= ~OPTION_MASK_POWERPC64; > >> +#endif > > > > All silent stuff is always bad. > > OK, with more testings for replacing warning instead of silently disablement > I noticed that some disablement is needed, one typical case is -m32 > compilation > on ppc64, we have OPTION_MASK_POWERPC64 on from TARGET_DEFAULT which is used > for initialization (It makes sense to have it on in TARGET_DEFAULT because > of it's 64 bit cpu). And -m32 compilation matches OS_MISSING_POWERPC64 > (!TARGET_64BIT), so it's the case that we have an implicit > OPTION_MASK_POWERPC64 > on and OS_MISSING_POWERPC64 holds, but it's unexpected not to disable it but > warn it. Right. If If mpowerpc64 is enabled while OS_MISSING_POWERPC64, warn for that; and if mpowerpc64 was only implicit, disable it as well (and say we did!) Segher
[committed] libstdc++: Update status docs for compare_exchange padding bits
Pushed to trunk. -- >8 -- libstdc++-v3/ChangeLog: * doc/xml/manual/status_cxx2020.xml: Update C++20 status. * doc/html/manual/status.html: Regenerate. --- libstdc++-v3/doc/html/manual/status.html | 9 ++--- libstdc++-v3/doc/xml/manual/status_cxx2020.xml | 15 --- 2 files changed, 18 insertions(+), 6 deletions(-) diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml index d979db06b11..44dee44f385 100644 --- a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml +++ b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml @@ -94,7 +94,7 @@ or any notes about the implementation. -P0595R2 std::is_constant_evaluated() +std::is_constant_evaluated() http://www.w3.org/1999/xlink; xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0595r2.html;> P0595R2 @@ -384,13 +384,12 @@ or any notes about the implementation. - The Curious Case of Padding Bits, Featuring Atomic Compare-and-Exchange http://www.w3.org/1999/xlink; xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0528r3.html;> P0528R3 - + 13.1 @@ -941,6 +940,16 @@ or any notes about the implementation. __cpp_lib_smart_ptr_for_overwrite = 201811L + +Rename "default_init" Functions + +http://www.w3.org/1999/xlink; xlink:href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1973r1.pdf;> +P1973R1 + + 12.1 + __cpp_lib_smart_ptr_for_overwrite = 201811L + + Make stateful allocator propagation more consistent for operator+(basic_string) -- 2.37.3
Re: PING [PATCH] gcc/config/t-i386: add build dependencies on i386-builtin-types.inc
On Mon, Oct 3, 2022 at 9:05 AM Sergei Trofimovich via Gcc-patches wrote: > > On Thu, 22 Sep 2022 22:07:52 +0100 > Sergei Trofimovich wrote: > > > On Fri, 16 Sept 2022 at 19:49, Sergei Trofimovich wrote: > > > > > > From: Sergei Trofimovich > > > > > > i386-builtin-types.inc is included indirectly via i386-builtins.h > > > into 4 files: i386.cc i386-builtins.cc i386-expand.cc i386-features.cc > > > > > > Only i386.cc dependency was present in gcc/config/t-i386 makefile. > > > > > > As a result parallel builds occasionally fail as: > > > > > > g++ ... -o i386-builtins.o ... > > > ../../gcc-13-20220911/gcc/config/i386/i386-builtins.cc > > > In file included from > > > ../../gcc-13-20220911/gcc/config/i386/i386-builtins.cc:92: > > > ../../gcc-13-20220911/gcc/config/i386/i386-builtins.h:25:10: > > > fatal error: i386-builtin-types.inc: No such file or directory > > >25 | #include "i386-builtin-types.inc" > > > | ^~~~ > > > compilation terminated. > > > make[3]: *** [../../gcc-13-20220911/gcc/config/i386/t-i386:54: > > > i386-builtins.o] > > > Error 1 shuffle=1663349189 > > > > > > gcc/ > > > * config/i386/t-i386: Add build-time dependencies against > > > i386-builtin-types.inc to i386-builtins.o, i386-expand.o, > > > i386-features.o. OK. Thanks, Uros. > > > --- > > > gcc/config/i386/t-i386 | 5 + > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/gcc/config/i386/t-i386 b/gcc/config/i386/t-i386 > > > index 4e2a0efc615..ffdbbdfe8ce 100644 > > > --- a/gcc/config/i386/t-i386 > > > +++ b/gcc/config/i386/t-i386 > > > @@ -62,7 +62,12 @@ i386-features.o: $(srcdir)/config/i386/i386-features.cc > > > $(COMPILE) $< > > > $(POSTCOMPILE) > > > > > > +# i386-builtin-types.inc is included into i386-builtins.h. > > > +# Below are direct users of i386-builtins.h: > > > i386.o: i386-builtin-types.inc > > > +i386-builtins.o: i386-builtin-types.inc > > > +i386-expand.o: i386-builtin-types.inc > > > +i386-features.o: i386-builtin-types.inc > > > > > > i386-builtin-types.inc: s-i386-bt ; @true > > > s-i386-bt: $(srcdir)/config/i386/i386-builtin-types.awk \ > > > -- > > > 2.37.2 > > > > > > > Is it a reasonable approach? Maybe gcc has an equivalent of automake's > > BUILT_SOURCES to avoid explicit tracking of such dependencies? > > > > -- > > Sergei > > > -- > > Sergei
[PATCH] elf: ELF toolchain --without-{headers, newlib} should provide stdint.h
stdint.h is considered a freestanding headers by C, and a valid stdint.h
is required for certain parts of libstdc++' configuration, so we should
simply provide one when we have no other way (i.e. newlib or
user-specified sysroot) of getting one.
gcc/ChangeLog:
* config.gcc: --target=*-elf --without-{newlib,headers} should
provide stdint.h.
---
Evening,
Currently, freestanding *-elf toolchains without newlib will always produce
invalid stdint.h files, tripping up libstdc++ configure scripts (see PR104605).
This patch should make no-newlib no-headers always provide stdint.h.
Thanks.
gcc/config.gcc | 5 +
1 file changed, 5 insertions(+)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 555f257c2e7..6633910d2b7 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1079,6 +1079,11 @@ case ${target} in
# Assume that newlib is being used and so __cxa_atexit is provided.
default_use_cxa_atexit=yes
use_gcc_stdint=wrap
+
+ case "${with_newlib}-${with_headers}" in
+ no-no) use_gcc_stdint=provide ;;
+ *) ;;
+ esac
;;
esac
--
2.37.3
[PATCH] c++, c, v2: Implement C++23 P1774R8 - Portable assumptions [PR106654]
On Fri, Sep 30, 2022 at 04:39:25PM -0400, Jason Merrill wrote:
> > * fold-const.h (simple_operand_p_2): Declare.
>
> This needs a better name if it's going to be a public interface.
>
> The usage also needs rationale for why this is the right predicate for
> assume, rather than just no-side-effects. Surely the latter is right for
> constexpr, at least?
You're right that for the constexpr case !TREE_SIDE_EFFECTS is all we need,
including const/pure function calls.
For the gimplification case, TREE_SIDE_EFFECTS isn't good enough.
TREE_SIDE_EFFECTS is documented as:
/* In any expression, decl, or constant, nonzero means it has side effects or
reevaluation of the whole expression could produce a different value.
This is set if any subexpression is a function call, a side effect or a
reference to a volatile variable. In a ..._DECL, this is set only if the
declaration said `volatile'. This will never be set for a constant. */
so !TREE_SIDE_EFFECTS expressions can be safely evaluated multiple times
instead of just once.
But we need more than that, we need basically the same requirements as
when trying to hoist an expression from inside of if (0) block to before
that block (or just any conditional guarded block where we don't know the
condition value). And so we need to ensure that we don't get any traps,
raise exceptions etc. or do anything else with observable effects.
And on top of that, we'd better limit it to something small, because
if we have a condition with hundreds of non-side-effect operations in it,
it will affect inlining limits and we'd need to trust that DCE will clean up
everything as unused.
>
> Let's factor this out of here and cp_parser_constant_expression rather than
> duplicate it.
Done.
> > + for (; attr; attr = lookup_attribute ("gnu", "assume", TREE_CHAIN
> > (attr)))
> > +{
> > + tree args = TREE_VALUE (attr);
> > + int nargs = list_length (args);
> > + if (nargs != 1)
> > + {
>
> Need auto_diagnostic_group.
Added (and while playing with finish_static_assert noticed that
it doesn't use that either).
Now that I look, attribs.cc (decl_attributes) doesn't do that either,
will test a separate patch for that.
> > + bool in_assume;
>
> I think it would be better to reject jumps into statement-expressions like
> the C front-end.
Already committed, thanks for the review.
> > + if (!*non_constant_p && !ctx->quiet)
> > + error_at (EXPR_LOCATION (t),
> > + "failed % attribute assumption");
>
> Maybe share some code for explaining the failure with finish_static_assert?
I couldn't share the find_failing_clause stuff (but fortunately it is
short), because it should call different function to evaluate it, but I can
share the reporting.
Here is a lightly tested updated patch which I'll bootstrap/regtest tonight.
2022-10-03 Jakub Jelinek
PR c++/106654
gcc/
* internal-fn.def (ASSUME): New internal function.
* internal-fn.h (expand_ASSUME): Declare.
* internal-fn.cc (expand_ASSUME): Define.
* gimplify.cc (gimplify_call_expr): Gimplify IFN_ASSUME.
* fold-const.h (simple_condition_p): Declare.
* fold-const.cc (simple_operand_p_2): Rename to ...
(simple_condition_p): ... this. Remove forward declaration.
No longer static. Adjust function comment and fix a typo in it.
Adjust recursive call.
(simple_operand_p): Adjust function comment.
(fold_truth_andor): Adjust simple_operand_p_2 callers to call
simple_condition_p.
* attribs.h (remove_attribute): Declare overload with additional
attr_ns argument.
(private_lookup_attribute): Declare overload with additional
attr_ns and attr_ns_len arguments.
(lookup_attribute): New overload with additional attr_ns argument.
* attribs.cc (remove_attribute): New overload with additional
attr_ns argument.
(private_lookup_attribute): New overload with additional
attr_ns and attr_ns_len arguments.
* doc/extend.texi: Document assume attribute. Move fallthrough
attribute example to its section.
gcc/c-family/
* c-attribs.cc (handle_assume_attribute): New function.
(c_common_attribute_table): Add entry for assume attribute.
* c-lex.cc (c_common_has_attribute): Handle
__have_cpp_attribute (assume).
gcc/c/
* c-parser.cc (handle_assume_attribute): New function.
(c_parser_declaration_or_fndef): Handle assume attribute.
(c_parser_attribute_arguments): Add assume_attr argument,
if true, parse first argument as conditional expression.
(c_parser_gnu_attribute, c_parser_std_attribute): Adjust
c_parser_attribute_arguments callers.
(c_parser_statement_after_labels) : Handle
assume attribute.
gcc/cp/
* cp-tree.h (process_stmt_assume_attribute): Implement C++23
P1774R8 - Portable assumptions.
Re: [PATCH] Fix gdb printers for std::string
On Mon, 3 Oct 2022 at 17:51, François Dumont wrote:
>
> On 01/10/22 17:30, Jonathan Wakely wrote:
> > On Sat, 1 Oct 2022 at 11:43, François Dumont wrote:
> >> On 01/10/22 12:06, Jonathan Wakely wrote:
> >>> On Sat, 1 Oct 2022 at 08:20, François Dumont via Libstdc++
> >>> wrote:
> I had forgotten to re-run tests after I removed the #define
> _GLIBCXX_USE_CXX11_ABI 0.
>
> The comment was misleading, it could also impact output of std::list.
>
> I am also restoring the correct std::string alias for
> std::__cxx11::basic_string, even if with my workaround it doesn't really
> matter as the one for std::basic_string will be used.
>
> I also restored the printer for std::__cxx11::string typedef. Is it
> intentional to keep this ?
> >>> Yes, I kept that intentionally. There can be programs where some
> >>> objects still use that typedef, if those objects were compiled with
> >>> GCC 8.x or older.
> >>>
> libstdc++: Fix gdb pretty printers when dealing with std::string
>
> Since revision 33b43b0d8cd2de722d177ef823930500948a7487
> std::string
> and other
> similar typedef are ambiguous from a gdb point of view because it
> matches both
> std::basic_string and std::__cxx11::basic_string
> symbols. For those
> typedef add a workaround to accept the substitution as long as the
> same regardless
> of __cxx11 namespace.
> >>> Thanks for figuring out what was going wrong here, and how to fix it.
> >>>
> >>>
> Also avoid to register printers for types in std::__cxx11::__8::
> namespace, there is
> no such symbols.
>
> libstdc++-v3/ChangeLog:
>
> * libstdc++-v3/python/libstdcxx/v6/printers.py
> (Printer.add_version): Do not add
> version namespace for __cxx11 symbols.
> (add_one_template_type_printer): Likewise.
> (add_one_type_printer): Likewise.
> (FilteringTypePrinter._recognizer.recognize): Add a
> workaround for std::string & al
> ambiguous typedef matching both std:: and std::__cxx11::
> symbols.
> (register_type_printers): Refine type registration to
> limit
> false positive in
> FilteringTypePrinter._recognize.recognize requiring to
> look
> for the type in gdb.
> >>> I don't really like this part of the change though:
> >> I'll check what you are proposing but I don't think it is necessary to
> >> fix the problem.
> > Most of my patch is an alternative way to make the filter match on
> > "basic_string > the ambiguous string typedefs, by using match.split('::')[-1] to get
> > the class template name without namespaces and then compare that to
> > "basic_string".
> >
> >> I did this on my path to find out what was going wrong. Once I
> >> understood it I consider that it was just a good change to keep. If you
> >> think otherwise I can revert this part.
> > Yeah it looks like it's just an optimization to fail faster without
> > having to do gdb.lookup_type.
> >
> > Please revert the changes to register_type_printers then, and we can
> > consider that part later if we want to revisit it. I'm not opposed to
> > making that fail-fast optimization, as long as we keep the property
> > that FilteringTypePrinter.match is the class template name. Maybe it
> > should be renamed to something other than "match" to make that clear.
>
> Or change the doc ? For my info, why is it so important to comply to the
> current doc ? Is it extracted from some gdb doc ?
The 'match' argument is the name of a class template to match. If we
want to match a class template with specific template arguments, I
would prefer to pass in the name of the class template and the names
of the template argument types, not just a string. We can do more with
individually named types, rather than just munging it all into a
single string and only being able to do string comparisons.
>
> Now that the problem is fixed it is less important but I never managed
> to find any doc about this gdb feature that we are relying on.
It's this one:
https://sourceware.org/gdb/onlinedocs/gdb/Type-Printing-API.html
>
>
> >
> > The rest of the patch is OK for trunk, thanks.
> >
> >> I also noted that gdb consider the filters as a filo list, not fifo. And
> >> I think that the 1st filters registered are the most extensively used. I
> >> can propose to invert all the registration if you think it worth it.
> > I've not noticed any performance problems with the printers, but I
> > have wondered how many printers is too many. That's an interesting
> > observation about the order they're checked. I'll talk to some of the
> > GDB devs to find out if they think it's something we should worry
> > about. Let's not try make premature optimizations until we know if it
> > matters.
>
Re: [PATCH] Fix gdb printers for std::string
On 01/10/22 17:30, Jonathan Wakely wrote: On Sat, 1 Oct 2022 at 11:43, François Dumont wrote: On 01/10/22 12:06, Jonathan Wakely wrote: On Sat, 1 Oct 2022 at 08:20, François Dumont via Libstdc++ wrote: I had forgotten to re-run tests after I removed the #define _GLIBCXX_USE_CXX11_ABI 0. The comment was misleading, it could also impact output of std::list. I am also restoring the correct std::string alias for std::__cxx11::basic_string, even if with my workaround it doesn't really matter as the one for std::basic_string will be used. I also restored the printer for std::__cxx11::string typedef. Is it intentional to keep this ? Yes, I kept that intentionally. There can be programs where some objects still use that typedef, if those objects were compiled with GCC 8.x or older. libstdc++: Fix gdb pretty printers when dealing with std::string Since revision 33b43b0d8cd2de722d177ef823930500948a7487 std::string and other similar typedef are ambiguous from a gdb point of view because it matches both std::basic_string and std::__cxx11::basic_string symbols. For those typedef add a workaround to accept the substitution as long as the same regardless of __cxx11 namespace. Thanks for figuring out what was going wrong here, and how to fix it. Also avoid to register printers for types in std::__cxx11::__8:: namespace, there is no such symbols. libstdc++-v3/ChangeLog: * libstdc++-v3/python/libstdcxx/v6/printers.py (Printer.add_version): Do not add version namespace for __cxx11 symbols. (add_one_template_type_printer): Likewise. (add_one_type_printer): Likewise. (FilteringTypePrinter._recognizer.recognize): Add a workaround for std::string & al ambiguous typedef matching both std:: and std::__cxx11:: symbols. (register_type_printers): Refine type registration to limit false positive in FilteringTypePrinter._recognize.recognize requiring to look for the type in gdb. I don't really like this part of the change though: I'll check what you are proposing but I don't think it is necessary to fix the problem. Most of my patch is an alternative way to make the filter match on "basic_string I did this on my path to find out what was going wrong. Once I understood it I consider that it was just a good change to keep. If you think otherwise I can revert this part. Yeah it looks like it's just an optimization to fail faster without having to do gdb.lookup_type. Please revert the changes to register_type_printers then, and we can consider that part later if we want to revisit it. I'm not opposed to making that fail-fast optimization, as long as we keep the property that FilteringTypePrinter.match is the class template name. Maybe it should be renamed to something other than "match" to make that clear. Or change the doc ? For my info, why is it so important to comply to the current doc ? Is it extracted from some gdb doc ? Now that the problem is fixed it is less important but I never managed to find any doc about this gdb feature that we are relying on. The rest of the patch is OK for trunk, thanks. I also noted that gdb consider the filters as a filo list, not fifo. And I think that the 1st filters registered are the most extensively used. I can propose to invert all the registration if you think it worth it. I've not noticed any performance problems with the printers, but I have wondered how many printers is too many. That's an interesting observation about the order they're checked. I'll talk to some of the GDB devs to find out if they think it's something we should worry about. Let's not try make premature optimizations until we know if it matters. Yes, but with the 1st registration and so the last evaluation being 'std::string' it sounds more like a premature lowering ;-)
Re: [patch] Fix thinko in powerpc default specs for -mabi
Hi!
On Fri, Sep 23, 2022 at 11:49:24AM -0400, Olivier Hainque wrote:
> For a powerpc compiler configured with --with-abi=elfv2, an explicit
> -mabi option other than elfv1 fails to override the default.
>
> For example, after
>
> [...]/configure --enable-languages=c --target=powerpc-elf --with-abi=elfv2
> make all-gcc
>
> This command:
>
> ./gcc/xgcc -B./gcc/ t.c -mabi=ieeelongdouble -v
>
> issues:
>
> ./gcc/cc1 [...] t.c -mabi=ieeelongdouble -mabi=elfv2
>
> elfv2 overrides the user request here, which I think
> is not as intended.
-mabi= does two separate things, unfortunately.
First, you can use it to set the base ABI: elfv1, elfv2. But you can
also use it to set ABI variants, ABI options: -mabi={no-,}altivec,
-mabi={ieee,ibm}longdouble, -mabi=vec-{extabi,default}. Things in that
latter category are completely orthogonal to anything else (except that
some only make sense together with some base ABIs).
Base ABI is not selectable for most, it is implied by your target
triple. -mabi=elfv[12] only makes sense for targets that have either of
the two by default.
> This is controlled by OPTION_DEFAULT_SPECS, where we have
>
> {"abi", "%{!mabi=elfv*:-mabi=%(VALUE)}" },
>
> >From https://gcc.gnu.org/pipermail/gcc-patches/2013-November/375042.html
> I don't see an explicit reason to trigger only on elfv* . It just looks
> like an oversight with a focus on elfv1 vs elfv2 at the time.
>
> The attached patch is a proposal to correct this, simply removing the
> "elfv" prefix from the spec and adding the corresponding description
> to the block comment just above.
>
> We have been using this for about a year now in gcc-11 based toolchains.
> This helps our dejagnu testsuite runs for VxWorks on powerpc and
> hasn't produced any ill side effect to date.
So what exactly is this meant to do?
> 2022-09-14 Olivier Hainque
>
> * config/rs6000/option-defaults.h (OPTION_DEFAULT_SPECS):
> Have any -mabi, not only -mabi=elfv*, override the --with-abi
> configuration default.
> /* Support for a compile-time default CPU, et cetera. The rules are:
> + --with-abi is ignored if -mabi is specified.
> --with-cpu is ignored if -mcpu is specified; likewise --with-cpu-32
> and --with-cpu-64.
> --with-tune is ignored if -mtune or -mcpu is specified; likewise
> @@ -54,7 +55,7 @@
> --with-float is ignored if -mhard-float or -msoft-float are
> specified. */
> #define OPTION_DEFAULT_SPECS \
> - {"abi", "%{!mabi=elfv*:-mabi=%(VALUE)}" }, \
> + {"abi", "%{!mabi=*:-mabi=%(VALUE)}" }, \
>{"tune", "%{!mtune=*:%{!mcpu=*:-mtune=%(VALUE)}}" }, \
>{"tune_32", "%{" OPT_ARCH32 ":%{!mtune=*:%{!mcpu=*:-mtune=%(VALUE)}}}" }, \
>{"tune_64", "%{" OPT_ARCH64 ":%{!mtune=*:%{!mcpu=*:-mtune=%(VALUE)}}}" }, \
So this patch will make a difference to people who use --with-abi= for
one of the ABI variant things.
But it does not seem correct. -mabi=optionA should not override the
-mabi=optionB set in --with-abi=, where A and B are independent, nor
should it override the base ABI.
Please open a PR for the problem you want to solve here, so we do not
lose track of it?
Thanks,
Segher
Re: [GCC13][Patch][V4][PATCH 1/2] Add a new option -fstrict-flex-arrays[=n] and new attribute strict_flex_arrays
> On Sep 30, 2022, at 1:39 PM, Martin Sebor wrote:
>
> On 9/28/22 13:17, Qing Zhao wrote:
>> Hi, Martin,
>> Thanks for the comments. And sorry for my late reply till now (I just came
>> back home from LPC, GNU Cauldron and then a one-week vacation after that…)
>>> On Sep 12, 2022, at 12:42 PM, Martin Sebor wrote:
>>>
>>> On 9/6/22 18:28, Qing Zhao wrote:
Add the following new option -fstrict-flex-arrays[=n] and a corresponding
attribute strict_flex_arrays to GCC:
'-fstrict-flex-arrays'
Treat the trailing array of a structure as a flexible array member
in a stricter way.
>>>
>>> A minor problem with this phrasing was pointed out in the review
>>> of the Clang option: https://reviews.llvm.org/D126864#inline-1282716
>>> It would be good to avoid it here.
>> Yes, I agree.
>>> (I think qualifying the sentence
>>> by adding "for the purposes of accessing the elements of such arrays"
>>> might be one way to do it).
>> How about:
>> '-fstrict-flex-arrays’
>> Treat the trailing array of a structure as a variable-length array
>> in a stricter way.
>> ?
>
> I don't think talking about variable length arrays in this context
> would be appropriate (they're a different thing). The concern in
> the review above was that the a in something like
>
> struct { int n, a[1]; } s;
>
> is treated as a flexible array member only for the purposes of
> accessing a's elements, but not also in a sizeof expression, for
> instance. sizeof s.a is 1 regardless of the -fstrict-flex-arrays
> argument, but if s.a were considered a flexible array member then
> sizeof s.a would a constraint violation. Similarly, if s.a were
> treated as a FAM the definition of s would pedantically speaking
> be invalid, and s's size would be equal to sizeof (int) because
> GCC accepts the defintion but adds no padding.
Okay, understood now. -:)
>
> One way to avoid implying that might be qualifying the description
> with what I suggested above:
>
> Control when to treat the trailing array of a structure as
> a flexible array member for the purposes of accessing
> the elements of such an array.
Okay, I will use this, I think it’s good enough.
Thank you!
>
> But I'm sure there are better ways to put it.
>
> In addition, it should probably also be made clear whether this
> stays the same when an object of such a structure is itself
> a subobject of another aggregate (array or struct). E.g.,
>
> struct A { int n, a[1]; };
> struct A a[2]; // is a.a treated as a FAM?
> struct B { struct A a; } b; // is b.a.a treated as a FAM?
> struct C { struct A a; int i; } c; // how about c.a.a?
Yes, right now, it stay the same behavior as before.
But I am not sure whether the current behavior is correct or not.
Any suggestion here?
>
> Finally, and with the caveat that I haven't been very close
> attention to the GCC patches so this may not be an issue, but I have
> the impression that the decision in Clang is to let -Warray-bounds
> trigger (at least somewhat) independently of -fstrict-flex-arrays.
> The goal is to make it possible to diagnose misuses without causing
> runtime errors.
You mean that in Clang, -Warray-bounds will NOT be adjusted with different
level of -fstrict-flex-array?
If so, I don’t think that’s a good idea.
> This has also been the historical GCC behavior that
> I think it should be maintained going forward.
I think that -Warray-bounds need to be adjusted to reflect the different level
of -fstrict-flex-array.
Only when all the phases (both analysis phase and warning phases) in GCC can
behavior consistently, we can consistently encourage the standard conforming
coding style.
Otherwise, the user and developers will be even more confusing with another
inconsistency added into GCC.
Qing
>
> Martin
>
>>>
The positive form is equivalent to
'-fstrict-flex-arrays=3', which is the strictest. A trailing array
is treated as a flexible array member only when it is declared as a
flexible array member per C99 standard onwards. The negative form
is equivalent to '-fstrict-flex-arrays=0', which is the least
strict. All trailing arrays of structures are treated as flexible
array members.
'-fstrict-flex-arrays=LEVEL'
Treat the trailing array of a structure as a flexible array member
in a stricter way. The value of LEVEL controls the level of
strictness.
The possible values of LEVEL are the same as for the
'strict_flex_arrays' attribute (*note Variable Attributes::).
You can control this behavior for a specific trailing array field
of a structure by using the variable attribute 'strict_flex_arrays'
attribute (*note Variable Attributes::).
'strict_flex_arrays (LEVEL)'
The 'strict_flex_arrays' attribute should be attached to the
trailing array field of a structure.
Re: [PATCH RFC] c++: streamline process for adding new builtin trait
On 10/3/22 08:48, Patrick Palka wrote:
On Fri, 30 Sep 2022, Jason Merrill wrote:
On 9/30/22 11:14, Patrick Palka wrote:
On Thu, 29 Sep 2022, Jason Merrill wrote:
On 9/29/22 11:05, Patrick Palka wrote:
Adding a new builtin trait currently involves some boilerplate (as can
be seen in r13-2956-g9ca147154074a0) of defining corresponding RID_ and
CPTK_ enumerators and adding them to various switch statements across
many files. The exact switch statements we need to change is determined
by whether the proposed trait yields a type or an expression.
This RFC patch attempts to streamline this process via a centralized
cp-trait.def file for declaring the important parts about a builtin
trait
(whether it yields a type or an expression, its code, its spelling and
its arity) and using this file to automate away the switch statement
addition boilerplate. It also converts 9 traits to use this approach
by way of example (we can convert all the traits once the design is
settled).
After this change, the process of adding a new builtin trait is just
(modulo tests): declare it in cp-trait.def, define its behavior in
finish_trait_type/expr, and handle it in diagnose_trait_expr if it's
an expression-yielding trait (this last step is unfortunate but since
the switch has no default case, we'll at least get a diagnostic if we
forget to do it).
Does this look like a good approach?
OK.
Thanks a lot, I committed the following (which migrates all the
C++-specific traits to the new approach):
-- >8 --
Subject: [PATCH] c++: streamline built-in trait addition process
Adding a new built-in trait currently involves manual boilerplate
consisting of defining an rid enumerator for the identifier as well as a
corresponding cp_trait_kind enumerator and handling them in various switch
statements, the exact set of which depends on whether the proposed trait
yields (and thus is recognized as) a type or an expression.
To streamline the process, this patch adds a central cp-trait.def file
that tabulates the essential details about each built-in trait (whether
it yields a type or an expression, its code, its spelling and its arity)
and uses this file to automate away the manual boilerplate. It also
migrates all the existing C++-specific built-in traits to use this
approach.
After this change, adding a new built-in trait just entails declaring
it in cp-trait.def and defining its behavior in finish_trait_expr/type
(and handling it in diagnose_trait_expr, if it's an expression-yielding
trait).
gcc/c-family/ChangeLog:
* c-common.cc (c_common_reswords): Use cp/cp-trait.def to handle
C++ traits.
* c-common.h (enum rid): Likewise.
gcc/cp/ChangeLog:
* constraint.cc (diagnose_trait_expr): Likewise.
* cp-objcp-common.cc (names_builtin_p): Likewise.
* cp-tree.h (enum cp_trait_kind): Likewise.
* cxx-pretty-print.cc (pp_cxx_trait): Likewise.
* parser.cc (cp_keyword_starts_decl_specifier_p): Likewise.
(cp_parser_primary_expression): Likewise.
(cp_parser_trait): Likewise.
(cp_parser_simple_type_specifier): Likewise.
* cp-trait.def: New file.
---
gcc/c-family/c-common.cc | 54 ++---
gcc/c-family/c-common.h| 33 ++
gcc/cp/constraint.cc | 12 +-
gcc/cp/cp-objcp-common.cc | 44 +---
gcc/cp/cp-trait.def| 106 ++
gcc/cp/cp-tree.h | 46 +---
gcc/cp/cxx-pretty-print.cc | 126 +
gcc/cp/parser.cc | 217 -
8 files changed, 161 insertions(+), 477 deletions(-)
create mode 100644 gcc/cp/cp-trait.def
diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index 6e0af863a49..3c60a89bfe2 100644
--- a/gcc/c-family/c-common.cc
+++ b/gcc/c-family/c-common.cc
@@ -378,7 +378,6 @@ const struct c_common_resword c_common_reswords[] =
{ "__attribute", RID_ATTRIBUTE, 0 },
{ "__attribute__", RID_ATTRIBUTE, 0 },
{ "__auto_type", RID_AUTO_TYPE, D_CONLY },
- { "__bases", RID_BASES, D_CXXONLY },
{ "__builtin_addressof", RID_ADDRESSOF, D_CXXONLY },
{ "__builtin_bit_cast", RID_BUILTIN_BIT_CAST, D_CXXONLY },
{ "__builtin_call_with_static_chain",
@@ -401,44 +400,12 @@ const struct c_common_resword c_common_reswords[] =
{ "__const__", RID_CONST, 0 },
{ "__constinit", RID_CONSTINIT, D_CXXONLY },
{ "__decltype", RID_DECLTYPE, D_CXXONLY },
- { "__direct_bases", RID_DIRECT_BASES, D_CXXONLY },
{ "__extension__", RID_EXTENSION, 0 },
{ "__func__",RID_C99_FUNCTION_NAME, 0 },
- { "__has_nothrow_assign", RID_HAS_NOTHROW_ASSIGN, D_CXXONLY },
- { "__has_nothrow_constructor", RID_HAS_NOTHROW_CONSTRUCTOR, D_CXXONLY },
- { "__has_nothrow_copy", RID_HAS_NOTHROW_COPY, D_CXXONLY },
- { "__has_trivial_assign", RID_HAS_TRIVIAL_ASSIGN, D_CXXONLY },
- { "__has_trivial_constructor", RID_HAS_TRIVIAL_CONSTRUCTOR, D_CXXONLY },
Re: [PATCH] c++: Disallow jumps into statement expressions
On 10/2/22 07:35, Jakub Jelinek wrote:
On Fri, Sep 30, 2022 at 04:39:25PM -0400, Jason Merrill wrote:
--- gcc/cp/decl.cc.jj 2022-09-22 00:14:55.478599363 +0200
+++ gcc/cp/decl.cc 2022-09-22 00:24:01.121178256 +0200
@@ -223,6 +223,7 @@ struct GTY((for_user)) named_label_entry
bool in_transaction_scope;
bool in_constexpr_if;
bool in_consteval_if;
+ bool in_assume;
I think it would be better to reject jumps into statement-expressions like
the C front-end.
Ok, here is a self-contained patch that does that.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK, thanks.
2022-10-01 Jakub Jelinek
* cp-tree.h (BCS_STMT_EXPR): New enumerator.
* name-lookup.h (enum scope_kind): Add sk_stmt_expr.
* name-lookup.cc (begin_scope): Handle sk_stmt_expr like sk_block.
* semantics.cc (begin_compound_stmt): For BCS_STMT_EXPR use
sk_stmt_expr.
* parser.cc (cp_parser_statement_expr): Use BCS_STMT_EXPR instead of
BCS_NORMAL.
* decl.cc (struct named_label_entry): Add in_stmt_expr.
(poplevel_named_label_1): Handle sk_stmt_expr.
(check_previous_goto_1): Diagnose entering of statement expression.
(check_goto): Likewise.
* g++.dg/ext/stmtexpr24.C: New test.
--- gcc/cp/cp-tree.h.jj 2022-09-30 18:38:55.351607176 +0200
+++ gcc/cp/cp-tree.h2022-10-01 13:06:20.731720730 +0200
@@ -7599,7 +7599,8 @@ enum {
BCS_NO_SCOPE = 1,
BCS_TRY_BLOCK = 2,
BCS_FN_BODY = 4,
- BCS_TRANSACTION = 8
+ BCS_TRANSACTION = 8,
+ BCS_STMT_EXPR = 16
};
extern tree begin_compound_stmt (unsigned int);
--- gcc/cp/name-lookup.h.jj 2022-09-23 09:02:31.103668514 +0200
+++ gcc/cp/name-lookup.h2022-10-01 13:37:50.158404107 +0200
@@ -200,6 +200,7 @@ enum scope_kind {
init-statement. */
sk_cond, /* The scope of the variable declared in the condition
of an if or switch statement. */
+ sk_stmt_expr, /* GNU statement expression block. */
sk_function_parms, /* The scope containing function parameters. */
sk_class,/* The scope containing the members of a class. */
sk_scoped_enum,/* The scope containing the enumerators of a C++11
--- gcc/cp/name-lookup.cc.jj2022-09-13 09:21:28.123540623 +0200
+++ gcc/cp/name-lookup.cc 2022-10-01 13:37:26.383732959 +0200
@@ -4296,6 +4296,7 @@ begin_scope (scope_kind kind, tree entit
case sk_scoped_enum:
case sk_transaction:
case sk_omp:
+case sk_stmt_expr:
scope->keep = keep_next_level_flag;
break;
--- gcc/cp/semantics.cc.jj 2022-09-30 18:38:50.337675080 +0200
+++ gcc/cp/semantics.cc 2022-10-01 13:09:34.958970367 +0200
@@ -1761,6 +1761,8 @@ begin_compound_stmt (unsigned int flags)
sk = sk_try;
else if (flags & BCS_TRANSACTION)
sk = sk_transaction;
+ else if (flags & BCS_STMT_EXPR)
+ sk = sk_stmt_expr;
r = do_pushlevel (sk);
}
--- gcc/cp/parser.cc.jj 2022-09-30 18:38:55.374606864 +0200
+++ gcc/cp/parser.cc2022-10-01 13:08:27.367927479 +0200
@@ -5272,7 +5272,7 @@ cp_parser_statement_expr (cp_parser *par
/* Start the statement-expression. */
tree expr = begin_stmt_expr ();
/* Parse the compound-statement. */
- cp_parser_compound_statement (parser, expr, BCS_NORMAL, false);
+ cp_parser_compound_statement (parser, expr, BCS_STMT_EXPR, false);
/* Finish up. */
expr = finish_stmt_expr (expr, false);
/* Consume the ')'. */
--- gcc/cp/decl.cc.jj 2022-09-27 08:27:47.671428567 +0200
+++ gcc/cp/decl.cc 2022-10-01 13:14:57.990434730 +0200
@@ -223,6 +223,7 @@ struct GTY((for_user)) named_label_entry
bool in_transaction_scope;
bool in_constexpr_if;
bool in_consteval_if;
+ bool in_stmt_expr;
};
#define named_labels cp_function_chain->x_named_labels
@@ -538,6 +539,9 @@ poplevel_named_label_1 (named_label_entr
case sk_transaction:
ent->in_transaction_scope = true;
break;
+ case sk_stmt_expr:
+ ent->in_stmt_expr = true;
+ break;
case sk_block:
if (level_for_constexpr_if (bl->level_chain))
ent->in_constexpr_if = true;
@@ -3487,7 +3491,7 @@ check_previous_goto_1 (tree decl, cp_bin
bool complained = false;
int identified = 0;
bool saw_eh = false, saw_omp = false, saw_tm = false, saw_cxif = false;
- bool saw_ceif = false;
+ bool saw_ceif = false, saw_se = false;
if (exited_omp)
{
@@ -3560,6 +3564,12 @@ check_previous_goto_1 (tree decl, cp_bin
saw_tm = true;
break;
+ case sk_stmt_expr:
+ if (!saw_se)
+ inf = G_(" enters statement expression");
+ saw_se = true;
+ break;
+
case sk_block:
if (!saw_cxif && level_for_constexpr_if (b->level_chain))
{
@@ -3650,12 +3660,13 @@ check_goto (tree decl)
if
Re: [PATCH 00/10] c-family,libstdc++: P1642 and related changes
On Fri, 30 Sept 2022 at 19:15, Jonathan Wakely wrote: > > On Fri, 30 Sept 2022 at 17:46, Arsen Arsenović via Libstdc++ > wrote: > > > > Hi, > > > > This patchset: > > - Implements the P1642 WG21 paper, with a fair few extensions, > > - Fixes libstdc++' build system on systems --without-headers, > > - Ports (a large chunk of) the libstdc++ testsuite to freestanding, and > > - Changes the semantics of `int main' in freestanding (!!). > > Thanks for all this work, Arsen! > > I'm testing these and will approve and commit all except [PATCH 5/10] > which is outside libstdc++ and needs review. All the libstdc++ changes are on trunk now. I can push the c-family one for you if it gets approved.
Re: [PATCH v2] btf: Add support to BTF_KIND_ENUM64 type
On 9/29/22 17:35, Indu Bhagat wrote:
On 9/28/22 2:15 PM, Guillermo E. Martinez via Gcc-patches wrote:
Hello GCC team,
The following is patch v2 to update BTF/CTF backend supporting
BTF_KIND_ENUM64 type. Changes from v1:
+ Fix typo in commit message.
+ Fix changelog entries.
Comments will be welcomed and appreciated!,
Kind regards,
guillermo
--
Hi Guillermo,
Hi Indu,
Thanks for your patch.
Sorry for the delay in reviewing this patch. Please see my comments inlined.
No worries, thanks so much for your comments!. They were really useful.
Indu
BTF supports 64-bits enumerators with following encoding:
struct btf_type:
name_off: 0 or offset to a valid C identifier
info.kind_flag: 0 for unsigned, 1 for signed
info.kind: BTF_KIND_ENUM64
info.vlen: number of enum values
size: 1/2/4/8
The btf_type is followed by info.vlen number of:
struct btf_enum64
{
uint32_t name_off; /* Offset in string section of enumerator name. */
uint32_t val_lo32; /* lower 32-bit value for a 64-bit value Enumerator
*/
uint32_t val_hi32; /* high 32-bit value for a 64-bit value Enumerator
*/
};
So, a new btf_enum64 structure was added to represent BTF_KIND_ENUM64
and a new field in ctf_dtdef to represent specific type's properties, in
the particular case for CTF enums it helps to distinguish when its
enumerators values are signed or unsigned, later that information is
used to encode the BTF enum type.
gcc/ChangeLog:
* btfout.cc (btf_calc_num_vbytes): Compute enumeration size depending of
enumerator type btf_enum{,64}.
(btf_asm_type): Update btf_kflag according to enumerators sign,
using correct BPF type in BTF_KIND_ENUMi{,64}.
Typo : i after ENUM
Fixed in v3.
(btf_asm_enum_const): New argument to represent the size of
the BTF enum type.
* ctfc.cc (ctf_add_enum): Use and initialization of flag field to
CTF_ENUM_F_NONE.
(ctf_add_enumerator): New argument to represent CTF flags,
updating the comment and flag vaue according to enumerators
sing.
* ctfc.h (ctf_dmdef): Update dmd_value to HOST_WIDE_INT to allow
use 32/64 bits enumerators.
(ctf_dtdef): Add flags to to describe specific type's properties.
* dwarf2ctf.cc (gen_ctf_enumeration_type): Update flags field
depending when a signed enumerator value is found.
include/
* btf.h (btf_enum64): Add new definition and new symbolic
constant to BTF_KIND_ENUM64 and BTF_KF_ENUM_{UN,}SIGNED.
gcc/testsuite/ChangeLog:
* gcc.dg/debug/btf/btf-enum-1.c: Update testcase, with correct
info.kflags encoding.
* gcc.dg/debug/btf/btf-enum64-1.c: New testcase.
---
gcc/btfout.cc | 24 ---
gcc/ctfc.cc | 14 ---
gcc/ctfc.h | 9 +++-
gcc/dwarf2ctf.cc | 9 +++-
gcc/testsuite/gcc.dg/debug/btf/btf-enum-1.c | 2 +-
gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c | 41 +++
include/btf.h | 19 +++--
7 files changed, 99 insertions(+), 19 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c
diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index 997a33fa089..4b11c867c23 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -223,7 +223,9 @@ btf_calc_num_vbytes (ctf_dtdef_ref dtd)
break;
case BTF_KIND_ENUM:
- vlen_bytes += vlen * sizeof (struct btf_enum);
+ vlen_bytes += (dtd->dtd_data.ctti_size == 0x8)
+ ? vlen * sizeof (struct btf_enum64)
+ : vlen * sizeof (struct btf_enum);
break;
case BTF_KIND_FUNC_PROTO:
@@ -622,6 +624,15 @@ btf_asm_type (ctf_container_ref ctfc, ctf_dtdef_ref dtd)
btf_size_type = 0;
}
+ if (btf_kind == BTF_KIND_ENUM)
+ {
+ btf_kflag = (dtd->flags & CTF_ENUM_F_ENUMERATORS_SIGNED)
+ ? BTF_KF_ENUM_SIGNED
+ : BTF_KF_ENUM_UNSIGNED;
+ if (dtd->dtd_data.ctti_size == 0x8)
+ btf_kind = BTF_KIND_ENUM64;
+ }
+
See below. If you do add a new member in ctf_dmdef instead (as I propose), you
should ideally iterate over the enumerators (dtd->dtd_u.dtu_members) to make
sure they are all the same signedness.
Correct, struct `ctf_dmdef' stores enumerator's information. However
in BTF spec ``info.kind_flag`` is not a property per enumerator, but
enumeration type property instead, so I decided to add in `ctf_dtdef'
a `flag' field to store the signeedness information for an enumeration
type, then in `gen_ctf_enumeration_type' when it builds the enumerators
entries,`ctf_dtdef.flag' is updated to `CTF_ENUM_F_ENUMERATORS_SIGNED'
when it found a signed enumerator value meaning that enumeration type
should be consider a signed type. i.e, I detect signeedness when
enumeration type is being building.
Of course, I can add `dmd_value_signed' field in `ctf_dmdef' but I need
to iterate over all
Re: [PATCH] [testsuite][arm] Fix cmse-15.c expected output
On 23/09/2022 09:43, Torbjörn SVENSSON via Gcc-patches wrote: The cmse-15.c testcase fails at -Os because ICF means that we generate secure3: b secure1 which is OK, but does not match the currently expected secure3: ... bx r[0-3] gcc/testsuite/ChangeLog: * gcc.target/arm/cmse/cmse-15.c: Align with -Os improvements. OK. R. Co-Authored-By: Yvan ROUX Signed-off-by: Torbjörn SVENSSON --- gcc/testsuite/gcc.target/arm/cmse/cmse-15.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gcc/testsuite/gcc.target/arm/cmse/cmse-15.c b/gcc/testsuite/gcc.target/arm/cmse/cmse-15.c index b0fefe561a1..5188f1d697f 100644 --- a/gcc/testsuite/gcc.target/arm/cmse/cmse-15.c +++ b/gcc/testsuite/gcc.target/arm/cmse/cmse-15.c @@ -144,6 +144,8 @@ int secure2 (s_bar_ptr s_bar_p) **bx r[0-3] ** | **blx r[0-3] +** | +** b secure1 ** ) **... */
Re: [PATCH] vect: while_ult for integer mask
On 29/09/2022 14:46, Richard Biener wrote:
It's not the nicest way of carrying the information but short of inventing
new modes I can't see something better (well, another optab). I see
the GCN backend expects a constant in operand 3 but the docs don't
specify the operand has to be a CONST_INT, can you adjust them
accordingly?
Otherwise I'm fine with it. It might even prove useful for x86.
Thank you.
Here's what I pushed.
Andrew
vect: while_ult for integer masks
Add a vector length parameter needed by amdgcn without breaking aarch64.
All amdgcn vector masks are DImode, regardless of vector length, so we can't
tell what length is implied simply from the operator mode. (Even if we used
different integer modes there's no mode small enough to differenciate a 2 or
4 lane mask). Without knowing the intended length we end up using a mask with
too many lanes enabled, which leads to undefined behaviour..
The extra operand is not added for vector mask types so AArch64 does not need
to be adjusted.
gcc/ChangeLog:
* config/gcn/gcn-valu.md (while_ultsidi): Limit mask length using
operand 3.
* doc/md.texi (while_ult): Document new operand 3 usage.
* internal-fn.cc (expand_while_optab_fn): Set operand 3 when lhs_type
maps to a non-vector mode.
diff --git a/gcc/config/gcn/gcn-valu.md b/gcc/config/gcn/gcn-valu.md
index 3bfdf8213fc..dec81e863f7 100644
--- a/gcc/config/gcn/gcn-valu.md
+++ b/gcc/config/gcn/gcn-valu.md
@@ -3052,7 +3052,8 @@ (define_expand "vcondu_exec"
(define_expand "while_ultsidi"
[(match_operand:DI 0 "register_operand")
(match_operand:SI 1 "")
- (match_operand:SI 2 "")]
+ (match_operand:SI 2 "")
+ (match_operand:SI 3 "")]
""
{
if (GET_CODE (operands[1]) != CONST_INT
@@ -3077,6 +3078,11 @@ (define_expand "while_ultsidi"
: ~((unsigned HOST_WIDE_INT)-1 << diff));
emit_move_insn (operands[0], gen_rtx_CONST_INT (VOIDmode, mask));
}
+if (INTVAL (operands[3]) < 64)
+ emit_insn (gen_anddi3 (operands[0], operands[0],
+gen_rtx_CONST_INT (VOIDmode,
+ ~((unsigned HOST_WIDE_INT)-1
+ << INTVAL (operands[3]);
DONE;
})
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index d46963f468c..bb42ee1da36 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -4950,9 +4950,10 @@ This pattern is not allowed to @code{FAIL}.
@cindex @code{while_ult@var{m}@var{n}} instruction pattern
@item @code{while_ult@var{m}@var{n}}
Set operand 0 to a mask that is true while incrementing operand 1
-gives a value that is less than operand 2. Operand 0 has mode @var{n}
-and operands 1 and 2 are scalar integers of mode @var{m}.
-The operation is equivalent to:
+gives a value that is less than operand 2, for a vector length up to operand 3.
+Operand 0 has mode @var{n} and operands 1 and 2 are scalar integers of mode
+@var{m}. Operand 3 should be omitted when @var{n} is a vector mode, and
+a @code{CONST_INT} otherwise. The operation for vector modes is equivalent to:
@smallexample
operand0[0] = operand1 < operand2;
@@ -4960,6 +4961,14 @@ for (i = 1; i < GET_MODE_NUNITS (@var{n}); i++)
operand0[i] = operand0[i - 1] && (operand1 + i < operand2);
@end smallexample
+And for non-vector modes the operation is equivalent to:
+
+@smallexample
+operand0[0] = operand1 < operand2;
+for (i = 1; i < operand3; i++)
+ operand0[i] = operand0[i - 1] && (operand1 + i < operand2);
+@end smallexample
+
@cindex @code{check_raw_ptrs@var{m}} instruction pattern
@item @samp{check_raw_ptrs@var{m}}
Check whether, given two pointers @var{a} and @var{b} and a length @var{len},
diff --git a/gcc/internal-fn.cc b/gcc/internal-fn.cc
index 651d99eaeb9..c306240c2ac 100644
--- a/gcc/internal-fn.cc
+++ b/gcc/internal-fn.cc
@@ -3664,7 +3664,7 @@ expand_direct_optab_fn (internal_fn fn, gcall *stmt,
direct_optab optab,
static void
expand_while_optab_fn (internal_fn, gcall *stmt, convert_optab optab)
{
- expand_operand ops[3];
+ expand_operand ops[4];
tree rhs_type[2];
tree lhs = gimple_call_lhs (stmt);
@@ -3680,10 +3680,24 @@ expand_while_optab_fn (internal_fn, gcall *stmt,
convert_optab optab)
create_input_operand ([i + 1], rhs_rtx, TYPE_MODE (rhs_type[i]));
}
+ int opcnt;
+ if (!VECTOR_MODE_P (TYPE_MODE (lhs_type)))
+{
+ /* When the mask is an integer mode the exact vector length may not
+be clear to the backend, so we pass it in operand[3].
+ Use the vector in arg2 for the most reliable intended size. */
+ tree type = TREE_TYPE (gimple_call_arg (stmt, 2));
+ create_integer_operand ([3], TYPE_VECTOR_SUBPARTS (type));
+ opcnt = 4;
+}
+ else
+/* The mask has a vector type so the length operand is unnecessary. */
+opcnt = 3;
+
insn_code icode = convert_optab_handler (optab, TYPE_MODE (rhs_type[0]),
[PATCH] PR tree-optimization/107109 - Don't process undefined range.
I audited all the op1/op2 range for undefined values, but missed that an
intervening calculation can also cause an undefined range in the middle
of operator_plus::op1_range, and that is the passed to
adjust_op1_for_overflow. That routine also needs to check for
undefined before asking for the type of the range.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
commit f41d1b39a6443fad38c36af34b1baa384954ca80
Author: Andrew MacLeod
Date: Sun Oct 2 18:43:35 2022 -0400
Don't process undefined range.
No need to continue processing an undefined range.
gcc/
PR tree-optimization/107109
* range-op.cc (adjust_op1_for_overflow): Don't process undefined.
gcc/testsuite/
* gcc.dg/pr107109.c: New.
diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index 7ef980315b6..4f647abd91c 100644
--- a/gcc/range-op.cc
+++ b/gcc/range-op.cc
@@ -1370,6 +1370,8 @@ static void
adjust_op1_for_overflow (irange , const irange , relation_kind rel,
bool add_p)
{
+ if (r.undefined_p ())
+return;
tree type = r.type ();
// Check for unsigned overflow and calculate the overflow part.
signop s = TYPE_SIGN (type);
diff --git a/gcc/testsuite/gcc.dg/pr107109.c b/gcc/testsuite/gcc.dg/pr107109.c
new file mode 100644
index 000..e3036f6ff22
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr107109.c
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+/* { dg-options "-O1" } */
+
+int printf(const char *, ...);
+int a, b;
+void c() {
+ int d, e;
+ L:
+ a = (b && a) ^ 2756578370;
+ d = ~a + (e ^ d) ^ 2756578370;
+ if (!d)
+printf("%d", a);
+ d = a / e;
+ goto L;
+}
+int main() {
+ if (a)
+c();
+ return 0;
+}
+
[committed] c: Adjust LDBL_EPSILON for C2x for IBM long double
C2x changes the definition of *_EPSILON to apply only to
normalized numbers. The effect is that LDBL_EPSILON for IBM long
double becomes 0x1p-105L instead of 0x1p-1074L.
There is a reasonable case for considering this a defect fix - it
originated from the issue reporting process (DR#467), though it ended
up being resolved by a paper (N2326) for C2x rather than through the
issue process, and code using *_EPSILON often needs to override the
pre-C2x value of LDBL_EPSILON and use something on the order of
magnitude of the C2x value instead. However, I've followed the
conservative approach of only making the change for C2x and not for
previous standard versions (and not for C++, which doesn't have the
C2x changes in this area).
The testcases added are intended to be valid for all long double
formats. The C11 one is based on
gcc.target/powerpc/rs6000-ldouble-2.c (and when we move to a C2x
default, gcc.target/powerpc/rs6000-ldouble-2.c will need an
appropriate option added to keep using an older language version).
Tested with no regressions for cross to powerpc-linux-gnu.
gcc/c-family/
* c-cppbuiltin.cc (builtin_define_float_constants): Do not
special-case __*_EPSILON__ setting for IBM long double for C2x.
gcc/testsuite/
* gcc.dg/c11-float-7.c, gcc.dg/c2x-float-12.c: New tests.
diff --git a/gcc/c-family/c-cppbuiltin.cc b/gcc/c-family/c-cppbuiltin.cc
index d4de5a0dc57..4b8486c8879 100644
--- a/gcc/c-family/c-cppbuiltin.cc
+++ b/gcc/c-family/c-cppbuiltin.cc
@@ -279,7 +279,7 @@ builtin_define_float_constants (const char *name_prefix,
/* The difference between 1 and the least value greater than 1 that is
representable in the given floating point type, b**(1-p). */
sprintf (name, "__%s_EPSILON__", name_prefix);
- if (fmt->pnan < fmt->p)
+ if (fmt->pnan < fmt->p && (c_dialect_cxx () || !flag_isoc2x))
/* This is an IBM extended double format, so 1.0 + any double is
representable precisely. */
sprintf (buf, "0x1p%d", fmt->emin - fmt->p);
diff --git a/gcc/testsuite/gcc.dg/c11-float-7.c
b/gcc/testsuite/gcc.dg/c11-float-7.c
new file mode 100644
index 000..a8a7ef5bc33
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c11-float-7.c
@@ -0,0 +1,24 @@
+/* Test C11 definition of LDBL_EPSILON. Based on
+ gcc.target/powerpc/rs6000-ldouble-2.c. */
+/* { dg-do run } */
+/* { dg-options "-std=c11 -pedantic-errors" } */
+
+#include
+
+extern void abort (void);
+extern void exit (int);
+
+int
+main (void)
+{
+ volatile long double ee = 1.0;
+ long double eps = ee;
+ while (ee + 1.0 != 1.0)
+{
+ eps = ee;
+ ee = eps / 2;
+}
+ if (eps != LDBL_EPSILON)
+abort ();
+ exit (0);
+}
diff --git a/gcc/testsuite/gcc.dg/c2x-float-12.c
b/gcc/testsuite/gcc.dg/c2x-float-12.c
new file mode 100644
index 000..40900bd918a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c2x-float-12.c
@@ -0,0 +1,19 @@
+/* Test C2x definition of LDBL_EPSILON. */
+/* { dg-do run } */
+/* { dg-options "-std=c2x -pedantic-errors" } */
+
+#include
+
+extern void abort (void);
+extern void exit (int);
+
+int
+main (void)
+{
+ volatile long double x = 1.0L;
+ for (int i = 0; i < LDBL_MANT_DIG - 1; i++)
+x /= 2;
+ if (x != LDBL_EPSILON)
+abort ();
+ exit (0);
+}
--
Joseph S. Myers
jos...@codesourcery.com
Re: [PATCH] arm: Add missing early clobber to MVE vrev64q_m patterns
On 03/10/2022 11:43, Christophe Lyon via Gcc-patches wrote:
Like the non-predicated vrev64q patterns, mve_vrev64q_m_
and mve_vrev64q_m_f need an early clobber constraint, otherwise
we can generate an unpredictable instruction:
Warning: 64-bit element size and same destination and source operands makes
instruction UNPREDICTABLE
when calling vrevq64_m* with the same first and second arguments.
Regression-tested on arm-none-eabi, bootstap in progress on
armv8l-unknown-linux-gnueabihf.
OK for trunk?
OK.
R.
Thanks,
Christophe
gcc/ChangeLog:
* config/arm/mve.md: (mve_vrev64q_m_): Add early
clobber.
(mve_vrev64q_m_f): Likewise.
gcc/testsuite/ChangeLog:
* gcc.target/arm/mve/intrinsics/vrev64q_m_s16-clobber.c: New test.
---
gcc/config/arm/mve.md | 4 ++--
.../arm/mve/intrinsics/vrev64q_m_s16-clobber.c | 17 +
2 files changed, 19 insertions(+), 2 deletions(-)
create mode 100644
gcc/testsuite/gcc.target/arm/mve/intrinsics/vrev64q_m_s16-clobber.c
diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
index 714178609f7..62186f124da 100644
--- a/gcc/config/arm/mve.md
+++ b/gcc/config/arm/mve.md
@@ -3503,7 +3503,7 @@ (define_insn "mve_vqshlq_m_r_"
;;
(define_insn "mve_vrev64q_m_"
[
- (set (match_operand:MVE_2 0 "s_register_operand" "=w")
+ (set (match_operand:MVE_2 0 "s_register_operand" "=")
(unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand" "0")
(match_operand:MVE_2 2 "s_register_operand" "w")
(match_operand: 3 "vpr_register_operand"
"Up")]
@@ -4598,7 +4598,7 @@ (define_insn "mve_vrev32q_m_"
;;
(define_insn "mve_vrev64q_m_f"
[
- (set (match_operand:MVE_0 0 "s_register_operand" "=w")
+ (set (match_operand:MVE_0 0 "s_register_operand" "=")
(unspec:MVE_0 [(match_operand:MVE_0 1 "s_register_operand" "0")
(match_operand:MVE_0 2 "s_register_operand" "w")
(match_operand: 3 "vpr_register_operand"
"Up")]
diff --git
a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vrev64q_m_s16-clobber.c
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vrev64q_m_s16-clobber.c
new file mode 100644
index 000..6464c96181d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vrev64q_m_s16-clobber.c
@@ -0,0 +1,17 @@
+/* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
+/* { dg-add-options arm_v8_1m_mve_fp } */
+/* { dg-additional-options "-O2" } */
+
+#include "arm_mve.h"
+
+int16x8_t
+foo (int16x8_t a, mve_pred16_t p)
+{
+ return vrev64q_m_s16 (a, a, p);
+}
+
+float16x8_t
+foo2 (float16x8_t a, mve_pred16_t p)
+{
+ return vrev64q_m_f16 (a, a, p);
+}
Re: [PATCH RFC] c++: streamline process for adding new builtin trait
On Fri, 30 Sep 2022, Jason Merrill wrote:
> On 9/30/22 11:14, Patrick Palka wrote:
> > On Thu, 29 Sep 2022, Jason Merrill wrote:
> >
> > > On 9/29/22 11:05, Patrick Palka wrote:
> > > > Adding a new builtin trait currently involves some boilerplate (as can
> > > > be seen in r13-2956-g9ca147154074a0) of defining corresponding RID_ and
> > > > CPTK_ enumerators and adding them to various switch statements across
> > > > many files. The exact switch statements we need to change is determined
> > > > by whether the proposed trait yields a type or an expression.
> > > >
> > > > This RFC patch attempts to streamline this process via a centralized
> > > > cp-trait.def file for declaring the important parts about a builtin
> > > > trait
> > > > (whether it yields a type or an expression, its code, its spelling and
> > > > its arity) and using this file to automate away the switch statement
> > > > addition boilerplate. It also converts 9 traits to use this approach
> > > > by way of example (we can convert all the traits once the design is
> > > > settled).
> > > >
> > > > After this change, the process of adding a new builtin trait is just
> > > > (modulo tests): declare it in cp-trait.def, define its behavior in
> > > > finish_trait_type/expr, and handle it in diagnose_trait_expr if it's
> > > > an expression-yielding trait (this last step is unfortunate but since
> > > > the switch has no default case, we'll at least get a diagnostic if we
> > > > forget to do it).
> > > >
> > > > Does this look like a good approach?
> > >
> > > OK.
> >
> > Thanks a lot, I committed the following (which migrates all the
> > C++-specific traits to the new approach):
> >
> > -- >8 --
> >
> > Subject: [PATCH] c++: streamline built-in trait addition process
> >
> > Adding a new built-in trait currently involves manual boilerplate
> > consisting of defining an rid enumerator for the identifier as well as a
> > corresponding cp_trait_kind enumerator and handling them in various switch
> > statements, the exact set of which depends on whether the proposed trait
> > yields (and thus is recognized as) a type or an expression.
> >
> > To streamline the process, this patch adds a central cp-trait.def file
> > that tabulates the essential details about each built-in trait (whether
> > it yields a type or an expression, its code, its spelling and its arity)
> > and uses this file to automate away the manual boilerplate. It also
> > migrates all the existing C++-specific built-in traits to use this
> > approach.
> >
> > After this change, adding a new built-in trait just entails declaring
> > it in cp-trait.def and defining its behavior in finish_trait_expr/type
> > (and handling it in diagnose_trait_expr, if it's an expression-yielding
> > trait).
> >
> > gcc/c-family/ChangeLog:
> >
> > * c-common.cc (c_common_reswords): Use cp/cp-trait.def to handle
> > C++ traits.
> > * c-common.h (enum rid): Likewise.
> >
> > gcc/cp/ChangeLog:
> >
> > * constraint.cc (diagnose_trait_expr): Likewise.
> > * cp-objcp-common.cc (names_builtin_p): Likewise.
> > * cp-tree.h (enum cp_trait_kind): Likewise.
> > * cxx-pretty-print.cc (pp_cxx_trait): Likewise.
> > * parser.cc (cp_keyword_starts_decl_specifier_p): Likewise.
> > (cp_parser_primary_expression): Likewise.
> > (cp_parser_trait): Likewise.
> > (cp_parser_simple_type_specifier): Likewise.
> > * cp-trait.def: New file.
> > ---
> > gcc/c-family/c-common.cc | 54 ++---
> > gcc/c-family/c-common.h| 33 ++
> > gcc/cp/constraint.cc | 12 +-
> > gcc/cp/cp-objcp-common.cc | 44 +---
> > gcc/cp/cp-trait.def| 106 ++
> > gcc/cp/cp-tree.h | 46 +---
> > gcc/cp/cxx-pretty-print.cc | 126 +
> > gcc/cp/parser.cc | 217 -
> > 8 files changed, 161 insertions(+), 477 deletions(-)
> > create mode 100644 gcc/cp/cp-trait.def
> >
> > diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
> > index 6e0af863a49..3c60a89bfe2 100644
> > --- a/gcc/c-family/c-common.cc
> > +++ b/gcc/c-family/c-common.cc
> > @@ -378,7 +378,6 @@ const struct c_common_resword c_common_reswords[] =
> > { "__attribute",RID_ATTRIBUTE, 0 },
> > { "__attribute__", RID_ATTRIBUTE, 0 },
> > { "__auto_type",RID_AUTO_TYPE, D_CONLY },
> > - { "__bases", RID_BASES, D_CXXONLY },
> > { "__builtin_addressof", RID_ADDRESSOF, D_CXXONLY },
> > { "__builtin_bit_cast", RID_BUILTIN_BIT_CAST, D_CXXONLY },
> > { "__builtin_call_with_static_chain",
> > @@ -401,44 +400,12 @@ const struct c_common_resword c_common_reswords[] =
> > { "__const__", RID_CONST, 0 },
> > { "__constinit",RID_CONSTINIT, D_CXXONLY },
> > { "__decltype", RID_DECLTYPE, D_CXXONLY },
> > - { "__direct_bases", RID_DIRECT_BASES, D_CXXONLY },
> > { "__extension__", RID_EXTENSION, 0
[COMMITTED] libsanitizer: Fix Solaris 11.3 compilation of sanitizer_procmaps_solaris.cpp [PR105531]
The latest libsanitizer import broke Solaris 11.3 bootstrap again, due to an oversight of mine. A fix has been committed upstream https://reviews.llvm.org/D133556 This patch cherry-picks it. Tested on Solaris 11.3 and 11.4, SPARC and x86. Approved by Martin in the PR, committed to trunk. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University 2022-09-23 Rainer Orth libsanitizer: PR sanitizer/105531 * sanitizer_common/sanitizer_procmaps_solaris.cpp: Cherry-pick llvm-project revision 1cd4d63fb9ab0f04c7151911dde0d58b673823de. # HG changeset patch # Parent 5b7d5c364ecfeb253a886a59046e4bd6bd339c1e Fix sanitizer_procmaps_solaris.cpp compilation on Solaris 11.3 diff --git a/libsanitizer/sanitizer_common/sanitizer_procmaps_solaris.cpp b/libsanitizer/sanitizer_common/sanitizer_procmaps_solaris.cpp --- a/libsanitizer/sanitizer_common/sanitizer_procmaps_solaris.cpp +++ b/libsanitizer/sanitizer_common/sanitizer_procmaps_solaris.cpp @@ -9,6 +9,8 @@ // Information about the process mappings (Solaris-specific parts). //===--===// +// Before Solaris 11.4, doesn't work in a largefile environment. +#undef _FILE_OFFSET_BITS #include "sanitizer_platform.h" #if SANITIZER_SOLARIS # include
[committed] libstdc++: Fix tests broken by C++23 P2266R3 "Simpler implicit move"
Tested x86_64-linux. Pushed to trunk.
-- >8 --
In C++23 mode these tests started to FAIL because an rvalue reference
parameter can no longer be bound to an lvalue reference return type. As
confirmed by Ville (who added these tests) the problem overloads are not
intended to be called, and only exist to verify that they don't
interfere with the intended behaviour. This changes the function bodies
to just throw, so that the tests will fail if the function is called.
libstdc++-v3/ChangeLog:
* testsuite/27_io/basic_ostream/inserters_other/char/6.cc:
Change body of unused operator<< overload to throw if called.
* testsuite/27_io/basic_ostream/inserters_other/wchar_t/6.cc:
Likewise.
---
.../testsuite/27_io/basic_ostream/inserters_other/char/6.cc | 2 +-
.../testsuite/27_io/basic_ostream/inserters_other/wchar_t/6.cc | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
a/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/6.cc
b/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/6.cc
index f62023c8c2e..e45af3c02af 100644
--- a/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/6.cc
+++ b/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/6.cc
@@ -42,7 +42,7 @@ std::ostream& operator<<(std::ostream&, const X&) = delete;
struct Y {};
std::ostream& operator<<(std::ostream& os, const Y&) {return os;}
-std::ostream& operator<<(std::ostream&& os, const Y&) {return os;}
+std::ostream& operator<<(std::ostream&& os, const Y&) {throw 1;} // not used
struct Z{};
diff --git
a/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/wchar_t/6.cc
b/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/wchar_t/6.cc
index 6bbf4a7f341..7ef6442d358 100644
--- a/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/wchar_t/6.cc
+++ b/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/wchar_t/6.cc
@@ -42,7 +42,7 @@ std::wostream& operator<<(std::wostream&, const X&) = delete;
struct Y {};
std::wostream& operator<<(std::wostream& os, const Y&) {return os;}
-std::wostream& operator<<(std::wostream&& os, const Y&) {return os;}
+std::wostream& operator<<(std::wostream&& os, const Y&) {throw 1;} // not used
struct Z{};
--
2.37.3
Re: [PATCH v2][DOCS] changes: mentioned ignore -gz=zlib-gnu option
On 9/29/22 22:31, Fangrui Song wrote: > At some point binutils will want to remove --compress-debug-sections=zlib-gnu > support as well. > I think the message can drop mentioning of --compress-debug-sections=zlib-gnu. Yes, makes sense and I'm going to push the documentation change. Martin
[COMMITTED] Do not compare nonzero masks for varying.
There is no need to compare nonzero masks when comparing two VARYING
ranges, as they are always the same when range types are the same.
gcc/ChangeLog:
* value-range.cc (irange::legacy_equal_p): Remove nonozero mask
check when comparing VR_VARYING ranges.
---
gcc/value-range.cc | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index 6154d73ccf5..ddbcdd67633 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -1233,10 +1233,7 @@ irange::legacy_equal_p (const irange ) const
if (m_kind == VR_UNDEFINED)
return true;
if (m_kind == VR_VARYING)
-{
- return (range_compatible_p (type (), other.type ())
- && vrp_operand_equal_p (m_nonzero_mask, other.m_nonzero_mask));
-}
+return range_compatible_p (type (), other.type ());
return (vrp_operand_equal_p (tree_lower_bound (0),
other.tree_lower_bound (0))
&& vrp_operand_equal_p (tree_upper_bound (0),
--
2.37.1
[COMMITTED] Do not pessimize range in set_nonzero_bits.
Currently if we have a range of [0,0] and we set the nonzero bits to
1, the current code pessimizes the range to [0,1] because it assumes
the range is [1,1] plus the possibility of 0. This fixes the
oversight.
gcc/ChangeLog:
* value-range.cc (irange::set_nonzero_bits): Do not pessimize range.
(range_tests_nonzero_bits): New test.
---
gcc/value-range.cc | 13 +
1 file changed, 13 insertions(+)
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index e1066f4946e..6e196574de9 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -2934,6 +2934,14 @@ irange::set_nonzero_bits (const wide_int_ref )
// range immediately.
if (wi::popcount (bits) == 1)
{
+ // Make sure we don't pessimize the range.
+ tree tbits = wide_int_to_tree (type (), bits);
+ if (!contains_p (tbits))
+ {
+ set_nonzero_bits (tbits);
+ return;
+ }
+
bool has_zero = contains_p (build_zero_cst (type ()));
set (type (), bits, bits);
if (has_zero)
@@ -3628,6 +3636,11 @@ range_tests_nonzero_bits ()
r1.set_nonzero_bits (0xff);
r0.union_ (r1);
ASSERT_TRUE (r0.varying_p ());
+
+ // Test that setting a nonzero bit of 1 does not pessimize the range.
+ r0.set_zero (integer_type_node);
+ r0.set_nonzero_bits (1);
+ ASSERT_TRUE (r0.zero_p ());
}
// Build an frange from string endpoints.
--
2.37.1
[COMMITTED] Do not compare incompatible ranges in ipa-prop.
Committed as obvious.
gcc/ChangeLog:
* ipa-prop.cc (struct ipa_vr_ggc_hash_traits): Do not compare
incompatible ranges in ipa-prop.
---
gcc/ipa-prop.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
index ca5b9f31570..724c9456308 100644
--- a/gcc/ipa-prop.cc
+++ b/gcc/ipa-prop.cc
@@ -126,8 +126,8 @@ struct ipa_vr_ggc_hash_traits : public ggc_cache_remove
static bool
equal (const value_range *a, const value_range *b)
{
- return (*a == *b
- && types_compatible_p (a->type (), b->type ()));
+ return (types_compatible_p (a->type (), b->type ())
+ && *a == *b);
}
static const bool empty_zero_p = true;
static void
--
2.37.1
[COMMITTED] Avoid comparing ranges when sub-ranges is 0.
There is nothing else to compare when the number of sub-ranges is 0.
gcc/ChangeLog:
* value-range.cc (irange::operator==): Early bail on m_num_ranges
equal to 0.
---
gcc/value-range.cc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index ddbcdd67633..e1066f4946e 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -1260,6 +1260,9 @@ irange::operator== (const irange ) const
if (m_num_ranges != other.m_num_ranges)
return false;
+ if (m_num_ranges == 0)
+return true;
+
for (unsigned i = 0; i < m_num_ranges; ++i)
{
tree lb = tree_lower_bound (i);
--
2.37.1
[PATCH] arm: Add missing early clobber to MVE vrev64q_m patterns
Like the non-predicated vrev64q patterns, mve_vrev64q_m_
and mve_vrev64q_m_f need an early clobber constraint, otherwise
we can generate an unpredictable instruction:
Warning: 64-bit element size and same destination and source operands makes
instruction UNPREDICTABLE
when calling vrevq64_m* with the same first and second arguments.
Regression-tested on arm-none-eabi, bootstap in progress on
armv8l-unknown-linux-gnueabihf.
OK for trunk?
Thanks,
Christophe
gcc/ChangeLog:
* config/arm/mve.md: (mve_vrev64q_m_): Add early
clobber.
(mve_vrev64q_m_f): Likewise.
gcc/testsuite/ChangeLog:
* gcc.target/arm/mve/intrinsics/vrev64q_m_s16-clobber.c: New test.
---
gcc/config/arm/mve.md | 4 ++--
.../arm/mve/intrinsics/vrev64q_m_s16-clobber.c | 17 +
2 files changed, 19 insertions(+), 2 deletions(-)
create mode 100644
gcc/testsuite/gcc.target/arm/mve/intrinsics/vrev64q_m_s16-clobber.c
diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
index 714178609f7..62186f124da 100644
--- a/gcc/config/arm/mve.md
+++ b/gcc/config/arm/mve.md
@@ -3503,7 +3503,7 @@ (define_insn "mve_vqshlq_m_r_"
;;
(define_insn "mve_vrev64q_m_"
[
- (set (match_operand:MVE_2 0 "s_register_operand" "=w")
+ (set (match_operand:MVE_2 0 "s_register_operand" "=")
(unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand" "0")
(match_operand:MVE_2 2 "s_register_operand" "w")
(match_operand: 3 "vpr_register_operand"
"Up")]
@@ -4598,7 +4598,7 @@ (define_insn "mve_vrev32q_m_"
;;
(define_insn "mve_vrev64q_m_f"
[
- (set (match_operand:MVE_0 0 "s_register_operand" "=w")
+ (set (match_operand:MVE_0 0 "s_register_operand" "=")
(unspec:MVE_0 [(match_operand:MVE_0 1 "s_register_operand" "0")
(match_operand:MVE_0 2 "s_register_operand" "w")
(match_operand: 3 "vpr_register_operand"
"Up")]
diff --git
a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vrev64q_m_s16-clobber.c
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vrev64q_m_s16-clobber.c
new file mode 100644
index 000..6464c96181d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vrev64q_m_s16-clobber.c
@@ -0,0 +1,17 @@
+/* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
+/* { dg-add-options arm_v8_1m_mve_fp } */
+/* { dg-additional-options "-O2" } */
+
+#include "arm_mve.h"
+
+int16x8_t
+foo (int16x8_t a, mve_pred16_t p)
+{
+ return vrev64q_m_s16 (a, a, p);
+}
+
+float16x8_t
+foo2 (float16x8_t a, mve_pred16_t p)
+{
+ return vrev64q_m_f16 (a, a, p);
+}
--
2.34.1
Re: [PATCH] libstdc++: Use ///< for inline documentation
On Mon, 3 Oct 2022 at 10:29, Arsen Arsenović wrote: > > On Monday, 3 October 2022 10:37:00 CEST Jonathan Wakely wrote: > > I did look into this after you pointed it out on IRC. Unless I fumbled > > my doxygen roll, the results are the same for /// and ///< so maybe > > at some point Doxygen started to DTRT even without the < character. > > It is actually unchanged for the standard IO objects, for some reason. Yes, those are the ones I checked. > The rounding style enum produced different results after this change Ah OK, thanks. I'll apply the patch then. > (for convenience, link below; intermediate is missing, towards_zero is > misdocumented). > > Unsure what the exact rule is, but, AFAICT, ///< is not worse, and on > top of that, clangd interprets it properly (it's how I stumbled upon > this, cout was "Linked to standard output" in its LSP hover response). > > https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a01635.html#a53dbc8572a84ca50272f9e55a1e23e18 > -- > Arsen Arsenović
Re: [PATCH] libstdc++: Use ///< for inline documentation
On Monday, 3 October 2022 10:37:00 CEST Jonathan Wakely wrote: > I did look into this after you pointed it out on IRC. Unless I fumbled > my doxygen roll, the results are the same for /// and ///< so maybe > at some point Doxygen started to DTRT even without the < character. It is actually unchanged for the standard IO objects, for some reason. The rounding style enum produced different results after this change (for convenience, link below; intermediate is missing, towards_zero is misdocumented). Unsure what the exact rule is, but, AFAICT, ///< is not worse, and on top of that, clangd interprets it properly (it's how I stumbled upon this, cout was "Linked to standard output" in its LSP hover response). https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a01635.html#a53dbc8572a84ca50272f9e55a1e23e18 -- Arsen Arsenović signature.asc Description: This is a digitally signed message part.
Re: [patch, RFC. Fortran] Some clobbering for INTENT(OUT) arrays
Hello,
Le 02/10/2022 à 22:07, Thomas Koenig via Fortran a écrit :
I am a bit stuck of how to generate a reference to the first element
of the array (really, just dereferencing the data pointer)
in the most elegant way. I am currently leaning towards
building a gfc_expr, which should work, but would be less
than elegant.
So, anything more elegant at hand?
I don't understand why you are trying to do this.
According to Richi [1], array references are not allowed, so you can
(and actually have to) pick the full variable decl directly.
[1] https://gcc.gnu.org/pipermail/fortran/2022-September/058181.html
A few comments about the rest...
What happens if the
+ if (!sym->attr.allocatable && !sym->attr.pointer
+ && !POINTER_TYPE_P (TREE_TYPE (sym->backend_decl)))
part is taken out is that the whole descriptor can be clobbered in
such a case, which is of course not what is wanted.
The canonical way is to look for GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (...)).
Your way should work in most cases, but there are twisted cases for
which I'm not sure (assumed shape arrays with the value attribute).
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 4f3ae82d39c..bbb00f90a77 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6896,10 +6897,23 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
fsym->attr.pointer);
}
else
- /* This is where we introduce a temporary to store the
- result of a non-lvalue array expression. */
- gfc_conv_array_parameter (, e, nodesc_arg, fsym,
- sym->name, NULL);
+ {
+ /* This is where we introduce a temporary to store the
+result of a non-lvalue array expression. */
+ gfc_conv_array_parameter (, e, nodesc_arg, fsym,
+ sym->name, NULL);
+ if (fsym && fsym->attr.intent == INTENT_OUT
+ && gfc_full_array_ref_p (e->ref, NULL))
The scalar case has a few more conditions this seems to miss.
e->expr_type == EXPR_VARIABLE at least, but also e->ts.type !=
CHARACTER, alloc_comp and finalizable derived types, etc.
+ clobber_array
+ = gfc_build_array_ref
(e->symtree->n.sym->backend_decl,
+build_int_cst (size_type_node,
0),
+NULL_TREE, true, NULL_TREE);
This is picking the decl from the frontend data.
This proved to be problematic in the scalar case, so maybe it would be
better to pick the variable to be clobbered from parmse.expr.
Admittedly I'm not too sure about this, arrays are much more difficult
to work with (and to think about).
@@ -6952,6 +6966,13 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
tmp, build_empty_stmt (input_location));
gfc_add_expr_to_block (>pre, tmp);
}
+
+ if (clobber_array != NULL_TREE)
+ {
+ tree clobber;
+ clobber = build_clobber (TREE_TYPE(clobber_array));
+ gfc_add_modify (, clobber_array, clobber);
+ }
}
}
/* Special case for an assumed-rank dummy argument. */
This can be moved to the preceding hunk.
Re: [PATCH] libstdc++: Use ///< for inline documentation
On Sat, 1 Oct 2022 at 19:43, Arsen Arsenović via Libstdc++
wrote:
>
> I accidentally that some variables were misdocumented when using
> trailing comment for documentation. I ran a search with a relatively
> simple regex[1] to look for any ///s following some code that did not
> have a <, and came up with these instances only.
>
> [1]: \s*([^ ]+\s*)+///[^<].*$
>
> libstdc++-v3/ChangeLog:
> * include/std/iostream: Use ///< for inline documentation.
> * include/std/limits: Likewise.
> * include/experimental/internet: Likewise.
>
> Signed-off-by: Arsen Arsenović
> ---
> Hey,
>
> I just got reminded that I found some trivial documentation errors a few
> months
> ago, and forgot to do anything about them after bringing them up on IRC. This
> patch should fix that.
I did look into this after you pointed it out on IRC. Unless I fumbled
my doxygen roll, the results are the same for /// and ///< so maybe at
some point Doxygen started to DTRT even without the < character.
>
> Thanks,
>
> libstdc++-v3/include/experimental/internet | 2 +-
> libstdc++-v3/include/std/iostream | 16
> libstdc++-v3/include/std/limits| 10 +-
> 3 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/libstdc++-v3/include/experimental/internet
> b/libstdc++-v3/include/experimental/internet
> index 4be4bfb731e..a6b7b235087 100644
> --- a/libstdc++-v3/include/experimental/internet
> +++ b/libstdc++-v3/include/experimental/internet
> @@ -2137,7 +2137,7 @@ namespace ip
> using resolver = basic_resolver; ///< A TCP resolver.
> using socket = basic_stream_socket;///< A TCP socket.
> using acceptor = basic_socket_acceptor; ///< A TCP acceptor.
> -using iostream = basic_socket_iostream; /// A TCP iostream.
> +using iostream = basic_socket_iostream; ///< A TCP iostream.
>
> #ifdef TCP_NODELAY
> /// Disable coalescing of small segments (i.e. the Nagle algorithm).
> diff --git a/libstdc++-v3/include/std/iostream
> b/libstdc++-v3/include/std/iostream
> index d705913f53c..83a238193ce 100644
> --- a/libstdc++-v3/include/std/iostream
> +++ b/libstdc++-v3/include/std/iostream
> @@ -57,16 +57,16 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> * manual linked to above.
>*/
>///@{
> - extern istream cin; /// Linked to standard input
> - extern ostream cout; /// Linked to standard output
> - extern ostream cerr; /// Linked to standard error (unbuffered)
> - extern ostream clog; /// Linked to standard error (buffered)
> + extern istream cin; ///< Linked to standard input
> + extern ostream cout; ///< Linked to standard output
> + extern ostream cerr; ///< Linked to standard error (unbuffered)
> + extern ostream clog; ///< Linked to standard error (buffered)
>
> #ifdef _GLIBCXX_USE_WCHAR_T
> - extern wistream wcin;/// Linked to standard input
> - extern wostream wcout; /// Linked to standard output
> - extern wostream wcerr; /// Linked to standard error (unbuffered)
> - extern wostream wclog; /// Linked to standard error (buffered)
> + extern wistream wcin;///< Linked to standard input
> + extern wostream wcout; ///< Linked to standard output
> + extern wostream wcerr; ///< Linked to standard error (unbuffered)
> + extern wostream wclog; ///< Linked to standard error (buffered)
> #endif
>///@}
>
> diff --git a/libstdc++-v3/include/std/limits b/libstdc++-v3/include/std/limits
> index 66201fa6215..a60611b1b11 100644
> --- a/libstdc++-v3/include/std/limits
> +++ b/libstdc++-v3/include/std/limits
> @@ -166,11 +166,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>*/
>enum float_round_style
>{
> -round_indeterminate = -1,/// Intermediate.
> -round_toward_zero = 0, /// To zero.
> -round_to_nearest = 1, /// To the nearest representable
> value.
> -round_toward_infinity = 2, /// To infinity.
> -round_toward_neg_infinity = 3 /// To negative infinity.
> +round_indeterminate = -1,///< Intermediate.
> +round_toward_zero = 0, ///< To zero.
> +round_to_nearest = 1, ///< To the nearest representable
> value.
> +round_toward_infinity = 2, ///< To infinity.
> +round_toward_neg_infinity = 3 ///< To negative infinity.
>};
>
>/**
> --
> 2.37.3
>
PING [PATCH] gcc/config/t-i386: add build dependencies on i386-builtin-types.inc
On Thu, 22 Sep 2022 22:07:52 +0100 Sergei Trofimovich wrote: > On Fri, 16 Sept 2022 at 19:49, Sergei Trofimovich wrote: > > > > From: Sergei Trofimovich > > > > i386-builtin-types.inc is included indirectly via i386-builtins.h > > into 4 files: i386.cc i386-builtins.cc i386-expand.cc i386-features.cc > > > > Only i386.cc dependency was present in gcc/config/t-i386 makefile. > > > > As a result parallel builds occasionally fail as: > > > > g++ ... -o i386-builtins.o ... > > ../../gcc-13-20220911/gcc/config/i386/i386-builtins.cc > > In file included from > > ../../gcc-13-20220911/gcc/config/i386/i386-builtins.cc:92: > > ../../gcc-13-20220911/gcc/config/i386/i386-builtins.h:25:10: > > fatal error: i386-builtin-types.inc: No such file or directory > >25 | #include "i386-builtin-types.inc" > > | ^~~~ > > compilation terminated. > > make[3]: *** [../../gcc-13-20220911/gcc/config/i386/t-i386:54: > > i386-builtins.o] > > Error 1 shuffle=1663349189 > > > > gcc/ > > * config/i386/t-i386: Add build-time dependencies against > > i386-builtin-types.inc to i386-builtins.o, i386-expand.o, > > i386-features.o. > > --- > > gcc/config/i386/t-i386 | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/gcc/config/i386/t-i386 b/gcc/config/i386/t-i386 > > index 4e2a0efc615..ffdbbdfe8ce 100644 > > --- a/gcc/config/i386/t-i386 > > +++ b/gcc/config/i386/t-i386 > > @@ -62,7 +62,12 @@ i386-features.o: $(srcdir)/config/i386/i386-features.cc > > $(COMPILE) $< > > $(POSTCOMPILE) > > > > +# i386-builtin-types.inc is included into i386-builtins.h. > > +# Below are direct users of i386-builtins.h: > > i386.o: i386-builtin-types.inc > > +i386-builtins.o: i386-builtin-types.inc > > +i386-expand.o: i386-builtin-types.inc > > +i386-features.o: i386-builtin-types.inc > > > > i386-builtin-types.inc: s-i386-bt ; @true > > s-i386-bt: $(srcdir)/config/i386/i386-builtin-types.awk \ > > -- > > 2.37.2 > > > > Is it a reasonable approach? Maybe gcc has an equivalent of automake's > BUILT_SOURCES to avoid explicit tracking of such dependencies? > > -- > Sergei -- Sergei
Re: [patch] Fix thinko in powerpc default specs for -mabi
Hello, Gentle ping for https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602143.html > 2022-09-14 Olivier Hainque > > * config/rs6000/option-defaults.h (OPTION_DEFAULT_SPECS): > Have any -mabi, not only -mabi=elfv*, override the --with-abi > configuration default. As an additional data point, the change gets the rs6000 definition in line with that of arm, mips and riscv. Thanks in advance! Best Regards, Olivier
[PATCH] Set discriminators for call stmts on the same line within the same basic block
This change is based on commit 1e6c4a7a8fb8e20545bb9f9032d3854f3f794c18
by Dehao Chen in vendors/google/heads/gcc-4_8.
Tested on x86_64-pc-linux-gnu.
gcc/ChangeLog:
* tree-cfg.cc (assign_discriminators): Set discriminators for call stmts
on the same line within the same basic block.
---
gcc/tree-cfg.cc | 31 +++
1 file changed, 31 insertions(+)
diff --git a/gcc/tree-cfg.cc b/gcc/tree-cfg.cc
index ade66c54499..8e2a3a5f6c6 100644
--- a/gcc/tree-cfg.cc
+++ b/gcc/tree-cfg.cc
@@ -1203,8 +1203,39 @@ assign_discriminators (void)
{
edge e;
edge_iterator ei;
+ gimple_stmt_iterator gsi;
gimple *last = last_stmt (bb);
location_t locus = last ? gimple_location (last) : UNKNOWN_LOCATION;
+ location_t curr_locus = UNKNOWN_LOCATION;
+ int curr_discr = 0;
+
+ /* Traverse the basic block, if two function calls within a basic block
+ are mapped to the same line, assign a new discriminator because a call
+ stmt could be a split point of a basic block. */
+ for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next ())
+ {
+ gimple *stmt = gsi_stmt (gsi);
+ expanded_location curr_locus_e;
+ if (curr_locus == UNKNOWN_LOCATION)
+ {
+ curr_locus = gimple_location (stmt);
+ curr_locus_e = expand_location (curr_locus);
+ }
+ else if (!same_line_p (curr_locus, _locus_e, gimple_location
(stmt)))
+ {
+ curr_locus = gimple_location (stmt);
+ curr_locus_e = expand_location (curr_locus);
+ curr_discr = 0;
+ }
+ else if (curr_discr != 0)
+ {
+ gimple_set_location (stmt, location_with_discriminator (
+ gimple_location (stmt), curr_discr));
+ }
+ /* Allocate a new discriminator for CALL stmt. */
+ if (gimple_code (stmt) == GIMPLE_CALL)
+ curr_discr = next_discriminator_for_locus (curr_locus);
+ }
if (locus == UNKNOWN_LOCATION)
continue;
--
2.25.1
