Re: [PATCH, V2] Add conversions between _Float128 and Decimal.
On Sat, Mar 27, 2021 at 04:07:18PM +0100, Florian Weimer wrote:
> This issue is still present.
>
> What about the patch below?
>
> Thanks,
> Florian
>
> rs6000: Do not build _Float128/Decimal routines with --disable-decimal-float
>
> Fixes commit 781183595acba67a37c66f59a0c1d9b5fee7e248 ("Add conversions
> between _Float128 and Decimal.).
>
> libgcc/
> * config/rs6000/t-float128 (fp128_ppc_funcs): Add decimal floating
> point functions for $(decimal_float) only.
>
> diff --git a/libgcc/config/rs6000/t-float128 b/libgcc/config/rs6000/t-float128
> index 6fb1a3d871b..b1f00accdf1 100644
> --- a/libgcc/config/rs6000/t-float128
> +++ b/libgcc/config/rs6000/t-float128
> @@ -37,8 +37,11 @@ ibm128_dec_funcs = _tf_to_sd _tf_to_dd _tf_to_td \
> # New functions for software emulation
> fp128_ppc_funcs = floattikf floatuntikf fixkfti fixunskfti \
> extendkftf2-sw trunctfkf2-sw \
> - sfp-exceptions _mulkc3 _divkc3 _powikf2 \
> - $(fp128_dec_funcs) $(fp128_decstr_funcs)
> + sfp-exceptions _mulkc3 _divkc3 _powikf2
> +
> +ifeq ($(decimal_float),yes)
> +fp128_ppc_funcs += $(fp128_dec_funcs) $(fp128_decstr_funcs)
> +endif
>
> fp128_ppc_src= $(addprefix
> $(srcdir)/config/rs6000/,$(addsuffix \
> .c,$(fp128_ppc_funcs)))
>
Here is an updated version of the patch that works with the change that I
checked in today. It works on a little endian power9 system with the stage1
builds for 3 compilers built with the 3 different long double types (IEEE, IBM,
64-bit). The bootstrap builds will be starting shortly.
Honor --disable-decimal-float on PowerPC Decimal/Float128 conversions
This patch fixes the problem that the Decimal <-> Float128 conversions
were built even if the user configured GCC with --disable-decimal-float.
libgcc/
2021-03-29 Florian Weimer
Michael Meissner
* config/rs6000/t-float128 (fp128_ppc_funcs): Add decimal floating
point functions for $(decimal_float) only.
---
libgcc/config/rs6000/t-float128 | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libgcc/config/rs6000/t-float128 b/libgcc/config/rs6000/t-float128
index 8b089d4433c..d745f0d82e1 100644
--- a/libgcc/config/rs6000/t-float128
+++ b/libgcc/config/rs6000/t-float128
@@ -33,8 +33,11 @@ ibm128_dec_funcs = _tf_to_sd _tf_to_dd _tf_to_td \
# New functions for software emulation
fp128_ppc_funcs= floattikf floatuntikf fixkfti fixunskfti \
extendkftf2-sw trunctfkf2-sw \
- sfp-exceptions _mulkc3 _divkc3 _powikf2 \
- $(fp128_dec_funcs)
+ sfp-exceptions _mulkc3 _divkc3 _powikf2
+
+ifeq ($(decimal_float),yes)
+fp128_ppc_funcs+= $(fp128_dec_funcs)
+endif
fp128_ppc_src = $(addprefix $(srcdir)/config/rs6000/,$(addsuffix \
.c,$(fp128_ppc_funcs)))
--
2.22.0
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
Re: [PATCH] rs6000: Enable 32bit variable vec_insert [PR99718]
Hi! On Fri, Mar 26, 2021 at 10:26:57PM -0500, Xionghu Luo wrote: > 32bit and P7 VSX could also benefit a lot from the variable vec_insert > implementation with shift/insert/shift back method. > * config/rs6000/altivec.md (altivec_lvsl_reg): Change to ... > (altivec_lvsl_reg_): ... this. > (altivec_lvsr_reg): Change to ... > (altivec_lvsr_reg_): ... this. This could use parameterised names. I'll handle that in a follow-up. > * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): > Enable 32bit variable vec_insert for all TARGET_VSX. I don't see why this is only for 32 bit? It looks correct though. > * config/rs6000/vector.md: Use vec_set_index_operand. That should be * config/rs6000/vector.md (vec_set): Use vec_set_index_operand. > -(define_insn "altivec_lvsl_reg" > +(define_insn "altivec_lvsl_reg_" >[(set (match_operand:V16QI 0 "altivec_register_operand" "=v") > (unspec:V16QI > - [(match_operand:DI 1 "gpc_reg_operand" "b")] > + [(match_operand:SDI 1 "gpc_reg_operand" "b")] > UNSPEC_LVSL_REG))] SDI isn't correct: you do not want DImode here with -mno-powerpc64. Instead, you want :GPR. > +;; Return true if TARGET_VSX for vec_set with variable index. > +(define_predicate "vec_set_index_operand" > + (if_then_else (match_test "TARGET_VSX") > + (match_operand 0 "reg_or_cint_operand") > + (match_operand 0 "const_int_operand"))) That comment isn't so great. I'll make it ;; Return 1 if this operand is valid as the index for vec_set. Btw, add new code at an appropriate spot, not at the end of file. You'll get fewer patch conflicts, as happy by-effect. > + rtx (*gen_ashl)(rtx, rtx, rtx); > + rtx (*gen_lvsl)(rtx, rtx); > + rtx (*gen_lvsr)(rtx, rtx); All this stuff will be unneeded with parameterised names :-) I'll fix up the nits and commit it for you, as we discussed. Thank you! Segher
[Ada] Fix PR ada/99802
This is a regression present on the mainline: the compiler fails to assign an aggregate to a full-access component (i.e. Atomic or VFA) as a whole if the type of the component is not full access itself. Tested on x86-64/Linux, applied on the mainline. 2021-03-29 Eric Botcazou PR ada/99802 * freeze.adb (Is_Full_Access_Aggregate): Call Is_Full_Access_Object on the name of an N_Assignment_Statement to spot full access. -- Eric Botcazoudiff --git a/gcc/ada/freeze.adb b/gcc/ada/freeze.adb index 8dc8a222396..da14af9b8bd 100644 --- a/gcc/ada/freeze.adb +++ b/gcc/ada/freeze.adb @@ -1754,8 +1754,7 @@ package body Freeze is Typ := Etype (Name (Par)); if not Is_Full_Access (Typ) - and then not (Is_Entity_Name (Name (Par)) - and then Is_Full_Access (Entity (Name (Par + and then not Is_Full_Access_Object (Name (Par)) then return False; end if;
Re: [PATCH] Complete __gnu_debug::basic_string
On 25/03/21 4:29 pm, Jonathan Wakely wrote:
Oh, it's the same generate(sz) bug as you already found. But I've
found other bugs, e.g. with GLIBCXX_SEED_TEST_RNG=1908970375).
I think we should also add a check for non-empty containers to those
test functions, and ensure we don't try to erase from empty
containers (see attached).
I had a look at this patch and on my side I was more thinking about
avoiding empty containers in the first place.
What do you think ?
François
diff --git a/libstdc++-v3/testsuite/util/exception/safety.h b/libstdc++-v3/testsuite/util/exception/safety.h
index 54449d2f7bb..6940f2f765d 100644
--- a/libstdc++-v3/testsuite/util/exception/safety.h
+++ b/libstdc++-v3/testsuite/util/exception/safety.h
@@ -55,14 +55,14 @@ namespace __gnu_test
// Return randomly generated integer on range [0, __max_size].
static size_type
-generate(size_type __max_size)
+generate(size_type __max_size, size_type __min_size = 0)
{
using param_type = typename distribution_type::param_type;
// Make the engine and distribution static...
static engine_type engine = get_engine();
static distribution_type distribution;
- return distribution(engine, param_type{0, __max_size});
+ return distribution(engine, param_type{__min_size, __max_size});
}
// Given an instantiating type, return a unique value.
@@ -198,7 +198,8 @@ namespace __gnu_test
// Size test container.
const size_type max_elements = 100;
- size_type n = generate(max_elements);
+ const size_type min_elements = 10;
+ size_type n = generate(max_elements, min_elements);
// Construct new container.
make_container_n made(n);
Re: Fix typo in ipa-modref
> > >gcc/testsuite/ChangeLog: > > > > > >2021-03-29 Jan Hubicka > > > > > > * gcc.c-torture/compile/pr99751.c: New test. > > > > Why compile torture? > > Ah, sorry, it was meant to be execute. I will move the test. It is now renamed as https://gcc.gnu.org/g:7b6ca93b2d57ead352cd5cc3e10be4c33dda674b PR ipa/99751 * gcc.c-torture/compile/pr99751.c: Rename from ... * gcc.c-torture/execute/pr99751.c: ... to this. diff --git a/gcc/testsuite/gcc.c-torture/compile/pr99751.c b/gcc/testsuite/gcc.c-torture/execute/pr99751.c similarity index 100% rename from gcc/testsuite/gcc.c-torture/compile/pr99751.c rename to gcc/testsuite/gcc.c-torture/execute/pr99751.c > > Honza
Re: Fix typo in ipa-modref
> >gcc/testsuite/ChangeLog: > > > >2021-03-29 Jan Hubicka > > > > * gcc.c-torture/compile/pr99751.c: New test. > > Why compile torture? Ah, sorry, it was meant to be execute. I will move the test. Honza
Re: [PATCH 2/3] libstdc++: Simplify copy-pasted algorithms in
On Mon, 29 Mar 2021, Patrick Palka wrote:
> The header currently copies some simple algorithms from
> , which was originally done in order to avoid a
> circular dependency with the header. This is no longer an issue since
> the latter header now includes instead of all of
> .
>
> This means we could now just include and remove the
> copied algorithms, but that would double the size of .
Whoops, more like increase the size of by ~10% (33k SLOC -> 37k).
> And we
> can't use the corresponding STL-style algorithms here because they
> assume input iterators are copyable. So this patch instead simplifies
> these copied algorithms, removing their constraints and unused
> parameters, and keeps them around. In a subsequent patch we're going to
> copy ranges::find into as well.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (__detail::find_if): Simplify.
> (__detail::find_if_not): Likewise.
> (__detail::min): Remove.
> (__detail::mismatch): Simplify.
> (take_view::size): Use std::min instead of __detail::min.
> ---
> libstdc++-v3/include/std/ranges | 59 ++---
> 1 file changed, 17 insertions(+), 42 deletions(-)
>
> diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
> index cfcbcaba065..9077271e4e6 100644
> --- a/libstdc++-v3/include/std/ranges
> +++ b/libstdc++-v3/include/std/ranges
> @@ -978,65 +978,40 @@ namespace views::__adaptor
>using all_t = decltype(all(std::declval<_Range>()));
>} // namespace views
>
> - // XXX: the following algos are copied from ranges_algo.h to avoid a
> circular
> - // dependency with that header.
> + // The following simple algos are transcribed from ranges_algo.h to avoid
> + // having to include that entire header.
>namespace __detail
>{
> -template _Sent,
> - typename _Proj = identity,
> - indirect_unary_predicate> _Pred>
> +template
>constexpr _Iter
> - find_if(_Iter __first, _Sent __last, _Pred __pred, _Proj __proj = {})
> + find_if(_Iter __first, _Sent __last, _Pred __pred)
>{
> while (__first != __last
> - && !(bool)std::__invoke(__pred, std::__invoke(__proj, *__first)))
> +&& !(bool)std::__invoke(__pred, *__first))
> ++__first;
> return __first;
>}
>
> -template _Sent,
> - typename _Proj = identity,
> - indirect_unary_predicate> _Pred>
> +template
>constexpr _Iter
> - find_if_not(_Iter __first, _Sent __last, _Pred __pred, _Proj __proj =
> {})
> + find_if_not(_Iter __first, _Sent __last, _Pred __pred)
>{
> while (__first != __last
> - && (bool)std::__invoke(__pred, std::__invoke(__proj, *__first)))
> +&& (bool)std::__invoke(__pred, *__first))
> ++__first;
> return __first;
>}
>
> -template - indirect_strict_weak_order>
> -_Comp = ranges::less>
> - constexpr const _Tp&
> - min(const _Tp& __a, const _Tp& __b, _Comp __comp = {}, _Proj __proj =
> {})
> - {
> - if (std::__invoke(std::move(__comp),
> - std::__invoke(__proj, __b),
> - std::__invoke(__proj, __a)))
> - return __b;
> - else
> - return __a;
> - }
> -
> -template _Sent1,
> - input_iterator _Iter2, sentinel_for<_Iter2> _Sent2,
> - typename _Pred = ranges::equal_to,
> - typename _Proj1 = identity, typename _Proj2 = identity>
> - requires indirectly_comparable<_Iter1, _Iter2, _Pred, _Proj1, _Proj2>
> +template _Sent2>
>constexpr pair<_Iter1, _Iter2>
> - mismatch(_Iter1 __first1, _Sent1 __last1, _Iter2 __first2, _Sent2
> __last2,
> -_Pred __pred = {}, _Proj1 __proj1 = {}, _Proj2 __proj2 = {})
> + mismatch(_Iter1 __first1, _Sent1 __last1, _Iter2 __first2, _Sent2
> __last2)
>{
> while (__first1 != __last1 && __first2 != __last2
> -&& (bool)std::__invoke(__pred,
> - std::__invoke(__proj1, *__first1),
> - std::__invoke(__proj2, *__first2)))
> - {
> - ++__first1;
> - ++__first2;
> - }
> +&& (bool)ranges::equal_to{}(*__first1, *__first2))
> + {
> + ++__first1;
> + ++__first2;
> + }
> return { std::move(__first1), std::move(__first2) };
>}
>} // namespace __detail
> @@ -1847,14 +1822,14 @@ namespace views::__adaptor
>size() requires sized_range<_Vp>
>{
> auto __n = ranges::size(_M_base);
> - return __detail::min(__n, static_cast(_M_count));
> + return std::min(__n, static_cast(_M_count));
>}
>
>constexpr auto
>size() const requires sized_range
>{
> auto __n = ranges::size(_M_base);
> - return __detail::min(__n, static_cast(_M_count));
> + return std::min(__n,
[PATCH 3/3] libstdc++: Fix split_view::_OuterIter::operator++ [LWG 3505]
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::find): Define.
(split_view::_OuterIter::operator++): Apply proposed resolution
of LWG 3505.
* testsuite/std/ranges/adaptors/split.cc (test10): New test.
---
libstdc++-v3/include/std/ranges | 28 ---
.../testsuite/std/ranges/adaptors/split.cc| 12
2 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 9077271e4e6..baec8c0efef 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -982,6 +982,16 @@ namespace views::__adaptor
// having to include that entire header.
namespace __detail
{
+template
+ constexpr _Iter
+ find(_Iter __first, _Sent __last, const _Tp& __value)
+ {
+ while (__first != __last
+ && !(bool)(*__first == __value))
+ ++__first;
+ return __first;
+ }
+
template
constexpr _Iter
find_if(_Iter __first, _Sent __last, _Pred __pred)
@@ -2656,21 +2666,31 @@ namespace views::__adaptor
constexpr _OuterIter&
operator++()
{
+ // _GLIBCXX_RESOLVE_LIB_DEFECTS
+ // 3505. split_view::outer-iterator::operator++ misspecified
const auto __end = ranges::end(_M_parent->_M_base);
if (__current() == __end)
return *this;
const auto [__pbegin, __pend] = subrange{_M_parent->_M_pattern};
if (__pbegin == __pend)
++__current();
+ else if constexpr (__detail::__tiny_range<_Pattern>)
+ {
+ __current() = __detail::find(std::move(__current()), __end,
+*__pbegin);
+ if (__current() != __end)
+ ++__current();
+ }
else
do
{
auto [__b, __p]
- = __detail::mismatch(std::move(__current()), __end,
-__pbegin, __pend);
- __current() = std::move(__b);
+ = __detail::mismatch(__current(), __end, __pbegin, __pend);
if (__p == __pend)
- break;
+ {
+ __current() = __b;
+ break;
+ }
} while (++__current() != __end);
return *this;
}
diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/split.cc
b/libstdc++-v3/testsuite/std/ranges/adaptors/split.cc
index b9fb3728708..9d2cfa8632a 100644
--- a/libstdc++-v3/testsuite/std/ranges/adaptors/split.cc
+++ b/libstdc++-v3/testsuite/std/ranges/adaptors/split.cc
@@ -182,6 +182,17 @@ test09()
static_assert(requires { adapt2(s); });
}
+void
+test10()
+{
+ // LWG 3505
+ auto to_string = [] (auto r) {
+return std::string(r.begin(), ranges::next(r.begin(), r.end()));
+ };
+ auto v = "xxyx"sv | views::split("xy"sv) | views::transform(to_string);
+ VERIFY( ranges::equal(v, (std::string_view[]){"x", "x"}) );
+}
+
int
main()
{
@@ -194,4 +205,5 @@ main()
test07();
test08();
test09();
+ test10();
}
--
2.31.1.133.g84d06cdc06
[PATCH 2/3] libstdc++: Simplify copy-pasted algorithms in
The header currently copies some simple algorithms from
, which was originally done in order to avoid a
circular dependency with the header. This is no longer an issue since
the latter header now includes instead of all of
.
This means we could now just include and remove the
copied algorithms, but that would double the size of . And we
can't use the corresponding STL-style algorithms here because they
assume input iterators are copyable. So this patch instead simplifies
these copied algorithms, removing their constraints and unused
parameters, and keeps them around. In a subsequent patch we're going to
copy ranges::find into as well.
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::find_if): Simplify.
(__detail::find_if_not): Likewise.
(__detail::min): Remove.
(__detail::mismatch): Simplify.
(take_view::size): Use std::min instead of __detail::min.
---
libstdc++-v3/include/std/ranges | 59 ++---
1 file changed, 17 insertions(+), 42 deletions(-)
diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index cfcbcaba065..9077271e4e6 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -978,65 +978,40 @@ namespace views::__adaptor
using all_t = decltype(all(std::declval<_Range>()));
} // namespace views
- // XXX: the following algos are copied from ranges_algo.h to avoid a circular
- // dependency with that header.
+ // The following simple algos are transcribed from ranges_algo.h to avoid
+ // having to include that entire header.
namespace __detail
{
-template _Sent,
-typename _Proj = identity,
-indirect_unary_predicate> _Pred>
+template
constexpr _Iter
- find_if(_Iter __first, _Sent __last, _Pred __pred, _Proj __proj = {})
+ find_if(_Iter __first, _Sent __last, _Pred __pred)
{
while (__first != __last
- && !(bool)std::__invoke(__pred, std::__invoke(__proj, *__first)))
+ && !(bool)std::__invoke(__pred, *__first))
++__first;
return __first;
}
-template _Sent,
-typename _Proj = identity,
-indirect_unary_predicate> _Pred>
+template
constexpr _Iter
- find_if_not(_Iter __first, _Sent __last, _Pred __pred, _Proj __proj = {})
+ find_if_not(_Iter __first, _Sent __last, _Pred __pred)
{
while (__first != __last
- && (bool)std::__invoke(__pred, std::__invoke(__proj, *__first)))
+ && (bool)std::__invoke(__pred, *__first))
++__first;
return __first;
}
-template>
- _Comp = ranges::less>
- constexpr const _Tp&
- min(const _Tp& __a, const _Tp& __b, _Comp __comp = {}, _Proj __proj = {})
- {
- if (std::__invoke(std::move(__comp),
- std::__invoke(__proj, __b),
- std::__invoke(__proj, __a)))
- return __b;
- else
- return __a;
- }
-
-template _Sent1,
-input_iterator _Iter2, sentinel_for<_Iter2> _Sent2,
-typename _Pred = ranges::equal_to,
-typename _Proj1 = identity, typename _Proj2 = identity>
- requires indirectly_comparable<_Iter1, _Iter2, _Pred, _Proj1, _Proj2>
+template
constexpr pair<_Iter1, _Iter2>
- mismatch(_Iter1 __first1, _Sent1 __last1, _Iter2 __first2, _Sent2
__last2,
- _Pred __pred = {}, _Proj1 __proj1 = {}, _Proj2 __proj2 = {})
+ mismatch(_Iter1 __first1, _Sent1 __last1, _Iter2 __first2, _Sent2
__last2)
{
while (__first1 != __last1 && __first2 != __last2
- && (bool)std::__invoke(__pred,
- std::__invoke(__proj1, *__first1),
- std::__invoke(__proj2, *__first2)))
- {
- ++__first1;
- ++__first2;
- }
+ && (bool)ranges::equal_to{}(*__first1, *__first2))
+ {
+ ++__first1;
+ ++__first2;
+ }
return { std::move(__first1), std::move(__first2) };
}
} // namespace __detail
@@ -1847,14 +1822,14 @@ namespace views::__adaptor
size() requires sized_range<_Vp>
{
auto __n = ranges::size(_M_base);
- return __detail::min(__n, static_cast(_M_count));
+ return std::min(__n, static_cast(_M_count));
}
constexpr auto
size() const requires sized_range
{
auto __n = ranges::size(_M_base);
- return __detail::min(__n, static_cast(_M_count));
+ return std::min(__n, static_cast(_M_count));
}
};
--
2.31.1.133.g84d06cdc06
[PATCH 1/3] libstdc++: Fix elements_view::operator* and operator[] [LWG 3502]
While we're modifying elements_view, this also implements the one-line
resolution of LWG 3492.
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::__returnable_element): New
concept.
(elements_view): Use this concept in its constraints. Add
missing private access specifier.
(elements_view::_S_get_element): Define as per LWG 3502.
(elements_view::operator*, elements_view::operator[]): Use
_S_get_element.
(elements_view::operator++): Remove unnecessary constraint
as per LWG 3492.
* testsuite/std/ranges/adaptors/elements.cc (test05): New test.
---
libstdc++-v3/include/std/ranges | 26 ---
.../testsuite/std/ranges/adaptors/elements.cc | 16
2 files changed, 38 insertions(+), 4 deletions(-)
diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 978578197dc..cfcbcaba065 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -3234,6 +3234,10 @@ namespace views::__adaptor
{ std::get<_Nm>(__t) }
-> convertible_to&>;
};
+
+template
+ concept __returnable_element
+ = is_reference_v<_Tp> || move_constructible>;
}
template
@@ -3241,6 +3245,7 @@ namespace views::__adaptor
&& __detail::__has_tuple_element, _Nm>
&&
__detail::__has_tuple_element>,
_Nm>
+ && __detail::__returnable_element, _Nm>
class elements_view : public view_interface>
{
public:
@@ -3298,10 +3303,23 @@ namespace views::__adaptor
template
struct _Iterator
{
+ private:
using _Base = __detail::__maybe_const_t<_Const, _Vp>;
iterator_t<_Base> _M_current = iterator_t<_Base>();
+ static constexpr decltype(auto)
+ _S_get_element(const iterator_t<_Base>& __i)
+ {
+ if constexpr (is_reference_v>)
+ return std::get<_Nm>(*__i);
+ else
+ {
+ using _Et = remove_cv_t>>;
+ return static_cast<_Et>(std::get<_Nm>(*__i));
+ }
+ }
+
friend _Iterator;
public:
@@ -3334,8 +3352,8 @@ namespace views::__adaptor
{ return std::move(_M_current); }
constexpr decltype(auto)
- operator*() const
- { return std::get<_Nm>(*_M_current); }
+ operator*() const
+ { return _S_get_element(_M_current); }
constexpr _Iterator&
operator++()
@@ -3345,7 +3363,7 @@ namespace views::__adaptor
}
constexpr void
- operator++(int) requires (!forward_range<_Base>)
+ operator++(int)
{ ++_M_current; }
constexpr _Iterator
@@ -3390,7 +3408,7 @@ namespace views::__adaptor
constexpr decltype(auto)
operator[](difference_type __n) const
requires random_access_range<_Base>
- { return std::get<_Nm>(*(_M_current + __n)); }
+ { return _S_get_element(_M_current + __n); }
friend constexpr bool
operator==(const _Iterator& __x, const _Iterator& __y)
diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/elements.cc
b/libstdc++-v3/testsuite/std/ranges/adaptors/elements.cc
index b0d122f8db5..134afd6a873 100644
--- a/libstdc++-v3/testsuite/std/ranges/adaptors/elements.cc
+++ b/libstdc++-v3/testsuite/std/ranges/adaptors/elements.cc
@@ -100,6 +100,21 @@ test04()
static_assert(!requires { 0 | elements; });
}
+void
+test05()
+{
+ // LWG 3502
+ std::vector vec = {42};
+ auto r1 = vec
+| views::transform([](auto c) { return std::make_tuple(c, c); })
+| views::keys;
+ VERIFY( ranges::equal(r1, (int[]){42}) );
+
+ std::tuple a[] = {{1,2},{3,4}};
+ auto r2 = a | views::keys;
+ VERIFY( r2[0] == 1 && r2[1] == 3 );
+}
+
int
main()
{
@@ -107,4 +122,5 @@ main()
test02();
test03();
test04();
+ test05();
}
--
2.31.1.133.g84d06cdc06
Re: [PATCH v2] C++ : Add the -stdlib= option.
Hi Iain, could you add a note about this change to the
gcc-11/changes.html page? There are probably some people who would be
interested in this who could use a note about it. Thanks
On Tue, Dec 22, 2020 at 3:53 PM Jason Merrill via Gcc-patches
wrote:
>
> On 12/22/20 3:39 PM, Iain Sandoe wrote:
> > Hi Jason,
> >
> > Jason Merrill wrote:
> >
> >> On 11/11/20 3:58 PM, Iain Sandoe wrote:
> >
> >>> This option allows the user to specify alternate C++ runtime libraries,
> >>> for example when a platform uses libc++ as the installed C++ runtime.
> >>> It is the same spelling as a clang option that allows that to use
> >>> libstdc++.
> >>> I have had this patch for some time now (more than a year) on Darwin
> >>> branches.
> >>>
> >
> >>> + /* Which standard library to link.
> >>> + 1 = libstdc++
> >>> + 2 = libc++. */
> >>> + int which_library = 1;
> >>
> >> Even if this variable is an int, let's introduce an enum for comparing it
> >> to specific values.
> >
> > done - it is also noted that it must track the enum in the opt file.
> >
> >>> @@ -264,6 +293,8 @@ lang_specific_driver (struct cl_decoded_option
> >>> **in_decoded_options,
> >>> /* Add one for shared_libgcc or extra static library. */
> >>> num_args = argc + added + need_math + (library > 0) * 4 + 1;
> >>> + if (which_library > 1 && LIBCXXABI != NULL)
> >>> +num_args += 4;
> >>
> >> Why does libc++ need more args than libstdc++? Please add a comment.
> >
> > done (JFTR, it’s because libc++ doesn’t include the abi library for most
> > platforms, so that also has to be
> > appended to the link line).
> >
> >>> +#ifdef GPLUSPLUS_LIBCXX_INCLUDE_DIR
> >>> +/* Pick up libc++ include files, if we have -stdlib=libc++. */
> >>> +{ GPLUSPLUS_LIBCXX_INCLUDE_DIR, "G++", 2, 1,
> >>
> >> If you're going to give cplusplus a non-boolean value, the comment in
> >> cppdefault.h needs to reflect that.
> >
> > done.
> >
> > (re-)tested on x86_64-darwin{11,16,17,19, 20} with the installed libc++ and
> > x86_64-linux-gnu with an
> > LLVM-9 build. Bootstrapped and smoke-tested for libc++ (regular testing
> > for libstdc++).
> >
> > OK for master now?
>
> OK.
>
> > thanks
> > Iain
> >
> > revised patch
> >
> >
> > This option allows the user to specifiy alternate C++ runtime libraries,
> > for example when a platform uses libc++ as the installed C++ runtime.
> >
> > We introduce the command line option: -stdlib= which is the user-facing
> > mechanism to select the C++ runtime to be used when compiling and linking
> > code. This is the same option spelling as that used by clang to allow the
> > use of libstdc++.
> >
> > The availability (and thus function) of the option are a configure-time
> > choice using the configuration control:
> > --with-gxx-libcxx-include-dir=
> >
> > Specification of the path for the libc++ headers, enables the -stdlib=
> > option (using the path as given), default values are set when the path
> > is unconfigured.
> >
> > If --with-gxx-libcxx-include-dir is given together with --with-sysroot=,
> > then we test to see if the include path starts with the sysroot and, if so,
> > record the sysroot-relative component as the local path. At runtime, we
> > prepend the sysroot that is actually active.
> >
> > At link time, we use the C++ runtime in force and (if that is libc++) also
> > append the libc++abi ABI library. As for other cases, if a target sets the
> > name pointer for the ABI library to NULL the G++ driver will omit it from
> > the link line.
> >
> > gcc/ChangeLog:
> >
> > * configure.ac: Add gxx-libcxx-include-dir handled
> > in the same way as the regular cxx header directory.
> > * Makefile.in: Regenerated.
> > * config.in: Likewise.
> > * configure: Likewise.
> > * cppdefault.c: Pick up libc++ headers if the option
> > is enabled.
> > * cppdefault.h (struct default_include): Amend comments
> > to reflect the extended use of the cplusplus field.
> > * incpath.c (add_standard_paths): Allow for multiple
> > c++ header include path variants.
> > * doc/invoke.texi: Document the -stdlib= option.
> >
> > gcc/c-family/ChangeLog:
> >
> > * c.opt: Add -stdlib= option and enumerations for
> > libstdc++ and libc++.
> >
> > gcc/cp/ChangeLog:
> >
> > * g++spec.c (LIBCXX, LIBCXX_PROFILE, LIBCXX_STATIC): New.
> > (LIBCXXABI, LIBCXXABI_PROFILE, LIBCXXABI_STATIC): New.
> > (enum stdcxxlib_kind): New.
> > (lang_specific_driver): Allow selection amongst multiple
> > c++ runtime libraries.
> > ---
> > gcc/Makefile.in | 6
> > gcc/c-family/c.opt | 14 +
> > gcc/config.in | 6
> > gcc/configure | 57 --
> > gcc/configure.ac| 44 +++
> > gcc/cp/g++spec.c| 74 -
> > gcc/cppdefault.c| 5 +++
> > gcc/cppdefault.h| 7 -
> >
Re: Fix typo in ipa-modref
On March 29, 2021 8:11:51 PM GMT+02:00, Jan Hubicka wrote:
>Hi,
>this patch fixes if (deref) that is reversed in merge_call_lhs_flags.
>I re-run stats on cc1plus that seems comparable to last run.
>
>Bootstrapped/regtested x86_64-linux.
>
>Alias oracle query stats:
>
>refs_may_alias_p: 66575703 disambiguations, 76462658 queries
>
>ref_maybe_used_by_call_p: 364568 disambiguations, 67280898 queries
>
>call_may_clobber_ref_p: 217587 disambiguations, 221304 queries
>
>nonoverlapping_component_refs_p: 0 disambiguations, 36514 queries
>
>nonoverlapping_refs_since_match_p: 17351 disambiguations, 61127 must
>overlaps, 79253 queries
>aliasing_component_refs_p: 64537 disambiguations, 2076259 queries
>
>TBAA oracle: 24082735 disambiguations 57590168 queries
>
> 11651231 are in alias set 0
> 10865812 queries asked about the same object
> 132 queries asked about the same alias set
> 0 access volatile
> 9473619 are dependent in the DAG
> 1516639 are aritificially in conflict with void *
>
>Modref stats:
>
>modref use: 13892 disambiguations, 409262 queries
>
>modref clobber: 1358267 disambiguations, 15950909 queries
>
>3287388 tbaa queries (0.206094 per modref query)
>
>519328 base compares (0.032558 per modref query)
>
>
>PTA query stats:
>
>pt_solution_includes: 11809203 disambiguations, 19340135 queries
>
>pt_solutions_intersect: 1217666 disambiguations, 13770732 queries
>
>
>gcc/ChangeLog:
>
>2021-03-29 Jan Hubicka
>
> * ipa-modref.c (merge_call_lhs_flags): Correct handling of deref.
> (analyze_ssa_name_flags): Fix typo in comment.
>
>gcc/testsuite/ChangeLog:
>
>2021-03-29 Jan Hubicka
>
> * gcc.c-torture/compile/pr99751.c: New test.
Why compile torture?
>diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
>index 7aaf53be8f4..5f33bb5b410 100644
>--- a/gcc/ipa-modref.c
>+++ b/gcc/ipa-modref.c
>@@ -1545,9 +1545,9 @@ merge_call_lhs_flags (gcall *call, int arg, int
>index, bool deref,
> tree lhs = gimple_call_lhs (call);
> analyze_ssa_name_flags (lhs, lattice, depth + 1, ipa);
> if (deref)
>- lattice[index].merge (lattice[SSA_NAME_VERSION (lhs)]);
>- else
> lattice[index].merge_deref (lattice[SSA_NAME_VERSION (lhs)], false);
>+ else
>+ lattice[index].merge (lattice[SSA_NAME_VERSION (lhs)]);
> }
> /* In the case of memory store we can do nothing. */
> else
>@@ -1621,7 +1621,7 @@ analyze_ssa_name_flags (tree name,
>vec , int depth,
> else if (gcall *call = dyn_cast (use_stmt))
> {
> tree callee = gimple_call_fndecl (call);
>-/* Return slot optiomization would require bit of propagation;
>+/* Return slot optimization would require bit of propagation;
>give up for now. */
> if (gimple_call_return_slot_opt_p (call)
> && gimple_call_lhs (call) != NULL_TREE
>diff --git a/gcc/testsuite/gcc.c-torture/compile/pr99751.c
>b/gcc/testsuite/gcc.c-torture/compile/pr99751.c
>new file mode 100644
>index 000..f1d5101c359
>--- /dev/null
>+++ b/gcc/testsuite/gcc.c-torture/compile/pr99751.c
>@@ -0,0 +1,20 @@
>+int *ptr1 = 0, **ptr2 =
>+
>+int *identity(int *p)
>+{
>+ return p;
>+}
>+
>+void store_to_c(int *p)
>+{
>+ *ptr2 = identity(p);
>+}
>+
>+int main()
>+{
>+ int f;
>+ store_to_c();
>+ if (ptr1 != )
>+__builtin_abort();
>+ return 0;
>+}
Fix typo in ipa-modref
Hi,
this patch fixes if (deref) that is reversed in merge_call_lhs_flags.
I re-run stats on cc1plus that seems comparable to last run.
Bootstrapped/regtested x86_64-linux.
Alias oracle query stats:
refs_may_alias_p: 66575703 disambiguations, 76462658 queries
ref_maybe_used_by_call_p: 364568 disambiguations, 67280898 queries
call_may_clobber_ref_p: 217587 disambiguations, 221304 queries
nonoverlapping_component_refs_p: 0 disambiguations, 36514 queries
nonoverlapping_refs_since_match_p: 17351 disambiguations, 61127 must
overlaps, 79253 queries
aliasing_component_refs_p: 64537 disambiguations, 2076259 queries
TBAA oracle: 24082735 disambiguations 57590168 queries
11651231 are in alias set 0
10865812 queries asked about the same object
132 queries asked about the same alias set
0 access volatile
9473619 are dependent in the DAG
1516639 are aritificially in conflict with void *
Modref stats:
modref use: 13892 disambiguations, 409262 queries
modref clobber: 1358267 disambiguations, 15950909 queries
3287388 tbaa queries (0.206094 per modref query)
519328 base compares (0.032558 per modref query)
PTA query stats:
pt_solution_includes: 11809203 disambiguations, 19340135 queries
pt_solutions_intersect: 1217666 disambiguations, 13770732 queries
gcc/ChangeLog:
2021-03-29 Jan Hubicka
* ipa-modref.c (merge_call_lhs_flags): Correct handling of deref.
(analyze_ssa_name_flags): Fix typo in comment.
gcc/testsuite/ChangeLog:
2021-03-29 Jan Hubicka
* gcc.c-torture/compile/pr99751.c: New test.
diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index 7aaf53be8f4..5f33bb5b410 100644
--- a/gcc/ipa-modref.c
+++ b/gcc/ipa-modref.c
@@ -1545,9 +1545,9 @@ merge_call_lhs_flags (gcall *call, int arg, int index,
bool deref,
tree lhs = gimple_call_lhs (call);
analyze_ssa_name_flags (lhs, lattice, depth + 1, ipa);
if (deref)
- lattice[index].merge (lattice[SSA_NAME_VERSION (lhs)]);
- else
lattice[index].merge_deref (lattice[SSA_NAME_VERSION (lhs)], false);
+ else
+ lattice[index].merge (lattice[SSA_NAME_VERSION (lhs)]);
}
/* In the case of memory store we can do nothing. */
else
@@ -1621,7 +1621,7 @@ analyze_ssa_name_flags (tree name, vec
, int depth,
else if (gcall *call = dyn_cast (use_stmt))
{
tree callee = gimple_call_fndecl (call);
- /* Return slot optiomization would require bit of propagation;
+ /* Return slot optimization would require bit of propagation;
give up for now. */
if (gimple_call_return_slot_opt_p (call)
&& gimple_call_lhs (call) != NULL_TREE
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr99751.c
b/gcc/testsuite/gcc.c-torture/compile/pr99751.c
new file mode 100644
index 000..f1d5101c359
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr99751.c
@@ -0,0 +1,20 @@
+int *ptr1 = 0, **ptr2 =
+
+int *identity(int *p)
+{
+ return p;
+}
+
+void store_to_c(int *p)
+{
+ *ptr2 = identity(p);
+}
+
+int main()
+{
+ int f;
+ store_to_c();
+ if (ptr1 != )
+__builtin_abort();
+ return 0;
+}
Re: [PATCH, V2] Add conversions between _Float128 and Decimal.
On Sat, Mar 27, 2021 at 04:07:18PM +0100, Florian Weimer wrote:
> This issue is still present.
>
> What about the patch below?
>
> Thanks,
> Florian
>
> rs6000: Do not build _Float128/Decimal routines with --disable-decimal-float
>
> Fixes commit 781183595acba67a37c66f59a0c1d9b5fee7e248 ("Add conversions
> between _Float128 and Decimal.).
>
> libgcc/
> * config/rs6000/t-float128 (fp128_ppc_funcs): Add decimal floating
> point functions for $(decimal_float) only.
>
> diff --git a/libgcc/config/rs6000/t-float128 b/libgcc/config/rs6000/t-float128
> index 6fb1a3d871b..b1f00accdf1 100644
> --- a/libgcc/config/rs6000/t-float128
> +++ b/libgcc/config/rs6000/t-float128
> @@ -37,8 +37,11 @@ ibm128_dec_funcs = _tf_to_sd _tf_to_dd _tf_to_td \
> # New functions for software emulation
> fp128_ppc_funcs = floattikf floatuntikf fixkfti fixunskfti \
> extendkftf2-sw trunctfkf2-sw \
> - sfp-exceptions _mulkc3 _divkc3 _powikf2 \
> - $(fp128_dec_funcs) $(fp128_decstr_funcs)
> + sfp-exceptions _mulkc3 _divkc3 _powikf2
> +
> +ifeq ($(decimal_float),yes)
> +fp128_ppc_funcs += $(fp128_dec_funcs) $(fp128_decstr_funcs)
> +endif
>
> fp128_ppc_src= $(addprefix
> $(srcdir)/config/rs6000/,$(addsuffix \
> .c,$(fp128_ppc_funcs)))
>
That patch looks ok (assuming you've tested it). There are still the wider
issues that Segher wanted addressed, but it should fix the problem with
disabling decimal float.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
Patch ping^2
Hi! I'd like to ping following patch: > https://gcc.gnu.org/pipermail/gcc-patches/2021-March/59.html > PR99490 dwarf2out -gsplit-dwarf ranges fixes Thanks Jakub
[committed] testsuite: Expect a warning on aarch64 for declare-simd-coarray-lib.f90 [PR93660]
Hi!
aarch64 currently doesn't support declare simd where the return value and
arguments
have different sizes and warns about that case. This change adds a dg-warning
for that case like various other tests have already.
Committed to trunk.
2021-03-29 Jakub Jelinek
PR fortran/93660
* gfortran.dg/gomp/declare-simd-coarray-lib.f90: Expect a mixed size
declare simd warning on aarch64.
--- gcc/testsuite/gfortran.dg/gomp/declare-simd-coarray-lib.f90.jj
2021-03-23 16:14:01.842299433 +0100
+++ gcc/testsuite/gfortran.dg/gomp/declare-simd-coarray-lib.f90 2021-03-29
17:01:29.885703123 +0200
@@ -5,7 +5,7 @@
! Failed as TREE_TYPE(fndecl) did not include the
! hidden caf_token/caf_offset arguments.
!
-integer function f(x)
+integer function f(x) ! { dg-warning "GCC does not currently support mixed
size types for 'simd' functions" "" { target aarch64*-*-* } }
integer :: x[*]
!$omp declare simd
f = x[1]
Jakub
Re: [PATCH] libstdc++: Reimplement range adaptors [PR99433]
On Sun, 28 Mar 2021, Patrick Palka wrote: > This rewrites our range adaptor implementation for more comprehensible > error messages, improved SFINAE behavior and conformance to P2281. > > The diagnostic improvements mostly comes from using appropriately named > functors instead of lambdas in the generic implementation of partial > application and composition of range adaptors, and in the definition of > each of the standard range adaptors. This makes their pretty printed > types of much more comprehensible. > > The improved SFINAE behavior comes from constraining the range adaptors' > member functions appropriately. This change fixes PR99433, and was also > necessary in order to implement the wording changes of P2281. > > Finally, P2281 clarified that partial application and composition of > range adaptors behaves like a perfect forwarding call wrapper. This > patch implements this, except that we don't bother adding overloads for > forwarding captured state entities as non-const lvalues, since it seems > we only really need to handle the const lvalue and non-const rvalue > cases. Such overloads can be easily added if they turn out to be > needed. > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? This better version of the patch uses the CRTP idiom for the class _RangeAdaptor, and a CRTP-like idea for the class _RangeAdaptorClosure. This latter class is now the base class of every range adaptor closure, but it's not a class template -- its only purpose is to make ADL find its two hidden friends functions when using the pipe operator on a range adaptor closure, and these hidden friends are defined so that they're only ever instantiated with the most derived class. This version should be functionallity equivalent to the previous version, but its simpler and gives us shorter type names (since the _RangeAdaptor and _RangeAdaptorClosure types are now hidden as a base class instead of being part of the name of each range adaptor). (I previously tried using the standard CRTP idiom for this base class, but that resulted in excessive instantiation due to each instantiation of _RangeAdaptorClosure having its own set of partially instantiated hidden friends. So when performing ADL on 'r | adaptor' where adaptor is a _Pipe, we would find six operator| candidates: two hidden friends from _RangeAdaptorClosure<_Pipe>, two from _RangeAdaptorClosure, and two from _RangeAdaptorClosure. We would then proceed to check constraints on each of them (before checking non-dependent conversions, ever since CWG2369), which would sometimes lead to hard errors due to excessive instantiation, as in test07 of transform.cc.) -- >8 -- Subject: [PATCH] libstdc++: Reimplement range adaptors [PR99433] This rewrites our range adaptor implementation for more comprehensible error messages, improved SFINAE behavior and conformance to P2281. The diagnostic improvements mostly come from using appropriately named functors instead of lambdas in the generic implementation of partial application and composition of range adaptors, and in the definition of each of the standard range adaptors. This makes their pretty printed types of much shorter and more descriptive. The improved SFINAE behavior comes from constraining the range adaptors' member functions appropriately. This improvement fixes PR99433, and is also necessary in order to implement the wording changes of P2281. Finally, P2281 clarified that partial application and composition of range adaptors behaves like a perfect forwarding call wrapper. This patch implements this, except that we don't bother adding overloads for forwarding captured state entities as non-const lvalues, since it seems it's sufficient to handle the const lvalue and non-const rvalue cases, given the current set of standard range adaptors. But such overloads can be easily added if they turn out to be needed. Tested on x86_64-pc-linux-gnu, does this look OK for trunk? libstdc++-v3/ChangeLog: PR libstdc++/99433 * include/std/ranges (__adaptor::__maybe_refwrap): Remove. (__adaptor::__adaptor_invocable): New concept. (__adaptor::__adaptor_partial_app_viable): New concept. (__adaptor::_RangeAdaptorClosure): Rewrite, turning it into a non-template base class. (__adaptor::_RangeAdaptor): Rewrite, turning it into a CRTP base class template. (__adaptor::_Partial): New class template that represents partial application of a range adaptor non-closure. (__adaptor::__pipe_invocable): New concept. (__adaptor::_Pipe): New class template. (__detail::__can_ref_view): New concept. (__detail::__can_subrange): New concept. (all): Replace the lambda here with ... (_All): ... this functor. Add appropriate constraints. (__detail::__can_filter_view): New concept. (filter, _Filter): As in all/_All. (__detail::__can_transform): New concept. (transform,
Re: [PATCH, V2] Add conversions between _Float128 and Decimal.
Hi!
On Sat, Mar 27, 2021 at 04:07:18PM +0100, Florian Weimer wrote:
> * Michael Meissner via Gcc-patches:
> > On Wed, Feb 24, 2021 at 11:12:54PM +, Joseph Myers wrote:
> >> This change appears to have broken builds for powerpc in a configuration
> >> that bootstraps a cross toolchain starting with a GCC build with no libc
> >> available.
> >>
> >> Specifically, such a bootstrap build uses --disable-decimal-float among
> >> other options (in the first GCC build before libc has been built), to
> >> disable GCC target library code that has any dependence on libc or libc
> >> headers - dfp-bit.c uses libc headers, without an inhibit_libc
> >> conditional, so cannot be used in such a bootstrap configuration. Most of
> >> the DFP code in libgcc is disabled by --disable-decimal-float, but it
> >> seems the new conversions are not. This results in errors of the form:
> >>
> >> In file included from
> >> /scratch/jmyers/glibc-bot/src/gcc/libgcc/config/rs6000/_kf_to_sd.c:37:
> >> /scratch/jmyers/glibc-bot/src/gcc/libgcc/dfp-bit.c:32:10: fatal error:
> >> stdio.h: No such file or directory
> >>32 | #include
> >> | ^
> >> compilation terminated.
> >>
> >> The appropriate fix is not to build any of these new conversions in the
> >> --disable-decimal-float case. (That clearly makes sense anyway, even in
> >> the absence of the bootstrap issue.)
> >>
> >> https://sourceware.org/pipermail/libc-testresults/2021q1/007576.html
> >
> > Thanks. I agree if --disable-decimal-float is used we should not build the
> > conversions. And we want to eliminate the stdio.h dependency. I will look
> > at
> > it unless somebody has already fixed it.
>
> This issue is still present.
>
> What about the patch below?
>
> Thanks,
> Florian
>
> rs6000: Do not build _Float128/Decimal routines with --disable-decimal-float
>
> Fixes commit 781183595acba67a37c66f59a0c1d9b5fee7e248 ("Add conversions
> between _Float128 and Decimal.).
That seems likely. Okay for trunk if Mike agrees. Thanks!
Segher
> libgcc/
> * config/rs6000/t-float128 (fp128_ppc_funcs): Add decimal floating
> point functions for $(decimal_float) only.
Re: [Patch, fortran] 99307 - FAIL: gfortran.dg/class_assign_4.f90 execution test
Hi all,
as preremark I want to note that the testcase class_assign_4.f90
was added for PR83118/PR96012 (fixes problems in handling class objects, Dec
18, 2020)
and got revised for PR99124 (class defined operators, Feb 23, 2021).
Both patches were then also applied to GCC 9 and 10.
On 26.03.21 17:30, Paul Richard Thomas via Gcc-patches wrote:
This patch comes in two versions: submit.diff with Change.Logs or
submit2.diff with Change2.Logs.
The first fixes the problem by changing array temporaries from class
expressions into class temporaries. This permits the use of
gfc_get_class_from_expr to obtain the vptr for these temporaries and all
the good things that come with that when handling dynamic types. The second
part of the fix is to use the array element length from the class
descriptor, when reallocating on assignment. This is needed because the
vptr is being set too early. I will set about trying to track down why this
is happening and fix it after release.
The second version does the same as the first but puts in place a load of
tidying up that is permitted by the fix to class array temporaries.
I couldn't readily see how to prepare a testcase - ideas?
Both regtest on FC33/x86_64. The first was tested by Dominique (see the
PR). OK for master?
Typo – underscore-'c' should be a dot-'c' – both changelog files
* trans-expr_c (gfc_trans_scalar_assign): Make use of pre and
I think the second longer version is nicer in general, but at least for
GCC 9/GCC10 the first version is simpler and, hence, less error prone.
As you only ask about mainline, I would prefer the second one.
However, I am not happy about gfc_find_and_cut_at_last_class_ref:
+ of refs following. If ts is non-null the cut is at the class entity
+ or component that is followed by an array reference, which is not +
an element. */ ... + + if (ts) + { + if (e->symtree + &&
e->symtree->n.sym->ts.type == BT_CLASS) + *ts =
>symtree->n.sym->ts; + else + *ts = NULL; + } + for (ref = e->ref;
ref; ref = ref->next) { + if (ts && ref->type == REF_COMPONENT + &&
ref->u.c.component->ts.type == BT_CLASS + && ref->next &&
ref->next->type == REF_COMPONENT + && strcmp
(ref->next->u.c.component->name, "_data") == 0 + && ref->next->next +
&& ref->next->next->type == REF_ARRAY + && ref->next->next->u.ar.type
!= AR_ELEMENT) + { + *ts = >u.c.component->ts; + class_ref = ref;
+ break; + } + + if (ts && *ts == NULL) + return NULL; +
Namely, if there is:
type1%array_class2 → array_class2 is used for 'ts' and later (ok)
type1%type%array_class2 → NULL is returned (why?)
class1%type%array_class2 → ts = class1 but array2_class is used later on
(ups!)
class1%...%scalar_class2 → ts = class1 but scalar_class2 is used
etc.
Thus this either needs to be cleaned up (separate 'ref' loop for
ts != NULL) – including the wording in the description which tells what
happens if 'ts' is passed as arg but the expr has rank == 0 – and
what value is assigned to 'ts'. (You can then also fix 'class.c::' to
'class.c: ' in the description above the function.)
Alternatively, you can leave the current code ref handling code in place
at build_class_array_ref, which might be the simpler alternative.
Otherwise, it looks sensible to me.
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
Re: [PATCH v2 1/3] x86: Update memcpy/memset inline strategies for Ice Lake
On Mon, Mar 22, 2021 at 4:57 PM H.J. Lu wrote: > > On Mon, Mar 22, 2021 at 7:10 AM Jan Hubicka wrote: > > > > > > > > gcc/ > > > > > > * config/i386/i386-expand.c (expand_set_or_cpymem_via_rep): > > > For TARGET_PREFER_KNOWN_REP_MOVSB_STOSB, don't convert QImode > > > to SImode. > > > (decide_alg): For TARGET_PREFER_KNOWN_REP_MOVSB_STOSB, use > > > "rep movsb/stosb" only for known sizes. > > > * config/i386/i386-options.c (processor_cost_table): Use Ice > > > Lake cost for Cannon Lake, Ice Lake, Tiger Lake, Sapphire > > > Rapids and Alder Lake. > > > * config/i386/i386.h (TARGET_PREFER_KNOWN_REP_MOVSB_STOSB): New. > > > * config/i386/x86-tune-costs.h (icelake_memcpy): New. > > > (icelake_memset): Likewise. > > > (icelake_cost): Likewise. > > > * config/i386/x86-tune.def (X86_TUNE_PREFER_KNOWN_REP_MOVSB_STOSB): > > > New. > > > > It looks like X86_TUNE_PREFER_KNOWN_REP_MOVSB_STOSB is quite obviously > > benefical and independent of the rest of changes. I think we will need > > to discuss bit more the move ratio and the code size/uop cache polution > > issues - one option would be to use increased limits for -O3 only. > > My change only increases CLEAR_RATIO, not MOVE_RATIO. We are > checking code size impacts on SPEC CPU 2017 and eembc. > > > Can you break this out to independent patch? I also wonder if it owuld > > X86_TUNE_PREFER_KNOWN_REP_MOVSB_STOSB improves performance > only when memcpy/memset costs and MOVE_RATIO are updated the same time, > like: > > https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567096.html > > Make it a standalone means moving from Ice Lake patch to Skylake patch. > > > not be more readable to special case this just on the beggining of > > decide_alg. > > > @@ -6890,6 +6891,7 @@ decide_alg (HOST_WIDE_INT count, HOST_WIDE_INT > > > expected_size, > > >const struct processor_costs *cost; > > >int i; > > >bool any_alg_usable_p = false; > > > + bool known_size_p = expected_size != -1; > > > > expected_size is not -1 if we have profile feedback and we detected from > > histogram average size of a block. It seems to me that from description > > that you want the const to be actual compile time constant that would be > > min_size == max_size I guess. > > > > You are right. Here is the v2 patch with min_size != max_size check for > unknown size. > Hi Honza, This patch only impacts Ice Lake. Do you have any comments for the v2 patch? Thanks. -- H.J.
[PATCH] arm: Fix mult autovectorization patterm for iwmmxt (PR target/99786)
Similarly to other recently-added autovectorization patterns, mult has
been erroneously enabled for iwmmxt. However, V4HI and V2SI modes are
supported, so we make an exception for them.
The new testcase is derived from gcc.dg/ubsan/pr79904.c, with
additional modes added.
I kept dg-do compile because 'assemble' results in error messages from
the assembler, which are not related to this PR:
Error: selected processor does not support `tmcrr wr0,r4,r5' in ARM mode
Error: selected processor does not support `wstrd wr0,[r0]' in ARM mode
Error: selected processor does not support `wldrd wr0,[r0]' in ARM mode
Error: selected processor does not support `wldrd wr2,.L5' in ARM mode
Error: selected processor does not support `wmulul wr0,wr0,wr2' in ARM mode
Error: selected processor does not support `wstrd wr0,[r0]' in ARM mode
Error: selected processor does not support `wldrd wr0,[r0]' in ARM mode
Error: selected processor does not support `wldrd wr2,.L8' in ARM mode
Error: selected processor does not support `wmulwl wr0,wr0,wr2' in ARM mode
Error: selected processor does not support `wstrd wr0,[r0]' in ARM mode
2021-03-29 Christophe Lyon
PR target/99786
gcc/
* config/arm/vec-common.md (mul3): Disable on iwMMXT, expect
for V4HI and V2SI.
gcc/testsuite/
* gcc.target/arm/pr99786.c: New test.
---
gcc/config/arm/vec-common.md | 5 -
gcc/testsuite/gcc.target/arm/pr99786.c | 30 ++
2 files changed, 34 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.target/arm/pr99786.c
diff --git a/gcc/config/arm/vec-common.md b/gcc/config/arm/vec-common.md
index 48ee659..0b2b3b1 100644
--- a/gcc/config/arm/vec-common.md
+++ b/gcc/config/arm/vec-common.md
@@ -103,7 +103,10 @@ (define_expand "mul3"
[(set (match_operand:VDQWH 0 "s_register_operand")
(mult:VDQWH (match_operand:VDQWH 1 "s_register_operand")
(match_operand:VDQWH 2 "s_register_operand")))]
- "ARM_HAVE__ARITH"
+ "ARM_HAVE__ARITH
+ && (!TARGET_REALLY_IWMMXT
+ || mode == V4HImode
+ || mode == V2SImode)"
)
(define_expand "smin3"
diff --git a/gcc/testsuite/gcc.target/arm/pr99786.c
b/gcc/testsuite/gcc.target/arm/pr99786.c
new file mode 100644
index 000..11d86f0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/pr99786.c
@@ -0,0 +1,30 @@
+/* { dg-do compile } */
+/* { dg-skip-if "Test is specific to the iWMMXt" { arm*-*-* } { "-mcpu=*" } {
"-mcpu=iwmmxt" } } */
+/* { dg-skip-if "Test is specific to the iWMMXt" { arm*-*-* } { "-mabi=*" } {
"-mabi=iwmmxt" } } */
+/* { dg-skip-if "Test is specific to the iWMMXt" { arm*-*-* } { "-march=*" } {
"-march=iwmmxt" } } */
+/* { dg-skip-if "Test is specific to ARM mode" { arm*-*-* } { "-mthumb" } { ""
} } */
+/* { dg-require-effective-target arm32 } */
+/* { dg-require-effective-target arm_iwmmxt_ok } */
+/* { dg-options "-O3 -mcpu=iwmmxt" } */
+
+typedef signed char V __attribute__((vector_size (8)));
+
+void
+foo (V *a)
+{
+ *a = *a * 3;
+}
+
+typedef signed short Vshort __attribute__((vector_size (8)));
+void
+foo_short (Vshort *a)
+{
+ *a = *a * 3;
+}
+
+typedef signed int Vint __attribute__((vector_size (8)));
+void
+foo_int (Vint *a)
+{
+ *a = *a * 3;
+}
--
2.7.4
Re: https://github.com/llvm/llvm-project/tree/master/pstl link broken
On 28/03/21 22:23 +0100, Jonathan Wakely via Libstdc++ wrote: On Sun, 28 Mar 2021, 22:20 Gerald Pfeifer, wrote: Hi folks, I noticed http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html has a link to https://github.com/llvm/llvm-project/tree/master/pstl which does not exist any more. Would you mind having a look and updating (or removing) that link? They renamed the 'master' branch. I'll adjust the link tomorrow. Done by this patch, pushed to master (which I think we should rename). commit e19afa0645f19287517a139c0428cfd1f3a63742 Author: Jonathan Wakely Date: Mon Mar 29 14:13:01 2021 libstdc++: Adjust link to PSTL upstream (again) The LLVM project renamed their default branch to 'main'. libstdc++-v3/ChangeLog: * doc/xml/manual/status_cxx2017.xml: Adjust link for PSTL. * doc/html/manual/status.html: Regenerate. diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml index 7f64c47bdfe..11372bb28b3 100644 --- a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml +++ b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml @@ -1882,7 +1882,7 @@ since C++14 and the implementation is complete. 28.4 Parallel algorithms - Using http://www.w3.org/1999/xlink; xlink:href="https://github.com/llvm/llvm-project/tree/master/pstl;>PSTL + Using http://www.w3.org/1999/xlink; xlink:href="https://github.com/llvm/llvm-project/tree/main/pstl;>PSTL 28.5
[PATCH] testsuite/aarch64: Skip SLP diagnostic under ILP32 (PR target/96974)
The vectorizer has a very different effect with -mabi=ilp32, and
doesn't emit the expecte diagnostic, so this patch expects it only
under lp64.
2021-03-29 Christophe Lyon
gcc/testsuite/
PR target/96974
* g++.target/aarch64/sve/pr96974.C: Expect SLP diagnostic only
under lp64.
---
gcc/testsuite/g++.target/aarch64/sve/pr96974.C | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/g++.target/aarch64/sve/pr96974.C
b/gcc/testsuite/g++.target/aarch64/sve/pr96974.C
index 363241d..54000f5 100644
--- a/gcc/testsuite/g++.target/aarch64/sve/pr96974.C
+++ b/gcc/testsuite/g++.target/aarch64/sve/pr96974.C
@@ -15,4 +15,4 @@ struct c {
int coeffs[10];
} f;
-/* { dg-final { scan-tree-dump "Not vectorized: Incompatible number of vector
subparts between" "slp1" } } */
+/* { dg-final { scan-tree-dump "Not vectorized: Incompatible number of vector
subparts between" "slp1" { target lp64 } } } */
--
2.7.4
New Serbian PO file for 'cpplib' (version 11.1-b20210207)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Serbian team of translators. The file is available at: https://translationproject.org/latest/cpplib/sr.po (This file, 'cpplib-11.1-b20210207.sr.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: https://translationproject.org/latest/cpplib/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/cpplib.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Contents of PO file 'cpplib-11.1-b20210207.sr.po'
cpplib-11.1-b20210207.sr.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.
[PATCH] tree-optimization/99807 - avoid bogus assert with permute SLP node
This avoids asserting anything on the SLP_TREE_REPRESENTATIVE of
an SLP permute node (which shouldn't be there).
Bootstrapped / tested on x86_64-unknown-linux-gnu, pushed.
2021-03-29 Richard Biener
PR tree-optimization/99807
* tree-vect-slp.c (vect_slp_analyze_node_operations_1): Move
assert below VEC_PERM handling.
* gfortran.dg/vect/pr99807.f90: New testcase.
---
gcc/testsuite/gfortran.dg/vect/pr99807.f90 | 11 +++
gcc/tree-vect-slp.c| 2 +-
2 files changed, 12 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/vect/pr99807.f90
diff --git a/gcc/testsuite/gfortran.dg/vect/pr99807.f90
b/gcc/testsuite/gfortran.dg/vect/pr99807.f90
new file mode 100644
index 000..4ab46a32515
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/vect/pr99807.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! { dg-additional-options "-march=armv8.3-a" { target aarch64-*-* } }
+
+subroutine cppco(ap, z)
+ implicit none
+ complex :: ap(*), z(*)
+
+ z(1) = z(1) + z(2) * (ap(1))
+
+ return
+end subroutine cppco
diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index f1a2b5d60fa..ceec7f5c410 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -3724,7 +3724,6 @@ vect_slp_analyze_node_operations_1 (vec_info *vinfo,
slp_tree node,
stmt_vector_for_cost *cost_vec)
{
stmt_vec_info stmt_info = SLP_TREE_REPRESENTATIVE (node);
- gcc_assert (STMT_SLP_TYPE (stmt_info) != loop_vect);
/* Calculate the number of vector statements to be created for the
scalar stmts in this node. For SLP reductions it is equal to the
@@ -3760,6 +3759,7 @@ vect_slp_analyze_node_operations_1 (vec_info *vinfo,
slp_tree node,
if (SLP_TREE_CODE (node) == VEC_PERM_EXPR)
return vectorizable_slp_permutation (vinfo, NULL, node, cost_vec);
+ gcc_assert (STMT_SLP_TYPE (stmt_info) != loop_vect);
if (is_a (vinfo)
&& !vect_update_shared_vectype (stmt_info, SLP_TREE_VECTYPE (node)))
{
--
2.26.2
RE: [PATCH] aarch64: PR target/99037 Fix RTL represntation in move_lo_quad patterns
> -Original Message- > From: Jakub Jelinek > Sent: 29 March 2021 11:45 > To: Kyrylo Tkachov > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] aarch64: PR target/99037 Fix RTL represntation in > move_lo_quad patterns > > On Mon, Mar 29, 2021 at 10:41:17AM +, Kyrylo Tkachov wrote: > > Hi all, > > > > This patch fixes the RTL representation of the move_lo_quad patterns to > use aarch64_simd_or_scalar_imm_zero > > for the zero part rather than a vec_duplicate of zero or a const_int 0. > > The expander that generates them is also adjusted so that we use and > match the correct const_vector forms throughout. > > > > Bootstrapped and tested on aarch64-none-linux-gnu and aarch64_be- > none-elf. > > Jakub, does this look like what you've had in mind? > > I'd probably also remove VQ_2E iterator that is now unused (the > VQMOV_NO2E > one is used in other patterns). But otherwise yes. Thanks, I've pushed it to trunk. gcc/ChangeLog: PR target/99037 * config/aarch64/aarch64-simd.md (move_lo_quad_internal_): Use aarch64_simd_or_scalar_imm_zero to match zeroes. Remove pattern matching const_int 0. (move_lo_quad_internal_be_): Likewise. (move_lo_quad_): Update for the above. * config/aarch64/iterators.md (VQ_2E): Delete. gcc/testsuite/ChangeLog: PR target/99808 * gcc.target/aarch64/pr99808.c: New test. > > > gcc/ChangeLog: > > > > PR target/99037 > > * config/aarch64/aarch64-simd.md > (move_lo_quad_internal_): Use > > aarch64_simd_or_scalar_imm_zero to match zeroes. Remove > pattern > > matching const_int 0. > > (move_lo_quad_internal_be_): Likewise. > > (move_lo_quad_): Update for the above. > > > > gcc/testsuite/ChangeLog: > > > > PR target/99808 > > * gcc.target/aarch64/pr99808.c: New test. > > > > Jakub movlo.patch Description: movlo.patch
Re: [PATCH] aarch64: PR target/99037 Fix RTL represntation in move_lo_quad patterns
On Mon, Mar 29, 2021 at 10:41:17AM +, Kyrylo Tkachov wrote: > Hi all, > > This patch fixes the RTL representation of the move_lo_quad patterns to use > aarch64_simd_or_scalar_imm_zero > for the zero part rather than a vec_duplicate of zero or a const_int 0. > The expander that generates them is also adjusted so that we use and match > the correct const_vector forms throughout. > > Bootstrapped and tested on aarch64-none-linux-gnu and aarch64_be-none-elf. > Jakub, does this look like what you've had in mind? I'd probably also remove VQ_2E iterator that is now unused (the VQMOV_NO2E one is used in other patterns). But otherwise yes. > gcc/ChangeLog: > > PR target/99037 > * config/aarch64/aarch64-simd.md (move_lo_quad_internal_): Use > aarch64_simd_or_scalar_imm_zero to match zeroes. Remove pattern > matching const_int 0. > (move_lo_quad_internal_be_): Likewise. > (move_lo_quad_): Update for the above. > > gcc/testsuite/ChangeLog: > > PR target/99808 > * gcc.target/aarch64/pr99808.c: New test. Jakub
[PATCH] aarch64: PR target/99037 Fix RTL represntation in move_lo_quad patterns
Hi all, This patch fixes the RTL representation of the move_lo_quad patterns to use aarch64_simd_or_scalar_imm_zero for the zero part rather than a vec_duplicate of zero or a const_int 0. The expander that generates them is also adjusted so that we use and match the correct const_vector forms throughout. Bootstrapped and tested on aarch64-none-linux-gnu and aarch64_be-none-elf. Jakub, does this look like what you've had in mind? Thanks, Kyrill Co-Authored-By: Jakub Jelinek gcc/ChangeLog: PR target/99037 * config/aarch64/aarch64-simd.md (move_lo_quad_internal_): Use aarch64_simd_or_scalar_imm_zero to match zeroes. Remove pattern matching const_int 0. (move_lo_quad_internal_be_): Likewise. (move_lo_quad_): Update for the above. gcc/testsuite/ChangeLog: PR target/99808 * gcc.target/aarch64/pr99808.c: New test. movlo.patch Description: movlo.patch
Re: [PATCH] fold-const: Fix ICE in extract_muldiv_1 [PR99777]
On Sat, 27 Mar 2021, Jakub Jelinek wrote:
> Hi!
>
> extract_muldiv{,_1} is apparently only prepared to handle scalar integer
> operations, the callers ensure it by only calling it if the divisor or
> one of the multiplicands is INTEGER_CST and because neither multiplication
> nor division nor modulo are really supported e.g. for pointer types, nullptr
> type etc. But the CASE_CONVERT handling doesn't really check if it isn't
> a cast from some other type kind, so on the testcase we end up trying to
> build MULT_EXPR in POINTER_TYPE which ICEs. A few years ago Marek has
> added ANY_INTEGRAL_TYPE_P checks to two spots, but the code uses
> TYPE_PRECISION which means something completely different for vector types,
> etc.
> So IMNSHO we should just punt on conversions from non-integrals or
> non-scalar integrals.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?
OK.
Richard.
> 2021-03-26 Jakub Jelinek
>
> PR tree-optimization/99777
> * fold-const.c (extract_muldiv_1): For conversions, punt on casts from
> types other than scalar integral types.
>
> * g++.dg/torture/pr99777.C: New test.
>
> --- gcc/fold-const.c.jj 2021-03-25 13:41:55.0 +0100
> +++ gcc/fold-const.c 2021-03-26 11:51:57.901091895 +0100
> @@ -6713,6 +6713,8 @@ extract_muldiv_1 (tree t, tree c, enum t
>break;
>
> CASE_CONVERT: case NON_LVALUE_EXPR:
> + if (!INTEGRAL_TYPE_P (TREE_TYPE (op0)))
> + break;
>/* If op0 is an expression ... */
>if ((COMPARISON_CLASS_P (op0)
> || UNARY_CLASS_P (op0)
> @@ -6721,8 +6723,7 @@ extract_muldiv_1 (tree t, tree c, enum t
> || EXPRESSION_CLASS_P (op0))
> /* ... and has wrapping overflow, and its type is smaller
>than ctype, then we cannot pass through as widening. */
> - && (((ANY_INTEGRAL_TYPE_P (TREE_TYPE (op0))
> - && TYPE_OVERFLOW_WRAPS (TREE_TYPE (op0)))
> + && ((TYPE_OVERFLOW_WRAPS (TREE_TYPE (op0))
> && (TYPE_PRECISION (ctype)
> > TYPE_PRECISION (TREE_TYPE (op0
> /* ... or this is a truncation (t is narrower than op0),
> @@ -6737,8 +6738,7 @@ extract_muldiv_1 (tree t, tree c, enum t
> /* ... or has undefined overflow while the converted to
>type has not, we cannot do the operation in the inner type
>as that would introduce undefined overflow. */
> - || ((ANY_INTEGRAL_TYPE_P (TREE_TYPE (op0))
> -&& TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (op0)))
> + || (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (op0))
> && !TYPE_OVERFLOW_UNDEFINED (type
> break;
>
> --- gcc/testsuite/g++.dg/torture/pr99777.C.jj 2021-03-26 12:22:49.833560450
> +0100
> +++ gcc/testsuite/g++.dg/torture/pr99777.C2021-03-26 12:22:37.927692142
> +0100
> @@ -0,0 +1,44 @@
> +// PR tree-optimization/99777
> +
> +template
> +inline const T &
> +min (const T , const T )
> +{
> + if (b < a)
> +return b;
> + return a;
> +}
> +
> +template
> +inline const T &
> +max (const T , const T )
> +{
> + if (a < b)
> +return b;
> + return a;
> +}
> +
> +extern int o, a, c;
> +long h;
> +unsigned long long e;
> +signed char d;
> +extern short p[][7][5][30];
> +
> +void
> +test (long long b, short f[][17][25][22][20])
> +{
> + for (char i = 0; i < 7; i += 3)
> +for (unsigned char l = e; l < 5; l += 2)
> + {
> + if (max (0LL, min (7LL, b)))
> + for (bool j = 0; j < 1; j = b)
> + {
> + for (unsigned k = d; k < 20; k++)
> + h = f[0][i][l][b][k];
> + for (int m = 0; m < 5; m++)
> + p[c][i][l][m] = 0;
> + }
> + for (int n = 0; n < 4; n += a)
> + o = n;
> + }
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
Re: [PATCH] slp tree vectorizer: Re-calculate vectorization factor in the case of invalid choices [PR96974]
On Fri, 26 Mar 2021, Richard Sandiford wrote: > Richard Biener writes: > > On Wed, 24 Mar 2021, Stam Markianos-Wright wrote: > > > >> Hi all, > >> > >> This patch resolves bug: > >> > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974 > >> > >> This is achieved by forcing a re-calculation of *stmt_vectype_out if an > >> incompatible combination of TYPE_VECTOR_SUBPARTS is detected, but with an > >> extra introduced max_nunits ceiling. > >> > >> I am not 100% sure if this is the best way to go about fixing this, because > >> this is my first look at the vectorizer and I lack knowledge of the wider > >> context, so do let me know if you see a better way to do this! > >> > >> I have added the previously ICE-ing reproducer as a new test. > >> > >> This is compiled as "g++ -Ofast -march=armv8.2-a+sve -fdisable-tree-fre4" > >> for > >> GCC11 and "g++ -Ofast -march=armv8.2-a+sve" for GCC10. > >> > >> (the non-fdisable-tree-fre4 version has gone latent on GCC11) > >> > >> Bootstrapped and reg-tested on aarch64-linux-gnu. > >> Also reg-tested on aarch64-none-elf. > > > > I don't think this is going to work well given uses will expect > > a vector type that's consistent here. > > > > I think giving up is for the moment the best choice, thus replacing > > the assert with vectorization failure. > > > > In the end we shouldn't require those nunits vectypes to be > > separately computed - we compute the vector type of the defs > > anyway and in case they're invariant the vectorizable_* function > > either can deal with the type mix or not anyway. > > I agree this area needs simplification, but I think the direction of > travel should be to make the assert valid. I agree this is probably > the pragmatic fix for GCC 11 and earlier though. The issue is that we compute a vector type for a use that may differ from what we'd compute for it in the context of its definition (or in the context of another use). Any such "local" decision is likely flawed and I'd rather simplify further doing the only decision on the definition side - if there's a disconnect between the number of lanes (and thus altering the VF won't help) then we have to give up anyway. Richard.
Patch ping - Re: [PATCH] aarch64: Don't emit -Wpsabi note when ABI was never affected [PR91710]
On Fri, Mar 19, 2021 at 01:04:19PM +, Richard Sandiford via Gcc-patches
wrote:
> > As the following testcase shows, we emit a -Wpsabi note about argument
> > passing change since GCC 9, but in reality the ABI didn't change.
> > The alignment is 8 bits in GCC < 9 and 32 bits in GCC >= 9 and
> > the aarch64_function_arg_alignment returns in that case:
> > return MIN (MAX (alignment, PARM_BOUNDARY), STACK_BOUNDARY);
> > so when both the old and new alignment are smaller or equal to PARM_BOUNDARY
> > (or both are larger than STACK_BOUNDARY, just in theory), even when the new
> > one is bigger, it doesn't change the argument passing.
> >
> > So, the following patch changes aarch64_function_arg_alignment to tell the
> > callers the exact old alignmentm so that they can test it if needed.
> > The other aarch64_function_arg_alignment callers either check the
> > alignment for equality against 16-byte alignment (when old alignment was
> > smaller than that and the new one is 16-byte, we want to emit -Wpsabi
> > in all the cases) or the va_arg case which I think is ok now too.
> >
> > Bootstrapped/regtested on aarch64-linux, ok for trunk?
>
> Looks good to me. Richard E knows this code better than I do though,
> so I think he should have the final say. He's currently on holiday
> but will be back next week.
I'd like to ping this patch.
Thanks.
> > 2021-03-18 Jakub Jelinek
> >
> > PR target/91710
> > * config/aarch64/aarch64.c (aarch64_function_arg_alignment): Change
> > abi_break argument from bool * to unsigned *, store there the pre-GCC 9
> > alignment.
> > (aarch64_layout_arg, aarch64_gimplify_va_arg_expr): Adjust callers.
> > (aarch64_function_arg_regno_p): Likewise. Only emit -Wpsabi note if
> > the old and new alignment after applying MIN/MAX to it is different.
> >
> > * gcc.target/aarch64/pr91710.c: New test.
> >
> > --- gcc/config/aarch64/aarch64.c.jj 2021-03-18 15:14:51.721425223 +0100
> > +++ gcc/config/aarch64/aarch64.c2021-03-18 16:35:04.437115447 +0100
> > @@ -5938,9 +5938,9 @@ aarch64_vfp_is_call_candidate (cumulativ
> >
> > static unsigned int
> > aarch64_function_arg_alignment (machine_mode mode, const_tree type,
> > - bool *abi_break)
> > + unsigned int *abi_break)
> > {
> > - *abi_break = false;
> > + *abi_break = 0;
> >if (!type)
> > return GET_MODE_ALIGNMENT (mode);
> >
> > @@ -5982,7 +5982,7 @@ aarch64_function_arg_alignment (machine_
> >
> >if (bitfield_alignment > alignment)
> > {
> > - *abi_break = true;
> > + *abi_break = alignment;
> >return bitfield_alignment;
> > }
> >
> > @@ -6004,7 +6004,7 @@ aarch64_layout_arg (cumulative_args_t pc
> >int ncrn, nvrn, nregs;
> >bool allocate_ncrn, allocate_nvrn;
> >HOST_WIDE_INT size;
> > - bool abi_break;
> > + unsigned int abi_break;
> >
> >/* We need to do this once per argument. */
> >if (pcum->aapcs_arg_processed)
> > @@ -6322,14 +6322,19 @@ aarch64_function_arg_regno_p (unsigned r
> > static unsigned int
> > aarch64_function_arg_boundary (machine_mode mode, const_tree type)
> > {
> > - bool abi_break;
> > + unsigned int abi_break;
> >unsigned int alignment = aarch64_function_arg_alignment (mode, type,
> >_break);
> > + alignment = MIN (MAX (alignment, PARM_BOUNDARY), STACK_BOUNDARY);
> >if (abi_break & warn_psabi)
> > -inform (input_location, "parameter passing for argument of type "
> > - "%qT changed in GCC 9.1", type);
> > +{
> > + abi_break = MIN (MAX (abi_break, PARM_BOUNDARY), STACK_BOUNDARY);
> > + if (alignment != abi_break)
> > + inform (input_location, "parameter passing for argument of type "
> > + "%qT changed in GCC 9.1", type);
> > +}
> >
> > - return MIN (MAX (alignment, PARM_BOUNDARY), STACK_BOUNDARY);
> > + return alignment;
> > }
> >
> > /* Implement TARGET_GET_RAW_RESULT_MODE and TARGET_GET_RAW_ARG_MODE. */
> > @@ -16616,7 +16621,7 @@ aarch64_gimplify_va_arg_expr (tree valis
> > f_stack, NULL_TREE);
> >size = int_size_in_bytes (type);
> >
> > - bool abi_break;
> > + unsigned int abi_break;
> >align
> > = aarch64_function_arg_alignment (mode, type, _break) /
> > BITS_PER_UNIT;
> >
> > --- gcc/testsuite/gcc.target/aarch64/pr91710.c.jj 2021-03-18
> > 16:42:33.529232710 +0100
> > +++ gcc/testsuite/gcc.target/aarch64/pr91710.c 2021-03-18
> > 16:42:07.271518121 +0100
> > @@ -0,0 +1,16 @@
> > +/* PR target/91710 */
> > +/* { dg-do compile } */
> > +
> > +struct S { unsigned int i:4; };
> > +
> > +unsigned int test1(struct S s) { /* { dg-bogus "parameter passing for
> > argument of type" } */
> > + return s.i;
> > +}
> > +
> > +unsigned int test2(unsigned x, struct S s) { /* { dg-bogus
> > "parameter passing for argument of type" } */
> > + return x - s.i;
> > +}
> > +
> > +unsigned
Re: [Patch, fortran] PR99602 - [11 regression] runtime error: pointer actual argument not associated
Hi Tobias, An earlier version of the patch, without the exclusion of unlimited polymorphic expressions caused several regressions. However, omitting the exclusion now causes no regressions. I forgot to go back to this wrinkle. I have included your testcases with appropriate attribution and pushed as 297363774e6a5dca2f46a85ab086f1d9e59431ac . Thanks for the review and the additional testcases. Paul On Fri, 26 Mar 2021 at 11:22, Tobias Burnus wrote: > Hi Paul, > > I do not understand the !UNLIMITED_POLY(fsym) part of the patch. > In particular, your patch causes foo.f90 to fail by wrongly diagnosting: > >Fortran runtime error: Pointer actual argument 'cptr' is not associated > > I have only did some light tests – but it seems that just removing > '&& !UNLIMITED_POLY(fsym)' seems to be enough. (But I did not run > the testsuite.) > > Hence: > - Please include the attached testcases or some variants of them. > - Check that removing !UNLIMITED_POLY does not cause any regressions > > If that works: OK for mainline > > Thanks for looking into this issue and working on the patches. > > Tobias > > On 26.03.21 07:58, Paul Richard Thomas via Fortran wrote: > > This patch is straightforward but the isolation of the problem was rather > > less so. Many thanks to Juergen for testcase reduction. > > > > Regtested on FC33/x86_64 - OK for master? > > > > Paul > > > > Fortran: Fix problem with runtime pointer chack [PR99602]. > > > > 2021-03-26 Paul Thomas > > > > gcc/fortran/ChangeLog > > > > PR fortran/99602 > > * trans-expr.c (gfc_conv_procedure_call): Use the _data attrs > > for class expressions and detect proc pointer evaluations by > > the non-null actual argument list. > > > > gcc/testsuite/ChangeLog > > > > PR fortran/99602 > > * gfortran.dg/pr99602.f90: New test. > > * gfortran.dg/pr99602a.f90: New test. > > * gfortran.dg/pr99602b.f90: New test. > - > Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München > Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank > Thürauf > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [Patch] libgomp: Fix on_device_arch.c aux-file handling [PR99555]
Hi!
On 2021-03-26T16:22:20+0100, Jakub Jelinek wrote:
> On Fri, Mar 26, 2021 at 04:19:56PM +0100, Tobias Burnus wrote:
>> On 26.03.21 15:46, Jakub Jelinek via Gcc-patches wrote:
>> > On Fri, Mar 26, 2021 at 03:42:22PM +0100, Tobias Burnus wrote:
>> > > How about the following patch? It moves the aux function to
>> > > libgomp.c-c++-common/on_device_arch.c
>> > > and #includes it in the new wrapper files
>> > > libgomp.{c,fortran}/on_device_arch.c.
>> > > (Based on the observation that #include with relative paths always works,
>> > > while dg-additional-sources may not, depending how the testsuite it
>> > > run.) [...]
I didn't know that 'dg-additional-sources' had such issues.
>> > For C/C++, why do we call it on_device_arch.c at all? Can't be just
>> > on_device_arch.h that is #included in each test instead of additional
>> > sources? If we don't like inlining, just use noinline attribute, but I
>> > don't see why inlining would hurt.
>> > For Fortran, sure, we can't include it, so let's add
>> > libgomp.fortran/on_device_arch.c that #includes that header.
No strong opinion on my side -- I simply did the same for C/C++/Fortran.
>> OK?
>
> LGTM, but please give Thomas a chance to chime in.
ACK, thanks.
And, I hope you did appreciate that I used OpenMP 'declare variant' for
this. :-)
Grüße
Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
[PATCH] testsuite/arm: Fix scan-assembler-times in pr96770.c with movt/movw
The previous change to this testcase missed the fact that the data may
be accessed via an anchor, depending on the optimization level,
leading to false failures.
This patch restricts matching to upper16:lower16 followed by
non-spaces, followed by +4 (in f4) or +320 (in f5).
Using '.*' instead of '[^ \]' would match accross the whole assembly
file, which is not what we want, hence the limitation with spaces.
2021-03-29 Christophe Lyon
gcc/testsuite/
PR target/96770
* gcc.target/arm/pure-code/pr96770.c: Fix scan-assembler-times
with movt/movw.
---
gcc/testsuite/gcc.target/arm/pure-code/pr96770.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/gcc/testsuite/gcc.target/arm/pure-code/pr96770.c
b/gcc/testsuite/gcc.target/arm/pure-code/pr96770.c
index ae1bd10..3c69614 100644
--- a/gcc/testsuite/gcc.target/arm/pure-code/pr96770.c
+++ b/gcc/testsuite/gcc.target/arm/pure-code/pr96770.c
@@ -4,12 +4,13 @@
int arr[1000];
int *f4 (void) { return [1]; }
-/* For cortex-m0 (thumb-1/v6m), we generate 4 movs with upper/lower:#arr+4. */
+/* For cortex-m0 (thumb-1/v6m), we generate 2 pairs of movs/adds with
upper/lower:#arr+4. */
/* { dg-final { scan-assembler-times "arr\\+4" 4 { target { { !
arm_thumb1_movt_ok } && { ! arm_thumb2_ok } } } } } */
/* For cortex-m with movt/movw (thumb-1/v8m.base or thumb-2), we
- generate a movt/movw pair with upper/lower:#arr+4. */
-/* { dg-final { scan-assembler-times "arr\\+4" 2 { target { arm_thumb1_movt_ok
|| arm_thumb2_ok } } } } */
+ generate a movt/movw pair with upper/lower:#arr+4 possibly via an anchor.
*/
+/* { dg-final { scan-assembler-times "upper16:\[^ \]+.\\+4" 1 { target {
arm_thumb1_movt_ok || arm_thumb2_ok } } } } */
+/* { dg-final { scan-assembler-times "lower16:\[^ \]+\\+4" 1 { target {
arm_thumb1_movt_ok || arm_thumb2_ok } } } } */
int *f5 (void) { return [80]; }
@@ -17,5 +18,6 @@ int *f5 (void) { return [80]; }
/* { dg-final { scan-assembler-times "arr\\+320" 1 { target { { !
arm_thumb1_movt_ok } && { ! arm_thumb2_ok } } } } } */
/* For cortex-m with movt/movw (thumb-1/v8m.base or thumb-2), we
- generate a movt/movw pair with upper/lower:arr+320. */
-/* { dg-final { scan-assembler-times "arr\\+320" 2 { target {
arm_thumb1_movt_ok || arm_thumb2_ok } } } } */
+ generate a movt/movw pair with upper/lower:arr+320 possibly via an anchor.
*/
+/* { dg-final { scan-assembler-times "upper16:\[^ \]+\\+320" 1 { target {
arm_thumb1_movt_ok || arm_thumb2_ok } } } } */
+/* { dg-final { scan-assembler-times "lower16:\[^ \]+\\+320" 1 { target {
arm_thumb1_movt_ok || arm_thumb2_ok } } } } */
--
2.7.4
[PING][PATCH] Aarch64: Prevent use of SIMD fcvtz[su] instruction variant with "nosimd"
From: Mihailo Stojanovic
Hi all,
Currently, SF->SI and DF->DI conversions on Aarch64 with the "nosimd"
flag provided sometimes cause the emitting of a vector variant of the
fcvtz[su] instruction (e.g. fcvtzu s0, s0).
This modifies the corresponding pattern to only select the vector
variant of the instruction when generating code with SIMD enabled.
Tested on aarch64-gnu-linux.
gcc/ChangeLog:
* gcc/config/aarch64/aarch64.md
(_trunc2): Set the "arch"
attribute to disambiguate between SIMD and FP variants of the
instruction.
gcc/testsuite/ChangeLog:
* gcc/testsuite/gcc.target/aarch64/fcvt_nosimd.c: New test.
---
gcc/config/aarch64/aarch64.md | 3 ++-
.../gcc.target/aarch64/fcvt_nosimd.c | 23 +++
2 files changed, 25 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.target/aarch64/fcvt_nosimd.c
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index b2abb5b5b3c..dd1dc2bd7a8 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -5989,7 +5989,8 @@
"@
fcvtz\t%0, %1
fcvtz\t%0, %1"
- [(set_attr "type" "neon_fp_to_int_s,f_cvtf2i")]
+ [(set_attr "type" "neon_fp_to_int_s,f_cvtf2i")
+ (set_attr "arch" "simd,fp")]
)
;; Convert HF -> SI or DI
diff --git a/gcc/testsuite/gcc.target/aarch64/fcvt_nosimd.c
b/gcc/testsuite/gcc.target/aarch64/fcvt_nosimd.c
new file mode 100644
index 000..7b2ab65e307
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/fcvt_nosimd.c
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+/* { dg-options "-march=armv8-a+nosimd" } */
+
+#include
+
+uint64_t test_double_to_uint64(double x) {
+ return (uint64_t)x;
+}
+
+int64_t test_double_to_int64(double x) {
+ return (int64_t)x;
+}
+
+uint32_t test_float_to_uint32(float x) {
+ return (uint32_t)x;
+}
+
+int32_t test_float_to_int32(float x) {
+ return (int32_t)x;
+}
+
+/* { dg-final { scan-assembler-not {\tfcvtz[su]\td[0-9]*, d[0-9]*} } } */
+/* { dg-final { scan-assembler-not {\tfcvtz[su]\ts[0-9]*, s[0-9]*} } } */
--
2.31.0
