Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc
On Wed, Jun 16, 2021 at 07:39:02PM +, Qing Zhao wrote: > So, the major question now is: > > Is one single repeatable pattern enough for pattern initialization for all > different types of auto variables? > > If YES, then the implementation for pattern initialization will be much > easier and simpler > as you pointed out. And will save me a lot of pain to implement this > part. > If NO, then we have to keep the current complicate implementation since it > provides us > the flexibility to assign different patterns to different types. > > Honestly, I don’t have a good justification on this question myself. > > The previous references I have so far are the current behavior of CLANG and > Microsoft compiler. > > For your reference, > . CLANG uses different patterns for INTEGER (0x) and FLOAT > (0x) and 32-bit pointer (0x00AA) > https://reviews.llvm.org/D54604 > . Microsoft uses different patterns for INTEGERS ( 0xE2), FLOAT (1.0) > https://msrc-blog.microsoft.com/2020/05/13/solving-uninitialized-stack-memory-on-windows/ > > My understanding from CLANG’s comment is, the patterns are easier to crash > the program for the certain type, therefore easier to > catch any potential bugs. Right, this is the justification for the different patterns. I am fine with a static value for the first version of this functionality, as long as it's a non-canonical virtual memory address when evaluated as a pointer (so that the pattern can't be made to aim at a legitimate fixed allocatable address in memory). > Don’t know why Microsoft chose the pattern like this. > > So, For GCC, what should we do on the pattern initializations, shall we > choose one single repeatable pattern for all the types as you suggested, > Or chose different patterns for different types as Clang and Microsoft > compiler’s behavior? > > Kees, do you have any comment on this? > > How did Linux Kernel use -ftrivial-auto-var-init=pattern feature of CLANG? It's just used as-is from the compiler, and recommended for "debug builds". -- Kees Cook
Re: [Patch] Add 'default' to -foffload=; document that flag [PR67300]
On 6/17/21 5:05 PM, Tobias Burnus wrote:
On 17.06.21 23:57, Sandra Loosemore wrote:
On 6/17/21 1:40 PM, Jakub Jelinek wrote:
Could we introduce a different option which wouldn't imply enabling that
target:
-foffload-options==option
I think that works – in particular, if we do not document all
the legacy stuff but just how it should be used.
That includes not mentioning that disable and default can
be used in a list and that those can also take arguments.
I don't feel qualified to comment on the details of the behavior, but
separating the options and making them more orthogonal to one another
would certainly make things easier to document. :-)
I fully concur.
Probably not fully polished, but I have attached a version for discussion.
Thanks. The description of the options is a lot easier to follow now,
so I mostly have only nit-picky Texinfo/grammar/terminology comments
about the docs now.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index af2ce189fae..82993fa2c1d 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -204,6 +204,7 @@ in the following sections.
-fhosted -ffreestanding @gol
-fopenacc -fopenacc-dim=@var{geom} @gol
-fopenmp -fopenmp-simd @gol
+-foffload=@var{arg} -foffload-options=@var{arg} @gol
-fms-extensions -fplan9-extensions -fsso-struct=@var{endianness} @gol
-fallow-single-precision -fcond-mismatch -flax-vector-conversions @gol
-fsigned-bitfields -fsigned-char @gol
Two spaces instead of one to separate options on the same line in a
@gccoptlist environment.
The -f options are alphabetized in most of the other @gccoptlist tables
in the option summary section. I'm not sure why this group isn't, but
you get extra credit if you fix that, too.
@@ -2639,6 +2640,46 @@ Enable handling of OpenMP's SIMD directives with
@code{#pragma omp}
in C/C++ and @code{!$omp} in Fortran. Other OpenMP directives
are ignored.
+@item -foffload=disable
+@itemx -foffload=default
+@itemx -foffload=@var{target-list}
+@opindex foffload
+@cindex Offloading
+@cindex OpenACC
+@cindex OpenMP
"OpenACC" and "OpenMP" are far too general to be useful for @cindex
entries. "Offloading targets", "OpenACC offloading targets", and
"OpenMP offloading targets" would be more helpful.
+Specify for which offload targets code should be generated. By default,
+code for all supported targets is generated. Using
+@option{-foffload=disable} only code for the host fallback is
+generated, while @option{-foffload=}@var{target-list} generates code
+only for the specified comma-separated list of offload-targets triplets.
+To reset the value to the default, @option{-foffload=default} can be
+used.
+
+Note: Running the compiler with @option{-v} shows the list of
+configured offload targets under @code{OFFLOAD_TARGET_NAMES}.
I'd like to rephrase this a little bit to avoid some awkward sentence
construction, and also not introduce the term "triplet" without
explanation in the user documentation (it's only used in the install and
internals manuals). So:
Specify for which OpenMP and OpenACC offload targets code should be
generated. The default behavior, equivalent to
@option{-foffload=default}, is to generate code for all supported
offload targets. The @option{-foffload=disable} form generates code
only for the host fallback, while @option{-foffload=@var{target-list}}
generates code only for the specified comma-separated list of offload
targets.
Offload targets are specified in GCC's internal target-triplet format.
You can run the compiler with @option{-v} to show the list of configured
offload targets under @code{OFFLOAD_TARGET_NAMES}.
+
+@item -foffload-options=@var{options}
+@itemx -foffload-options=@var{target-triplet-list}=@var{options}
+@opindex foffload
+@cindex Offloading
+@cindex OpenACC
+@cindex OpenMP
Ditto with the overly-general @cindex entries. I'd list these as
"Offloading options" etc instead.
Also use @var{target-list} here instead of @var{target-triplet-list} for
consistency with the previous option and because triplets are not
otherwise a user-visible thing in GCC.
+
+Specify the options passed to the offload-target compiler. While using
+@option{-foffload-options=}@var{options} passes the options to all enabled
+offloading compiler,
+@option{-foffload-options=}@var{target-triplet-list}=@var{options} can
+be used to pass them only to the specified comma-separated list of
+target triplets.
+
Again to fix sentence construction and markup issues:
With @option{-foffload-options=@var{options}}, GCC passes the specified
@var{options} to the compilers for all enabled offloading targets. You
can specify options that apply only to a specific target or targets by
using the @option{-foffload-options=@var{target-list}=@var{options}}
form. The @var{target-list} is a comma-separated list in the same
format as for the @option{-foffload=} option.
+Typical commandlines are
"command lines", two words.
+
+@smallexample
[committed] More useless code elimination on the H8
Two minor improvements on the H8 today.
First, the source operand of a SET could be a SYMBOL_REF. That's valid
for setting condition codes. I'm guessing its primarily valuable when
testing for weak symbols. Either way, adding support for that in
select_cc_mode allows the compiler to remove a few more comparisons.
Second, the H8 does not expose DImode operations, so generic parts of
the compiler will arrange to synthesize DImode operations from SImode
operations. This is fine and good. However, doing so does tend to
generate some useless code. For example (and:DI (reg:DI) (const_int
0x) when synthesized via SImode operations generates an
AND against -1 for the upper word which should simplify into a trivial copy.
But on the H8 we do not have SImode and DImode tieable. So the costing
model falls apart a bit and CSE thinks it's better to just leave things
alone. This patch adds a bit of smarts to the logical expander to avoid
creating the obviously useless logical ops. Note we don't have to
handle everything here. If the RHS would simplify to a constant, CSE
would do the right thing. So we just want to handle cases where the
RHS is going to simplify into a simple register operand. And in
practice I've only seen this fire for AND. Anyway, the twiddle to the
expander eliminates a few more instructions, particularly in libgcc.
Anyway, these have both run through my tester and I'm committing this to
the trunk.
Jeff
commit 629cbc682a773e64c4bcb800ea98fb3051cd810c
Author: Jeff Law
Date: Fri Jun 18 18:02:16 2021 -0400
[committed] More useless code elimination on the H8
gcc/
* config/h8300/h8300.c (h8300_select_cc_mode): Handle SYMBOL_REF.
* config/h8300/logical.md (3 logcial expander): Generate
more efficient code when the source can be trivially simplified.
diff --git a/gcc/config/h8300/h8300.c b/gcc/config/h8300/h8300.c
index 1077a2b6ae0..2b88325d2f7 100644
--- a/gcc/config/h8300/h8300.c
+++ b/gcc/config/h8300/h8300.c
@@ -1950,7 +1950,7 @@ h8300_select_cc_mode (enum rtx_code cond, rtx op0, rtx
op1)
|| GET_CODE (op0) == NEG || GET_CODE (op0) == AND
|| GET_CODE (op0) == IOR || GET_CODE (op0) == XOR
|| GET_CODE (op0) == NOT || GET_CODE (op0) == ASHIFT
- || GET_CODE (op0) == MULT
+ || GET_CODE (op0) == MULT || GET_CODE (op0) == SYMBOL_REF
|| GET_CODE (op0) == SIGN_EXTEND || GET_CODE (op0) == ZERO_EXTEND
|| REG_P (op0) || MEM_P (op0)))
return CCZNmode;
diff --git a/gcc/config/h8300/logical.md b/gcc/config/h8300/logical.md
index cb4c6384bdf..07d36cf0ef4 100644
--- a/gcc/config/h8300/logical.md
+++ b/gcc/config/h8300/logical.md
@@ -4,7 +4,27 @@
(logicals:QHSI (match_operand:QHSI 1 "register_operand" "")
(match_operand:QHSI 2 "h8300_src_operand" "")))]
""
- "")
+ "
+ {
+enum machine_mode mode = GET_MODE (operands[0]);
+/* DImodes are not considered tieable, as a result operations involving
+ subregs of DImode objects are considered expensive which can prevent
+ CSE from doing obvious simplifications.
+
+ We may ultimately change what is tieable, but this is an immediate
+ workaround while we evaluate changes to tieable modes.
+
+ The key in terms of what we want to handle is then the result of
+ the operation is not a constant. */
+if (( == AND && operands[2] == CONSTM1_RTX (mode))
+ || ( == IOR && operands[2] == CONST0_RTX (mode))
+ || ( == XOR && operands[2] == CONST0_RTX (mode))
+ || (( == AND || == IOR) && operands[1] == operands[2]))
+ {
+ emit_move_insn (operands[0], operands[1]);
+ DONE;
+ }
+ }")
;; There's a ton of cleanup to do from here below.
;; --
Re: [PATCH] libstdc++: Implement LWG 3553 change to split_view
On Fri, 18 Jun 2021 at 05:01, Patrick Palka via Libstdc++
wrote:
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (split_view::_OuterIter::value_type::begin):
> Remove the non-const overload, and remove the copyable constraint
> on the const overload as per LWG 3553.
OK
> ---
> libstdc++-v3/include/std/ranges | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
> index bf85b1629f0..49babe81437 100644
> --- a/libstdc++-v3/include/std/ranges
> +++ b/libstdc++-v3/include/std/ranges
> @@ -2932,14 +2932,8 @@ namespace views::__adaptor
>
> constexpr _InnerIter<_Const>
> begin() const
> - requires copyable<_OuterIter>
> { return _InnerIter<_Const>{_M_i}; }
>
> - constexpr _InnerIter<_Const>
> - begin()
> - requires (!copyable<_OuterIter>)
> - { return _InnerIter<_Const>{std::move(_M_i)}; }
> -
> constexpr default_sentinel_t
> end() const
> { return default_sentinel; }
> --
> 2.32.0.93.g670b81a890
>
Re: [PATCH 5/5] libstdc++: Implement new views::split as per P2210
On Thu, 17 Jun 2021 at 16:59, Patrick Palka via Libstdc++
wrote:
>
> This implements the new views::split as specified by P2210R2 "Superior
> string splitting".
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (__non_propagating_cache::operator bool):
> Define.
> (split_view): Define as per P2210.
> (views::__detail::__can_split_view): Define.
> (views::_Split, views::Split): Define.
> * testsuite/std/ranges/adaptors/100577.cc (test01, test02):
> Test views::split.
> * testsuite/std/ranges/adaptors/split.cc: New test.
> * testsuite/std/ranges/p2325.cc (test08a): New test.
> * testsuite/std/ranges/p2367.cc (test01): Test views::split.
OK
> ---
> libstdc++-v3/include/std/ranges | 205 ++
> .../testsuite/std/ranges/adaptors/100577.cc | 16 +-
> .../testsuite/std/ranges/adaptors/split.cc| 196 +
> libstdc++-v3/testsuite/std/ranges/p2325.cc| 14 ++
> libstdc++-v3/testsuite/std/ranges/p2367.cc| 1 +
> 5 files changed, 430 insertions(+), 2 deletions(-)
> create mode 100644 libstdc++-v3/testsuite/std/ranges/adaptors/split.cc
>
> diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
> index 78562924bee..42278f128b8 100644
> --- a/libstdc++-v3/include/std/ranges
> +++ b/libstdc++-v3/include/std/ranges
> @@ -1195,6 +1195,10 @@ namespace views::__adaptor
> return *this;
> }
>
> + constexpr explicit
> + operator bool() const noexcept
> + { return this->_M_is_engaged(); }
> +
> constexpr _Tp&
> operator*() noexcept
> { return this->_M_get(); }
> @@ -3278,6 +3282,207 @@ namespace views::__adaptor
> inline constexpr _LazySplit lazy_split;
>} // namespace views
>
> + template
> +requires view<_Vp> && view<_Pattern>
> + && indirectly_comparable, iterator_t<_Pattern>,
> + ranges::equal_to>
> + class split_view : public view_interface>
> + {
> + private:
> +_Pattern _M_pattern = _Pattern();
> +__detail::__non_propagating_cache>>
> _M_cached_begin;
> +_Vp _M_base = _Vp();
> +
> +struct _Iterator;
> +struct _Sentinel;
> +
> + public:
> +split_view() requires (default_initializable<_Vp>
> + && default_initializable<_Pattern>)
> + = default;
> +
> +constexpr
> +split_view(_Vp __base, _Pattern __pattern)
> + : _M_pattern(std::move(__pattern)),
> + _M_base(std::move(__base))
> +{ }
> +
> +template
> + requires constructible_from<_Vp, views::all_t<_Range>>
> + && constructible_from<_Pattern, single_view>>
> +constexpr
> +split_view(_Range&& __r, range_value_t<_Range> __e)
> + : _M_pattern(views::single(__e)),
> + _M_base(views::all(std::forward<_Range>(__r)))
> +{ }
> +
> +constexpr _Vp
> +base() const& requires copyable<_Vp>
> +{ return _M_base; }
> +
> +constexpr _Vp
> +base() &&
> +{ return std::move(_M_base); }
> +
> +constexpr _Iterator
> +begin()
> +{
> + if (!_M_cached_begin)
> + _M_cached_begin = _M_find_next(ranges::begin(_M_base));
> + return {this, ranges::begin(_M_base), *_M_cached_begin};
> +}
> +
> +constexpr auto
> +end()
> +{
> + if constexpr (common_range<_Vp>)
> + return _Iterator{this, ranges::end(_M_base), {}};
> + else
> + return _Sentinel{this};
> +}
> +
> +constexpr subrange>
> +_M_find_next(iterator_t<_Vp> __it)
> +{
> + auto [__b, __e] = ranges::search(subrange(__it, ranges::end(_M_base)),
> _M_pattern);
> + if (__b != ranges::end(_M_base) && ranges::empty(_M_pattern))
> + {
> + ++__b;
> + ++__e;
> + }
> + return {__b, __e};
> +}
> +
> + private:
> +struct _Iterator
> +{
> +private:
> + split_view* _M_parent = nullptr;
> + iterator_t<_Vp> _M_cur = iterator_t<_Vp>();
> + subrange> _M_next = subrange>();
> + bool _M_trailing_empty = false;
> +
> +public:
> + using iterator_concept = forward_iterator_tag;
> + using iterator_category = input_iterator_tag;
> + using value_type = subrange>;
> + using difference_type = range_difference_t<_Vp>;
> +
> + _Iterator() requires default_initializable> = default;
> +
> + constexpr
> + _Iterator(split_view* __parent,
> + iterator_t<_Vp> __current,
> + subrange> __next)
> + : _M_parent(__parent),
> + _M_cur(std::move(__current)),
> + _M_next(std::move(__next))
> + { }
> +
> + constexpr iterator_t<_Vp>
> + base() const
> + { return _M_cur; }
> +
> + constexpr value_type
> + operator*() const
> + { return {_M_cur, _M_next.begin()}; }
> +
> + constexpr _Iterator&
> + operator++()
> + {
> + _M_cur = _M_next.begin();
> + if (_M_cur !=
Re: [PATCH 4/5] libstdc++: Implement resolution of LWG 3478 as per P2210
On Thu, 17 Jun 2021 at 16:51, Patrick Palka via Libstdc++
wrote:
>
> This implements the part of P2210R2 "Superior String Splitting" that
> resolves LWG 3478 for split_view (now named lazy_split_view).
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (lazy_split_view::_OuterIter::__at_end):
> Check _M_trailing_empty.
> (lazy_split_view::_OuterIter::_M_trailing_empty): Define this
> data member.
> (lazy_split_view::_OuterIter::operator++): Set _M_trailing_empty
> appropriately.
> (lazy_split_view::_OuterIter::operator==): Compare
> _M_trailing_empty.
> * testsuite/std/ranges/adaptors/100479.cc (test03): Expect two
> split parts instead of one.
> * testsuite/std/ranges/adaptors/lazy_split.cc (test11): New test.
OK (for trunk only, I think).
> ---
> libstdc++-v3/include/std/ranges | 21 +++
> .../testsuite/std/ranges/adaptors/100479.cc | 6 +++---
> .../std/ranges/adaptors/lazy_split.cc | 15 +
> 3 files changed, 35 insertions(+), 7 deletions(-)
>
> diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
> index cc1ef112ff1..78562924bee 100644
> --- a/libstdc++-v3/include/std/ranges
> +++ b/libstdc++-v3/include/std/ranges
> @@ -2879,7 +2879,7 @@ namespace views::__adaptor
>
> constexpr bool
> __at_end() const
> - { return __current() == ranges::end(_M_parent->_M_base); }
> + { return __current() == ranges::end(_M_parent->_M_base) &&
> !_M_trailing_empty; }
>
> // [range.lazy.split.outer] p1
> // Many of the following specifications refer to the notional
> member
> @@ -2909,6 +2909,7 @@ namespace views::__adaptor
> [[no_unique_address]]
> __detail::__maybe_present_t,
> iterator_t<_Base>> _M_current;
> + bool _M_trailing_empty = false;
>
> public:
> using iterator_concept = conditional_t,
> @@ -2977,7 +2978,10 @@ namespace views::__adaptor
> // 3505. lazy_split_view::outer-iterator::operator++ misspecified
> const auto __end = ranges::end(_M_parent->_M_base);
> if (__current() == __end)
> - return *this;
> + {
> + _M_trailing_empty = false;
> + return *this;
> + }
> const auto [__pbegin, __pend] = subrange{_M_parent->_M_pattern};
> if (__pbegin == __pend)
> ++__current();
> @@ -2986,7 +2990,11 @@ namespace views::__adaptor
> __current() = ranges::find(std::move(__current()), __end,
>*__pbegin);
> if (__current() != __end)
> - ++__current();
> + {
> + ++__current();
> + if (__current() == __end)
> + _M_trailing_empty = true;
> + }
> }
> else
> do
> @@ -2996,6 +3004,8 @@ namespace views::__adaptor
> if (__p == __pend)
> {
> __current() = __b;
> + if (__current() == __end)
> + _M_trailing_empty = true;
> break;
> }
> } while (++__current() != __end);
> @@ -3018,7 +3028,10 @@ namespace views::__adaptor
> friend constexpr bool
> operator==(const _OuterIter& __x, const _OuterIter& __y)
> requires forward_range<_Base>
> - { return __x._M_current == __y._M_current; }
> + {
> + return __x._M_current == __y._M_current
> + && __x._M_trailing_empty == __y._M_trailing_empty;
> + }
>
> friend constexpr bool
> operator==(const _OuterIter& __x, default_sentinel_t)
> diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/100479.cc
> b/libstdc++-v3/testsuite/std/ranges/adaptors/100479.cc
> index 9899ff92c0b..b8c1e6f4f57 100644
> --- a/libstdc++-v3/testsuite/std/ranges/adaptors/100479.cc
> +++ b/libstdc++-v3/testsuite/std/ranges/adaptors/100479.cc
> @@ -95,11 +95,11 @@ test03()
> | views::drop_while([](auto) { return false; })
> | views::filter([](auto) { return true; });
>static_assert(ranges::forward_range);
> - VERIFY( ranges::next(v.begin()) == v.end() );
> + VERIFY( ranges::distance(v) == 2 );
>auto w = v;
> - VERIFY( ranges::next(w.begin()) == w.end() );
> + VERIFY( ranges::distance(v) == 2 );
>auto z = std::move(w);
> - VERIFY( ranges::next(z.begin()) == z.end() );
> + VERIFY( ranges::distance(v) == 2 );
>return true;
> }
>
> diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/lazy_split.cc
> b/libstdc++-v3/testsuite/std/ranges/adaptors/lazy_split.cc
> index 12844525d86..133e9a7025b 100644
> --- a/libstdc++-v3/testsuite/std/ranges/adaptors/lazy_split.cc
> +++
Re: [PATCH 3/5] libstdc++: Rename views::split to views::lazy_split as per P2210
On Thu, 17 Jun 2021 at 16:55, Patrick Palka via Libstdc++
wrote:
>
> This mostly mechanical patch performs the renaming part of P2210R3
> "Superior string splitting". It also defines _InnerIter::base()
> overloads.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges: Rename views::split to views::lazy_split,
> split_view to lazy_split_view, etc. throughout.
> (lazy_split_view::_InnerIter::base): Define as per P2210.
> * testsuite/std/ranges/*: Likewise.
The base() member could be noexcept, but that can be added later.
OK.
> ---
> libstdc++-v3/include/std/ranges | 68 +++
> .../testsuite/std/ranges/adaptors/100479.cc | 2 +-
> .../testsuite/std/ranges/adaptors/100577.cc | 20 +++---
> .../testsuite/std/ranges/adaptors/join.cc | 2 +-
> .../adaptors/{split.cc => lazy_split.cc} | 54 +++
> .../{split_neg.cc => lazy_split_neg.cc} | 6 +-
> .../testsuite/std/ranges/adaptors/p2281.cc| 18 ++---
> .../testsuite/std/ranges/adaptors/sizeof.cc | 2 +-
> libstdc++-v3/testsuite/std/ranges/p2259.cc| 6 +-
> libstdc++-v3/testsuite/std/ranges/p2325.cc| 10 +--
> libstdc++-v3/testsuite/std/ranges/p2367.cc| 4 +-
> 11 files changed, 100 insertions(+), 92 deletions(-)
> rename libstdc++-v3/testsuite/std/ranges/adaptors/{split.cc =>
> lazy_split.cc} (76%)
> rename libstdc++-v3/testsuite/std/ranges/adaptors/{split_neg.cc =>
> lazy_split_neg.cc} (79%)
>
> diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
> index f93a880ff8a..cc1ef112ff1 100644
> --- a/libstdc++-v3/include/std/ranges
> +++ b/libstdc++-v3/include/std/ranges
> @@ -2826,19 +2826,19 @@ namespace views::__adaptor
> && (remove_reference_t<_Range>::size() <= 1);
>
> template
> - struct __split_view_outer_iter_cat
> + struct __lazy_split_view_outer_iter_cat
>{ };
>
> template
> - struct __split_view_outer_iter_cat<_Base>
> + struct __lazy_split_view_outer_iter_cat<_Base>
>{ using iterator_category = input_iterator_tag; };
>
> template
> - struct __split_view_inner_iter_cat
> + struct __lazy_split_view_inner_iter_cat
>{ };
>
> template
> - struct __split_view_inner_iter_cat<_Base>
> + struct __lazy_split_view_inner_iter_cat<_Base>
>{
>private:
> static constexpr auto
> @@ -2860,7 +2860,7 @@ namespace views::__adaptor
>&& indirectly_comparable, iterator_t<_Pattern>,
>ranges::equal_to>
>&& (forward_range<_Vp> || __detail::__tiny_range<_Pattern>)
> -class split_view : public view_interface>
> +class lazy_split_view : public view_interface _Pattern>>
> {
> private:
>template
> @@ -2871,17 +2871,17 @@ namespace views::__adaptor
>
>template
> struct _OuterIter
> - : __detail::__split_view_outer_iter_cat<_Base<_Const>>
> + : __detail::__lazy_split_view_outer_iter_cat<_Base<_Const>>
> {
> private:
> - using _Parent = __detail::__maybe_const_t<_Const, split_view>;
> - using _Base = split_view::_Base<_Const>;
> + using _Parent = __detail::__maybe_const_t<_Const, lazy_split_view>;
> + using _Base = lazy_split_view::_Base<_Const>;
>
> constexpr bool
> __at_end() const
> { return __current() == ranges::end(_M_parent->_M_base); }
>
> - // [range.split.outer] p1
> + // [range.lazy.split.outer] p1
> // Many of the following specifications refer to the notional
> member
> // current of outer-iterator. current is equivalent to current_ if
> // V models forward_range, and parent_->current_ otherwise.
> @@ -2914,7 +2914,7 @@ namespace views::__adaptor
> using iterator_concept = conditional_t,
> forward_iterator_tag,
> input_iterator_tag>;
> - // iterator_category defined in __split_view_outer_iter_cat
> + // iterator_category defined in __lazy_split_view_outer_iter_cat
> using difference_type = range_difference_t<_Base>;
>
> struct value_type : view_interface
> @@ -2974,7 +2974,7 @@ namespace views::__adaptor
> operator++()
> {
> // _GLIBCXX_RESOLVE_LIB_DEFECTS
> - // 3505. split_view::outer-iterator::operator++ misspecified
> + // 3505. lazy_split_view::outer-iterator::operator++ misspecified
> const auto __end = ranges::end(_M_parent->_M_base);
> if (__current() == __end)
> return *this;
> @@ -3030,10 +3030,10 @@ namespace views::__adaptor
>
>template
> struct _InnerIter
> - : __detail::__split_view_inner_iter_cat<_Base<_Const>>
> + : __detail::__lazy_split_view_inner_iter_cat<_Base<_Const>>
> {
> private:
> -
Re: [PATCH] libstdc++: Implement LWG 3555 changes to transform/elements_view
On Fri, 18 Jun 2021 at 05:04, Patrick Palka via Libstdc++
wrote:
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (transform_view::_Iterator::_S_iter_concept):
> Consider _Base instead of _Vp as per LWG 3555.
> (elements_view::_Iterator::_S_iter_concept): Likewise.
OK
> ---
> libstdc++-v3/include/std/ranges | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
> index f93a880ff8a..bf85b1629f0 100644
> --- a/libstdc++-v3/include/std/ranges
> +++ b/libstdc++-v3/include/std/ranges
> @@ -1613,11 +1613,11 @@ namespace views::__adaptor
> static auto
> _S_iter_concept()
> {
> - if constexpr (random_access_range<_Vp>)
> + if constexpr (random_access_range<_Base>)
> return random_access_iterator_tag{};
> - else if constexpr (bidirectional_range<_Vp>)
> + else if constexpr (bidirectional_range<_Base>)
> return bidirectional_iterator_tag{};
> - else if constexpr (forward_range<_Vp>)
> + else if constexpr (forward_range<_Base>)
> return forward_iterator_tag{};
> else
> return input_iterator_tag{};
> @@ -3659,11 +3659,11 @@ namespace views::__adaptor
> static auto
> _S_iter_concept()
> {
> - if constexpr (random_access_range<_Vp>)
> + if constexpr (random_access_range<_Base>)
> return random_access_iterator_tag{};
> - else if constexpr (bidirectional_range<_Vp>)
> + else if constexpr (bidirectional_range<_Base>)
> return bidirectional_iterator_tag{};
> - else if constexpr (forward_range<_Vp>)
> + else if constexpr (forward_range<_Base>)
> return forward_iterator_tag{};
> else
> return input_iterator_tag{};
> --
> 2.32.0.93.g670b81a890
>
Re: [PATCH] libstdc++: Implement LWG 3546 changes to common_iterator
On Fri, 18 Jun 2021 at 04:59, Patrick Palka via Libstdc++
wrote:
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/stl_iterator.h
> (__detail::__common_iter_use_postfix_proxy): Add
> move_constructible constraint as LWG 3546.
> (common_iterator::__postfix_proxy): Adjust initializer of
> _M_keep as per LWG 3546.
OK, thanks
> ---
> libstdc++-v3/include/bits/stl_iterator.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libstdc++-v3/include/bits/stl_iterator.h
> b/libstdc++-v3/include/bits/stl_iterator.h
> index 6ec046b597b..7fe727d8093 100644
> --- a/libstdc++-v3/include/bits/stl_iterator.h
> +++ b/libstdc++-v3/include/bits/stl_iterator.h
> @@ -1672,7 +1672,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> template
>concept __common_iter_use_postfix_proxy
> = (!requires (_It& __i) { { *__i++ } -> __can_reference; })
> - && constructible_from, iter_reference_t<_It>>;
> + && constructible_from, iter_reference_t<_It>>
> + && move_constructible>;
>} // namespace __detail
>
>/// An iterator/sentinel adaptor for representing a non-common range.
> @@ -1715,7 +1716,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>iter_value_t<_It> _M_keep;
>
>__postfix_proxy(iter_reference_t<_It>&& __x)
> - : _M_keep(std::move(__x)) { }
> + : _M_keep(std::forward>(__x)) { }
>
>friend class common_iterator;
>
> --
> 2.32.0.93.g670b81a890
>
[PATCH] tree-optimization/101014 - Remove poor value computations.
I am pleased to say that this patch kills the poor value computations in
the ranger's cache.
Its been a bit of a thorn, and is mostly a hack that was applied early
on to enable getting some opportunities that were hard to get otherwise.
The more consistent propagation we now do combined with other changes
means I can kill this wart on trunk. It even results in a 1% speedup..
and should resolve some of the excessive compile time issues causes by
undesirable iteration, including 101014.. for good I hope :-).
I tried turning off the poor_value computations on the GCC11 branch, and
we may want to consider doing it there too. In my testsuite, we miss a
total of 3 cases out of 4700 new ones identified by ranger. For the
stability, I'd suggest we turn off poor_value computations there as
well. This patch rips out all the code, but for GCC11 I'd just change
push_poor_value to always return false, thus never registering any
values. less churn that way. I'll run some tests and post that
separately if you think we should go ahead with it.
Bootstraps on 86_64-pc-linux-gnu with no regressions. pushed.
Andrew
The details:
The cache is designed to propagate info without creating NEW info. Ie,
It cannot query new ranges, cannot set global ranges, etc... only the
higher level ranger can do that. This is how we avoid cycles when
iterating.. Ranger says "This set this value to X here" , and the
cache's job is to propagate that info around the CFG as needed, applying
static GORI outgoing ranges along the way. Only the ranger can request
/set NEW information.
There were some cases where back edges were missing key bits of info
that hadn't been created yet. The "poor value" approach was a stop-gap
measure until things improve. When the cache is trying to propagate a
range, the GORI edge computations sometimes wants a value which is not
available. Under some conditions it is allowed to register this as a
"poor value" and continue propagating. When done, it looks at the poor
value list, and asks the ranger to "go get a new value for this". If
the ranger finds a better value, then this new value is propagated
around. So its a bit of a cheat from the original design. The ranger is
still the only new-info creator, but the request is sometimes started
from the cache. This is not desirable, and can lead to some
inconsistencies & inefficiencies.
As one can imagine. this sometimes causes significant iteration, as in
this testcase. Ie, the new ranger request from the cache triggers
another poor value request, etc etc. Which is why it wasn't designed to
work that way. Anyway, longer story shorter, I revisited the poor value
code, and discovered that with the new GORI and fold_using_range rework
from the past month, dropping the poor value code results in *0*
difference in any of our test cases/suites. Further more, the biggest
thing that it really enabled was picking up range restrictions imposed
by unvisited statements that were being forced to VARYING. The new
rework allows such statements to simply be folded using the new
global_range_query and even so that bit of info is now easily captured.
That's the enhancement from the second patch.
commit 870b674f72d4894b94efa61764fd87ecec29ffde
Author: Andrew MacLeod
Date: Fri Jun 18 12:33:18 2021 -0400
Remove poor value computations.
Remove the old "poor value" approach which made callbacks into ranger
from the cache. Use only the best available value for all propagation.
PR tree-optimization/101014
* gimple-range-cache.cc (ranger_cache::ranger_cache): Remove poor
value list.
(ranger_cache::~ranger_cache): Ditto.
(ranger_cache::enable_new_values): Delete.
(ranger_cache::push_poor_value): Delete.
(ranger_cache::range_of_def): Remove poor value processing.
(ranger_cache::entry_range): Ditto.
(ranger_cache::fill_block_cache): Ditto.
* gimple-range-cache.h (class ranger_cache): Remove poor value members.
* gimple-range.cc (gimple_ranger::range_of_expr): Remove call.
* gimple-range.h (class gimple_ranger): Adjust.
diff --git a/gcc/gimple-range-cache.cc b/gcc/gimple-range-cache.cc
index 2c6e5bb2d38..c85b299d13e 100644
--- a/gcc/gimple-range-cache.cc
+++ b/gcc/gimple-range-cache.cc
@@ -706,16 +706,13 @@ temporal_cache::set_always_current (tree name)
// --
-ranger_cache::ranger_cache (gimple_ranger ) : query (q)
+ranger_cache::ranger_cache ()
{
m_workback.create (0);
m_workback.safe_grow_cleared (last_basic_block_for_fn (cfun));
m_update_list.create (0);
m_update_list.safe_grow_cleared (last_basic_block_for_fn (cfun));
m_update_list.truncate (0);
- m_poor_value_list.create (0);
- m_poor_value_list.safe_grow_cleared (20);
- m_poor_value_list.truncate (0);
Re: [PATCH] libstdc++: Reduce ranges::minmax/minmax_element comparison complexity
On Fri, 18 Jun 2021 at 18:44, Patrick Palka wrote: > > Ping; here's the same patch with the above comment corrected. > > -- >8 -- > > Subject: [PATCH] libstdc++: Reduce ranges::minmax/minmax_element comparison > complexity > > This rewrites ranges::minmax and ranges::minmax_element so that it > performs at most 3*N/2 many comparisons, as required by the standard. > In passing, this also fixes PR100387 by avoiding a premature std::move > in ranges::minmax and in std::shift_right. > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps > 10/11? OK, for all branches, thanks.
Re: [PATCH] Modula-2 into the GCC tree on master
Matthias Klose writes: > > I checked that with a profiled lto build. The build succeeds with the > attached > patch to respect the parallel linking limitations, which you can configure > with > --enable-link-serialization=N > > However the build fails in the installation step with: > > [...] > Linking stage1/m2/cc1gm2 |--| 0% > x86_64-linux-gnu-g++-10 -std=c++11 -no-pie -g -O2 -DIN_GCC-W -Wall > -Wno-narrowing -Wwrite-strings -Wcast-q > ual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes > -Wno-error=format-diag -Wold-style-definition -Wc++-compat - > fno-common -DHAVE_CONFIG_H -o stage1/m2/cc1gm2 m2/gm2-lang.o > m2/stor-layout.o > m2/m2pp.o m2/gm2-gcc/m2assert.o m2/gm2-gcc/m2block.o m2/gm2-gcc/m2builtins.o > m2/gm2-gcc/m2except.o m2/gm2-gcc/m2convert.o m2/gm2-gcc/m2color.o > m2/gm2-gcc/m2decl.o m2/gm2-gcc/m2expr.o m2/gm2-gcc/m2linemap.o > m2/gm2-gcc/m2statement.o m2/gm2-gcc/m2type.o m2/gm2-gcc/m2tree.o > m2/gm2-gcc/m2treelib.o m2/gm2-gcc/m2top.o m2/gm2-gcc/m2misc.o > m2/gm2-gcc/init.o > m2/gm2-compiler-boot/m2flex.o \ > attribs.o \ > m2/gm2-compiler-boot/gm2.a > m2/gm2-libs-boot/libgm2.a m2/mc-boot-ch/Glibc.o m2/mc-boot-ch/Gmcrts.o > m2/gm2-gcc/rtegraph.o \ > libbackend.a main.o libcommon-target.a > libcommon.a > ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a > ../libcpp/libcpp.a > ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a > ../libdecnumber/libdecnumber.a -lisl -lmpc -lmpfr -lgmp -rdynamic -ldl -lz > -lzstd > lto1: fatal error: bytecode stream in file 'm2/gm2-compiler-boot/m2flex.o' > generated with LTO version 12.0 instead of the expected 9.2 > compilation terminated. > lto-wrapper: fatal error: x86_64-linux-gnu-g++-10 returned 1 exit status > compilation terminated. > /usr/bin/ld: error: lto-wrapper failed > collect2: error: ld returned 1 exit status > Command exited with non-zero status 1 > > x86_64-linux-gnu-g++-10 is the compiler used for the bootstrap. I haven't > checked if that is also seen for a normal bootstrap. Apparently it tries to > re-bootstrap the compiler. > > The build is configured with --with-build-config=bootstrap-lto-lean, built > with > make profiledbootstrap-lean Hi Matthias, thanks for the patch - I will re-examine the install - there is definitely something odd going on. On one of my machines it always wants to rebuild gcc/m2/gm2-lang.o and falls over and on another (same release - same gcc version 6.3.0 20170516 - debian stretch) it succeeds. Thanks for the tips on --enable-link-serialization=N, regards, Gaius
Re: [PATCH] libgccjit: Handle truncation and extension for casts [PR 95498]
Ok. Here's the patch with the updated subject and with format fixed. Le vendredi 18 juin 2021 à 16:54 -0400, David Malcolm a écrit : > On Fri, 2021-06-18 at 16:42 -0400, Antoni Boucher wrote: > > I'm sending the patch once again for review. > > > > As it's the first time I'll land a patch, I'm not sure what needs > > to be > > done when it's approved. > > Do I just commit it to the master branch directly? > > Commit (and push), yes, but... > > Please ensure the subject line of the commit matches our policy: > > "libgccjit: Handle truncation and extension for casts [PR95498]" > > is a good subject, whereas: > > "This patch handles truncation and extension for casts in jit." > > is not. > > We have some hooks that will only accept pushes if the commit message > has a correctly formatted ChangeLog. The hooks ought to also add > notification comments to bugzilla for any bugs mentioned in the > commit > message. > > See https://gcc.gnu.org/gitwrite.html#checkin > > > FWIW in my own workflow I have a writable working copy that I keep > for > just doing pushes; > I do a > git pull > verify the build, then > git am FOO.patch --ignore-date > to apply the patch that was tested and approved, then do a last test > with that, then > git push > > That way I only push the patches that I've tested and have been > approved, and the other ones are in an entirely separate working > copy. > This may be overkill though. > > I'm also on #gcc IRC right now on OFTC (dmalcolm) if you run into > issues. > > Dave > > > > > Thanks! > > > > Le vendredi 11 juin 2021 à 13:49 -0400, David Malcolm a écrit : > > > On Thu, 2021-05-27 at 21:22 -0400, Antoni Boucher wrote: > > > > Here's the patch with the condition removed. > > > > I believe everything is now fixed. > > > > Thanks! > > > > > > Thanks; this looks good to me. Is this the latest version of the > > > patch; would you like me to apply it? > > > > > > Dave > > > > > > > > > > > Le jeudi 27 mai 2021 à 18:21 -0400, David Malcolm a écrit : > > > > > On Tue, 2021-05-25 at 20:16 -0400, Antoni Boucher wrote: > > > > > > I updated the patch according to the comments by Tom > > > > > > Tromey. > > > > > > > > > > > > There's one question left about your question regarding > > > > > > C_MAYBE_CONST_EXPR, David: > > > > > > > > > > > > I am not sure if we can get a C_MAYBE_CONST_EXPR from > > > > > > libgccjit, > > > > > > and > > > > > > it > > > > > > indeed seems like it's only created in c-family. > > > > > > However, we do use it in libgccjit here: > > > > > > https://github.com/gcc-mirror/gcc/blob/master/gcc/jit/jit-playback.c#L1180 > > > > > > > > > > > > I tried removing the condition `if (TREE_CODE (t_ret) != > > > > > > C_MAYBE_CONST_EXPR)` and all the tests of libgccjit still > > > > > > pass. > > > > > > > > > > > > That code was copied from here: > > > > > > https://github.com/gcc-mirror/gcc/blob/master/gcc/c/c-convert.c#L175 > > > > > > and might not be needed in libgccjit. > > > > > > > > > > > > Should I just remove the condition, then? > > > > > > > > > > I think so. > > > > > > > > > > Thanks > > > > > Dave > > > > > > > > > > > > > > > > > Le jeudi 13 mai 2021 à 19:58 -0400, David Malcolm a écrit : > > > > > > > On Thu, 2021-05-13 at 19:31 -0400, Antoni Boucher wrote: > > > > > > > > Thanks for your answer. > > > > > > > > > > > > > > > > See my answers below: > > > > > > > > > > > > > > > > Le jeudi 13 mai 2021 à 18:13 -0400, David Malcolm a > > > > > > > > écrit : > > > > > > > > > On Sat, 2021-02-20 at 17:17 -0500, Antoni Boucher via > > > > > > > > > Gcc- > > > > > > > > > patches > > > > > > > > > wrote: > > > > > > > > > > Hi. > > > > > > > > > > Thanks for your feedback! > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sorry about the delay in responding. > > > > > > > > > > > > > > > > > > In the past I was hesitant about adding more cast > > > > > > > > > support > > > > > > > > > to > > > > > > > > > libgccjit > > > > > > > > > since I felt that the user could always just create a > > > > > > > > > union > > > > > > > > > to > > > > > > > > > do > > > > > > > > > the > > > > > > > > > cast. Then I tried actually using the libgccjit API > > > > > > > > > to > > > > > > > > > do > > > > > > > > > this, > > > > > > > > > and > > > > > > > > > realized how much work it adds, so I now think we do > > > > > > > > > want > > > > > > > > > to > > > > > > > > > support > > > > > > > > > casting more types. > > > > > > > > > > > > > > > > > > > > > > > > > > > > See answers below: > > > > > > > > > > > > > > > > > > > > On Sat, Feb 20, 2021 at 11:20:35AM -0700, Tom > > > > > > > > > > Tromey > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > "Antoni" == Antoni Boucher via Gcc- > > > > > > > > > > > > > > > > patches > > > > > > > > > > > > > > > > < > > > > > > > > > > > > > > > > gcc-patches@gcc.gnu.org> writes: > > > > > > > > > > > > > > > > > > > > > > Antoni> gcc/jit/ > > > > > > > > > > > Antoni>
Re: [PATCH] Modula-2 into the GCC tree on master
Segher Boessenkool writes: > Hi Gaius, > > On Thu, Jun 17, 2021 at 11:26:41PM +0100, Gaius Mulley via Gcc-patches wrote: >> here are a set of patches which merge the gm2 front end into the >> GCC tree. > > I have looked through the patches in this email, and they all look good > too me. (There are a few warnings about whitespace from "git am", I > haven't looked if those are from your code, or auto-generated). ah thanks - yes I'll try and avoid generating whitespace diff hunks >> The patches have been bootstrapped under aarch64 GNU/Linux >> Debian Stretch using make -j 4, x86_64 GNU/Linux Debian Stretch built >> using make -j 24 and also under x86_64 GNU/Linux Debian Buster using >> make -j 4. > > I am building it on powerpc64-linux (-m32,-m64) and poweerpc64le-linux > currently. (All CentOS 7 fwiw). excellent the more varieties the better - I'm eagerly awaiting a risc-v motherboard which might also be interesting > It does not want to build gm2tools, haven't investigated that yet > either. > > Will report results later. Thanks for your persistence! many thanks for trying it and your patience, regards, Gaius
[PATCH] Added myself to the MAINTAINERS file
Hi. I pushed a patch adding myself to the maintainers file. From 93022946df2463ad49e3eaa2f6d43c47c16f31c0 Mon Sep 17 00:00:00 2001 From: Antoni Boucher Date: Fri, 18 Jun 2021 16:49:20 -0400 Subject: [PATCH] MAINTAINERS: Add myself for write after approval ChangeLog: 2021-06-18 Antoni Boucher * MAINTAINERS (Write After Approval): Add myself. --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index e04477831eb..32a414ba8af 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -337,6 +337,7 @@ Lynn Boger Ian Bolton Andrea Bona Neil Booth +Antoni Boucher Robert Bowdidge Joel Brobecker Dave Brolley -- 2.32.0
Re: [PATCH] libgccjit: Handle truncation and extension for casts [PR 95498]
On Fri, 2021-06-18 at 16:42 -0400, Antoni Boucher wrote:
> I'm sending the patch once again for review.
>
> As it's the first time I'll land a patch, I'm not sure what needs to be
> done when it's approved.
> Do I just commit it to the master branch directly?
Commit (and push), yes, but...
Please ensure the subject line of the commit matches our policy:
"libgccjit: Handle truncation and extension for casts [PR95498]"
is a good subject, whereas:
"This patch handles truncation and extension for casts in jit."
is not.
We have some hooks that will only accept pushes if the commit message
has a correctly formatted ChangeLog. The hooks ought to also add
notification comments to bugzilla for any bugs mentioned in the commit
message.
See https://gcc.gnu.org/gitwrite.html#checkin
FWIW in my own workflow I have a writable working copy that I keep for
just doing pushes;
I do a
git pull
verify the build, then
git am FOO.patch --ignore-date
to apply the patch that was tested and approved, then do a last test
with that, then
git push
That way I only push the patches that I've tested and have been
approved, and the other ones are in an entirely separate working copy.
This may be overkill though.
I'm also on #gcc IRC right now on OFTC (dmalcolm) if you run into
issues.
Dave
>
> Thanks!
>
> Le vendredi 11 juin 2021 à 13:49 -0400, David Malcolm a écrit :
> > On Thu, 2021-05-27 at 21:22 -0400, Antoni Boucher wrote:
> > > Here's the patch with the condition removed.
> > > I believe everything is now fixed.
> > > Thanks!
> >
> > Thanks; this looks good to me. Is this the latest version of the
> > patch; would you like me to apply it?
> >
> > Dave
> >
> > >
> > > Le jeudi 27 mai 2021 à 18:21 -0400, David Malcolm a écrit :
> > > > On Tue, 2021-05-25 at 20:16 -0400, Antoni Boucher wrote:
> > > > > I updated the patch according to the comments by Tom Tromey.
> > > > >
> > > > > There's one question left about your question regarding
> > > > > C_MAYBE_CONST_EXPR, David:
> > > > >
> > > > > I am not sure if we can get a C_MAYBE_CONST_EXPR from
> > > > > libgccjit,
> > > > > and
> > > > > it
> > > > > indeed seems like it's only created in c-family.
> > > > > However, we do use it in libgccjit here:
> > > > > https://github.com/gcc-mirror/gcc/blob/master/gcc/jit/jit-playback.c#L1180
> > > > >
> > > > > I tried removing the condition `if (TREE_CODE (t_ret) !=
> > > > > C_MAYBE_CONST_EXPR)` and all the tests of libgccjit still pass.
> > > > >
> > > > > That code was copied from here:
> > > > > https://github.com/gcc-mirror/gcc/blob/master/gcc/c/c-convert.c#L175
> > > > > and might not be needed in libgccjit.
> > > > >
> > > > > Should I just remove the condition, then?
> > > >
> > > > I think so.
> > > >
> > > > Thanks
> > > > Dave
> > > >
> > > > >
> > > > > Le jeudi 13 mai 2021 à 19:58 -0400, David Malcolm a écrit :
> > > > > > On Thu, 2021-05-13 at 19:31 -0400, Antoni Boucher wrote:
> > > > > > > Thanks for your answer.
> > > > > > >
> > > > > > > See my answers below:
> > > > > > >
> > > > > > > Le jeudi 13 mai 2021 à 18:13 -0400, David Malcolm a écrit :
> > > > > > > > On Sat, 2021-02-20 at 17:17 -0500, Antoni Boucher via
> > > > > > > > Gcc-
> > > > > > > > patches
> > > > > > > > wrote:
> > > > > > > > > Hi.
> > > > > > > > > Thanks for your feedback!
> > > > > > > > >
> > > > > > > >
> > > > > > > > Sorry about the delay in responding.
> > > > > > > >
> > > > > > > > In the past I was hesitant about adding more cast support
> > > > > > > > to
> > > > > > > > libgccjit
> > > > > > > > since I felt that the user could always just create a
> > > > > > > > union
> > > > > > > > to
> > > > > > > > do
> > > > > > > > the
> > > > > > > > cast. Then I tried actually using the libgccjit API to
> > > > > > > > do
> > > > > > > > this,
> > > > > > > > and
> > > > > > > > realized how much work it adds, so I now think we do want
> > > > > > > > to
> > > > > > > > support
> > > > > > > > casting more types.
> > > > > > > >
> > > > > > > >
> > > > > > > > > See answers below:
> > > > > > > > >
> > > > > > > > > On Sat, Feb 20, 2021 at 11:20:35AM -0700, Tom Tromey
> > > > > > > > > wrote:
> > > > > > > > > > > > > > > "Antoni" == Antoni Boucher via Gcc-patches
> > > > > > > > > > > > > > > <
> > > > > > > > > > > > > > > gcc-patches@gcc.gnu.org> writes:
> > > > > > > > > >
> > > > > > > > > > Antoni> gcc/jit/
> > > > > > > > > > Antoni> PR target/95498
> > > > > > > > > > Antoni> * jit-playback.c: Add support to
> > > > > > > > > > handle
> > > > > > > > > > truncation
> > > > > > > > > > and extension
> > > > > > > > > > Antoni> in the convert function.
> > > > > > > > > >
> > > > > > > > > > Antoni> + switch (dst_code)
> > > > > > > > > > Antoni> + {
> > > > > > > > > > Antoni> + case INTEGER_TYPE:
> > > > > > > > > > Antoni> + case ENUMERAL_TYPE:
> > > > > > > > > > Antoni> + t_ret = convert_to_integer (dst_type,
> > > > > > > > > > expr);
> > > >
Re: [PATCH,rs6000] Fix p10 fusion regtests
Hi!
On Fri, Jun 18, 2021 at 01:16:23PM -0500, Aaron Sawdey wrote:
> Update the count of matches for the fusion combine patterns after
> the recent changes to them. At Segher's request, used \m and \M
> in the match patterns. Also I have grouped together all alternatives of
> each fusion insn, which should hopefully make this test a little less
> fragile.
> * gcc.target/powerpc/fusion-p10-2logical.c: Update pattern
> match counts.
> * gcc.target/powerpc/fusion-p10-addadd.c: Update pattern match
> counts.
> * gcc.target/powerpc/fusion-p10-ldcmpi.c: Update pattern match
> counts.
> * gcc.target/powerpc/fusion-p10-logadd.c: Update pattern match
> counts.
All of these fit on one line, fwiw.
> /* Recreate with:
> - grep ' \*fuse_' fusion-p10-2logical.s|sed -e 's,^.*\*,,' |sort -k 7,7
> |uniq -c|awk '{l=30-length($2); printf("/%s* { %s { scan-assembler-times
> \"%s\"%-*s%4d { target lp64 } } }
> *%s/\n","","dg-final",$2,l,"",$1,"");}'
> + grep ' \*fuse_' fusion-p10-2logical.s|sed -e 's,^.*\*,,' -e 's,/[0-9],/,'
> |sort -k 7,7 |uniq -c|awk '{l=30-length($2); printf("/%s* { %s {
> scan-assembler-times {\\m%s\\M}%-*s%4d { target lp64 } } }
> *%s/\n","","dg-final",$2,l,"",$1,"");}'
> */
Let me see if I can understand that :-)
... well enough. Okay. Maybe rewrite this as a Perl script before you
reach a line length of 250 chars? :-) (But only if you need any
significant changes here again of course.)
> +/* { dg-final { scan-assembler-times {\mfuse_xor_or\M/}
> 32 { target lp64 } } } */
> +/* { dg-final { scan-assembler-times {\mfuse_xor_orc\M/}
> 32 { target lp64 } } } */
\M matters for things like this (or the former would match everything
the latter does as well). You didn't have that problem when your REs
didn't end in text, of course. \m isn't so important here of course,
but it is easier to just add it than to reason about if you need it.
I take it you have checked that the new counts are correct and/or
expected.
This is okay for trunk, and for 11 too once it has shown reasonable
results for all configs these tests failed on before. Thanks!
Segher
PING [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514
*PING* > Gesendet: Mittwoch, 09. Juni 2021 um 23:39 Uhr > Von: "Harald Anlauf" > An: "fortran" , "gcc-patches" > Betreff: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, > at varasm.c:5514 > > Dear Fortranners, > > we should be able to simplify the length of a substring with known > constant bounds. The attached patch adds this. > > Regtested on x86_64-pc-linux-gnu. > > OK for mainline? Since this should be rather safe, to at least 11-branch? > > Thanks, > Harald > > > Fortran - simplify length of substring with constant bounds > > gcc/fortran/ChangeLog: > > PR fortran/100950 > * simplify.c (substring_has_constant_len): New. > (gfc_simplify_len): Handle case of substrings with constant > bounds. > > gcc/testsuite/ChangeLog: > > PR fortran/100950 > * gfortran.dg/pr100950.f90: New test. > >
Re: [PATCH] libgccjit: Handle truncation and extension for casts [PR 95498]
I'm sending the patch once again for review.
As it's the first time I'll land a patch, I'm not sure what needs to be
done when it's approved.
Do I just commit it to the master branch directly?
Thanks!
Le vendredi 11 juin 2021 à 13:49 -0400, David Malcolm a écrit :
> On Thu, 2021-05-27 at 21:22 -0400, Antoni Boucher wrote:
> > Here's the patch with the condition removed.
> > I believe everything is now fixed.
> > Thanks!
>
> Thanks; this looks good to me. Is this the latest version of the
> patch; would you like me to apply it?
>
> Dave
>
> >
> > Le jeudi 27 mai 2021 à 18:21 -0400, David Malcolm a écrit :
> > > On Tue, 2021-05-25 at 20:16 -0400, Antoni Boucher wrote:
> > > > I updated the patch according to the comments by Tom Tromey.
> > > >
> > > > There's one question left about your question regarding
> > > > C_MAYBE_CONST_EXPR, David:
> > > >
> > > > I am not sure if we can get a C_MAYBE_CONST_EXPR from
> > > > libgccjit,
> > > > and
> > > > it
> > > > indeed seems like it's only created in c-family.
> > > > However, we do use it in libgccjit here:
> > > > https://github.com/gcc-mirror/gcc/blob/master/gcc/jit/jit-playback.c#L1180
> > > >
> > > > I tried removing the condition `if (TREE_CODE (t_ret) !=
> > > > C_MAYBE_CONST_EXPR)` and all the tests of libgccjit still pass.
> > > >
> > > > That code was copied from here:
> > > > https://github.com/gcc-mirror/gcc/blob/master/gcc/c/c-convert.c#L175
> > > > and might not be needed in libgccjit.
> > > >
> > > > Should I just remove the condition, then?
> > >
> > > I think so.
> > >
> > > Thanks
> > > Dave
> > >
> > > >
> > > > Le jeudi 13 mai 2021 à 19:58 -0400, David Malcolm a écrit :
> > > > > On Thu, 2021-05-13 at 19:31 -0400, Antoni Boucher wrote:
> > > > > > Thanks for your answer.
> > > > > >
> > > > > > See my answers below:
> > > > > >
> > > > > > Le jeudi 13 mai 2021 à 18:13 -0400, David Malcolm a écrit :
> > > > > > > On Sat, 2021-02-20 at 17:17 -0500, Antoni Boucher via
> > > > > > > Gcc-
> > > > > > > patches
> > > > > > > wrote:
> > > > > > > > Hi.
> > > > > > > > Thanks for your feedback!
> > > > > > > >
> > > > > > >
> > > > > > > Sorry about the delay in responding.
> > > > > > >
> > > > > > > In the past I was hesitant about adding more cast support
> > > > > > > to
> > > > > > > libgccjit
> > > > > > > since I felt that the user could always just create a
> > > > > > > union
> > > > > > > to
> > > > > > > do
> > > > > > > the
> > > > > > > cast. Then I tried actually using the libgccjit API to
> > > > > > > do
> > > > > > > this,
> > > > > > > and
> > > > > > > realized how much work it adds, so I now think we do want
> > > > > > > to
> > > > > > > support
> > > > > > > casting more types.
> > > > > > >
> > > > > > >
> > > > > > > > See answers below:
> > > > > > > >
> > > > > > > > On Sat, Feb 20, 2021 at 11:20:35AM -0700, Tom Tromey
> > > > > > > > wrote:
> > > > > > > > > > > > > > "Antoni" == Antoni Boucher via Gcc-patches
> > > > > > > > > > > > > > <
> > > > > > > > > > > > > > gcc-patches@gcc.gnu.org> writes:
> > > > > > > > >
> > > > > > > > > Antoni> gcc/jit/
> > > > > > > > > Antoni> PR target/95498
> > > > > > > > > Antoni> * jit-playback.c: Add support to
> > > > > > > > > handle
> > > > > > > > > truncation
> > > > > > > > > and extension
> > > > > > > > > Antoni> in the convert function.
> > > > > > > > >
> > > > > > > > > Antoni> + switch (dst_code)
> > > > > > > > > Antoni> + {
> > > > > > > > > Antoni> + case INTEGER_TYPE:
> > > > > > > > > Antoni> + case ENUMERAL_TYPE:
> > > > > > > > > Antoni> + t_ret = convert_to_integer (dst_type,
> > > > > > > > > expr);
> > > > > > > > > Antoni> + goto maybe_fold;
> > > > > > > > > Antoni> +
> > > > > > > > > Antoni> + default:
> > > > > > > > > Antoni> + gcc_assert
> > > > > > > > > (gcc::jit::active_playback_ctxt);
> > > > > > > > > Antoni> + gcc::jit::active_playback_ctxt-
> > > > > > > > > > add_error
> > > > > > > > > (NULL,
> > > > > > > > > "unhandled conversion");
> > > > > > > > > Antoni> + fprintf (stderr, "input
> > > > > > > > > expression:\n");
> > > > > > > > > Antoni> + debug_tree (expr);
> > > > > > > > > Antoni> + fprintf (stderr, "requested type:\n");
> > > > > > > > > Antoni> + debug_tree (dst_type);
> > > > > > > > > Antoni> + return error_mark_node;
> > > > > > > > > Antoni> +
> > > > > > > > > Antoni> + maybe_fold:
> > > > > > > > > Antoni> + if (TREE_CODE (t_ret) !=
> > > > > > > > > C_MAYBE_CONST_EXPR)
> > > > > > >
> > > > > > > Do we even get C_MAYBE_CONST_EXPR in libgccjit? That
> > > > > > > tree
> > > > > > > code
> > > > > > > is
> > > > > > > defined in c-family/c-common.def; how can nodes of that
> > > > > > > kind
> > > > > > > be
> > > > > > > created
> > > > > > > outside of the c-family?
> > > > > >
> > > > > > I am not sure, but that seems like it's only created in c-
> > > > > > family
> > > > > > indeed.
> > > > > >
[PATCH] c++: conversion to base of vbase in NSDMI [PR80431]
The delayed processing of conversions to a virtual base inside an NSDMI
assumes the target base type is a (possibly indirect) virtual base of
the current class, but the target base type could also be an indirect
non-virtual base inherited from a virtual base, as in the testcase below.
Since such a base isn't a part of CLASSTYPE_VBASECLASSES, we end up
miscompiling the testcase due to build_base_path (called with
binfo=NULL_TREE) silently returning error_mark_node. Fix this by
using convert_to_base to build the conversion.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
PR c++/80431
gcc/cp/ChangeLog:
* tree.c (bot_replace): Use convert_to_base instead of
only looking through CLASSTYPE_VBASECLASSES of the current class
type.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/nsdmi-virtual1a.C: New test.
---
gcc/cp/tree.c| 10 ++-
gcc/testsuite/g++.dg/cpp0x/nsdmi-virtual1a.C | 29
2 files changed, 32 insertions(+), 7 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/nsdmi-virtual1a.C
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index fec5afaa2be..3537f395960 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -3244,13 +3244,9 @@ bot_replace (tree* t, int* /*walk_subtrees*/, void*
data_)
{
/* In an NSDMI build_base_path defers building conversions to virtual
bases, and we handle it here. */
- tree basetype = TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (*t)));
- vec *vbases = CLASSTYPE_VBASECLASSES (current_class_type);
- int i; tree binfo;
- FOR_EACH_VEC_SAFE_ELT (vbases, i, binfo)
- if (BINFO_TYPE (binfo) == basetype)
- break;
- *t = build_base_path (PLUS_EXPR, TREE_OPERAND (*t, 0), binfo, true,
+ tree basetype = TREE_TYPE (*t);
+ *t = convert_to_base (TREE_OPERAND (*t, 0), basetype,
+ /*check_access=*/false, /*nonnull=*/true,
tf_warning_or_error);
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/nsdmi-virtual1a.C
b/gcc/testsuite/g++.dg/cpp0x/nsdmi-virtual1a.C
new file mode 100644
index 000..fe647fe3cf7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/nsdmi-virtual1a.C
@@ -0,0 +1,29 @@
+// PR c++/80431
+// { dg-do run { target c++11 } }
+
+// A variant of nsdmi-virtual1.C that turns A from a virtual base of B to a
base
+// of a virtual base of B, using the intermediate class D.
+
+struct A
+{
+ A(): i(42) { }
+ int i;
+ int f() { return i; }
+};
+
+struct D : A { int pad; };
+
+struct B : virtual D
+{
+ int j = i + f();
+ int k = A::i + A::f();
+};
+
+struct C: B { int pad; };
+
+int main()
+{
+ C c;
+ if (c.j != 84 || c.k != 84)
+__builtin_abort();
+}
--
2.32.0.93.g670b81a890
Re: [PATCH] libgccjit: add some reflection functions in the jit C api
On Fri, 2021-06-18 at 15:41 -0400, Antoni Boucher wrote: > I have write access now. Great. > I'm not sure how I'm supposed to send my patches: > should I put it in personal branches and you'll merge them? Please send them to this mailing list for review; once they're approved you can merge them. > > And for the MAINTAINERS file, should I just push to master right > away, > after sending it to the mailing list? I think people just push the MAINTAINERS change and then let the list know, since it makes a good test that write access is working correctly. Dave > > Thanks for your help! > > Le vendredi 18 juin 2021 à 12:09 -0400, David Malcolm a écrit : > > On Fri, 2021-06-18 at 11:55 -0400, Antoni Boucher wrote: > > > Le vendredi 11 juin 2021 à 14:00 -0400, David Malcolm a écrit : > > > > On Fri, 2021-06-11 at 08:15 -0400, Antoni Boucher wrote: > > > > > Thank you for your answer. > > > > > I attached the updated patch. > > > > > > > > BTW you (or possibly me) dropped the mailing lists; was that > > > > deliberate? > > > > > > Oh, my bad. > > > > > > > [...] > > > > > > > > > > > > > > > > > I have signed the FSF copyright attribution. > > > > > > > > I can push changes on your behalf, but I'd prefer it if you did > > > > it, > > > > especially given that you have various other patches you want > > > > to > > > > get > > > > in. > > > > > > > > Instructions on how to get push rights to the git repo are > > > > here: > > > > https://gcc.gnu.org/gitwrite.html > > > > > > > > I can sponsor you. > > > > > > Thanks. > > > I did sign up to get push rights. > > > Have you accepted my request to get those? > > > > I did, but I didn't see any kind of notification. Did you get an > > email > > about it? > > > > > > Dave > > > >
Re: [PATCH] libgccjit: add some reflection functions in the jit C api
I have write access now. I'm not sure how I'm supposed to send my patches: should I put it in personal branches and you'll merge them? And for the MAINTAINERS file, should I just push to master right away, after sending it to the mailing list? Thanks for your help! Le vendredi 18 juin 2021 à 12:09 -0400, David Malcolm a écrit : > On Fri, 2021-06-18 at 11:55 -0400, Antoni Boucher wrote: > > Le vendredi 11 juin 2021 à 14:00 -0400, David Malcolm a écrit : > > > On Fri, 2021-06-11 at 08:15 -0400, Antoni Boucher wrote: > > > > Thank you for your answer. > > > > I attached the updated patch. > > > > > > BTW you (or possibly me) dropped the mailing lists; was that > > > deliberate? > > > > Oh, my bad. > > > > [...] > > > > > > > > > > > > I have signed the FSF copyright attribution. > > > > > > I can push changes on your behalf, but I'd prefer it if you did > > > it, > > > especially given that you have various other patches you want to > > > get > > > in. > > > > > > Instructions on how to get push rights to the git repo are here: > > > https://gcc.gnu.org/gitwrite.html > > > > > > I can sponsor you. > > > > Thanks. > > I did sign up to get push rights. > > Have you accepted my request to get those? > > I did, but I didn't see any kind of notification. Did you get an > email > about it? > > > Dave >
[PATCH,rs6000] Fix p10 fusion regtests
From: Aaron Sawdey
Update the count of matches for the fusion combine patterns after
the recent changes to them. At Segher's request, used \m and \M
in the match patterns. Also I have grouped together all alternatives of
each fusion insn, which should hopefully make this test a little less
fragile.
OK for trunk and backport to 11?
Thanks!
Aaron
gcc/testsuite/ChangeLog
* gcc.target/powerpc/fusion-p10-2logical.c: Update pattern
match counts.
* gcc.target/powerpc/fusion-p10-addadd.c: Update pattern match
counts.
* gcc.target/powerpc/fusion-p10-ldcmpi.c: Update pattern match
counts.
* gcc.target/powerpc/fusion-p10-logadd.c: Update pattern match
counts.
---
.../gcc.target/powerpc/fusion-p10-2logical.c | 401 -
.../gcc.target/powerpc/fusion-p10-addadd.c | 17 +-
.../gcc.target/powerpc/fusion-p10-ldcmpi.c | 10 +-
.../gcc.target/powerpc/fusion-p10-logadd.c | 129 ++-
4 files changed, 194 insertions(+), 363 deletions(-)
diff --git a/gcc/testsuite/gcc.target/powerpc/fusion-p10-2logical.c
b/gcc/testsuite/gcc.target/powerpc/fusion-p10-2logical.c
index de22176..009a5f2 100644
--- a/gcc/testsuite/gcc.target/powerpc/fusion-p10-2logical.c
+++ b/gcc/testsuite/gcc.target/powerpc/fusion-p10-2logical.c
@@ -64,262 +64,151 @@ TEST(vboolchar_t);
TEST(vuint_t);
/* Recreate with:
- grep ' \*fuse_' fusion-p10-2logical.s|sed -e 's,^.*\*,,' |sort -k 7,7 |uniq
-c|awk '{l=30-length($2); printf("/%s* { %s { scan-assembler-times \"%s\"%-*s
%4d { target lp64 } } } *%s/\n","","dg-final",$2,l,"",$1,"");}'
+ grep ' \*fuse_' fusion-p10-2logical.s|sed -e 's,^.*\*,,' -e 's,/[0-9],/,'
|sort -k 7,7 |uniq -c|awk '{l=30-length($2); printf("/%s* { %s {
scan-assembler-times {\\m%s\\M}%-*s%4d { target lp64 } } }
*%s/\n","","dg-final",$2,l,"",$1,"");}'
*/
-
-/* { dg-final { scan-assembler-times "fuse_and_and/1"
16 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_and_and/2"
16 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_andc_and/0"
16 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_andc_and/1"
26 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_andc_and/2"
48 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_andc_and/3"
6 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_andc_or/0"
16 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_andc_or/1"
16 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_andc_or/2"
32 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_andc_orc/0"
8 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_andc_orc/1"
8 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_andc_orc/2"
48 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_andc_xor/0"
16 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_andc_xor/1"
16 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_andc_xor/2"
32 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_and_eqv/0"
8 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_and_eqv/2"
24 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_and_or/0"
16 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_and_or/2"
16 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_and_orc/0"
8 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_and_orc/2"
24 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_and_xor/0"
16 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_and_xor/2"
16 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_eqv_and/0"
16 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_eqv_and/2"
16 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_eqv_andc/0"
8 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_eqv_andc/2"
24 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_eqv_or/0"
8 { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fuse_eqv_or/2"
24 { target
Re: [PATCH] libstdc++: Reduce ranges::minmax/minmax_element comparison complexity
On Wed, 5 May 2021, Patrick Palka wrote:
> On Wed, 5 May 2021, Patrick Palka wrote:
>
> > On Wed, 5 May 2021, Jonathan Wakely wrote:
> >
> > > On 04/05/21 21:42 -0400, Patrick Palka via Libstdc++ wrote:
> > > > This rewrites ranges::minmax and ranges::minmax_element so that it
> > > > performs at most 3*N/2 many comparisons, as required by the standard.
> > > > In passing, this also fixes PR100387 by avoiding a premature std::move
> > > > in ranges::minmax and in std::shift_right.
> > > >
> > > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
> > > > 10/11?
> > > >
> > > > libstdc++-v3/ChangeLog:
> > > >
> > > > PR libstdc++/100387
> > > > * include/bits/ranges_algo.h (__minmax_fn::operator()): Rewrite
> > > > to limit comparison complexity to 3*N/2. Avoid premature
> > > > std::move.
> > > > (__minmax_element_fn::operator()): Likewise.
> > > > (shift_right): Avoid premature std::move of __result.
> > > > * testsuite/25_algorithms/minmax/constrained.cc (test04,
> > > > test05):
> > > > New tests.
> > > > * testsuite/25_algorithms/minmax_element/constrained.cc
> > > > (test02):
> > > > Likewise.
> > > > ---
> > > > libstdc++-v3/include/bits/ranges_algo.h | 87 ++-
> > > > .../25_algorithms/minmax/constrained.cc | 31 +++
> > > > .../minmax_element/constrained.cc | 19
> > > > 3 files changed, 113 insertions(+), 24 deletions(-)
> > > >
> > > > diff --git a/libstdc++-v3/include/bits/ranges_algo.h
> > > > b/libstdc++-v3/include/bits/ranges_algo.h
> > > > index cda3042c11f..bbd29127e89 100644
> > > > --- a/libstdc++-v3/include/bits/ranges_algo.h
> > > > +++ b/libstdc++-v3/include/bits/ranges_algo.h
> > > > @@ -3291,18 +3291,39 @@ namespace ranges
> > > > auto __first = ranges::begin(__r);
> > > > auto __last = ranges::end(__r);
> > > > __glibcxx_assert(__first != __last);
> > > > + auto __comp_proj = __detail::__make_comp_proj(__comp, __proj);
> > > > minmax_result> __result = {*__first,
> > > > *__first};
> > > > while (++__first != __last)
> > > > {
> > > > - auto __tmp = *__first;
> > > > - if (std::__invoke(__comp,
> > > > - std::__invoke(__proj, __tmp),
> > > > - std::__invoke(__proj, __result.min)))
> > > > - __result.min = std::move(__tmp);
> > > > - if (!(bool)std::__invoke(__comp,
> > > > -std::__invoke(__proj, __tmp),
> > > > -std::__invoke(__proj,
> > > > __result.max)))
> > > > - __result.max = std::move(__tmp);
> > > > + // Process two elements at a time so that we perform at most
> > > > + // 3*N/2 many comparisons in total (each of the N/2
> > > > iterations
> > >
> > > Is "many" a typo here?
> >
> > Just a bad habit of mine to usually write " many" instead of just
> > "" :) Consider the "many" removed.
> >
> > >
> > > > + // of this loop performs three comparisions).
> > > > + auto __val1 = *__first;
> > >
> > > Can we avoid making this copy if the range satisfies forward_range, by
> > > keeping copies of the min/max iterators, or just forwarding to
> > > ranges::minmax_element?
> >
> > Maybe we can make __val1 and __val2 universal references? Ah, but then
> > __val1 would potentially be invalidated after incrementing __first. I
> > think it should be safe to make __val2 a universal reference though.
> > I've done this in v2 below.
> >
> > Forwarding to ranges::minmax_element seems like it would be profitable
> > in some situations, e.g if the value type isn't trivially copyable. I
> > can do this in a followup patch for ranges::max/max_element and
> > ranges::min/min_element too, they should all use the same heuristic.
> >
> > >
> > >
> > > > + if (++__first == __last)
> > > > + {
> > > > + // N is odd; in this final iteration, we perform a just
> > > > one
> > >
> > > s/perform a just one/perform just one/
> >
> > Fixed.
> >
> > >
> > > > + // comparison, for a total of 3*(N-1)/2 + 1 < 3*N/2
> > > > comparisons.
> > >
> > > I find this a bit hard to parse with the inequality there.
> >
> > Removed.
> >
> > >
> > > > + if (__comp_proj(__val1, __result.min))
> > > > + __result.min = std::move(__val1);
> > > > + else if (!__comp_proj(__val1, __result.max))
> > > > + __result.max = std::move(__val1);
> > >
> > > This can be two comparisons, can't it? Would this be better...
> >
> > Whoops, yeah...
> >
> > >
> > > // N is odd; in this final iteration, we perform at most two
> > > // comparisons, for a total of 3*(N-1)/2 + 2 comparisons,
> > > // which is not more than 3*N/2, as required.
> > >
> > > ?
> >
> > Ah, but then the
[Patch, committed] PR fortran/101123 - [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8
As confirmed in the PR by Jakub, there was a bad conversion of the result
of min0/max0 to the result type. We should just unconditionally convert
in all cases.
As a benefit, this also fixes pr100283.
Committed after regtesting.
Thanks,
Harald
Fortran - fix conversion to result type for the min/max intrinsic
gcc/fortran/ChangeLog:
PR fortran/100283
PR fortran/101123
* trans-intrinsic.c (gfc_conv_intrinsic_minmax): Unconditionally
convert result of min/max to result type.
gcc/testsuite/ChangeLog:
PR fortran/100283
PR fortran/101123
* gfortran.dg/min0_max0_1.f90: New test.
* gfortran.dg/min0_max0_2.f90: New test.
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 73b0bcc9dea..e578449995a 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -4147,10 +4147,7 @@ gfc_conv_intrinsic_minmax (gfc_se * se, gfc_expr * expr, enum tree_code op)
build_empty_stmt (input_location));
gfc_add_expr_to_block (>pre, tmp);
}
- if (TREE_CODE (type) == INTEGER_TYPE)
-se->expr = fold_build1_loc (input_location, FIX_TRUNC_EXPR, type, mvar);
- else
-se->expr = convert (type, mvar);
+ se->expr = convert (type, mvar);
}
diff --git a/gcc/testsuite/gfortran.dg/min0_max0_1.f90 b/gcc/testsuite/gfortran.dg/min0_max0_1.f90
new file mode 100644
index 000..118b0f03b52
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/min0_max0_1.f90
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! { dg-options "-std=gnu" }
+! PR fortran/100283
+
+subroutine s ()
+ integer(kind=8) :: i,j,k
+ i = min0 (j,k)
+ i = max0 (-127_8, min0 (j,127_8))
+end subroutine s
diff --git a/gcc/testsuite/gfortran.dg/min0_max0_2.f90 b/gcc/testsuite/gfortran.dg/min0_max0_2.f90
new file mode 100644
index 000..3fe4fcd3609
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/min0_max0_2.f90
@@ -0,0 +1,10 @@
+! { dg-do compile }
+! { dg-options "-fdefault-integer-8 -std=gnu" }
+! PR fortran/101123
+
+SUBROUTINE TEST
+ IMPLICIT INTEGER*4 (I-N)
+ MAXMN=MAX0(M,N)
+ MINMN=MIN0(M,0_4)
+ MAXRS=MAX1(R,S)
+END SUBROUTINE TEST
[committed] analyzer: fix issue with symbolic reads with concrete bindings
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as 3bb85b868722e69aef0d37858c0dc3c88d92a0eb.
gcc/analyzer/ChangeLog:
* store.cc (binding_cluster::get_any_binding): Make symbolic reads
from a cluster with concrete bindings return unknown.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/symbolic-7.c: New test.
Signed-off-by: David Malcolm
---
gcc/analyzer/store.cc | 10 +
gcc/testsuite/gcc.dg/analyzer/symbolic-7.c | 44 ++
2 files changed, 54 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/analyzer/symbolic-7.c
diff --git a/gcc/analyzer/store.cc b/gcc/analyzer/store.cc
index b643b631863..320370326bd 100644
--- a/gcc/analyzer/store.cc
+++ b/gcc/analyzer/store.cc
@@ -1177,6 +1177,16 @@ binding_cluster::get_any_binding (store_manager *mgr,
return rmm_mgr->get_or_create_unknown_svalue (reg->get_type ());
}
+ /* Alternatively, if this is a symbolic read and the cluster has any
bindings,
+ then we don't know if we're reading those values or not, so the result
+ is also "UNKNOWN". */
+ if (reg->get_offset ().symbolic_p ()
+ && m_map.elements () > 0)
+{
+ region_model_manager *rmm_mgr = mgr->get_svalue_manager ();
+ return rmm_mgr->get_or_create_unknown_svalue (reg->get_type ());
+}
+
if (const svalue *compound_sval = maybe_get_compound_binding (mgr, reg))
return compound_sval;
diff --git a/gcc/testsuite/gcc.dg/analyzer/symbolic-7.c
b/gcc/testsuite/gcc.dg/analyzer/symbolic-7.c
new file mode 100644
index 000..4f013677f86
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/symbolic-7.c
@@ -0,0 +1,44 @@
+#include "analyzer-decls.h"
+
+extern void maybe_write (int *);
+
+void test_1 (int i)
+{
+ /* An array with purely concrete bindings. */
+ int arr[2];
+ arr[0] = 1066;
+ arr[1] = 1776;
+
+ /* Concrete reads. */
+ __analyzer_eval (arr[0] == 1066); /* { dg-warning "TRUE" } */
+ __analyzer_eval (arr[1] == 1776); /* { dg-warning "TRUE" } */
+
+ /* Symbolic read. */
+ __analyzer_describe (0, arr[i]); /* { dg-warning "svalue:
'UNKNOWN\\(int\\)'" } */
+ __analyzer_eval (arr[i] == 1776); /* { dg-warning "UNKNOWN" } */
+}
+
+void test_2 (int i)
+{
+ /* An array that could have been touched. */
+ int arr[2];
+ maybe_write (arr);
+
+ /* Concrete reads. */
+ __analyzer_eval (arr[0] == 42); /* { dg-warning "UNKNOWN" } */
+
+ /* Symbolic read. */
+ __analyzer_eval (arr[i] == 42); /* { dg-warning "UNKNOWN" } */
+}
+
+void test_3 (int i)
+{
+ /* An array that can't have been touched. */
+ int arr[2];
+
+ /* Concrete reads. */
+ __analyzer_eval (arr[0] == 42); /* { dg-warning "UNKNOWN" } */
+
+ /* Symbolic read. */
+ __analyzer_eval (arr[i] == 42); /* { dg-warning "UNKNOWN" } */
+}
--
2.26.3
Re: [PATCH] AArch64: Add support for __builtin_roundeven[f] [PR100966]
Wilco Dijkstra writes:
> Enable __builtin_roundeven[f] by adding roundeven as an alias to the
> existing frintn support.
Although frint_pattern maps UNSPEC_FRINTN to "frintn", "frintn"
doesn't mean anything to the target-independent part of the compiler.
I assume it was just picked as a placeholder since the roundeven
optabs didn't exist at the time.
So rather than have two patterns that generate frintn, I think
it would be better to change the existing frint_pattern entry to
"roundeven" instead, and fix whatever the fallout is. Hopefully it
shouldn't be too bad, since we already use the optab names for the
other UNSPEC_FRINT* codes.
Thanks,
Richard
> Bootstrap OK and passes regress.
>
> ChangeLog:
> 2021-06-18 Wilco Dijkstra
>
> PR target/100966
> * config/aarch64/aarch64.md (UNSPEC_FRINTR): Add.
> * config/aarch64/aarch64.c (aarch64_frint_unspec_p): Add
> UNSPEC_FRINTR.
> (aarch64_rtx_cost): Likewise.
> * config/aarch64/iterators.md (FRINT): Add UNSPEC_FRINTR.
> (frint_pattern): Likewise.
> (frint_suffix): Likewise.
>
> gcc/testsuite
> PR target/100966
> * gcc.target/aarch64/frint.x: Add roundeven tests.
> * gcc.target/aarch64/frint_double.c: Likewise.
> * gcc.target/aarch64/frint_float.c: Likewise.
>
> ---
>
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index
> f4d264bbc817153b330bac9ab423bf561689ebf2..63bd49d475433c04faa89bb380a9d17e4ad4bc6c
> 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -12253,6 +12253,7 @@ aarch64_frint_unspec_p (unsigned int u)
>case UNSPEC_FRINTM:
>case UNSPEC_FRINTA:
>case UNSPEC_FRINTN:
> + case UNSPEC_FRINTR:
>case UNSPEC_FRINTX:
>case UNSPEC_FRINTI:
> return true;
> @@ -13648,6 +13649,7 @@ cost_plus:
>|| uns_code == UNSPEC_FRINTM
>|| uns_code == UNSPEC_FRINTN
>|| uns_code == UNSPEC_FRINTP
> + || uns_code == UNSPEC_FRINTR
>|| uns_code == UNSPEC_FRINTZ)
> x = XVECEXP (x, 0, 0);
> }
> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index
> 30effca6f3562f6870a6cc8097750e63bb0d424d..70e46f28259640a273d444a2b963246ed9a91109
> 100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -167,6 +167,7 @@ (define_c_enum "unspec" [
> UNSPEC_FRINTM
> UNSPEC_FRINTN
> UNSPEC_FRINTP
> +UNSPEC_FRINTR
> UNSPEC_FRINTX
> UNSPEC_FRINTZ
> UNSPEC_GOTSMALLPIC
> diff --git a/gcc/config/aarch64/iterators.md b/gcc/config/aarch64/iterators.md
> index
> cac33ae812b382cd55611b0da8a6e9eac3a513c4..1542661c6d101ed53c6e1c8683cbca32baefebbd
> 100644
> --- a/gcc/config/aarch64/iterators.md
> +++ b/gcc/config/aarch64/iterators.md
> @@ -2291,7 +2291,7 @@ (define_int_iterator REVERSE [UNSPEC_REV64 UNSPEC_REV32
> UNSPEC_REV16])
>
> (define_int_iterator FRINT [UNSPEC_FRINTZ UNSPEC_FRINTP UNSPEC_FRINTM
> UNSPEC_FRINTN UNSPEC_FRINTI UNSPEC_FRINTX
> -UNSPEC_FRINTA])
> +UNSPEC_FRINTA UNSPEC_FRINTR ])
>
> (define_int_iterator FCVT [UNSPEC_FRINTZ UNSPEC_FRINTP UNSPEC_FRINTM
> UNSPEC_FRINTA UNSPEC_FRINTN])
> @@ -3079,13 +3079,14 @@ (define_int_attr frint_pattern [(UNSPEC_FRINTZ
> "btrunc")
> (UNSPEC_FRINTI "nearbyint")
> (UNSPEC_FRINTX "rint")
> (UNSPEC_FRINTA "round")
> - (UNSPEC_FRINTN "frintn")])
> + (UNSPEC_FRINTN "frintn")
> + (UNSPEC_FRINTR "roundeven")])
>
> ;; frint suffix for floating-point rounding instructions.
> (define_int_attr frint_suffix [(UNSPEC_FRINTZ "z") (UNSPEC_FRINTP "p")
>(UNSPEC_FRINTM "m") (UNSPEC_FRINTI "i")
>(UNSPEC_FRINTX "x") (UNSPEC_FRINTA "a")
> - (UNSPEC_FRINTN "n")])
> + (UNSPEC_FRINTN "n") (UNSPEC_FRINTR "n")])
>
> (define_int_attr fcvt_pattern [(UNSPEC_FRINTZ "btrunc") (UNSPEC_FRINTA
> "round")
>(UNSPEC_FRINTP "ceil") (UNSPEC_FRINTM "floor")
> diff --git a/gcc/testsuite/gcc.target/aarch64/frint.x
> b/gcc/testsuite/gcc.target/aarch64/frint.x
> index
> 1403740686ea3927d2c39eb2466ef8cc67e223b2..d598a25ff21b8feeca6a96de79848b2fbde7f31e
> 100644
> --- a/gcc/testsuite/gcc.target/aarch64/frint.x
> +++ b/gcc/testsuite/gcc.target/aarch64/frint.x
> @@ -4,6 +4,7 @@ extern GPF SUFFIX(floor) (GPF);
> extern GPF SUFFIX(nearbyint) (GPF);
> extern GPF SUFFIX(rint) (GPF);
> extern GPF SUFFIX(round) (GPF);
> +extern GPF SUFFIX(roundeven) (GPF);
>
> GPF test1a (GPF x)
> {
> @@ -64,3 +65,14 @@ GPF test6b (GPF x)
> {
>return
[PATCH] AArch64: Add support for __builtin_roundeven[f] [PR100966]
Enable __builtin_roundeven[f] by adding roundeven as an alias to the
existing frintn support.
Bootstrap OK and passes regress.
ChangeLog:
2021-06-18 Wilco Dijkstra
PR target/100966
* config/aarch64/aarch64.md (UNSPEC_FRINTR): Add.
* config/aarch64/aarch64.c (aarch64_frint_unspec_p): Add UNSPEC_FRINTR.
(aarch64_rtx_cost): Likewise.
* config/aarch64/iterators.md (FRINT): Add UNSPEC_FRINTR.
(frint_pattern): Likewise.
(frint_suffix): Likewise.
gcc/testsuite
PR target/100966
* gcc.target/aarch64/frint.x: Add roundeven tests.
* gcc.target/aarch64/frint_double.c: Likewise.
* gcc.target/aarch64/frint_float.c: Likewise.
---
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index
f4d264bbc817153b330bac9ab423bf561689ebf2..63bd49d475433c04faa89bb380a9d17e4ad4bc6c
100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -12253,6 +12253,7 @@ aarch64_frint_unspec_p (unsigned int u)
case UNSPEC_FRINTM:
case UNSPEC_FRINTA:
case UNSPEC_FRINTN:
+ case UNSPEC_FRINTR:
case UNSPEC_FRINTX:
case UNSPEC_FRINTI:
return true;
@@ -13648,6 +13649,7 @@ cost_plus:
|| uns_code == UNSPEC_FRINTM
|| uns_code == UNSPEC_FRINTN
|| uns_code == UNSPEC_FRINTP
+ || uns_code == UNSPEC_FRINTR
|| uns_code == UNSPEC_FRINTZ)
x = XVECEXP (x, 0, 0);
}
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index
30effca6f3562f6870a6cc8097750e63bb0d424d..70e46f28259640a273d444a2b963246ed9a91109
100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -167,6 +167,7 @@ (define_c_enum "unspec" [
UNSPEC_FRINTM
UNSPEC_FRINTN
UNSPEC_FRINTP
+UNSPEC_FRINTR
UNSPEC_FRINTX
UNSPEC_FRINTZ
UNSPEC_GOTSMALLPIC
diff --git a/gcc/config/aarch64/iterators.md b/gcc/config/aarch64/iterators.md
index
cac33ae812b382cd55611b0da8a6e9eac3a513c4..1542661c6d101ed53c6e1c8683cbca32baefebbd
100644
--- a/gcc/config/aarch64/iterators.md
+++ b/gcc/config/aarch64/iterators.md
@@ -2291,7 +2291,7 @@ (define_int_iterator REVERSE [UNSPEC_REV64 UNSPEC_REV32
UNSPEC_REV16])
(define_int_iterator FRINT [UNSPEC_FRINTZ UNSPEC_FRINTP UNSPEC_FRINTM
UNSPEC_FRINTN UNSPEC_FRINTI UNSPEC_FRINTX
-UNSPEC_FRINTA])
+UNSPEC_FRINTA UNSPEC_FRINTR ])
(define_int_iterator FCVT [UNSPEC_FRINTZ UNSPEC_FRINTP UNSPEC_FRINTM
UNSPEC_FRINTA UNSPEC_FRINTN])
@@ -3079,13 +3079,14 @@ (define_int_attr frint_pattern [(UNSPEC_FRINTZ "btrunc")
(UNSPEC_FRINTI "nearbyint")
(UNSPEC_FRINTX "rint")
(UNSPEC_FRINTA "round")
- (UNSPEC_FRINTN "frintn")])
+ (UNSPEC_FRINTN "frintn")
+ (UNSPEC_FRINTR "roundeven")])
;; frint suffix for floating-point rounding instructions.
(define_int_attr frint_suffix [(UNSPEC_FRINTZ "z") (UNSPEC_FRINTP "p")
(UNSPEC_FRINTM "m") (UNSPEC_FRINTI "i")
(UNSPEC_FRINTX "x") (UNSPEC_FRINTA "a")
- (UNSPEC_FRINTN "n")])
+ (UNSPEC_FRINTN "n") (UNSPEC_FRINTR "n")])
(define_int_attr fcvt_pattern [(UNSPEC_FRINTZ "btrunc") (UNSPEC_FRINTA "round")
(UNSPEC_FRINTP "ceil") (UNSPEC_FRINTM "floor")
diff --git a/gcc/testsuite/gcc.target/aarch64/frint.x
b/gcc/testsuite/gcc.target/aarch64/frint.x
index
1403740686ea3927d2c39eb2466ef8cc67e223b2..d598a25ff21b8feeca6a96de79848b2fbde7f31e
100644
--- a/gcc/testsuite/gcc.target/aarch64/frint.x
+++ b/gcc/testsuite/gcc.target/aarch64/frint.x
@@ -4,6 +4,7 @@ extern GPF SUFFIX(floor) (GPF);
extern GPF SUFFIX(nearbyint) (GPF);
extern GPF SUFFIX(rint) (GPF);
extern GPF SUFFIX(round) (GPF);
+extern GPF SUFFIX(roundeven) (GPF);
GPF test1a (GPF x)
{
@@ -64,3 +65,14 @@ GPF test6b (GPF x)
{
return SUFFIX(round)(x);
}
+
+GPF test7a (GPF x)
+{
+ return SUFFIX(__builtin_roundeven)(x);
+}
+
+GPF test7b (GPF x)
+{
+ return SUFFIX(roundeven)(x);
+}
+
diff --git a/gcc/testsuite/gcc.target/aarch64/frint_double.c
b/gcc/testsuite/gcc.target/aarch64/frint_double.c
index
96139496ca454cebd41d31e8b018dab7ffa33a3f..1d28eb09e11842802ab632a7696de4407263f8ce
100644
--- a/gcc/testsuite/gcc.target/aarch64/frint_double.c
+++ b/gcc/testsuite/gcc.target/aarch64/frint_double.c
@@ -12,3 +12,4 @@
/* { dg-final { scan-assembler-times "frinti\td\[0-9\]" 2 } } */
/* { dg-final { scan-assembler-times "frintx\td\[0-9\]" 2 } } */
/* { dg-final { scan-assembler-times "frinta\td\[0-9\]" 2 } } */
+/* { dg-final { scan-assembler-times "frintn\td\[0-9\]" 2 } } */
diff --git
Re: [PATCH] libgccjit: add some reflection functions in the jit C api
On Fri, 2021-06-18 at 11:55 -0400, Antoni Boucher wrote: > Le vendredi 11 juin 2021 à 14:00 -0400, David Malcolm a écrit : > > On Fri, 2021-06-11 at 08:15 -0400, Antoni Boucher wrote: > > > Thank you for your answer. > > > I attached the updated patch. > > > > BTW you (or possibly me) dropped the mailing lists; was that > > deliberate? > > Oh, my bad. > [...] > > > > > > > I have signed the FSF copyright attribution. > > > > I can push changes on your behalf, but I'd prefer it if you did it, > > especially given that you have various other patches you want to > > get > > in. > > > > Instructions on how to get push rights to the git repo are here: > > https://gcc.gnu.org/gitwrite.html > > > > I can sponsor you. > > Thanks. > I did sign up to get push rights. > Have you accepted my request to get those? I did, but I didn't see any kind of notification. Did you get an email about it? Dave
Re: [PATCH 5/6] make get_domminated_by_region return a auto_vec
On 6/18/21 4:38 AM, Richard Biener wrote: On Thu, Jun 17, 2021 at 4:43 PM Martin Sebor wrote: On 6/17/21 12:03 AM, Richard Biener wrote: On Wed, Jun 16, 2021 at 6:01 PM Martin Sebor wrote: On 6/16/21 6:46 AM, Richard Sandiford via Gcc-patches wrote: Richard Biener via Gcc-patches writes: On Tue, Jun 15, 2021 at 8:02 AM Trevor Saunders wrote: This makes it clear the caller owns the vector, and ensures it is cleaned up. Signed-off-by: Trevor Saunders bootstrapped and regtested on x86_64-linux-gnu, ok? OK. Btw, are "standard API" returns places we can use 'auto'? That would avoid excessive indent for - dom_bbs = get_dominated_by_region (CDI_DOMINATORS, -bbs.address (), -bbs.length ()); + auto_vec dom_bbs = get_dominated_by_region (CDI_DOMINATORS, + bbs.address (), + bbs.length ()); and just uses auto dom_bbs = get_dominated_by_region (... Not asking you to do this, just a question for the audience. Personally I think this would be surprising for something that doesn't have copy semantics. (Not that I'm trying to reopen that debate here :-) FWIW, I agree not having copy semantics is probably the most practical way forward for now.) But you did open the door for me to reiterate my strong disagreement with that. The best C++ practice going back to the early 1990's is to make types safely copyable and assignable. It is the default for all types, in both C++ and C, and so natural and expected. Preventing copying is appropriate in special and rare circumstances (e.g, a mutex may not be copyable, or a file or iostream object may not be because they represent a unique physical resource.) In the absence of such special circumstances preventing copying is unexpected, and in the case of an essential building block such as a container, makes the type difficult to use. The only argument for disabling copying that has been given is that it could be surprising(*). But because all types are copyable by default the "surprise" is usually when one can't be. I think Richi's "surprising" has to do with the fact that it lets one inadvertently copy a large amount of data, thus leading to an inefficiency. But by analogy, there are infinitely many ways to end up with inefficient code (e.g., deep recursion, or heap allocation in a loop), and they are not a reason to ban the coding constructs that might lead to it. IIUC, Jason's comment about surprising effects was about implicit conversion from auto_vec to vec. I share that concern, and agree that it should be addressed by preventing the conversion (as Jason suggested). But fact is that how vec<> and auto_vec<> are used today in GCC do not favor that. In fact your proposed vec<> would be quite radically different (and IMHO vec<> and auto_vec<> should be unified then to form your proposed new container). auto_vec<> at the moment simply maintains ownership like a smart pointer - which is _also_ not copyable. Yes, as we discussed in the review below, vec is not a good model because (as you note again above) it's constrained by its legacy uses. The best I think we can do for it is to make it safer to use. https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571622.html Which is what Trevors patches do by simply disallowing things that do not work at the moment. (Smart pointers don't rule out copying. A std::unique_ptr does and std::shared_ptr doesn't. But vec and especially auto_vec are designed to be containers, not "unique pointers" so any relationship there is purely superficial and a distraction.) That auto_vec and vec share a name and an is-a relationship is incidental, an implementation detail leaked into the API. A better name than vector is hard to come up with, but the public inheritance is a design flaw, a bug waiting to be introduced due to the conversion and the assumptions the base vec makes about POD-ness and shallow copying. Hindsight is always 20/20 but past mistakes should not dictate the design of a general purpose vector-like container in GCC. That auto_vec<> "decays" to vec<> was on purpose design. By-value passing of vec<> is also on purpose to avoid an extra pointer indirection on each access. I think you may have misunderstood what I mean by is-a relationship. It's fine to convert an auto_vec to another interface. The danger is in allowing that to happen implicitly because that tends to let it happen even when it's not intended. The usual way to avoid that risk is to provide a conversion function, like auto_vec::to_vec(). This is also why standard classes like std::vector or std::string don't allow such implicit conversions and instead provide member functions (see for example Stroustrup: The C++ Programming Language). So a safer auto_vec class would not be publicly derived from vec but instead use the has-a
Re: [PATCH] libgccjit: add some reflection functions in the jit C api
Le vendredi 11 juin 2021 à 14:00 -0400, David Malcolm a écrit :
> On Fri, 2021-06-11 at 08:15 -0400, Antoni Boucher wrote:
> > Thank you for your answer.
> > I attached the updated patch.
>
> BTW you (or possibly me) dropped the mailing lists; was that
> deliberate?
Oh, my bad.
> >
> > See my answers below.
> >
> > Le jeudi 10 juin 2021 à 18:41 -0400, David Malcolm a écrit :
> > > On Thu, 2021-05-27 at 21:51 -0400, Antoni Boucher wrote:
> > > > I chose option A, so everything is a size_t, now.
> > > > I also renamed the dyncast functions.
> > > > Here's the new patch.
> > >
> > > Thanks, sorry again about the delays in reviewing your work.
> > >
> > > You didn't specify how you tested the patch; are you running the
> > > full
> > > jit regression test suite?
> >
> > Yes, I run the full jit test suite.
>
> Great.
>
> [...snip...]
>
> > >
> > > I can't remember, sorry, do you have push rights to the gcc git
> > > repository?
> >
> > I don't have push rights; it's actually my first contribution to
> > gcc.
>
> Congratulations! I'm excited about having Rust support for GCC (two
> different ways, in fact!)
Yup. Exciting times!
>
> > I have signed the FSF copyright attribution.
>
> I can push changes on your behalf, but I'd prefer it if you did it,
> especially given that you have various other patches you want to get
> in.
>
> Instructions on how to get push rights to the git repo are here:
> https://gcc.gnu.org/gitwrite.html
>
> I can sponsor you.
Thanks.
I did sign up to get push rights.
Have you accepted my request to get those?
>
> Note that your patches would still need review/approval ("Write After
> Approval").
>
> > > Do you have a preference as to which patch you want me to look at
> > > next?
> > > Otherwise I'll go through them in the order in
> > > https://github.com/antoyo/rustc_codegen_gcc/tree/master/gcc-patches
> >
> > You can indeed look in this directory in the order they were added.
> > There was one patch before the reflection one (0001-This-patch-
> > handles-
> > truncation-and-extension-for-cast.patch), but since it's only a
> > bugfix,
> > it doesn't matter if it's merged after.
>
> That one looks good to me now too (I've replied on that patch).
>
> >
> > This one is ready for review, but I believe the other one needs
> > correction on my end since the last review you made. I'll make sure
> > to
> > fix them soon.
>
> Now I'm confused as to which patches you're referring to, sorry.
> I'll
> hold off for now on further reviews; let me know when you want me to
> look at them, and which ones.
>
> Thanks
> Dave
>
RE: [PATCH][GCC-10] arm: Fix multilib mapping for CDE extensions [PR100856].
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 18 June 2021 16:22
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Earnshaw
>
> Subject: [PATCH][GCC-10] arm: Fix multilib mapping for CDE extensions
> [PR100856].
>
> Hi,
>
> This is a backport to gcc-10 and the patch applied cleanly on the branch.
>
> On passing +cdecp[0-7] extension to the -march string in command line
> options,
> multilib linking is failing as mentioned in PR100856. This patch fixes this
> issue
> by
> generating a separate canonical string by removing compiler options which
> are not
> required for multilib linking from march string and assign the new string to
> mlibarch
> option. This mlibarch string is used for multilib comparison.
>
> Ok for gcc-10 branch?
Ok.
Thanks,
Kyrill
>
> Regards,
> Srinath.
>
> gcc/ChangeLog:
>
> 2021-06-10 Srinath Parvathaneni
>
> PR target/100856
> * common/config/arm/arm-common.c (arm_canon_arch_option_1):
> New function
> derived from arm_canon_arch.
> (arm_canon_arch_option): Call it.
> (arm_canon_arch_multilib_option): New function.
> * config/arm/arm-cpus.in (IGNORE_FOR_MULTILIB): New fgroup.
> * config/arm/arm.h (arm_canon_arch_multilib_option): New
> prototype.
> (CANON_ARCH_MULTILIB_SPEC_FUNCTION): New macro.
> (MULTILIB_ARCH_CANONICAL_SPECS): New macro.
> (DRIVER_SELF_SPECS): Add MULTILIB_ARCH_CANONICAL_SPECS.
> * config/arm/arm.opt (mlibarch): New option.
> * config/arm/t-rmprofile (MULTILIB_MATCHES): For armv8*-m,
> replace use
> of march on RHS with mlibarch.
>
> gcc/testsuite/ChangeLog:
>
> 2021-06-10 Srinath Parvathaneni
>
> PR target/100856
> * gcc.target/arm/acle/pr100856.c: New test.
> * gcc.target/arm/multilib.exp: Add tests for cde options.
>
> (cherry picked from commit f58d03b5df25f9eab06b7eacea8da780fc2e0219)
>
>
> ### Attachment also inlined for ease of reply
> ###
>
>
> diff --git a/gcc/common/config/arm/arm-common.c
> b/gcc/common/config/arm/arm-common.c
> index
> 78a779c935071c534a780821d399cb7d2e170808..a4b3e86ad5251be18f7131
> cd05fdab40f11d3742 100644
> --- a/gcc/common/config/arm/arm-common.c
> +++ b/gcc/common/config/arm/arm-common.c
> @@ -590,9 +590,15 @@ public:
> The options array consists of couplets of information where the
> first item in each couplet is the string describing which option
> name was selected (arch, cpu, fpu) and the second is the value
> - passed for that option. */
> -const char *
> -arm_canon_arch_option (int argc, const char **argv)
> + passed for that option.
> +
> + arch_for_multilib is boolean variable taking value true or false.
> + arch_for_multilib is false when the canonical representation is for -march
> + option and it is true when canonical representation is for -mlibarch
> option.
> + On passing arch_for_multilib true the canonical string generated will be
> + without the compiler options which are not required for multilib linking.
> */
> +static const char *
> +arm_canon_arch_option_1 (int argc, const char **argv, bool
> arch_for_multilib)
> {
>const char *arch = NULL;
>const char *cpu = NULL;
> @@ -657,8 +663,8 @@ arm_canon_arch_option (int argc, const char **argv)
>/* First build up a bitmap describing the target architecture. */
>if (arch)
> {
> - selected_arch = arm_parse_arch_option_name (all_architectures,
> - "-march", arch);
> + selected_arch = arm_parse_arch_option_name (all_architectures, "-
> march",
> + arch, !arch_for_multilib);
>
>if (selected_arch == NULL)
> return "";
> @@ -666,6 +672,15 @@ arm_canon_arch_option (int argc, const char
> **argv)
>arm_initialize_isa (target_isa, selected_arch->common.isa_bits);
>arm_parse_option_features (target_isa, _arch->common,
>strchr (arch, '+'));
> + if (arch_for_multilib)
> + {
> + const enum isa_feature removable_bits[] =
> {ISA_IGNORE_FOR_MULTILIB,
> + isa_nobit};
> + sbitmap isa_bits = sbitmap_alloc (isa_num_bits);
> + arm_initialize_isa (isa_bits, removable_bits);
> + bitmap_and_compl (target_isa, target_isa, isa_bits);
> + }
> +
>if (fpu && strcmp (fpu, "auto") != 0)
> {
> /* We assume that architectures do not have any FPU bits
> @@ -682,7 +697,8 @@ arm_canon_arch_option (int argc, const char **argv)
>else if (cpu)
> {
>const cpu_option *selected_cpu
> - = arm_parse_cpu_option_name (all_cores, "-mcpu", cpu);
> + = arm_parse_cpu_option_name (all_cores, "-mcpu", cpu,
> + !arch_for_multilib);
>
>if (selected_cpu == NULL)
> return "";
> @@ -1032,3 +1048,22 @@ arm_asm_auto_mfpu (int argc, const char
> **argv)
>
RE: [PATCH][GCC-11] arm: Fix multilib mapping for CDE extensions [PR100856].
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 18 June 2021 16:22
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Earnshaw
>
> Subject: [PATCH][GCC-11] arm: Fix multilib mapping for CDE extensions
> [PR100856].
>
> Hi,
>
> This is a backport to gcc-11 and the patch applied cleanly on the branch.
>
> On passing +cdecp[0-7] extension to the -march string in command line
> options,
> multilib linking is failing as mentioned in PR100856. This patch fixes this
> issue
> by
> generating a separate canonical string by removing compiler options which
> are not
> required for multilib linking from march string and assign the new string to
> mlibarch
> option. This mlibarch string is used for multilib comparison.
>
> Ok for gcc-11 branch?
Ok.
Thanks,
Kyrill
>
> Regards,
> Srinath.
>
> gcc/ChangeLog:
>
> 2021-06-10 Srinath Parvathaneni
>
> PR target/100856
> * common/config/arm/arm-common.c (arm_canon_arch_option_1):
> New function
> derived from arm_canon_arch.
> (arm_canon_arch_option): Call it.
> (arm_canon_arch_multilib_option): New function.
> * config/arm/arm-cpus.in (IGNORE_FOR_MULTILIB): New fgroup.
> * config/arm/arm.h (arm_canon_arch_multilib_option): New
> prototype.
> (CANON_ARCH_MULTILIB_SPEC_FUNCTION): New macro.
> (MULTILIB_ARCH_CANONICAL_SPECS): New macro.
> (DRIVER_SELF_SPECS): Add MULTILIB_ARCH_CANONICAL_SPECS.
> * config/arm/arm.opt (mlibarch): New option.
> * config/arm/t-rmprofile (MULTILIB_MATCHES): For armv8*-m,
> replace use
> of march on RHS with mlibarch.
>
> gcc/testsuite/ChangeLog:
>
> 2021-06-10 Srinath Parvathaneni
>
> PR target/100856
> * gcc.target/arm/acle/pr100856.c: New test.
> * gcc.target/arm/multilib.exp: Add tests for cde options.
>
> (cherry picked from commit f58d03b5df25f9eab06b7eacea8da780fc2e0219)
>
>
> ### Attachment also inlined for ease of reply
> ###
>
>
> diff --git a/gcc/common/config/arm/arm-common.c
> b/gcc/common/config/arm/arm-common.c
> index
> 9980af6885c3dfe68f61fa0f39b23022b4e59c19..481aa9e43d9c73e464e1e99
> 2ad7d94c30d2db001 100644
> --- a/gcc/common/config/arm/arm-common.c
> +++ b/gcc/common/config/arm/arm-common.c
> @@ -627,9 +627,15 @@ public:
> The options array consists of couplets of information where the
> first item in each couplet is the string describing which option
> name was selected (arch, cpu, fpu) and the second is the value
> - passed for that option. */
> -const char *
> -arm_canon_arch_option (int argc, const char **argv)
> + passed for that option.
> +
> + arch_for_multilib is boolean variable taking value true or false.
> + arch_for_multilib is false when the canonical representation is for -march
> + option and it is true when canonical representation is for -mlibarch
> option.
> + On passing arch_for_multilib true the canonical string generated will be
> + without the compiler options which are not required for multilib linking.
> */
> +static const char *
> +arm_canon_arch_option_1 (int argc, const char **argv, bool
> arch_for_multilib)
> {
>const char *arch = NULL;
>const char *cpu = NULL;
> @@ -694,8 +700,8 @@ arm_canon_arch_option (int argc, const char **argv)
>/* First build up a bitmap describing the target architecture. */
>if (arch)
> {
> - selected_arch = arm_parse_arch_option_name (all_architectures,
> - "-march", arch);
> + selected_arch = arm_parse_arch_option_name (all_architectures, "-
> march",
> + arch, !arch_for_multilib);
>
>if (selected_arch == NULL)
> return "";
> @@ -703,6 +709,15 @@ arm_canon_arch_option (int argc, const char
> **argv)
>arm_initialize_isa (target_isa, selected_arch->common.isa_bits);
>arm_parse_option_features (target_isa, _arch->common,
>strchr (arch, '+'));
> + if (arch_for_multilib)
> + {
> + const enum isa_feature removable_bits[] =
> {ISA_IGNORE_FOR_MULTILIB,
> + isa_nobit};
> + sbitmap isa_bits = sbitmap_alloc (isa_num_bits);
> + arm_initialize_isa (isa_bits, removable_bits);
> + bitmap_and_compl (target_isa, target_isa, isa_bits);
> + }
> +
>if (fpu && strcmp (fpu, "auto") != 0)
> {
> /* We assume that architectures do not have any FPU bits
> @@ -719,7 +734,8 @@ arm_canon_arch_option (int argc, const char **argv)
>else if (cpu)
> {
>const cpu_option *selected_cpu
> - = arm_parse_cpu_option_name (all_cores, "-mcpu", cpu);
> + = arm_parse_cpu_option_name (all_cores, "-mcpu", cpu,
> + !arch_for_multilib);
>
>if (selected_cpu == NULL)
> return "";
> @@ -1069,3 +1085,22 @@ arm_asm_auto_mfpu (int argc, const char
> **argv)
>
RE: [GCC-11 backport][PATCH] arm: Fix polymorphic variants failing with undefined reference to `__ARM_undef` error.
> -Original Message- > From: Srinath Parvathaneni > Sent: 14 June 2021 11:35 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov ; Richard Earnshaw > > Subject: [GCC-11 backport][PATCH] arm: Fix polymorphic variants failing with > undefined reference to `__ARM_undef` error. > > Hi, > > This patch fixes the issue mentioned in PR101016, which is mve polymorphic > variants > failing at linking with undefined reference to "__ARM_undef" error. > > Regression tested on arm-none-eabi and found no regressions. > > This patch have cleanly applied, ok for the GCC-11 branch? Ok. Thanks, Kyrill > > gcc/ChangeLog: > > 2021-06-11 Srinath Parvathaneni > > PR target/101016 > * config/arm/arm_mve.h (__arm_vld1q): Change > __ARM_mve_coerce(p0, > int8_t const *) to __ARM_mve_coerce1(p0, int8_t *) in the argument > for > the polymorphic variants matching code. > (__arm_vld1q_z): Likewise. > (__arm_vld2q): Likewise. > (__arm_vld4q): Likewise. > (__arm_vldrbq_gather_offset): Likewise. > (__arm_vldrbq_gather_offset_z): Likewise. > > gcc/testsuite/ChangeLog: > > 2021-06-11 Srinath Parvathaneni > > PR target/101016 > * gcc.target/arm/mve/intrinsics/pr101016.c: New test. > > (cherry picked from commit b13f297f01c943aa167f7c6eb94bed40dce0d553) > > > ### Attachment also inlined for ease of reply > ### > > > diff --git a/gcc/config/arm/arm_mve.h b/gcc/config/arm/arm_mve.h > index > dc1d874a6366eb5fe755a70c72ed371c915bd04b..182b2aac6da5d4f0046aa6 > 28b0d813ff8e43839a 100644 > --- a/gcc/config/arm/arm_mve.h > +++ b/gcc/config/arm/arm_mve.h > @@ -37565,47 +37565,47 @@ extern void *__ARM_undef; > > #define __arm_vld1q(p0) (\ >_Generic( (int (*)[__ARM_mve_typeid(p0)])0, \ > - int (*)[__ARM_mve_type_int8_t_ptr]: __arm_vld1q_s8 > (__ARM_mve_coerce(p0, int8_t const *)), \ > - int (*)[__ARM_mve_type_int16_t_ptr]: __arm_vld1q_s16 > (__ARM_mve_coerce(p0, int16_t const *)), \ > - int (*)[__ARM_mve_type_int32_t_ptr]: __arm_vld1q_s32 > (__ARM_mve_coerce(p0, int32_t const *)), \ > - int (*)[__ARM_mve_type_uint8_t_ptr]: __arm_vld1q_u8 > (__ARM_mve_coerce(p0, uint8_t const *)), \ > - int (*)[__ARM_mve_type_uint16_t_ptr]: __arm_vld1q_u16 > (__ARM_mve_coerce(p0, uint16_t const *)), \ > - int (*)[__ARM_mve_type_uint32_t_ptr]: __arm_vld1q_u32 > (__ARM_mve_coerce(p0, uint32_t const *)), \ > - int (*)[__ARM_mve_type_float16_t_ptr]: __arm_vld1q_f16 > (__ARM_mve_coerce(p0, float16_t const *)), \ > - int (*)[__ARM_mve_type_float32_t_ptr]: __arm_vld1q_f32 > (__ARM_mve_coerce(p0, float32_t const * > + int (*)[__ARM_mve_type_int8_t_ptr]: __arm_vld1q_s8 > (__ARM_mve_coerce1(p0, int8_t *)), \ > + int (*)[__ARM_mve_type_int16_t_ptr]: __arm_vld1q_s16 > (__ARM_mve_coerce1(p0, int16_t *)), \ > + int (*)[__ARM_mve_type_int32_t_ptr]: __arm_vld1q_s32 > (__ARM_mve_coerce1(p0, int32_t *)), \ > + int (*)[__ARM_mve_type_uint8_t_ptr]: __arm_vld1q_u8 > (__ARM_mve_coerce1(p0, uint8_t *)), \ > + int (*)[__ARM_mve_type_uint16_t_ptr]: __arm_vld1q_u16 > (__ARM_mve_coerce1(p0, uint16_t *)), \ > + int (*)[__ARM_mve_type_uint32_t_ptr]: __arm_vld1q_u32 > (__ARM_mve_coerce1(p0, uint32_t *)), \ > + int (*)[__ARM_mve_type_float16_t_ptr]: __arm_vld1q_f16 > (__ARM_mve_coerce1(p0, float16_t *)), \ > + int (*)[__ARM_mve_type_float32_t_ptr]: __arm_vld1q_f32 > (__ARM_mve_coerce1(p0, float32_t * > > #define __arm_vld1q_z(p0,p1) ( \ >_Generic( (int (*)[__ARM_mve_typeid(p0)])0, \ > - int (*)[__ARM_mve_type_int8_t_ptr]: __arm_vld1q_z_s8 > (__ARM_mve_coerce(p0, int8_t const *), p1), \ > - int (*)[__ARM_mve_type_int16_t_ptr]: __arm_vld1q_z_s16 > (__ARM_mve_coerce(p0, int16_t const *), p1), \ > - int (*)[__ARM_mve_type_int32_t_ptr]: __arm_vld1q_z_s32 > (__ARM_mve_coerce(p0, int32_t const *), p1), \ > - int (*)[__ARM_mve_type_uint8_t_ptr]: __arm_vld1q_z_u8 > (__ARM_mve_coerce(p0, uint8_t const *), p1), \ > - int (*)[__ARM_mve_type_uint16_t_ptr]: __arm_vld1q_z_u16 > (__ARM_mve_coerce(p0, uint16_t const *), p1), \ > - int (*)[__ARM_mve_type_uint32_t_ptr]: __arm_vld1q_z_u32 > (__ARM_mve_coerce(p0, uint32_t const *), p1), \ > - int (*)[__ARM_mve_type_float16_t_ptr]: __arm_vld1q_z_f16 > (__ARM_mve_coerce(p0, float16_t const *), p1), \ > - int (*)[__ARM_mve_type_float32_t_ptr]: __arm_vld1q_z_f32 > (__ARM_mve_coerce(p0, float32_t const *), p1))) > + int (*)[__ARM_mve_type_int8_t_ptr]: __arm_vld1q_z_s8 > (__ARM_mve_coerce1(p0, int8_t *), p1), \ > + int (*)[__ARM_mve_type_int16_t_ptr]: __arm_vld1q_z_s16 > (__ARM_mve_coerce1(p0, int16_t *), p1), \ > + int (*)[__ARM_mve_type_int32_t_ptr]: __arm_vld1q_z_s32 > (__ARM_mve_coerce1(p0, int32_t *), p1), \ > + int (*)[__ARM_mve_type_uint8_t_ptr]: __arm_vld1q_z_u8 > (__ARM_mve_coerce1(p0, uint8_t *), p1), \ > + int (*)[__ARM_mve_type_uint16_t_ptr]: __arm_vld1q_z_u16 > (__ARM_mve_coerce1(p0, uint16_t *), p1), \ > + int (*)[__ARM_mve_type_uint32_t_ptr]: __arm_vld1q_z_u32 > (__ARM_mve_coerce1(p0,
RE: [GCC-10 backport][PATCH] arm: Fix polymorphic variants failing with undefined reference to `__ARM_undef` error.
> -Original Message- > From: Srinath Parvathaneni > Sent: 14 June 2021 11:35 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov ; Richard Earnshaw > > Subject: [GCC-10 backport][PATCH] arm: Fix polymorphic variants failing with > undefined reference to `__ARM_undef` error. > > Hi, > > This patch fixes the issue mentioned in PR101016, which is mve polymorphic > variants > failing at linking with undefined reference to "__ARM_undef" error. > > Regression tested on arm-none-eabi and found no regressions. > > This patch have cleanly applied, ok for the GCC-10 branch? Ok. Thanks, Kyrill > > Regards, > Srinath. > > gcc/ChangeLog: > > 2021-06-11 Srinath Parvathaneni > > PR target/101016 > * config/arm/arm_mve.h (__arm_vld1q): Change > __ARM_mve_coerce(p0, > int8_t const *) to __ARM_mve_coerce1(p0, int8_t *) in the argument > for > the polymorphic variants matching code. > (__arm_vld1q_z): Likewise. > (__arm_vld2q): Likewise. > (__arm_vld4q): Likewise. > (__arm_vldrbq_gather_offset): Likewise. > (__arm_vldrbq_gather_offset_z): Likewise. > > gcc/testsuite/ChangeLog: > > 2021-06-11 Srinath Parvathaneni > > PR target/101016 > * gcc.target/arm/mve/intrinsics/pr101016.c: New test. > > (cherry picked from commit b13f297f01c943aa167f7c6eb94bed40dce0d553) > > > ### Attachment also inlined for ease of reply > ### > > > diff --git a/gcc/config/arm/arm_mve.h b/gcc/config/arm/arm_mve.h > index > 1132c7cf87d217a380cf26dd6f110130ea7bf175..4aa3787ca536215450fcb1a > 5bb602b7d5bdbbb16 100644 > --- a/gcc/config/arm/arm_mve.h > +++ b/gcc/config/arm/arm_mve.h > @@ -37559,47 +37559,47 @@ extern void *__ARM_undef; > > #define __arm_vld1q(p0) (\ >_Generic( (int (*)[__ARM_mve_typeid(p0)])0, \ > - int (*)[__ARM_mve_type_int8_t_ptr]: __arm_vld1q_s8 > (__ARM_mve_coerce(p0, int8_t const *)), \ > - int (*)[__ARM_mve_type_int16_t_ptr]: __arm_vld1q_s16 > (__ARM_mve_coerce(p0, int16_t const *)), \ > - int (*)[__ARM_mve_type_int32_t_ptr]: __arm_vld1q_s32 > (__ARM_mve_coerce(p0, int32_t const *)), \ > - int (*)[__ARM_mve_type_uint8_t_ptr]: __arm_vld1q_u8 > (__ARM_mve_coerce(p0, uint8_t const *)), \ > - int (*)[__ARM_mve_type_uint16_t_ptr]: __arm_vld1q_u16 > (__ARM_mve_coerce(p0, uint16_t const *)), \ > - int (*)[__ARM_mve_type_uint32_t_ptr]: __arm_vld1q_u32 > (__ARM_mve_coerce(p0, uint32_t const *)), \ > - int (*)[__ARM_mve_type_float16_t_ptr]: __arm_vld1q_f16 > (__ARM_mve_coerce(p0, float16_t const *)), \ > - int (*)[__ARM_mve_type_float32_t_ptr]: __arm_vld1q_f32 > (__ARM_mve_coerce(p0, float32_t const * > + int (*)[__ARM_mve_type_int8_t_ptr]: __arm_vld1q_s8 > (__ARM_mve_coerce1(p0, int8_t *)), \ > + int (*)[__ARM_mve_type_int16_t_ptr]: __arm_vld1q_s16 > (__ARM_mve_coerce1(p0, int16_t *)), \ > + int (*)[__ARM_mve_type_int32_t_ptr]: __arm_vld1q_s32 > (__ARM_mve_coerce1(p0, int32_t *)), \ > + int (*)[__ARM_mve_type_uint8_t_ptr]: __arm_vld1q_u8 > (__ARM_mve_coerce1(p0, uint8_t *)), \ > + int (*)[__ARM_mve_type_uint16_t_ptr]: __arm_vld1q_u16 > (__ARM_mve_coerce1(p0, uint16_t *)), \ > + int (*)[__ARM_mve_type_uint32_t_ptr]: __arm_vld1q_u32 > (__ARM_mve_coerce1(p0, uint32_t *)), \ > + int (*)[__ARM_mve_type_float16_t_ptr]: __arm_vld1q_f16 > (__ARM_mve_coerce1(p0, float16_t *)), \ > + int (*)[__ARM_mve_type_float32_t_ptr]: __arm_vld1q_f32 > (__ARM_mve_coerce1(p0, float32_t * > > #define __arm_vld1q_z(p0,p1) ( \ >_Generic( (int (*)[__ARM_mve_typeid(p0)])0, \ > - int (*)[__ARM_mve_type_int8_t_ptr]: __arm_vld1q_z_s8 > (__ARM_mve_coerce(p0, int8_t const *), p1), \ > - int (*)[__ARM_mve_type_int16_t_ptr]: __arm_vld1q_z_s16 > (__ARM_mve_coerce(p0, int16_t const *), p1), \ > - int (*)[__ARM_mve_type_int32_t_ptr]: __arm_vld1q_z_s32 > (__ARM_mve_coerce(p0, int32_t const *), p1), \ > - int (*)[__ARM_mve_type_uint8_t_ptr]: __arm_vld1q_z_u8 > (__ARM_mve_coerce(p0, uint8_t const *), p1), \ > - int (*)[__ARM_mve_type_uint16_t_ptr]: __arm_vld1q_z_u16 > (__ARM_mve_coerce(p0, uint16_t const *), p1), \ > - int (*)[__ARM_mve_type_uint32_t_ptr]: __arm_vld1q_z_u32 > (__ARM_mve_coerce(p0, uint32_t const *), p1), \ > - int (*)[__ARM_mve_type_float16_t_ptr]: __arm_vld1q_z_f16 > (__ARM_mve_coerce(p0, float16_t const *), p1), \ > - int (*)[__ARM_mve_type_float32_t_ptr]: __arm_vld1q_z_f32 > (__ARM_mve_coerce(p0, float32_t const *), p1))) > + int (*)[__ARM_mve_type_int8_t_ptr]: __arm_vld1q_z_s8 > (__ARM_mve_coerce1(p0, int8_t *), p1), \ > + int (*)[__ARM_mve_type_int16_t_ptr]: __arm_vld1q_z_s16 > (__ARM_mve_coerce1(p0, int16_t *), p1), \ > + int (*)[__ARM_mve_type_int32_t_ptr]: __arm_vld1q_z_s32 > (__ARM_mve_coerce1(p0, int32_t *), p1), \ > + int (*)[__ARM_mve_type_uint8_t_ptr]: __arm_vld1q_z_u8 > (__ARM_mve_coerce1(p0, uint8_t *), p1), \ > + int (*)[__ARM_mve_type_uint16_t_ptr]: __arm_vld1q_z_u16 > (__ARM_mve_coerce1(p0, uint16_t *), p1), \ > + int (*)[__ARM_mve_type_uint32_t_ptr]: __arm_vld1q_z_u32 >
[PATCH][GCC-11] arm: Fix multilib mapping for CDE extensions [PR100856].
Hi,
This is a backport to gcc-11 and the patch applied cleanly on the branch.
On passing +cdecp[0-7] extension to the -march string in command line options,
multilib linking is failing as mentioned in PR100856. This patch fixes this
issue by
generating a separate canonical string by removing compiler options which are
not
required for multilib linking from march string and assign the new string to
mlibarch
option. This mlibarch string is used for multilib comparison.
Ok for gcc-11 branch?
Regards,
Srinath.
gcc/ChangeLog:
2021-06-10 Srinath Parvathaneni
PR target/100856
* common/config/arm/arm-common.c (arm_canon_arch_option_1): New function
derived from arm_canon_arch.
(arm_canon_arch_option): Call it.
(arm_canon_arch_multilib_option): New function.
* config/arm/arm-cpus.in (IGNORE_FOR_MULTILIB): New fgroup.
* config/arm/arm.h (arm_canon_arch_multilib_option): New prototype.
(CANON_ARCH_MULTILIB_SPEC_FUNCTION): New macro.
(MULTILIB_ARCH_CANONICAL_SPECS): New macro.
(DRIVER_SELF_SPECS): Add MULTILIB_ARCH_CANONICAL_SPECS.
* config/arm/arm.opt (mlibarch): New option.
* config/arm/t-rmprofile (MULTILIB_MATCHES): For armv8*-m, replace use
of march on RHS with mlibarch.
gcc/testsuite/ChangeLog:
2021-06-10 Srinath Parvathaneni
PR target/100856
* gcc.target/arm/acle/pr100856.c: New test.
* gcc.target/arm/multilib.exp: Add tests for cde options.
(cherry picked from commit f58d03b5df25f9eab06b7eacea8da780fc2e0219)
### Attachment also inlined for ease of reply###
diff --git a/gcc/common/config/arm/arm-common.c
b/gcc/common/config/arm/arm-common.c
index
9980af6885c3dfe68f61fa0f39b23022b4e59c19..481aa9e43d9c73e464e1e992ad7d94c30d2db001
100644
--- a/gcc/common/config/arm/arm-common.c
+++ b/gcc/common/config/arm/arm-common.c
@@ -627,9 +627,15 @@ public:
The options array consists of couplets of information where the
first item in each couplet is the string describing which option
name was selected (arch, cpu, fpu) and the second is the value
- passed for that option. */
-const char *
-arm_canon_arch_option (int argc, const char **argv)
+ passed for that option.
+
+ arch_for_multilib is boolean variable taking value true or false.
+ arch_for_multilib is false when the canonical representation is for -march
+ option and it is true when canonical representation is for -mlibarch option.
+ On passing arch_for_multilib true the canonical string generated will be
+ without the compiler options which are not required for multilib linking.
*/
+static const char *
+arm_canon_arch_option_1 (int argc, const char **argv, bool arch_for_multilib)
{
const char *arch = NULL;
const char *cpu = NULL;
@@ -694,8 +700,8 @@ arm_canon_arch_option (int argc, const char **argv)
/* First build up a bitmap describing the target architecture. */
if (arch)
{
- selected_arch = arm_parse_arch_option_name (all_architectures,
- "-march", arch);
+ selected_arch = arm_parse_arch_option_name (all_architectures, "-march",
+ arch, !arch_for_multilib);
if (selected_arch == NULL)
return "";
@@ -703,6 +709,15 @@ arm_canon_arch_option (int argc, const char **argv)
arm_initialize_isa (target_isa, selected_arch->common.isa_bits);
arm_parse_option_features (target_isa, _arch->common,
strchr (arch, '+'));
+ if (arch_for_multilib)
+ {
+ const enum isa_feature removable_bits[] = {ISA_IGNORE_FOR_MULTILIB,
+isa_nobit};
+ sbitmap isa_bits = sbitmap_alloc (isa_num_bits);
+ arm_initialize_isa (isa_bits, removable_bits);
+ bitmap_and_compl (target_isa, target_isa, isa_bits);
+ }
+
if (fpu && strcmp (fpu, "auto") != 0)
{
/* We assume that architectures do not have any FPU bits
@@ -719,7 +734,8 @@ arm_canon_arch_option (int argc, const char **argv)
else if (cpu)
{
const cpu_option *selected_cpu
- = arm_parse_cpu_option_name (all_cores, "-mcpu", cpu);
+ = arm_parse_cpu_option_name (all_cores, "-mcpu", cpu,
+!arch_for_multilib);
if (selected_cpu == NULL)
return "";
@@ -1069,3 +1085,22 @@ arm_asm_auto_mfpu (int argc, const char **argv)
#define TARGET_EXCEPT_UNWIND_INFO arm_except_unwind_info
struct gcc_targetm_common targetm_common = TARGETM_COMMON_INITIALIZER;
+
+/* Returns a canonical representation of the -march option from the current
+ -march string (if given) and other options on the command line that might
+ affect the architecture. */
+const char *
+arm_canon_arch_option (int argc, const char **argv)
+{
+ return arm_canon_arch_option_1 (argc, argv, false);
+}
+
[PATCH][GCC-10] arm: Fix multilib mapping for CDE extensions [PR100856].
Hi,
This is a backport to gcc-10 and the patch applied cleanly on the branch.
On passing +cdecp[0-7] extension to the -march string in command line options,
multilib linking is failing as mentioned in PR100856. This patch fixes this
issue by
generating a separate canonical string by removing compiler options which are
not
required for multilib linking from march string and assign the new string to
mlibarch
option. This mlibarch string is used for multilib comparison.
Ok for gcc-10 branch?
Regards,
Srinath.
gcc/ChangeLog:
2021-06-10 Srinath Parvathaneni
PR target/100856
* common/config/arm/arm-common.c (arm_canon_arch_option_1): New function
derived from arm_canon_arch.
(arm_canon_arch_option): Call it.
(arm_canon_arch_multilib_option): New function.
* config/arm/arm-cpus.in (IGNORE_FOR_MULTILIB): New fgroup.
* config/arm/arm.h (arm_canon_arch_multilib_option): New prototype.
(CANON_ARCH_MULTILIB_SPEC_FUNCTION): New macro.
(MULTILIB_ARCH_CANONICAL_SPECS): New macro.
(DRIVER_SELF_SPECS): Add MULTILIB_ARCH_CANONICAL_SPECS.
* config/arm/arm.opt (mlibarch): New option.
* config/arm/t-rmprofile (MULTILIB_MATCHES): For armv8*-m, replace use
of march on RHS with mlibarch.
gcc/testsuite/ChangeLog:
2021-06-10 Srinath Parvathaneni
PR target/100856
* gcc.target/arm/acle/pr100856.c: New test.
* gcc.target/arm/multilib.exp: Add tests for cde options.
(cherry picked from commit f58d03b5df25f9eab06b7eacea8da780fc2e0219)
### Attachment also inlined for ease of reply###
diff --git a/gcc/common/config/arm/arm-common.c
b/gcc/common/config/arm/arm-common.c
index
78a779c935071c534a780821d399cb7d2e170808..a4b3e86ad5251be18f7131cd05fdab40f11d3742
100644
--- a/gcc/common/config/arm/arm-common.c
+++ b/gcc/common/config/arm/arm-common.c
@@ -590,9 +590,15 @@ public:
The options array consists of couplets of information where the
first item in each couplet is the string describing which option
name was selected (arch, cpu, fpu) and the second is the value
- passed for that option. */
-const char *
-arm_canon_arch_option (int argc, const char **argv)
+ passed for that option.
+
+ arch_for_multilib is boolean variable taking value true or false.
+ arch_for_multilib is false when the canonical representation is for -march
+ option and it is true when canonical representation is for -mlibarch option.
+ On passing arch_for_multilib true the canonical string generated will be
+ without the compiler options which are not required for multilib linking.
*/
+static const char *
+arm_canon_arch_option_1 (int argc, const char **argv, bool arch_for_multilib)
{
const char *arch = NULL;
const char *cpu = NULL;
@@ -657,8 +663,8 @@ arm_canon_arch_option (int argc, const char **argv)
/* First build up a bitmap describing the target architecture. */
if (arch)
{
- selected_arch = arm_parse_arch_option_name (all_architectures,
- "-march", arch);
+ selected_arch = arm_parse_arch_option_name (all_architectures, "-march",
+ arch, !arch_for_multilib);
if (selected_arch == NULL)
return "";
@@ -666,6 +672,15 @@ arm_canon_arch_option (int argc, const char **argv)
arm_initialize_isa (target_isa, selected_arch->common.isa_bits);
arm_parse_option_features (target_isa, _arch->common,
strchr (arch, '+'));
+ if (arch_for_multilib)
+ {
+ const enum isa_feature removable_bits[] = {ISA_IGNORE_FOR_MULTILIB,
+isa_nobit};
+ sbitmap isa_bits = sbitmap_alloc (isa_num_bits);
+ arm_initialize_isa (isa_bits, removable_bits);
+ bitmap_and_compl (target_isa, target_isa, isa_bits);
+ }
+
if (fpu && strcmp (fpu, "auto") != 0)
{
/* We assume that architectures do not have any FPU bits
@@ -682,7 +697,8 @@ arm_canon_arch_option (int argc, const char **argv)
else if (cpu)
{
const cpu_option *selected_cpu
- = arm_parse_cpu_option_name (all_cores, "-mcpu", cpu);
+ = arm_parse_cpu_option_name (all_cores, "-mcpu", cpu,
+!arch_for_multilib);
if (selected_cpu == NULL)
return "";
@@ -1032,3 +1048,22 @@ arm_asm_auto_mfpu (int argc, const char **argv)
#define TARGET_EXCEPT_UNWIND_INFO arm_except_unwind_info
struct gcc_targetm_common targetm_common = TARGETM_COMMON_INITIALIZER;
+
+/* Returns a canonical representation of the -march option from the current
+ -march string (if given) and other options on the command line that might
+ affect the architecture. */
+const char *
+arm_canon_arch_option (int argc, const char **argv)
+{
+ return arm_canon_arch_option_1 (argc, argv, false);
+}
+
[committed] analyzer: add region_model_manager::get_or_create_int_cst
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as 1aff29d42601927a416a484d6c0fa37a25faae79.
gcc/analyzer/ChangeLog:
* region-model-manager.cc
(region_model_manager::get_or_create_int_cst): New.
(region_model_manager::maybe_undo_optimize_bit_field_compare): Use
it to simplify away a local tree.
* region-model.cc (region_model::on_setjmp): Likewise.
(region_model::on_longjmp): Likewise.
* region-model.h (region_model_manager::get_or_create_int_cst):
New decl.
* store.cc (binding_cluster::zero_fill_region): Use it to simplify
away a local tree.
Signed-off-by: David Malcolm
---
gcc/analyzer/region-model-manager.cc | 14 --
gcc/analyzer/region-model.cc | 11 +--
gcc/analyzer/region-model.h | 1 +
gcc/analyzer/store.cc| 4 ++--
4 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/gcc/analyzer/region-model-manager.cc
b/gcc/analyzer/region-model-manager.cc
index 621eff0e139..1ee6663f05e 100644
--- a/gcc/analyzer/region-model-manager.cc
+++ b/gcc/analyzer/region-model-manager.cc
@@ -210,6 +210,17 @@ region_model_manager::get_or_create_constant_svalue (tree
cst_expr)
return cst_sval;
}
+/* Return the svalue * for a constant_svalue for the INTEGER_CST
+ for VAL of type TYPE, creating it if necessary. */
+
+const svalue *
+region_model_manager::get_or_create_int_cst (tree type, poly_int64 val)
+{
+ gcc_assert (type);
+ tree tree_cst = build_int_cst (type, val);
+ return get_or_create_constant_svalue (tree_cst);
+}
+
/* Return the svalue * for a unknown_svalue for TYPE (which can be NULL),
creating it if necessary.
The unknown_svalue instances are reused, based on pointer equality
@@ -475,8 +486,7 @@ maybe_undo_optimize_bit_field_compare (tree type,
shift it by the correct number of bits. */
const svalue *lhs = get_or_create_cast (type, sval);
HOST_WIDE_INT bit_offset = bits.get_start_bit_offset ().to_shwi ();
- tree shift_amt = build_int_cst (type, bit_offset);
- const svalue *shift_sval = get_or_create_constant_svalue (shift_amt);
+ const svalue *shift_sval = get_or_create_int_cst (type, bit_offset);
const svalue *shifted_sval = get_or_create_binop (type, LSHIFT_EXPR,
lhs, shift_sval);
/* Reapply the mask (needed for negative
diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index e02a89765f0..462fe6d8b3c 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -1259,8 +1259,8 @@ region_model::on_setjmp (const gcall *call, const
exploded_node *enode,
/* Direct calls to setjmp return 0. */
if (tree lhs = gimple_call_lhs (call))
{
- tree zero = build_int_cst (TREE_TYPE (lhs), 0);
- const svalue *new_sval = m_mgr->get_or_create_constant_svalue (zero);
+ const svalue *new_sval
+ = m_mgr->get_or_create_int_cst (TREE_TYPE (lhs), 0);
const region *lhs_reg = get_lvalue (lhs, ctxt);
set_value (lhs_reg, new_sval, ctxt);
}
@@ -1291,15 +1291,14 @@ region_model::on_longjmp (const gcall *longjmp_call,
const gcall *setjmp_call,
if (tree lhs = gimple_call_lhs (setjmp_call))
{
/* Passing 0 as the val to longjmp leads to setjmp returning 1. */
- tree t_zero = build_int_cst (TREE_TYPE (fake_retval), 0);
- const svalue *zero_sval = m_mgr->get_or_create_constant_svalue (t_zero);
+ const svalue *zero_sval
+ = m_mgr->get_or_create_int_cst (TREE_TYPE (fake_retval), 0);
tristate eq_zero = eval_condition (fake_retval_sval, EQ_EXPR, zero_sval);
/* If we have 0, use 1. */
if (eq_zero.is_true ())
{
- tree t_one = build_int_cst (TREE_TYPE (fake_retval), 1);
const svalue *one_sval
- = m_mgr->get_or_create_constant_svalue (t_one);
+ = m_mgr->get_or_create_int_cst (TREE_TYPE (fake_retval), 1);
fake_retval_sval = one_sval;
}
else
diff --git a/gcc/analyzer/region-model.h b/gcc/analyzer/region-model.h
index 7b12d35ab59..a4b584d186e 100644
--- a/gcc/analyzer/region-model.h
+++ b/gcc/analyzer/region-model.h
@@ -238,6 +238,7 @@ public:
/* svalue consolidation. */
const svalue *get_or_create_constant_svalue (tree cst_expr);
+ const svalue *get_or_create_int_cst (tree type, poly_int64);
const svalue *get_or_create_unknown_svalue (tree type);
const svalue *get_or_create_setjmp_svalue (const setjmp_record ,
tree type);
diff --git a/gcc/analyzer/store.cc b/gcc/analyzer/store.cc
index d75fb2c4c7a..b643b631863 100644
--- a/gcc/analyzer/store.cc
+++ b/gcc/analyzer/store.cc
@@ -1043,8 +1043,8 @@ binding_cluster::zero_fill_region (store_manager *mgr,
const region *reg)
/* Add a default binding to zero. */
region_model_manager *sval_mgr = mgr->get_svalue_manager ();
- tree cst_zero =
[committed] analyzer: refactor custom_event, introducing precanned_custom_event class
I have followup work where a custom event's description would be better
handled via a vfunc rather that a precanned string, hence this
refactoring to make it easy to add custom_event subclasses.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as 86606d2ab731a4b8dbbe1e5318a1920210abd65d.
gcc/analyzer/ChangeLog:
* checker-path.cc (class custom_event): Make abstract to allow for
custom vfuncs, splitting existing implementation into...
(class precanned_custom_event): New subclass.
(custom_event::get_desc): Move to...
(precanned_custom_event::get_desc): ...subclass.
* checker-path.h (class custom_event): Make abstract to allow for
custom vfuncs, splitting existing implementation into...
(class precanned_custom_event): New subclass.
* diagnostic-manager.cc (diagnostic_manager::add_events_for_eedge):
Use precanned_custom_event.
* engine.cc
(stale_jmp_buf::maybe_add_custom_events_for_superedge): Likewise.
* sm-signal.cc (signal_delivery_edge_info_t::add_events_to_path):
Likewise.
Signed-off-by: David Malcolm
---
gcc/analyzer/checker-path.cc | 6 +++---
gcc/analyzer/checker-path.h| 22 +-
gcc/analyzer/diagnostic-manager.cc | 2 +-
gcc/analyzer/engine.cc | 2 +-
gcc/analyzer/sm-signal.cc | 7 ---
5 files changed, 26 insertions(+), 13 deletions(-)
diff --git a/gcc/analyzer/checker-path.cc b/gcc/analyzer/checker-path.cc
index e6f838b7d52..e10c8e2bb7c 100644
--- a/gcc/analyzer/checker-path.cc
+++ b/gcc/analyzer/checker-path.cc
@@ -162,14 +162,14 @@ debug_event::get_desc (bool) const
return label_text::borrow (m_desc);
}
-/* class custom_event : public checker_event. */
+/* class precanned_custom_event : public custom_event. */
/* Implementation of diagnostic_event::get_desc vfunc for
- custom_event.
+ precanned_custom_event.
Use the saved string as the event's description. */
label_text
-custom_event::get_desc (bool) const
+precanned_custom_event::get_desc (bool) const
{
return label_text::borrow (m_desc);
}
diff --git a/gcc/analyzer/checker-path.h b/gcc/analyzer/checker-path.h
index f76bb94e7cc..1843c4bc7b4 100644
--- a/gcc/analyzer/checker-path.h
+++ b/gcc/analyzer/checker-path.h
@@ -56,6 +56,7 @@ extern const char *event_kind_to_string (enum event_kind ek);
checker_event
debug_event (EK_DEBUG)
custom_event (EK_CUSTOM)
+precanned_custom_event
statement_event (EK_STMT)
function_entry_event (EK_FUNCTION_ENTRY)
state_change_event (EK_STATE_CHANGE)
@@ -144,19 +145,30 @@ private:
char *m_desc;
};
-/* A concrete event subclass for custom events. These are not filtered,
+/* An abstract event subclass for custom events. These are not filtered,
as they are likely to be pertinent to the diagnostic. */
class custom_event : public checker_event
{
+protected:
+ custom_event (location_t loc, tree fndecl, int depth)
+ : checker_event (EK_CUSTOM, loc, fndecl, depth)
+ {
+ }
+};
+
+/* A concrete custom_event subclass with a precanned message. */
+
+class precanned_custom_event : public custom_event
+{
public:
- custom_event (location_t loc, tree fndecl, int depth,
- const char *desc)
- : checker_event (EK_CUSTOM, loc, fndecl, depth),
+ precanned_custom_event (location_t loc, tree fndecl, int depth,
+ const char *desc)
+ : custom_event (loc, fndecl, depth),
m_desc (xstrdup (desc))
{
}
- ~custom_event ()
+ ~precanned_custom_event ()
{
free (m_desc);
}
diff --git a/gcc/analyzer/diagnostic-manager.cc
b/gcc/analyzer/diagnostic-manager.cc
index 443ff058f65..7eb4ed8a4f2 100644
--- a/gcc/analyzer/diagnostic-manager.cc
+++ b/gcc/analyzer/diagnostic-manager.cc
@@ -1587,7 +1587,7 @@ diagnostic_manager::add_events_for_eedge (const
path_builder ,
"this path would have been rejected as infeasible"
" at this edge: ");
pb.get_feasibility_problem ()->dump_to_pp ();
- emission_path->add_event (new custom_event
+ emission_path->add_event (new precanned_custom_event
(dst_point.get_location (),
dst_point.get_fndecl (),
dst_stack_depth,
diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index 529965af187..f322fdb6497 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -1395,7 +1395,7 @@ public:
{
/* Compare with diagnostic_manager::add_events_for_superedge. */
const int src_stack_depth = src_point.get_stack_depth ();
- m_stack_pop_event = new custom_event
+ m_stack_pop_event = new precanned_custom_event
(src_point.get_location (),
src_point.get_fndecl (),
src_stack_depth,
diff --git a/gcc/analyzer/sm-signal.cc b/gcc/analyzer/sm-signal.cc
Re: [PATCH] libstdc++: Implement LWG 3557 change to convertible_to
OK, thanks.
On Fri, 18 Jun 2021 at 16:13, Patrick Palka via Libstdc++
wrote:
>
> libstdc++-v3/ChangeLog:
>
> * include/std/concepts (convertible_to): Just use declval as per
> LWG 3557.
> ---
> libstdc++-v3/include/std/concepts | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/libstdc++-v3/include/std/concepts
> b/libstdc++-v3/include/std/concepts
> index 4490f534412..7f5421f1475 100644
> --- a/libstdc++-v3/include/std/concepts
> +++ b/libstdc++-v3/include/std/concepts
> @@ -70,9 +70,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>/// [concept.convertible], concept convertible_to
>template
> concept convertible_to = is_convertible_v<_From, _To>
> - && requires(add_rvalue_reference_t<_From> (&__f)()) {
> - static_cast<_To>(__f());
> - };
> + && requires { static_cast<_To>(std::declval<_From>()); };
>
>/// [concept.commonref], concept common_reference_with
>template
> --
> 2.32.0.93.g670b81a890
>
Re: [PATCH 1/5] amdgcn: Use unsigned types for udivsi3/umodsi3 libgcc helper args/return
On 18/06/2021 15:19, Julian Brown wrote:
This patch changes the argument and return types for the libgcc __udivsi3
and __umodsi3 helper functions for GCN to USItype instead of SItype.
This is probably just cosmetic in practice.
I can probably self-approve this, but I'll give Andrew Stubbs a chance
to comment.
Thanks,
Julian
2021-06-18 Julian Brown
libgcc/
* config/gcn/lib2-divmod.c (__udivsi3, __umodsi3): Change argument and
return types to USItype.
* config/gcn/lib2-gcn.h (__udivsi3, __umodsi3): Update prototypes.
---
libgcc/config/gcn/lib2-divmod.c | 8
libgcc/config/gcn/lib2-gcn.h| 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libgcc/config/gcn/lib2-divmod.c b/libgcc/config/gcn/lib2-divmod.c
index 0d6ca44f521..7c72e24e0c3 100644
--- a/libgcc/config/gcn/lib2-divmod.c
+++ b/libgcc/config/gcn/lib2-divmod.c
@@ -102,15 +102,15 @@ __modsi3 (SItype a, SItype b)
}
-SItype
-__udivsi3 (SItype a, SItype b)
+USItype
+__udivsi3 (USItype a, USItype b)
{
return udivmodsi4 (a, b, 0);
}
-SItype
-__umodsi3 (SItype a, SItype b)
+USItype
+__umodsi3 (USItype a, USItype b)
{
return udivmodsi4 (a, b, 1);
}
diff --git a/libgcc/config/gcn/lib2-gcn.h b/libgcc/config/gcn/lib2-gcn.h
index 11476c4cda8..9223d73b8e7 100644
--- a/libgcc/config/gcn/lib2-gcn.h
+++ b/libgcc/config/gcn/lib2-gcn.h
@@ -38,8 +38,8 @@ typedef int word_type __attribute__ ((mode (__word__)));
/* Exported functions. */
extern SItype __divsi3 (SItype, SItype);
extern SItype __modsi3 (SItype, SItype);
-extern SItype __udivsi3 (SItype, SItype);
-extern SItype __umodsi3 (SItype, SItype);
+extern USItype __udivsi3 (USItype, USItype);
+extern USItype __umodsi3 (USItype, USItype);
extern HItype __divhi3 (HItype, HItype);
extern HItype __modhi3 (HItype, HItype);
extern UHItype __udivhi3 (UHItype, UHItype);
OK, this seems to match what some other targets have. Except NIOS2
though, which is probably where this file was copied from.
Andrew
[PATCH] libstdc++: Implement LWG 3557 change to convertible_to
libstdc++-v3/ChangeLog:
* include/std/concepts (convertible_to): Just use declval as per
LWG 3557.
---
libstdc++-v3/include/std/concepts | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libstdc++-v3/include/std/concepts
b/libstdc++-v3/include/std/concepts
index 4490f534412..7f5421f1475 100644
--- a/libstdc++-v3/include/std/concepts
+++ b/libstdc++-v3/include/std/concepts
@@ -70,9 +70,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
/// [concept.convertible], concept convertible_to
template
concept convertible_to = is_convertible_v<_From, _To>
- && requires(add_rvalue_reference_t<_From> (&__f)()) {
- static_cast<_To>(__f());
- };
+ && requires { static_cast<_To>(std::declval<_From>()); };
/// [concept.commonref], concept common_reference_with
template
--
2.32.0.93.g670b81a890
Re: [PATCH] Modula-2 into the GCC tree on master
Richard Biener writes: >> > I would suggest to not rush this in now during stage4 but instead >> > take the opportunity of this "quiet" phase to prepare an integration >> > branch with all the issues above sorted out which we can merge at >> > the beginning of stage1 for GCC 12 (or later during stage4 if >> > everyone is happy and/or backport for GCC 11.2 when it landed in >> > trunk). > > So as suggested above please create a public branch off trunk where you > do the integration and keep it rebased on trunk regularly. It looks > like you do not have write access to the GCC repository, please > obtain that and make yourself familiar with the repository and > branch layout. ok thanks - will do. Incidentally there is a nightly rebase automatically performed on git clone http://floppsie.comp.glam.ac.uk/gm2 combined-repro-gcc with a number of branches. git checkout remotes/origin/gm2-master obtains gcc 12, it runs about 24 hours behind gcc and the gm2 repro. I'll create a public branch on gcc.gnu.org and keep it up to date. > I see there are copyright disclaimers and assignments to the FSF > for you though for GCC I see specific changes rather than > boiler-plate "past and future changes". Fortunately we now have > a DCO in place so I suggest to make sure to annotate commits > to areas you did not assign copyright with appropriate Signed-Off-By > lines - or maybe for simplicity apply that to all commits. good idea - as you say fortunate the DCO came along - impeccable timing :-). I will use a DCO on all commits to be safe, > The SC may also have comments here. > > Basically I'd like to see the merged state accessible on a branch. > > Thanks, > Richard. regards, Gaius
Re: [PATCH 4/5] amdgcn: Enable support for TImode for AMD GCN
On 18/06/2021 15:19, Julian Brown wrote:
This patch enables support for TImode for AMD GCN, the lack of which
is currently causing a number of test failures for the target and which
is also needed to support "omp_depend_kind" for OpenMP 5.0, since that
is implemented as a 128-bit integer.
Several libgcc support routines are built by default for the "word size"
of a machine, and also for "2 * word size" of the machine. The libgcc
build for AMD GCN is changed so that it builds for a "word size" of 64
bits, in order to better match the (64-bit) host compiler. However it
isn't really true that we have 64-bit words -- GCN has 32-bit registers,
so changing UNITS_PER_WORD unconditionally would be the wrong thing to do.
Changing this setting for libgcc (only) means that support routines
are built for "single word" operations that are DImode (64 bits), and
those for "double word" operations are built for TImode (128 bits).
That leaves some gaps regarding previous operations that were built
for a "single word" size of 32 bits and a "double word" size of 64 bits
(generic code doesn't cover both alternatives for all operations that
might be needed). Those gaps are filled in by this patch, or by the
preceding patches in the series.
I can probably self-approve this, but I'll give Andrew Stubbs a chance
to comment.
Thanks,
Julian
2021-06-18 Julian Brown
gcc/
* config/gcn/gcn.c (gcn_init_libfuncs): New function.
(TARGET_INIT_LIBFUNCS): Define target hook using above function.
* config/gcn/gcn.h (UNITS_PER_WORD): Define to 8 for IN_LIBGCC2, 4
otherwise.
(LIBGCC2_UNITS_PER_WORD, BITS_PER_WORD): Remove definitions.
(MAX_FIXED_MODE_SIZE): Change to 128.
libgcc/
* config/gcn/lib2-bswapti2.c: New file.
* config/gcn/lib2-divmod-di.c: New file.
* config/gcn/lib2-gcn.h (DItype, UDItype, TItype, UTItype): Add
typedefs.
(__divdi3, __moddi3, __udivdi3, __umoddi3): Add prototypes.
* config/gcn/t-amdgcn (LIB2ADD): Add lib2-divmod-di.c and
lib2-bswapti2.c.
---
gcc/config/gcn/gcn.c | 30 +++
gcc/config/gcn/gcn.h | 11 ---
libgcc/config/gcn/lib2-bswapti2.c | 47 ++
libgcc/config/gcn/lib2-divmod-di.c | 35 ++
libgcc/config/gcn/lib2-gcn.h | 8 +
libgcc/config/gcn/t-amdgcn | 2 ++
6 files changed, 129 insertions(+), 4 deletions(-)
create mode 100644 libgcc/config/gcn/lib2-bswapti2.c
create mode 100644 libgcc/config/gcn/lib2-divmod-di.c
diff --git a/gcc/config/gcn/gcn.c b/gcc/config/gcn/gcn.c
index 283a91fe50a..45f37d5310d 100644
--- a/gcc/config/gcn/gcn.c
+++ b/gcc/config/gcn/gcn.c
@@ -3610,6 +3610,34 @@ gcn_init_builtins (void)
#endif
}
+/* Implement TARGET_INIT_LIBFUNCS. */
+
+static void
+gcn_init_libfuncs (void)
+{
+ /* BITS_PER_UNIT * 2 is 64 bits, which causes
+ optabs-libfuncs.c:gen_int_libfunc to omit TImode (i.e 128 bits)
+ libcalls that we need to support operations for that type. Initialise
+ them here instead. */
+ set_optab_libfunc (udiv_optab, TImode, "__udivti3");
+ set_optab_libfunc (umod_optab, TImode, "__umodti3");
+ set_optab_libfunc (sdiv_optab, TImode, "__divti3");
+ set_optab_libfunc (smod_optab, TImode, "__modti3");
+ set_optab_libfunc (smul_optab, TImode, "__multi3");
+ set_optab_libfunc (addv_optab, TImode, "__addvti3");
+ set_optab_libfunc (subv_optab, TImode, "__subvti3");
+ set_optab_libfunc (negv_optab, TImode, "__negvti2");
+ set_optab_libfunc (absv_optab, TImode, "__absvti2");
+ set_optab_libfunc (smulv_optab, TImode, "__mulvti3");
+ set_optab_libfunc (ffs_optab, TImode, "__ffsti2");
+ set_optab_libfunc (clz_optab, TImode, "__clzti2");
+ set_optab_libfunc (ctz_optab, TImode, "__ctzti2");
+ set_optab_libfunc (clrsb_optab, TImode, "__clrsbti2");
+ set_optab_libfunc (popcount_optab, TImode, "__popcountti2");
+ set_optab_libfunc (parity_optab, TImode, "__parityti2");
+ set_optab_libfunc (bswap_optab, TImode, "__bswapti2");
+}
+
/* Expand the CMP_SWAP GCN builtins. We have our own versions that do
not require taking the address of any object, other than the memory
cell being operated on.
@@ -6336,6 +6364,8 @@ gcn_dwarf_register_span (rtx rtl)
#define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed
#undef TARGET_INIT_BUILTINS
#define TARGET_INIT_BUILTINS gcn_init_builtins
+#undef TARGET_INIT_LIBFUNCS
+#define TARGET_INIT_LIBFUNCS gcn_init_libfuncs
#undef TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS
#define TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS \
gcn_ira_change_pseudo_allocno_class
diff --git a/gcc/config/gcn/gcn.h b/gcc/config/gcn/gcn.h
index eba4646f1bf..540835b81cc 100644
--- a/gcc/config/gcn/gcn.h
+++ b/gcc/config/gcn/gcn.h
@@ -46,9 +46,12 @@
#define BYTES_BIG_ENDIAN 0
#define WORDS_BIG_ENDIAN 0
-#define BITS_PER_WORD 32
-#define UNITS_PER_WORD (BITS_PER_WORD/BITS_PER_UNIT)
Re: [PATCH 3/5] amdgcn: Add clrsbsi2/clrsbdi2 implementation
On 18/06/2021 15:19, Julian Brown wrote:
This patch adds an open-coded implementation of the clrsb2
(count leading redundant sign bit) standard names using the GCN flbit_i*
instructions for SImode and DImode. Those don't count exactly as we need,
so we need a couple of other instructions to fix up the result afterwards.
These patterns are lost from libgcc if we build it for DImode/TImode
rather than SImode/DImode, a change we make in a later patch in this
series.
I can probably self-approve this, but I'll give Andrew Stubbs a chance
to comment.
Thanks,
Julian
2021-06-18 Julian Brown
gcc/
* config/gcn/gcn.md (UNSPEC_FLBIT_INT): New unspec constant.
(s_mnemonic): Add clrsb.
(gcn_flbit_int): Add insn pattern for SImode/DImode.
(clrsb2): Add expander for SImode/DImode.
---
gcc/config/gcn/gcn.md | 40 ++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/gcc/config/gcn/gcn.md b/gcc/config/gcn/gcn.md
index 70655ca4b8b..0fa7f86702e 100644
--- a/gcc/config/gcn/gcn.md
+++ b/gcc/config/gcn/gcn.md
@@ -81,7 +81,8 @@
UNSPEC_MOV_FROM_LANE63
UNSPEC_GATHER
UNSPEC_SCATTER
- UNSPEC_RCP])
+ UNSPEC_RCP
+ UNSPEC_FLBIT_INT])
;; }}}
;; {{{ Attributes
@@ -338,7 +339,8 @@
[(not "not%b")
(popcount "bcnt1_i32%b")
(clz "flbit_i32%b")
- (ctz "ff1_i32%b")])
+ (ctz "ff1_i32%b")
+ (clrsb "flbit_i32%i")])
(define_code_attr revmnemonic
[(minus "subrev%i")
@@ -1509,6 +1511,40 @@
[(set_attr "type" "sop1")
(set_attr "length" "4,8")])
+(define_insn "gcn_flbit_int"
+ [(set (match_operand:SI 0 "register_operand" "=Sg,Sg")
+ (unspec:SI [(match_operand:SIDI 1 "gcn_alu_operand" "SgA, B")]
+ UNSPEC_FLBIT_INT))]
+ ""
+ {
+if (mode == SImode)
+ return "s_flbit_i32\t%0, %1";
+else
+ return "s_flbit_i32_i64\t%0, %1";
+ }
+ [(set_attr "type" "sop1")
+ (set_attr "length" "4,8")])
+
+(define_expand "clrsb2"
+ [(set (match_operand:SI 0 "register_operand" "")
+ (clrsb:SI (match_operand:SIDI 1 "gcn_alu_operand" "")))]
+ ""
+ {
+rtx tmp = gen_reg_rtx (SImode);
+/* FLBIT_I* counts sign or zero bits at the most-significant end of the
+ input register (and returns -1 for 0/-1 inputs). We want the number of
+ *redundant* bits (i.e. that value minus one), and an answer of 31/63 for
+ 0/-1 inputs. We can do that in three instructions... */
+emit_insn (gen_gcn_flbit_int (tmp, operands[1]));
+emit_insn (gen_uminsi3 (tmp, tmp,
+ gen_int_mode (GET_MODE_BITSIZE (mode),
+ SImode)));
+/* If we put this last, it can potentially be folded into a subsequent
+ arithmetic operation. */
+emit_insn (gen_subsi3 (operands[0], tmp, const1_rtx));
+DONE;
+ })
+
;; }}}
;; {{{ ALU: generic 32-bit binop
OK.
Andrew
Re: [PATCH 2/5] amdgcn: Add [us]mulsi3_highpart SGPR alternatives & [us]mulsid3/muldi3 expanders
On 18/06/2021 15:19, Julian Brown wrote:
This patch improves 64-bit multiplication for AMD GCN: patterns for
unsigned and signed 32x32->64 bit multiplication have been added, and
also 64x64->64 bit multiplication is now open-coded rather than calling
a library function (which may be a win for code size as well as speed:
the function calling sequence isn't particularly concise for GCN).
The mulsi3_highpart pattern has also been extended for GCN5+, since
that ISA version supports high-part result multiply instructions with
SGPR operands.
The DImode multiply implementation is lost from libgcc if we build it
for DImode/TImode rather than SImode/DImode, a change we make in a later
patch in this series.
I can probably self-approve this, but I'll give Andrew Stubbs a chance
to comment.
Thanks,
Julian
2021-06-18 Julian Brown
gcc/
* config/gcn/gcn.md (mulsi3_highpart): Add SGPR alternatives for
GCN5+.
(mulsidi3, muldi3): Add expanders.
---
gcc/config/gcn/gcn.md | 55 ++-
1 file changed, 49 insertions(+), 6 deletions(-)
diff --git a/gcc/config/gcn/gcn.md b/gcc/config/gcn/gcn.md
index b5f895a93e2..70655ca4b8b 100644
--- a/gcc/config/gcn/gcn.md
+++ b/gcc/config/gcn/gcn.md
@@ -1392,19 +1392,62 @@
(define_code_attr e [(sign_extend "e") (zero_extend "")])
(define_insn "mulsi3_highpart"
- [(set (match_operand:SI 0 "register_operand" "= v")
+ [(set (match_operand:SI 0 "register_operand" "=Sg, Sg, v")
(truncate:SI
(lshiftrt:DI
(mult:DI
(any_extend:DI
- (match_operand:SI 1 "register_operand" "% v"))
+ (match_operand:SI 1 "register_operand" "%SgA,SgA, v"))
(any_extend:DI
- (match_operand:SI 2 "register_operand" "vSv")))
+ (match_operand:SI 2 "register_operand" "SgA, B,vSv")))
(const_int 32]
""
- "v_mul_hi0\t%0, %2, %1"
- [(set_attr "type" "vop3a")
- (set_attr "length" "8")])
+ "@
+ s_mul_hi0\t%0, %1, %2
+ s_mul_hi0\t%0, %1, %2
+ v_mul_hi0\t%0, %2, %1"
+ [(set_attr "type" "sop2,sop2,vop3a")
+ (set_attr "length" "4,8,8")
+ (set_attr "gcn_version" "gcn5,gcn5,*")])
+
+(define_expand "mulsidi3"
+ [(set (match_operand:DI 0 "register_operand" "")
+ (mult:DI
+ (any_extend:DI (match_operand:SI 1 "register_operand" ""))
+ (any_extend:DI (match_operand:SI 2 "register_operand" ""]
+ ""
+ {
+rtx dst = gen_reg_rtx (DImode);
+rtx dstlo = gen_lowpart (SImode, dst);
+rtx dsthi = gen_highpart_mode (SImode, DImode, dst);
+emit_insn (gen_mulsi3 (dstlo, operands[1], operands[2]));
+emit_insn (gen_mulsi3_highpart (dsthi, operands[1], operands[2]));
+emit_move_insn (operands[0], dst);
+DONE;
+ })
+
+(define_expand "muldi3"
+ [(set (match_operand:DI 0 "register_operand" "")
+ (mult:DI (match_operand:DI 1 "register_operand" "")
+(match_operand:DI 2 "register_operand" "")))]
+ ""
+ {
+rtx tmp0 = gen_reg_rtx (SImode);
+rtx tmp1 = gen_reg_rtx (SImode);
+rtx dst = gen_reg_rtx (DImode);
+rtx dsthi = gen_highpart_mode (SImode, DImode, dst);
+rtx op1lo = gen_lowpart (SImode, operands[1]);
+rtx op1hi = gen_highpart_mode (SImode, DImode, operands[1]);
+rtx op2lo = gen_lowpart (SImode, operands[2]);
+rtx op2hi = gen_highpart_mode (SImode, DImode, operands[2]);
+emit_insn (gen_umulsidi3 (dst, op1lo, op2lo));
+emit_insn (gen_mulsi3 (tmp0, op1lo, op2hi));
+emit_insn (gen_addsi3 (dsthi, dsthi, tmp0));
+emit_insn (gen_mulsi3 (tmp1, op1hi, op2lo));
+emit_insn (gen_addsi3 (dsthi, dsthi, tmp1));
+emit_move_insn (operands[0], dst);
+DONE;
+ })
(define_insn "mulhisi3"
[(set (match_operand:SI 0 "register_operand" "=v")
Most of the rest of the backend expands 64-bit operations to 32-bit
pairs much later, using define_insn_and_split, because there were lots
of issues with splitting it early. I don't recall exactly what right
now, unfortunately. (It might have been related to spilling only half
the value to the stack?) It also makes it hard to debug, I think.
Andrew
[PATCH, OpenMP 5.0] Improve OpenMP target support for C++ [PR92120 v4]
Hi Jakub,
this patch is the "v4" version of my PR92120 patch, v3 was here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570886.html
(there I listed the various patches from devel/omp/gcc-10 branch that was
combined,
which I won't repeat here).
Basically this v4 adds fixes for lambda capture, which was already pushed to
devel/omp/gcc-11 yesterday:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572988.html
I have attached both the combined v4 version, and the v3-to-v4 diff.
Tested on x86_64-linux with nvptx offloading, seeking for approval to trunk.
Thanks,
Chung-Lin
gcc/cp/
* cp-tree.h (finish_omp_target): New declaration.
(finish_omp_target_clauses): Likewise.
* parser.c (cp_parser_omp_clause_map): Adjust call to
cp_parser_omp_var_list_no_open to set 'allow_deref' argument to true.
(cp_parser_omp_target): Factor out code, adjust into calls to new
function finish_omp_target.
* pt.c (tsubst_expr): Add call to finish_omp_target_clauses for
OMP_TARGET case.
* semantics.c (handle_omp_array_sections_1): Add handling to create
'this->member' from 'member' FIELD_DECL.
(handle_omp_array_sections): Likewise.
(finish_omp_clauses): Likewise. Adjust to allow 'this[]' in OpenMP
map clauses. Handle 'A->member' case in map clauses.
(struct omp_target_walk_data): New struct for walking over
target-directive tree body.
(finish_omp_target_clauses_r): New function for tree walk.
(finish_omp_target_clauses): New function.
(finish_omp_target): New function.
gcc/c/
* c-parser.c (c_parser_omp_clause_map): Set 'allow_deref' argument in
call to c_parser_omp_variable_list to 'true'.
* c-typeck.c (handle_omp_array_sections_1): Add strip of MEM_REF in
array base handling.
(c_finish_omp_clauses): Handle 'A->member' case in map clauses.
gcc/
* gimplify.c ("tree-hash-traits.h"): Add include.
(gimplify_scan_omp_clauses): Change struct_map_to_clause to type
hash_map *. Adjust struct map handling to handle
cases of *A and A->B expressions. Under !DECL_P case of
GOMP_CLAUSE_MAP handling, add STRIP_NOPS for indir_p case, add to
struct_deref_set for map(*ptr_to_struct) cases. Add MEM_REF case when
handling component_ref_p case. Add unshare_expr and gimplification
when created GOMP_MAP_STRUCT is not a DECL. Add code to add
firstprivate pointer for *pointer-to-struct case.
(gimplify_adjust_omp_clauses): Move GOMP_MAP_STRUCT removal code for
exit data directives code to earlier position.
* omp-low.c (lower_omp_target):
Handle GOMP_MAP_ATTACH_ZERO_LENGTH_ARRAY_SECTION, and
GOMP_MAP_POINTER_TO_ZERO_LENGTH_ARRAY_SECTION map kinds.
* tree-pretty-print.c (dump_omp_clause): Likewise.
gcc/testsuite/
* gcc.dg/gomp/target-3.c: New testcase.
* g++.dg/gomp/target-3.C: New testcase.
* g++.dg/gomp/target-lambda-1.C: New testcase.
* g++.dg/gomp/target-lambda-2.C: New testcase.
* g++.dg/gomp/target-this-1.C: New testcase.
* g++.dg/gomp/target-this-2.C: New testcase.
* g++.dg/gomp/target-this-3.C: New testcase.
* g++.dg/gomp/target-this-4.C: New testcase.
* g++.dg/gomp/target-this-5.C: New testcase.
* g++.dg/gomp/this-2.C: Adjust testcase.
include/
* gomp-constants.h (enum gomp_map_kind):
Add GOMP_MAP_ATTACH_ZERO_LENGTH_ARRAY_SECTION, and
GOMP_MAP_POINTER_TO_ZERO_LENGTH_ARRAY_SECTION map kinds.
(GOMP_MAP_POINTER_P):
Include GOMP_MAP_POINTER_TO_ZERO_LENGTH_ARRAY_SECTION.
libgomp/
* libgomp.h (gomp_attach_pointer): Add bool parameter.
* oacc-mem.c (acc_attach_async): Update call to gomp_attach_pointer.
(goacc_enter_data_internal): Likewise.
* target.c (gomp_map_vars_existing): Update assert condition to
include GOMP_MAP_ATTACH_ZERO_LENGTH_ARRAY_SECTION.
(gomp_map_pointer): Add 'bool allow_zero_length_array_sections'
parameter, add support for mapping a pointer with NULL target.
(gomp_attach_pointer): Add 'bool allow_zero_length_array_sections'
parameter, add support for attaching a pointer with NULL target.
(gomp_map_vars_internal): Update calls to gomp_map_pointer and
gomp_attach_pointer, add handling for
GOMP_MAP_ATTACH_ZERO_LENGTH_ARRAY_SECTION, and
GOMP_MAP_POINTER_TO_ZERO_LENGTH_ARRAY_SECTION cases.
* testsuite/libgomp.c++/target-23.C: New testcase.
* testsuite/libgomp.c++/target-lambda-1.C: New testcase.
* testsuite/libgomp.c++/target-lambda-2.C: New testcase.
* testsuite/libgomp.c++/target-this-1.C: New testcase.
* testsuite/libgomp.c++/target-this-2.C: New testcase.
* testsuite/libgomp.c++/target-this-3.C: New
Re: [PATCH] tree-optimization/101120 - fix compile-time issue with SLP groups
On Fri, Jun 18, 2021 at 2:23 PM Richard Biener wrote: > > This places two hacks to avoid an old compile-time issue when > vectorizing large permuted SLP groups with gaps where we end up > emitting loads and IV adjustments for the gap as well and those > have quite a high cost until they are eventually cleaned up. > > The first hack is to fold the auto-inc style IV updates early > in the vectorizer rather than in the next forwprop pass which > shortens the SSA use-def chains of the used IV. > > The second hack is to remove the unused loads after we've picked > all that we possibly use. > > Bootstrap / regtest running on x86_64-unknown-linux-gnu. > > I wonder if this is too gross (and I have to check the one or two > bug duplicates), but it should be at least easy to backport ... Was apparently too simple - the following passes bootstrap and regtest. Richard. p Description: Binary data
[PATCH 5/5] Fortran: Re-enable 128-bit integers for AMD GCN
This patch reverts the part of Tobias's patch for PR target/96306 that
disables 128-bit integer support for AMD GCN.
OK for mainline (assuming the previous patches are in first)?
Thanks,
Julian
2021-06-18 Julian Brown
libgfortran/
PR target/96306
* configure.ac: Remove stanza that removes KIND=16 integers for AMD GCN.
* configure: Regenerate.
---
libgfortran/configure| 22 --
libgfortran/configure.ac | 4
2 files changed, 4 insertions(+), 22 deletions(-)
diff --git a/libgfortran/configure b/libgfortran/configure
index f3634389cf8..886216f69d4 100755
--- a/libgfortran/configure
+++ b/libgfortran/configure
@@ -6017,7 +6017,7 @@ case "$host" in
case "$enable_cet" in
auto)
# Check if target supports multi-byte NOPs
- # and if assembler supports CET insn.
+ # and if compiler and assembler support CET insn.
cet_save_CFLAGS="$CFLAGS"
CFLAGS="$CFLAGS -fcf-protection"
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -6216,10 +6216,6 @@ fi
LIBGOMP_CHECKED_INT_KINDS="1 2 4 8 16"
LIBGOMP_CHECKED_REAL_KINDS="4 8 10 16"
-if test "x${target_cpu}" = xamdgcn; then
- # amdgcn only has limited support for __int128.
- LIBGOMP_CHECKED_INT_KINDS="1 2 4 8"
-fi
@@ -12731,7 +12727,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 12744 "configure"
+#line 12730 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
@@ -12837,7 +12833,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 12850 "configure"
+#line 12836 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
@@ -15532,16 +15528,6 @@ freebsd* | dragonfly*)
esac
;;
-gnu*)
- version_type=linux
- need_lib_prefix=no
- need_version=no
- library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}${major} ${libname}${shared_ext}'
- soname_spec='${libname}${release}${shared_ext}$major'
- shlibpath_var=LD_LIBRARY_PATH
- hardcode_into_libs=yes
- ;;
-
haiku*)
version_type=linux
need_lib_prefix=no
@@ -15663,7 +15649,7 @@ linux*oldld* | linux*aout* | linux*coff*)
# project, but have not yet been accepted: they are GCC-local changes
# for the time being. (See
# https://lists.gnu.org/archive/html/libtool-patches/2018-05/msg0.html)
-linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinuxfdpiceabi)
+linux* | k*bsd*-gnu | kopensolaris*-gnu | gnu* | uclinuxfdpiceabi)
version_type=linux
need_lib_prefix=no
need_version=no
diff --git a/libgfortran/configure.ac b/libgfortran/configure.ac
index 8961e314d82..523eb24bca1 100644
--- a/libgfortran/configure.ac
+++ b/libgfortran/configure.ac
@@ -222,10 +222,6 @@ AM_CONDITIONAL(LIBGFOR_MINIMAL, [test "x${target_cpu}" =
xnvptx])
LIBGOMP_CHECKED_INT_KINDS="1 2 4 8 16"
LIBGOMP_CHECKED_REAL_KINDS="4 8 10 16"
-if test "x${target_cpu}" = xamdgcn; then
- # amdgcn only has limited support for __int128.
- LIBGOMP_CHECKED_INT_KINDS="1 2 4 8"
-fi
AC_SUBST(LIBGOMP_CHECKED_INT_KINDS)
AC_SUBST(LIBGOMP_CHECKED_REAL_KINDS)
--
2.29.2
[PATCH 4/5] amdgcn: Enable support for TImode for AMD GCN
This patch enables support for TImode for AMD GCN, the lack of which
is currently causing a number of test failures for the target and which
is also needed to support "omp_depend_kind" for OpenMP 5.0, since that
is implemented as a 128-bit integer.
Several libgcc support routines are built by default for the "word size"
of a machine, and also for "2 * word size" of the machine. The libgcc
build for AMD GCN is changed so that it builds for a "word size" of 64
bits, in order to better match the (64-bit) host compiler. However it
isn't really true that we have 64-bit words -- GCN has 32-bit registers,
so changing UNITS_PER_WORD unconditionally would be the wrong thing to do.
Changing this setting for libgcc (only) means that support routines
are built for "single word" operations that are DImode (64 bits), and
those for "double word" operations are built for TImode (128 bits).
That leaves some gaps regarding previous operations that were built
for a "single word" size of 32 bits and a "double word" size of 64 bits
(generic code doesn't cover both alternatives for all operations that
might be needed). Those gaps are filled in by this patch, or by the
preceding patches in the series.
I can probably self-approve this, but I'll give Andrew Stubbs a chance
to comment.
Thanks,
Julian
2021-06-18 Julian Brown
gcc/
* config/gcn/gcn.c (gcn_init_libfuncs): New function.
(TARGET_INIT_LIBFUNCS): Define target hook using above function.
* config/gcn/gcn.h (UNITS_PER_WORD): Define to 8 for IN_LIBGCC2, 4
otherwise.
(LIBGCC2_UNITS_PER_WORD, BITS_PER_WORD): Remove definitions.
(MAX_FIXED_MODE_SIZE): Change to 128.
libgcc/
* config/gcn/lib2-bswapti2.c: New file.
* config/gcn/lib2-divmod-di.c: New file.
* config/gcn/lib2-gcn.h (DItype, UDItype, TItype, UTItype): Add
typedefs.
(__divdi3, __moddi3, __udivdi3, __umoddi3): Add prototypes.
* config/gcn/t-amdgcn (LIB2ADD): Add lib2-divmod-di.c and
lib2-bswapti2.c.
---
gcc/config/gcn/gcn.c | 30 +++
gcc/config/gcn/gcn.h | 11 ---
libgcc/config/gcn/lib2-bswapti2.c | 47 ++
libgcc/config/gcn/lib2-divmod-di.c | 35 ++
libgcc/config/gcn/lib2-gcn.h | 8 +
libgcc/config/gcn/t-amdgcn | 2 ++
6 files changed, 129 insertions(+), 4 deletions(-)
create mode 100644 libgcc/config/gcn/lib2-bswapti2.c
create mode 100644 libgcc/config/gcn/lib2-divmod-di.c
diff --git a/gcc/config/gcn/gcn.c b/gcc/config/gcn/gcn.c
index 283a91fe50a..45f37d5310d 100644
--- a/gcc/config/gcn/gcn.c
+++ b/gcc/config/gcn/gcn.c
@@ -3610,6 +3610,34 @@ gcn_init_builtins (void)
#endif
}
+/* Implement TARGET_INIT_LIBFUNCS. */
+
+static void
+gcn_init_libfuncs (void)
+{
+ /* BITS_PER_UNIT * 2 is 64 bits, which causes
+ optabs-libfuncs.c:gen_int_libfunc to omit TImode (i.e 128 bits)
+ libcalls that we need to support operations for that type. Initialise
+ them here instead. */
+ set_optab_libfunc (udiv_optab, TImode, "__udivti3");
+ set_optab_libfunc (umod_optab, TImode, "__umodti3");
+ set_optab_libfunc (sdiv_optab, TImode, "__divti3");
+ set_optab_libfunc (smod_optab, TImode, "__modti3");
+ set_optab_libfunc (smul_optab, TImode, "__multi3");
+ set_optab_libfunc (addv_optab, TImode, "__addvti3");
+ set_optab_libfunc (subv_optab, TImode, "__subvti3");
+ set_optab_libfunc (negv_optab, TImode, "__negvti2");
+ set_optab_libfunc (absv_optab, TImode, "__absvti2");
+ set_optab_libfunc (smulv_optab, TImode, "__mulvti3");
+ set_optab_libfunc (ffs_optab, TImode, "__ffsti2");
+ set_optab_libfunc (clz_optab, TImode, "__clzti2");
+ set_optab_libfunc (ctz_optab, TImode, "__ctzti2");
+ set_optab_libfunc (clrsb_optab, TImode, "__clrsbti2");
+ set_optab_libfunc (popcount_optab, TImode, "__popcountti2");
+ set_optab_libfunc (parity_optab, TImode, "__parityti2");
+ set_optab_libfunc (bswap_optab, TImode, "__bswapti2");
+}
+
/* Expand the CMP_SWAP GCN builtins. We have our own versions that do
not require taking the address of any object, other than the memory
cell being operated on.
@@ -6336,6 +6364,8 @@ gcn_dwarf_register_span (rtx rtl)
#define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed
#undef TARGET_INIT_BUILTINS
#define TARGET_INIT_BUILTINS gcn_init_builtins
+#undef TARGET_INIT_LIBFUNCS
+#define TARGET_INIT_LIBFUNCS gcn_init_libfuncs
#undef TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS
#define TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS \
gcn_ira_change_pseudo_allocno_class
diff --git a/gcc/config/gcn/gcn.h b/gcc/config/gcn/gcn.h
index eba4646f1bf..540835b81cc 100644
--- a/gcc/config/gcn/gcn.h
+++ b/gcc/config/gcn/gcn.h
@@ -46,9 +46,12 @@
#define BYTES_BIG_ENDIAN 0
#define WORDS_BIG_ENDIAN 0
-#define BITS_PER_WORD 32
-#define UNITS_PER_WORD (BITS_PER_WORD/BITS_PER_UNIT)
-#define LIBGCC2_UNITS_PER_WORD 4
+#ifdef IN_LIBGCC2
+/* We want
[PATCH 3/5] amdgcn: Add clrsbsi2/clrsbdi2 implementation
This patch adds an open-coded implementation of the clrsb2
(count leading redundant sign bit) standard names using the GCN flbit_i*
instructions for SImode and DImode. Those don't count exactly as we need,
so we need a couple of other instructions to fix up the result afterwards.
These patterns are lost from libgcc if we build it for DImode/TImode
rather than SImode/DImode, a change we make in a later patch in this
series.
I can probably self-approve this, but I'll give Andrew Stubbs a chance
to comment.
Thanks,
Julian
2021-06-18 Julian Brown
gcc/
* config/gcn/gcn.md (UNSPEC_FLBIT_INT): New unspec constant.
(s_mnemonic): Add clrsb.
(gcn_flbit_int): Add insn pattern for SImode/DImode.
(clrsb2): Add expander for SImode/DImode.
---
gcc/config/gcn/gcn.md | 40 ++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/gcc/config/gcn/gcn.md b/gcc/config/gcn/gcn.md
index 70655ca4b8b..0fa7f86702e 100644
--- a/gcc/config/gcn/gcn.md
+++ b/gcc/config/gcn/gcn.md
@@ -81,7 +81,8 @@
UNSPEC_MOV_FROM_LANE63
UNSPEC_GATHER
UNSPEC_SCATTER
- UNSPEC_RCP])
+ UNSPEC_RCP
+ UNSPEC_FLBIT_INT])
;; }}}
;; {{{ Attributes
@@ -338,7 +339,8 @@
[(not "not%b")
(popcount "bcnt1_i32%b")
(clz "flbit_i32%b")
- (ctz "ff1_i32%b")])
+ (ctz "ff1_i32%b")
+ (clrsb "flbit_i32%i")])
(define_code_attr revmnemonic
[(minus "subrev%i")
@@ -1509,6 +1511,40 @@
[(set_attr "type" "sop1")
(set_attr "length" "4,8")])
+(define_insn "gcn_flbit_int"
+ [(set (match_operand:SI 0 "register_operand" "=Sg,Sg")
+ (unspec:SI [(match_operand:SIDI 1 "gcn_alu_operand" "SgA, B")]
+ UNSPEC_FLBIT_INT))]
+ ""
+ {
+if (mode == SImode)
+ return "s_flbit_i32\t%0, %1";
+else
+ return "s_flbit_i32_i64\t%0, %1";
+ }
+ [(set_attr "type" "sop1")
+ (set_attr "length" "4,8")])
+
+(define_expand "clrsb2"
+ [(set (match_operand:SI 0 "register_operand" "")
+ (clrsb:SI (match_operand:SIDI 1 "gcn_alu_operand" "")))]
+ ""
+ {
+rtx tmp = gen_reg_rtx (SImode);
+/* FLBIT_I* counts sign or zero bits at the most-significant end of the
+ input register (and returns -1 for 0/-1 inputs). We want the number of
+ *redundant* bits (i.e. that value minus one), and an answer of 31/63 for
+ 0/-1 inputs. We can do that in three instructions... */
+emit_insn (gen_gcn_flbit_int (tmp, operands[1]));
+emit_insn (gen_uminsi3 (tmp, tmp,
+ gen_int_mode (GET_MODE_BITSIZE (mode),
+ SImode)));
+/* If we put this last, it can potentially be folded into a subsequent
+ arithmetic operation. */
+emit_insn (gen_subsi3 (operands[0], tmp, const1_rtx));
+DONE;
+ })
+
;; }}}
;; {{{ ALU: generic 32-bit binop
--
2.29.2
[PATCH 2/5] amdgcn: Add [us]mulsi3_highpart SGPR alternatives & [us]mulsid3/muldi3 expanders
This patch improves 64-bit multiplication for AMD GCN: patterns for
unsigned and signed 32x32->64 bit multiplication have been added, and
also 64x64->64 bit multiplication is now open-coded rather than calling
a library function (which may be a win for code size as well as speed:
the function calling sequence isn't particularly concise for GCN).
The mulsi3_highpart pattern has also been extended for GCN5+, since
that ISA version supports high-part result multiply instructions with
SGPR operands.
The DImode multiply implementation is lost from libgcc if we build it
for DImode/TImode rather than SImode/DImode, a change we make in a later
patch in this series.
I can probably self-approve this, but I'll give Andrew Stubbs a chance
to comment.
Thanks,
Julian
2021-06-18 Julian Brown
gcc/
* config/gcn/gcn.md (mulsi3_highpart): Add SGPR alternatives for
GCN5+.
(mulsidi3, muldi3): Add expanders.
---
gcc/config/gcn/gcn.md | 55 ++-
1 file changed, 49 insertions(+), 6 deletions(-)
diff --git a/gcc/config/gcn/gcn.md b/gcc/config/gcn/gcn.md
index b5f895a93e2..70655ca4b8b 100644
--- a/gcc/config/gcn/gcn.md
+++ b/gcc/config/gcn/gcn.md
@@ -1392,19 +1392,62 @@
(define_code_attr e [(sign_extend "e") (zero_extend "")])
(define_insn "mulsi3_highpart"
- [(set (match_operand:SI 0 "register_operand""= v")
+ [(set (match_operand:SI 0 "register_operand" "=Sg, Sg, v")
(truncate:SI
(lshiftrt:DI
(mult:DI
(any_extend:DI
- (match_operand:SI 1 "register_operand" "% v"))
+ (match_operand:SI 1 "register_operand" "%SgA,SgA, v"))
(any_extend:DI
- (match_operand:SI 2 "register_operand" "vSv")))
+ (match_operand:SI 2 "register_operand" "SgA, B,vSv")))
(const_int 32]
""
- "v_mul_hi0\t%0, %2, %1"
- [(set_attr "type" "vop3a")
- (set_attr "length" "8")])
+ "@
+ s_mul_hi0\t%0, %1, %2
+ s_mul_hi0\t%0, %1, %2
+ v_mul_hi0\t%0, %2, %1"
+ [(set_attr "type" "sop2,sop2,vop3a")
+ (set_attr "length" "4,8,8")
+ (set_attr "gcn_version" "gcn5,gcn5,*")])
+
+(define_expand "mulsidi3"
+ [(set (match_operand:DI 0 "register_operand" "")
+ (mult:DI
+ (any_extend:DI (match_operand:SI 1 "register_operand" ""))
+ (any_extend:DI (match_operand:SI 2 "register_operand" ""]
+ ""
+ {
+rtx dst = gen_reg_rtx (DImode);
+rtx dstlo = gen_lowpart (SImode, dst);
+rtx dsthi = gen_highpart_mode (SImode, DImode, dst);
+emit_insn (gen_mulsi3 (dstlo, operands[1], operands[2]));
+emit_insn (gen_mulsi3_highpart (dsthi, operands[1], operands[2]));
+emit_move_insn (operands[0], dst);
+DONE;
+ })
+
+(define_expand "muldi3"
+ [(set (match_operand:DI 0 "register_operand" "")
+ (mult:DI (match_operand:DI 1 "register_operand" "")
+(match_operand:DI 2 "register_operand" "")))]
+ ""
+ {
+rtx tmp0 = gen_reg_rtx (SImode);
+rtx tmp1 = gen_reg_rtx (SImode);
+rtx dst = gen_reg_rtx (DImode);
+rtx dsthi = gen_highpart_mode (SImode, DImode, dst);
+rtx op1lo = gen_lowpart (SImode, operands[1]);
+rtx op1hi = gen_highpart_mode (SImode, DImode, operands[1]);
+rtx op2lo = gen_lowpart (SImode, operands[2]);
+rtx op2hi = gen_highpart_mode (SImode, DImode, operands[2]);
+emit_insn (gen_umulsidi3 (dst, op1lo, op2lo));
+emit_insn (gen_mulsi3 (tmp0, op1lo, op2hi));
+emit_insn (gen_addsi3 (dsthi, dsthi, tmp0));
+emit_insn (gen_mulsi3 (tmp1, op1hi, op2lo));
+emit_insn (gen_addsi3 (dsthi, dsthi, tmp1));
+emit_move_insn (operands[0], dst);
+DONE;
+ })
(define_insn "mulhisi3"
[(set (match_operand:SI 0 "register_operand" "=v")
--
2.29.2
[PATCH 1/5] amdgcn: Use unsigned types for udivsi3/umodsi3 libgcc helper args/return
This patch changes the argument and return types for the libgcc __udivsi3
and __umodsi3 helper functions for GCN to USItype instead of SItype.
This is probably just cosmetic in practice.
I can probably self-approve this, but I'll give Andrew Stubbs a chance
to comment.
Thanks,
Julian
2021-06-18 Julian Brown
libgcc/
* config/gcn/lib2-divmod.c (__udivsi3, __umodsi3): Change argument and
return types to USItype.
* config/gcn/lib2-gcn.h (__udivsi3, __umodsi3): Update prototypes.
---
libgcc/config/gcn/lib2-divmod.c | 8
libgcc/config/gcn/lib2-gcn.h| 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libgcc/config/gcn/lib2-divmod.c b/libgcc/config/gcn/lib2-divmod.c
index 0d6ca44f521..7c72e24e0c3 100644
--- a/libgcc/config/gcn/lib2-divmod.c
+++ b/libgcc/config/gcn/lib2-divmod.c
@@ -102,15 +102,15 @@ __modsi3 (SItype a, SItype b)
}
-SItype
-__udivsi3 (SItype a, SItype b)
+USItype
+__udivsi3 (USItype a, USItype b)
{
return udivmodsi4 (a, b, 0);
}
-SItype
-__umodsi3 (SItype a, SItype b)
+USItype
+__umodsi3 (USItype a, USItype b)
{
return udivmodsi4 (a, b, 1);
}
diff --git a/libgcc/config/gcn/lib2-gcn.h b/libgcc/config/gcn/lib2-gcn.h
index 11476c4cda8..9223d73b8e7 100644
--- a/libgcc/config/gcn/lib2-gcn.h
+++ b/libgcc/config/gcn/lib2-gcn.h
@@ -38,8 +38,8 @@ typedef int word_type __attribute__ ((mode (__word__)));
/* Exported functions. */
extern SItype __divsi3 (SItype, SItype);
extern SItype __modsi3 (SItype, SItype);
-extern SItype __udivsi3 (SItype, SItype);
-extern SItype __umodsi3 (SItype, SItype);
+extern USItype __udivsi3 (USItype, USItype);
+extern USItype __umodsi3 (USItype, USItype);
extern HItype __divhi3 (HItype, HItype);
extern HItype __modhi3 (HItype, HItype);
extern UHItype __udivhi3 (UHItype, UHItype);
--
2.29.2
[PATCH 0/5] amdgcn: Improve TImode support
This patch series extends TImode support for AMD GCN (see e.g. PR96306 and PR95730). This fixes several test failures that appear at present, and enables use of a 128-bit integer "omp_depend_kind" for OpenMP 5.0. Tested with offloading to AMD GCN. Further commentary on invididual patches. Thanks, Julian Julian Brown (5): amdgcn: Use unsigned types for udivsi3/umodsi3 libgcc helper args/return amdgcn: Add [us]mulsi3_highpart SGPR alternatives & [us]mulsid3/muldi3 expanders amdgcn: Add clrsbsi2/clrsbdi2 implementation amdgcn: Enable support for TImode for AMD GCN Fortran: Re-enable 128-bit integers for AMD GCN gcc/config/gcn/gcn.c | 30 ++ gcc/config/gcn/gcn.h | 11 ++-- gcc/config/gcn/gcn.md | 95 +++--- libgcc/config/gcn/lib2-bswapti2.c | 47 +++ libgcc/config/gcn/lib2-divmod-di.c | 35 +++ libgcc/config/gcn/lib2-divmod.c| 8 +-- libgcc/config/gcn/lib2-gcn.h | 12 +++- libgcc/config/gcn/t-amdgcn | 2 + libgfortran/configure | 22 ++- libgfortran/configure.ac | 4 -- 10 files changed, 226 insertions(+), 40 deletions(-) create mode 100644 libgcc/config/gcn/lib2-bswapti2.c create mode 100644 libgcc/config/gcn/lib2-divmod-di.c -- 2.29.2
[committed] libstdc++: Replace incorrect static assertion in std::reduce [PR95833]
The standard does not require the iterator's value type to be
convertible to the result type, it only requires that the result of
dereferencing the iterator can be passed to the binary function.
libstdc++-v3/ChangeLog:
PR libstdc++/95833
* include/std/numeric (reduce(Iter, Iter, T, BinaryOp)): Replace
incorrect static_assert with ones matching the 'Mandates'
conditions in the standard.
* testsuite/26_numerics/reduce/95833.cc: New test.
Tested powerpc64le-linux. Committed to trunk. Backports will follow.
commit 0532452dcd17910dfd3d2b0df50dfe3ef1194bf7
Author: Jonathan Wakely
Date: Fri Jun 18 14:46:58 2021
libstdc++: Replace incorrect static assertion in std::reduce [PR95833]
The standard does not require the iterator's value type to be
convertible to the result type, it only requires that the result of
dereferencing the iterator can be passed to the binary function.
libstdc++-v3/ChangeLog:
PR libstdc++/95833
* include/std/numeric (reduce(Iter, Iter, T, BinaryOp)): Replace
incorrect static_assert with ones matching the 'Mandates'
conditions in the standard.
* testsuite/26_numerics/reduce/95833.cc: New test.
diff --git a/libstdc++-v3/include/std/numeric b/libstdc++-v3/include/std/numeric
index f36c1f96b2e..2ab337a0f3a 100644
--- a/libstdc++-v3/include/std/numeric
+++ b/libstdc++-v3/include/std/numeric
@@ -278,9 +278,11 @@ namespace __detail
reduce(_InputIterator __first, _InputIterator __last, _Tp __init,
_BinaryOperation __binary_op)
{
- using value_type = typename iterator_traits<_InputIterator>::value_type;
+ using __ref = typename iterator_traits<_InputIterator>::reference;
+ static_assert(is_invocable_r_v<_Tp, _BinaryOperation&, _Tp&, __ref>);
+ static_assert(is_invocable_r_v<_Tp, _BinaryOperation&, __ref, _Tp&>);
static_assert(is_invocable_r_v<_Tp, _BinaryOperation&, _Tp&, _Tp&>);
- static_assert(is_convertible_v);
+ static_assert(is_invocable_r_v<_Tp, _BinaryOperation&, __ref, __ref>);
if constexpr (__is_random_access_iter<_InputIterator>::value)
{
while ((__last - __first) >= 4)
diff --git a/libstdc++-v3/testsuite/26_numerics/reduce/95833.cc
b/libstdc++-v3/testsuite/26_numerics/reduce/95833.cc
new file mode 100644
index 000..cf4644f53c9
--- /dev/null
+++ b/libstdc++-v3/testsuite/26_numerics/reduce/95833.cc
@@ -0,0 +1,16 @@
+// { dg-do compile { target c++17 } }
+// PR libstdc++/95833 - Incorrect static_assert in std::reduce overload
+
+#include
+
+struct A { };
+struct B { };
+
+struct binop
+{
+ template
+A operator()(T&&, U&&) const { return A{}; }
+};
+
+B b;
+A a = std::reduce(, + 1, A{}, binop{});
Re: [PATCH] Modula-2 into the GCC tree on master
On Fri, Jun 18, 2021 at 12:52:41PM +0200, Richard Biener wrote: > So as suggested above please create a public branch off trunk where you > do the integration and keep it rebased on trunk regularly. It looks > like you do not have write access to the GCC repository, please > obtain that and make yourself familiar with the repository and > branch layout. I've pushed a branch with the patches in the first post in this thread to users/segher/heads/gm2 . Maybe it can help; I'll delete it to reduce confusion when something more official shows up :-) > I see there are copyright disclaimers and assignments to the FSF > for you though for GCC I see specific changes rather than > boiler-plate "past and future changes". Fortunately we now have > a DCO in place so I suggest to make sure to annotate commits > to areas you did not assign copyright with appropriate Signed-Off-By > lines - or maybe for simplicity apply that to all commits. It is spelled Signed-off-by: (one capital only). Segher
Re: [PATCH] Modula-2 into the GCC tree on master
Hi Gaius, On Thu, Jun 17, 2021 at 11:26:41PM +0100, Gaius Mulley via Gcc-patches wrote: > here are a set of patches which merge the gm2 front end into the > GCC tree. I have looked through the patches in this email, and they all look good too me. (There are a few warnings about whitespace from "git am", I haven't looked if those are from your code, or auto-generated). > The patches have been bootstrapped under aarch64 GNU/Linux > Debian Stretch using make -j 4, x86_64 GNU/Linux Debian Stretch built > using make -j 24 and also under x86_64 GNU/Linux Debian Buster using > make -j 4. I am building it on powerpc64-linux (-m32,-m64) and poweerpc64le-linux currently. (All CentOS 7 fwiw). It does not want to build gm2tools, haven't investigated that yet either. Will report results later. Thanks for your persistence! Segher
[PATCH] tree-optimization/101120 - fix compile-time issue with SLP groups
This places two hacks to avoid an old compile-time issue when
vectorizing large permuted SLP groups with gaps where we end up
emitting loads and IV adjustments for the gap as well and those
have quite a high cost until they are eventually cleaned up.
The first hack is to fold the auto-inc style IV updates early
in the vectorizer rather than in the next forwprop pass which
shortens the SSA use-def chains of the used IV.
The second hack is to remove the unused loads after we've picked
all that we possibly use.
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
I wonder if this is too gross (and I have to check the one or two
bug duplicates), but it should be at least easy to backport ...
Thanks,
Richard.
2021-06-18 Richard Biener
PR tree-optimization/101120
* tree-vect-data-refs.c (bump_vector_ptr): Fold the
built increment.
* tree-vect-stmts.c (vectorizable_load): Remove unused
loads in the DR chain for SLP.
---
gcc/tree-vect-data-refs.c | 12 +++-
gcc/tree-vect-stmts.c | 12
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
index bb086c6ac1c..be067c8923b 100644
--- a/gcc/tree-vect-data-refs.c
+++ b/gcc/tree-vect-data-refs.c
@@ -53,6 +53,7 @@ along with GCC; see the file COPYING3. If not see
#include "tree-hash-traits.h"
#include "vec-perm-indices.h"
#include "internal-fn.h"
+#include "gimple-fold.h"
/* Return true if load- or store-lanes optab OPTAB is implemented for
COUNT vectors of type VECTYPE. NAME is the name of OPTAB. */
@@ -5026,7 +5027,7 @@ bump_vector_ptr (vec_info *vinfo,
struct data_reference *dr = STMT_VINFO_DATA_REF (stmt_info);
tree vectype = STMT_VINFO_VECTYPE (stmt_info);
tree update = TYPE_SIZE_UNIT (vectype);
- gassign *incr_stmt;
+ gimple *incr_stmt;
ssa_op_iter iter;
use_operand_p use_p;
tree new_dataref_ptr;
@@ -5041,6 +5042,15 @@ bump_vector_ptr (vec_info *vinfo,
incr_stmt = gimple_build_assign (new_dataref_ptr, POINTER_PLUS_EXPR,
dataref_ptr, update);
vect_finish_stmt_generation (vinfo, stmt_info, incr_stmt, gsi);
+ /* Fold the increment, avoiding excessive chains use-def chains of
+ those, leading to compile-time issues for passes until the next
+ forwprop pass which would do this as well. */
+ gimple_stmt_iterator fold_gsi = gsi_for_stmt (incr_stmt);
+ if (fold_stmt (_gsi, follow_all_ssa_edges))
+{
+ incr_stmt = gsi_stmt (fold_gsi);
+ update_stmt (incr_stmt);
+}
/* Copy the points-to information if it exists. */
if (DR_PTR_INFO (dr))
diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index eeef96a2eb6..1636e6716df 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -9765,6 +9765,18 @@ vectorizable_load (vec_info *vinfo,
bool ok = vect_transform_slp_perm_load (vinfo, slp_node, dr_chain,
gsi, vf, false, _perms);
gcc_assert (ok);
+ /* For SLP we know we've seen all possible uses of dr_chain.
+See to remove stmts we didn't need.
+??? This is a hack to prevent compile-time issues as seen
+in PR101120 and friends. */
+ for (tree op : dr_chain)
+ if (has_zero_uses (op))
+ {
+ gimple *stmt = SSA_NAME_DEF_STMT (op);
+ gimple_stmt_iterator rgsi = gsi_for_stmt (stmt);
+ gsi_remove (, true);
+ release_defs (stmt);
+ }
}
else
{
--
2.26.2
Re: [GCC-10 backport][PATCH] arm: Fix the mve multilib for the broken cmse support (pr99939).
On 14/06/2021 11:34, Srinath Parvathaneni via Gcc-patches wrote:
Hi,
The current CMSE support in the multilib build for
"-march=armv8.1-m.main+mve -mfloat-abi=hard -mfpu=auto" is broken
as specified in PR99939 and this patch fixes the issue.
Regression tested on arm-none-eabi and found no regressions.
This patch have cleanly applied, ok for the GCC-10 branch?
Regards,
Srinath.
gcc/testsuite/ChangeLog:
2021-06-11 Srinath Parvathaneni
PR target/99939
* gcc.target/arm/cmse/cmse-18.c: Add separate scan-assembler
directives check for target is v8.1-m.main+mve or not before
comparing the assembly output.
* gcc.target/arm/cmse/cmse-20.c: New test.
libgcc/ChangeLog:
2021-06-11 Srinath Parvathaneni
PR target/99939
* config/arm/cmse_nonsecure_call.S: Add __ARM_FEATURE_MVE
macro.
* config/arm/t-arm: To link cmse.o and cmse_nonsecure_call.o
on passing -mcmse option.
(cherry picked from commit c5ed0148347beea1bd34795de146a2454c36)
OK.
R.
### Attachment also inlined for ease of reply###
diff --git a/gcc/testsuite/gcc.target/arm/cmse/cmse-18.c
b/gcc/testsuite/gcc.target/arm/cmse/cmse-18.c
index
e1ff09257b7900982f49117d4cfc16f3bd79d76c..db7d975a90ea4bd1810aea03949ec1e8837e
100644
--- a/gcc/testsuite/gcc.target/arm/cmse/cmse-18.c
+++ b/gcc/testsuite/gcc.target/arm/cmse/cmse-18.c
@@ -8,4 +8,5 @@ void bar(f func, int a)
func(a);
}
-/* { dg-final { scan-rtl-dump "call unspec\\\[\\\[r4:SI\\\]\\\]" "final" } } */
+/* { dg-final { scan-rtl-dump "call unspec\\\[\\\[r4:SI\\\]\\\]" "final" {
target { ! arm_v8_1m_mve_ok } } } } */
+/* { dg-final { scan-rtl-dump "call unspec\\\[\\\[r\[0-7\]:SI\\\]\\\]" "final"
{ target { arm_v8_1m_mve_ok } } } } */
diff --git a/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c
b/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c
new file mode 100644
index
..08e89bff6378f1f96950fc40f3ab3946bd433773
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c
@@ -0,0 +1,28 @@
+/* This test is executed only if the execution engine supports CMSE
instructions. */
+/* { dg-options "--save-temps -mcmse
-Wl,--section-start,.gnu.sgstubs=0x0040" } */
+
+#include
+#include
+#include
+
+void __attribute__((cmse_nonsecure_entry))
+secure_fun (int a, int *p)
+{
+ void *b = cmse_check_address_range ((void *)p, a, 1);
+
+ if (b == NULL)
+ __builtin_abort ();
+ printf("%d", *((int *)b));
+}
+
+int
+main (void)
+{
+ int *ptr;
+ int size = 1;
+ ptr = (int *) calloc (1, sizeof(int *));
+ *ptr = 1315852292;
+ secure_fun (size, ptr);
+ free (ptr);
+ return 0;
+}
diff --git a/libgcc/config/arm/cmse_nonsecure_call.S
b/libgcc/config/arm/cmse_nonsecure_call.S
index
5ba28692d6b8a919939404d0f0d97d490df472e9..b1954b8714d6badc7311992847492c8c123799e0
100644
--- a/libgcc/config/arm/cmse_nonsecure_call.S
+++ b/libgcc/config/arm/cmse_nonsecure_call.S
@@ -25,7 +25,7 @@
.syntax unified
#ifdef __ARM_PCS_VFP
-# if __ARM_FP & 0x8
+# if (__ARM_FP & 0x8) || (__ARM_FEATURE_MVE & 1)
.fpu fpv5-d16
# else
.fpu fpv4-sp-d16
@@ -59,7 +59,7 @@ vmov s24, s25, r5, r5
vmov s26, s27, r5, r5
vmov s28, s29, r5, r5
vmov s30, s31, r5, r5
-#elif __ARM_FP & 0x08
+#elif (__ARM_FP & 0x8) || (__ARM_FEATURE_MVE & 1)
vmov.f64d9, d8
vmov.f64d10, d8
vmov.f64d11, d8
diff --git a/libgcc/config/arm/t-arm b/libgcc/config/arm/t-arm
index
3625a2590beec4e4e0e0881be9ad284c595c7190..c1553d4e5d80751b13dc2e9c9e36d5ebe82e5f8c
100644
--- a/libgcc/config/arm/t-arm
+++ b/libgcc/config/arm/t-arm
@@ -3,18 +3,17 @@ LIB1ASMFUNCS = _thumb1_case_sqi _thumb1_case_uqi
_thumb1_case_shi \
_thumb1_case_uhi _thumb1_case_si _speculation_barrier
HAVE_CMSE:=$(findstring __ARM_FEATURE_CMSE,$(shell $(gcc_compile_bare) -dM -E -
-HAVE_V81M:=$(findstring armv8.1-m.main,$(gcc_compile_bare))
ifeq ($(shell $(gcc_compile_bare) -E -mcmse - /dev/null
2>/dev/null; echo $$?),0)
CMSE_OPTS:=-mcmse
endif
ifdef HAVE_CMSE
-ifndef HAVE_V81M
+
libgcc-objects += cmse.o cmse_nonsecure_call.o
cmse.o: $(srcdir)/config/arm/cmse.c
$(gcc_compile) -c $(CMSE_OPTS) $<
+
cmse_nonsecure_call.o: $(srcdir)/config/arm/cmse_nonsecure_call.S
$(gcc_compile) -c $<
endif
-endif
Re: [GCC-11 backport][PATCH] arm: Fix the mve multilib for the broken cmse support (pr99939).
On 14/06/2021 11:34, Srinath Parvathaneni via Gcc-patches wrote:
Hi,
The current CMSE support in the multilib build for
"-march=armv8.1-m.main+mve -mfloat-abi=hard -mfpu=auto" is broken
as specified in PR99939 and this patch fixes the issue.
Regression tested on arm-none-eabi and found no regressions.
This patch have cleanly applied, ok for the GCC-11 branch?
Regards,
Srinath.
gcc/testsuite/ChangeLog:
2021-06-11 Srinath Parvathaneni
PR target/99939
* gcc.target/arm/cmse/cmse-18.c: Add separate scan-assembler
directives check for target is v8.1-m.main+mve or not before
comparing the assembly output.
* gcc.target/arm/cmse/cmse-20.c: New test.
libgcc/ChangeLog:
2021-06-11 Srinath Parvathaneni
PR target/99939
* config/arm/cmse_nonsecure_call.S: Add __ARM_FEATURE_MVE
macro.
* config/arm/t-arm: To link cmse.o and cmse_nonsecure_call.o
on passing -mcmse option.
(cherry picked from commit c5ed0148347beea1bd34795de146a2454c36)
OK.
R.
### Attachment also inlined for ease of reply###
diff --git a/gcc/testsuite/gcc.target/arm/cmse/cmse-18.c
b/gcc/testsuite/gcc.target/arm/cmse/cmse-18.c
index
e1ff09257b7900982f49117d4cfc16f3bd79d76c..db7d975a90ea4bd1810aea03949ec1e8837e
100644
--- a/gcc/testsuite/gcc.target/arm/cmse/cmse-18.c
+++ b/gcc/testsuite/gcc.target/arm/cmse/cmse-18.c
@@ -8,4 +8,5 @@ void bar(f func, int a)
func(a);
}
-/* { dg-final { scan-rtl-dump "call unspec\\\[\\\[r4:SI\\\]\\\]" "final" } } */
+/* { dg-final { scan-rtl-dump "call unspec\\\[\\\[r4:SI\\\]\\\]" "final" {
target { ! arm_v8_1m_mve_ok } } } } */
+/* { dg-final { scan-rtl-dump "call unspec\\\[\\\[r\[0-7\]:SI\\\]\\\]" "final"
{ target { arm_v8_1m_mve_ok } } } } */
diff --git a/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c
b/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c
new file mode 100644
index
..08e89bff6378f1f96950fc40f3ab3946bd433773
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c
@@ -0,0 +1,28 @@
+/* This test is executed only if the execution engine supports CMSE
instructions. */
+/* { dg-options "--save-temps -mcmse
-Wl,--section-start,.gnu.sgstubs=0x0040" } */
+
+#include
+#include
+#include
+
+void __attribute__((cmse_nonsecure_entry))
+secure_fun (int a, int *p)
+{
+ void *b = cmse_check_address_range ((void *)p, a, 1);
+
+ if (b == NULL)
+ __builtin_abort ();
+ printf("%d", *((int *)b));
+}
+
+int
+main (void)
+{
+ int *ptr;
+ int size = 1;
+ ptr = (int *) calloc (1, sizeof(int *));
+ *ptr = 1315852292;
+ secure_fun (size, ptr);
+ free (ptr);
+ return 0;
+}
diff --git a/libgcc/config/arm/cmse_nonsecure_call.S
b/libgcc/config/arm/cmse_nonsecure_call.S
index
146f3ed52e9c7e915e5dbd9b70624ec3bd7cd5b5..00830ade98ea650c328c709d5d308fbc96f7f21c
100644
--- a/libgcc/config/arm/cmse_nonsecure_call.S
+++ b/libgcc/config/arm/cmse_nonsecure_call.S
@@ -25,7 +25,7 @@
.syntax unified
#ifdef __ARM_PCS_VFP
-# if __ARM_FP & 0x8
+# if (__ARM_FP & 0x8) || (__ARM_FEATURE_MVE & 1)
.fpu fpv5-d16
# else
.fpu fpv4-sp-d16
@@ -59,7 +59,7 @@ vmov s24, s25, r5, r5
vmov s26, s27, r5, r5
vmov s28, s29, r5, r5
vmov s30, s31, r5, r5
-#elif __ARM_FP & 0x08
+#elif (__ARM_FP & 0x8) || (__ARM_FEATURE_MVE & 1)
vmov.f64d9, d8
vmov.f64d10, d8
vmov.f64d11, d8
diff --git a/libgcc/config/arm/t-arm b/libgcc/config/arm/t-arm
index
3625a2590beec4e4e0e0881be9ad284c595c7190..c1553d4e5d80751b13dc2e9c9e36d5ebe82e5f8c
100644
--- a/libgcc/config/arm/t-arm
+++ b/libgcc/config/arm/t-arm
@@ -3,18 +3,17 @@ LIB1ASMFUNCS = _thumb1_case_sqi _thumb1_case_uqi
_thumb1_case_shi \
_thumb1_case_uhi _thumb1_case_si _speculation_barrier
HAVE_CMSE:=$(findstring __ARM_FEATURE_CMSE,$(shell $(gcc_compile_bare) -dM -E -
-HAVE_V81M:=$(findstring armv8.1-m.main,$(gcc_compile_bare))
ifeq ($(shell $(gcc_compile_bare) -E -mcmse - /dev/null
2>/dev/null; echo $$?),0)
CMSE_OPTS:=-mcmse
endif
ifdef HAVE_CMSE
-ifndef HAVE_V81M
+
libgcc-objects += cmse.o cmse_nonsecure_call.o
cmse.o: $(srcdir)/config/arm/cmse.c
$(gcc_compile) -c $(CMSE_OPTS) $<
+
cmse_nonsecure_call.o: $(srcdir)/config/arm/cmse_nonsecure_call.S
$(gcc_compile) -c $<
endif
-endif
Re: [GCC][PATCH] arm: Fix multilib mapping for CDE extensions [PR100856].
On 14/06/2021 15:29, Srinath Parvathaneni via Gcc-patches wrote:
Hi Richard,
I have all addressed all your review comments (in [1]) in the below patch.
On passing +cdecp[0-7] extension to the -march string in command line options,
multilib linking is failing as mentioned in PR100856. This patch fixes this
issue by
generating a separate canonical string by removing compiler options which are
not
required for multilib linking from march string and assign the new string to
mlibarch
option. This mlibarch string is used for multilib comparison.
Regression tested on arm-none-eabi and found no regressions.
Ok for master?
[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571731.html
Regards,
Srinath.
gcc/ChangeLog:
2021-06-14 Srinath Parvathaneni
PR target/100856
* common/config/arm/arm-common.c (arm_canon_arch_option_1): New function
derived from arm_canon_arch.
(arm_canon_arch_option): Call it.
(arm_canon_arch_multilib_option): New function.
* config/arm/arm-cpus.in (IGNORE_FOR_MULTILIB): New fgroup.
* config/arm/arm.h (arm_canon_arch_multilib_option): New prototype.
(CANON_ARCH_MULTILIB_SPEC_FUNCTION): New macro.
(MULTILIB_ARCH_CANONICAL_SPECS): New macro.
(DRIVER_SELF_SPECS): Add MULTILIB_ARCH_CANONICAL_SPECS.
* config/arm/arm.opt (mlibarch): New option.
* config/arm/t-rmprofile (MULTILIB_MATCHES): For armv8*-m, replace use
of march on RHS with mlibarch.
gcc/testsuite/ChangeLog:
2021-06-14 Srinath Parvathaneni
PR target/100856
* gcc.target/arm/acle/pr100856.c: New test.
* gcc.target/arm/multilib.exp: Add tests for cde options.
Yes, this is much better. Thanks.
OK
R.
### Attachment also inlined for ease of reply###
diff --git a/gcc/common/config/arm/arm-common.c
b/gcc/common/config/arm/arm-common.c
index
9980af6885c3dfe68f61fa0f39b23022b4e59c19..481aa9e43d9c73e464e1e992ad7d94c30d2db001
100644
--- a/gcc/common/config/arm/arm-common.c
+++ b/gcc/common/config/arm/arm-common.c
@@ -627,9 +627,15 @@ public:
The options array consists of couplets of information where the
first item in each couplet is the string describing which option
name was selected (arch, cpu, fpu) and the second is the value
- passed for that option. */
-const char *
-arm_canon_arch_option (int argc, const char **argv)
+ passed for that option.
+
+ arch_for_multilib is boolean variable taking value true or false.
+ arch_for_multilib is false when the canonical representation is for -march
+ option and it is true when canonical representation is for -mlibarch option.
+ On passing arch_for_multilib true the canonical string generated will be
+ without the compiler options which are not required for multilib linking.
*/
+static const char *
+arm_canon_arch_option_1 (int argc, const char **argv, bool arch_for_multilib)
{
const char *arch = NULL;
const char *cpu = NULL;
@@ -694,8 +700,8 @@ arm_canon_arch_option (int argc, const char **argv)
/* First build up a bitmap describing the target architecture. */
if (arch)
{
- selected_arch = arm_parse_arch_option_name (all_architectures,
- "-march", arch);
+ selected_arch = arm_parse_arch_option_name (all_architectures, "-march",
+ arch, !arch_for_multilib);
if (selected_arch == NULL)
return "";
@@ -703,6 +709,15 @@ arm_canon_arch_option (int argc, const char **argv)
arm_initialize_isa (target_isa, selected_arch->common.isa_bits);
arm_parse_option_features (target_isa, _arch->common,
strchr (arch, '+'));
+ if (arch_for_multilib)
+ {
+ const enum isa_feature removable_bits[] = {ISA_IGNORE_FOR_MULTILIB,
+isa_nobit};
+ sbitmap isa_bits = sbitmap_alloc (isa_num_bits);
+ arm_initialize_isa (isa_bits, removable_bits);
+ bitmap_and_compl (target_isa, target_isa, isa_bits);
+ }
+
if (fpu && strcmp (fpu, "auto") != 0)
{
/* We assume that architectures do not have any FPU bits
@@ -719,7 +734,8 @@ arm_canon_arch_option (int argc, const char **argv)
else if (cpu)
{
const cpu_option *selected_cpu
- = arm_parse_cpu_option_name (all_cores, "-mcpu", cpu);
+ = arm_parse_cpu_option_name (all_cores, "-mcpu", cpu,
+!arch_for_multilib);
if (selected_cpu == NULL)
return "";
@@ -1069,3 +1085,22 @@ arm_asm_auto_mfpu (int argc, const char **argv)
#define TARGET_EXCEPT_UNWIND_INFO arm_except_unwind_info
struct gcc_targetm_common targetm_common = TARGETM_COMMON_INITIALIZER;
+
+/* Returns a canonical representation of the -march option from the current
+ -march string (if given) and
[PATCH] tree-optimization/101112 - fix pattern stmt def lookup in SLP reassoc
This fixes the lookup of a pattern stmt def operand.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-06-18 Richard Biener
PR tree-optimization/101112
* tree-vect-slp.c (vect_slp_linearize_chain): Fix condition
to lookup a pattern stmt def.
---
gcc/tree-vect-slp.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index 0c1f85beeb2..f9c33c0bb14 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -1482,13 +1482,9 @@ vect_slp_linearize_chain (vec_info *vinfo,
stmt_vec_info def_stmt_info;
bool res = vect_is_simple_use (op, vinfo, , _stmt_info);
gcc_assert (res);
- if (dt == vect_internal_def)
- {
- stmt_vec_info orig_def_stmt_info = def_stmt_info;
- def_stmt_info = vect_stmt_to_vectorize (def_stmt_info);
- if (def_stmt_info != orig_def_stmt_info)
- op = gimple_get_lhs (def_stmt_info->stmt);
- }
+ if (dt == vect_internal_def
+ && is_pattern_stmt_p (def_stmt_info))
+ op = gimple_get_lhs (def_stmt_info->stmt);
gimple *use_stmt;
use_operand_p use_p;
if (dt == vect_internal_def
--
2.26.2
Re: [PATCH 5/6] make get_domminated_by_region return a auto_vec
On Fri, 18 Jun 2021 at 12:03, Jonathan Wakely wrote: > > On Fri, 18 Jun 2021 at 11:54, Jakub Jelinek wrote: > > > > On Fri, Jun 18, 2021 at 12:38:09PM +0200, Richard Biener via Gcc-patches > > wrote: > > > > Yes, as we discussed in the review below, vec is not a good model > > > > because (as you note again above) it's constrained by its legacy > > > > uses. The best I think we can do for it is to make it safer to > > > > use. > > > > https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571622.html > > > > > > Which is what Trevors patches do by simply disallowing things > > > that do not work at the moment. > > > > I only see > > // You probably don't want to copy a vector, so these are deleted to > > prevent > > // unintentional use. If you really need a copy of the vectors contents > > you > > // can use copy (). > > auto_vec(const auto_vec &) = delete; > > auto_vec = (const auto_vec &) = delete; > > on the > > template > > class auto_vec : public vec > > specialization, but not on the > > template > > class auto_vec : public vec > > template itself. Shouldn't that one have also the deleted > > copy ctor/assignment operator and in addition to that maybe deleted > > move ctor/move assignment operator? > > That might have some value as documentation for people reading the > code, but it's not necessary. If vec has a deleted copy ctor and copy > assignment then it has no implicitly-defined move ctor and move > assignment. And the same goes for anything deriving from vec. Oh sorry, I misread the first snippet. So yes, it should probably be on both specializations. But deleting the moves is not necessary.
Re: [PATCH 5/6] make get_domminated_by_region return a auto_vec
On Fri, 18 Jun 2021 at 11:54, Jakub Jelinek wrote: > > On Fri, Jun 18, 2021 at 12:38:09PM +0200, Richard Biener via Gcc-patches > wrote: > > > Yes, as we discussed in the review below, vec is not a good model > > > because (as you note again above) it's constrained by its legacy > > > uses. The best I think we can do for it is to make it safer to > > > use. > > > https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571622.html > > > > Which is what Trevors patches do by simply disallowing things > > that do not work at the moment. > > I only see > // You probably don't want to copy a vector, so these are deleted to prevent > // unintentional use. If you really need a copy of the vectors contents you > // can use copy (). > auto_vec(const auto_vec &) = delete; > auto_vec = (const auto_vec &) = delete; > on the > template > class auto_vec : public vec > specialization, but not on the > template > class auto_vec : public vec > template itself. Shouldn't that one have also the deleted > copy ctor/assignment operator and in addition to that maybe deleted > move ctor/move assignment operator? That might have some value as documentation for people reading the code, but it's not necessary. If vec has a deleted copy ctor and copy assignment then it has no implicitly-defined move ctor and move assignment. And the same goes for anything deriving from vec.
Re: [PATCH 5/6] make get_domminated_by_region return a auto_vec
On Fri, Jun 18, 2021 at 12:38:09PM +0200, Richard Biener via Gcc-patches wrote: > > Yes, as we discussed in the review below, vec is not a good model > > because (as you note again above) it's constrained by its legacy > > uses. The best I think we can do for it is to make it safer to > > use. > > https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571622.html > > Which is what Trevors patches do by simply disallowing things > that do not work at the moment. I only see // You probably don't want to copy a vector, so these are deleted to prevent // unintentional use. If you really need a copy of the vectors contents you // can use copy (). auto_vec(const auto_vec &) = delete; auto_vec = (const auto_vec &) = delete; on the template class auto_vec : public vec specialization, but not on the template class auto_vec : public vec template itself. Shouldn't that one have also the deleted copy ctor/assignment operator and in addition to that maybe deleted move ctor/move assignment operator? Jakub
Re: [PATCH] Modula-2 into the GCC tree on master
On Thu, 17 Jun 2021, Gaius Mulley wrote: > > > Hello Richard, David, Matthias and GCC Steering Committee, > > here are a set of patches which merge the gm2 front end into the > GCC tree. The patches have been bootstrapped under aarch64 GNU/Linux > Debian Stretch using make -j 4, x86_64 GNU/Linux Debian Stretch built > using make -j 24 and also under x86_64 GNU/Linux Debian Buster using > make -j 4. > > Tested on Debian Stretch x86_64 > === > > built GCC bootstrap 3 times: > > 1. built vanilla GCC (enabling bootstrap) enabling front ends: > c,c++,go,d,fortran and ran the regression tests. (make -j 4). > > 2. the patches below were applied and associated tarball untarred. > The same front ends c,c++,go,d,fortran (again building from > bootstrap) were enabled (no m2) and ran the regression tests. > There were no changes to the regression test results between 1 and > 2. > > 3. Then it was rebuilt (from bootstrap) enabling the front ends > c,c++,go,d,fortran,m2 and ran the > regression tests and again no extra failures were seen. > > 4. It has been built in source tree (./configure --enable-languages=m2) > and out of source tree with make -j 24. > > Built on Debian Buster x86_64 > = > > 1. built vanilla GCC (enabling bootstrap) enabling front ends: > c,c++,go,d,fortran and ran the regression tests. > > 2. the patches below were applied and associated tarball untarred. > The same front ends c,c++,go,d,fortran (again building from > bootstrap) were enabled (no m2) and ran the regression tests. > There were no changes to the regression test results between 1 and > 2. > > 3. Then it was rebuilt (from bootstrap) enabling the front ends > c,c++,go,d,fortran,m2 and ran the > regression tests and again no extra failures were seen. > > Built a patched tree enabling bootstrap make -j 4 for front ends > c,c++,m2 all compiled and bootstrapped. > > How to merge > > > 1. apply patches below to the master GCC tree. > > 2. cd gcc-git-top > > wget http://floppsie.comp.glam.ac.uk/download/c/gm2-front-end-20210617-tar.gz > > tar zxf gm2-front-end-20210617-tar.gz > rm gm2-front-end-20210617-tar.gz > # new directories gm2tools, libgm2, gcc/m2, gcc/testsuite/gm2 are created > # and populated. Documentation in gcc/doc and testsuite/lib contains some > # Modula-2 dejagnu scripts. > > 3. cd gcc-git-top > autogen Makefile.def > autoconf > cd libgm2 > /bin/sh ./autogen.sh > cd ../gm2tools > /bin/sh ./autogen.sh > > Thank you Richard for the extensive feedback from the last time the > patches were posted. I've gone though your points and addressed them > (I think). > > > It looks like libgm2 is built independently on whether m2 is enabled > > or not? I'd like to see a while-listing of supported targets like > > done for example for libgomp via configure.tgt or for libgo (see > > toplevel configure). > > I've added a test in libgm2/configure.ac to restict the building of > libgm2 - or to restrict it to building libm2min which is a near zero > runtime library. It restricts on host and target and can easily be > changed. > > > The driver changes have been posted and reviewed previously but I > > didn't see any real OK there but motivational questions - they never > > were posted together with the m2 driver portion (I guess that would > > be gcc/m2/gm2spec.c in the tarball). > > yes gcc/m2/gm2spec.c. > > > I've not seen reviews or postings (besides as tarball) of the > > frontend or the library (but I don't remember seeing extensive > > reviews of other languages frontends or runtime portions at the > > point of their inclusion - still the glueing to the middle-end > > should get the chance to be reviewed). > > the glue code is in m2/gm2-gcc/*.[ch]. The filenames adopt a similar > naming scheme to other front ends: m2/gm2-gcc/m2decl.c for > declarations, m2/gm2-gcc/m2expr.c for expressions etc. The exported > names are prefixed by the module name so that the code can be linked > against the Modula-2 version with an appropriate definition module > (for example m2/gm2-gcc/m2expr.def). > > > I've tried to find my way through gcc/m2 but am quite lost in the > > number of subdirectories. > > I've added a README in each directory giving an overview of the > contents. > > > I do see in gm2-lang.c and elsewhere inclusion of system headers > > outside of system.h which is going to be a portability problem. > > I've changed nearly all headers to use "config.h", "system.h" and > friends and modified the bootstrap tool to automatically generate > these gcc header includes. > > > From the parse_file langhook we eventually dispatch to > > init_PerCompilationInit which looks like a Modula-2 scaffolding > > file? > > yes indeed. > > > Is the compiler written in Modula-2? It's not clear what > > parts make up the interface to the GCC
Re: [PATCH 5/6] make get_domminated_by_region return a auto_vec
On Thu, Jun 17, 2021 at 4:43 PM Martin Sebor wrote: > > On 6/17/21 12:03 AM, Richard Biener wrote: > > On Wed, Jun 16, 2021 at 6:01 PM Martin Sebor wrote: > >> > >> On 6/16/21 6:46 AM, Richard Sandiford via Gcc-patches wrote: > >>> Richard Biener via Gcc-patches writes: > On Tue, Jun 15, 2021 at 8:02 AM Trevor Saunders > wrote: > > > > This makes it clear the caller owns the vector, and ensures it is > > cleaned up. > > > > Signed-off-by: Trevor Saunders > > > > bootstrapped and regtested on x86_64-linux-gnu, ok? > > OK. > > Btw, are "standard API" returns places we can use 'auto'? That would > avoid > excessive indent for > > - dom_bbs = get_dominated_by_region (CDI_DOMINATORS, > -bbs.address (), > -bbs.length ()); > + auto_vec dom_bbs = get_dominated_by_region > (CDI_DOMINATORS, > + bbs.address > (), > + bbs.length > ()); > > and just uses > > auto dom_bbs = get_dominated_by_region (... > > Not asking you to do this, just a question for the audience. > >>> > >>> Personally I think this would be surprising for something that doesn't > >>> have copy semantics. (Not that I'm trying to reopen that debate here :-) > >>> FWIW, I agree not having copy semantics is probably the most practical > >>> way forward for now.) > >> > >> But you did open the door for me to reiterate my strong disagreement > >> with that. The best C++ practice going back to the early 1990's is > >> to make types safely copyable and assignable. It is the default for > >> all types, in both C++ and C, and so natural and expected. > >> > >> Preventing copying is appropriate in special and rare circumstances > >> (e.g, a mutex may not be copyable, or a file or iostream object may > >> not be because they represent a unique physical resource.) > >> > >> In the absence of such special circumstances preventing copying is > >> unexpected, and in the case of an essential building block such as > >> a container, makes the type difficult to use. > >> > >> The only argument for disabling copying that has been given is > >> that it could be surprising(*). But because all types are copyable > >> by default the "surprise" is usually when one can't be. > >> > >> I think Richi's "surprising" has to do with the fact that it lets > >> one inadvertently copy a large amount of data, thus leading to > >> an inefficiency. But by analogy, there are infinitely many ways > >> to end up with inefficient code (e.g., deep recursion, or heap > >> allocation in a loop), and they are not a reason to ban the coding > >> constructs that might lead to it. > >> > >> IIUC, Jason's comment about surprising effects was about implicit > >> conversion from auto_vec to vec. I share that concern, and agree > >> that it should be addressed by preventing the conversion (as Jason > >> suggested). > > > > But fact is that how vec<> and auto_vec<> are used today in GCC > > do not favor that. In fact your proposed vec<> would be quite radically > > different (and IMHO vec<> and auto_vec<> should be unified then to > > form your proposed new container). auto_vec<> at the moment simply > > maintains ownership like a smart pointer - which is _also_ not copyable. > > Yes, as we discussed in the review below, vec is not a good model > because (as you note again above) it's constrained by its legacy > uses. The best I think we can do for it is to make it safer to > use. > https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571622.html Which is what Trevors patches do by simply disallowing things that do not work at the moment. > (Smart pointers don't rule out copying. A std::unique_ptr does > and std::shared_ptr doesn't. But vec and especially auto_vec > are designed to be containers, not "unique pointers" so any > relationship there is purely superficial and a distraction.) > > That auto_vec and vec share a name and an is-a relationship is > incidental, an implementation detail leaked into the API. A better > name than vector is hard to come up with, but the public inheritance > is a design flaw, a bug waiting to be introduced due to the conversion > and the assumptions the base vec makes about POD-ness and shallow > copying. Hindsight is always 20/20 but past mistakes should not > dictate the design of a general purpose vector-like container in > GCC. That auto_vec<> "decays" to vec<> was on purpose design. By-value passing of vec<> is also on purpose to avoid an extra pointer indirection on each access. > I fully support fixing or at least mitigating the problems with > the vec base class (unsafe copying, pass-by-value etc.). As I > mentioned, I already started working on this cleanup. I also > have no objection to
[committed 2/2] libstdc++: Simplify constexpr checks in std::char_traits [PR 91488]
On 17/06/21 22:45 +0100, Jonathan Wakely wrote:
This removes the helper functions added by r8-1294 to detect whether the
char_traits member functions can be evaluated at compile time. Instead,
we can just use __builtin_constant_evaluated directly, which is well
supported by non-GCC compilers by now.
As a result, there is a chance that those members will no longer be
usable in constant expressions when using old versions of non-GCC
compilers. Make the relevant feature test macros depend on the
availability of __builtin_constant_evaluated, so they are defined only
when the feature is actualyl available.
The new testcase from the PR is added to the libitm testsuite, because
that's where we can be sure it's OK to use the -fgnu-tm option.
Signed-off-by: Jonathan Wakely
PR libstdc++/91488
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (__cpp_lib_constexpr_string): Only
define when is_constant_evaluated is available.
* include/bits/char_traits.h (__cpp_lib_constexpr_char_traits):
Likewise.
(__constant_string_p, __constant_array_p): Remove.
(char_traits): Use is_constant_evaluated directly.
* include/std/version (__cpp_lib_constexpr_char_traits)
(__cpp_lib_constexpr_string): Only define when
is_constant_evaluated is available.
libitm/ChangeLog:
* testsuite/libitm.c++/libstdc++-pr91488.C: New test.
The attached patch is the backport. Instead of removing the
__constant_string_p and __constant_array_p functions entirely, just
give them external linkage. That seems to avoid the bug, and means the
release branches can still be used with older non-GCC compilers which
don't support __builtin_is_constant_evaluated yet.
Tested x86_64-linux. Committed to gcc-11 for now, gcc-10 and gcc-9 to
follow soon.
commit 0191c74141cfea8973a6d977ce9944d39f7c4329
Author: Jonathan Wakely
Date: Thu Jun 17 14:11:22 2021
libstdc++: Simplify constexpr checks in std::char_traits [PR 91488]
This removes the 'static' keyword from the helper functions added by
r8-1294 to detect whether the char_traits member functions can be
evaluated at compile time. This prevents the "inlining failed" error
reported in the PR.
The new testcase from the PR is added to the libitm testsuite, because
that's where we can be sure it's OK to use the -fgnu-tm option.
As a drive-by fix, the feature test macros for C++20 P0980R1 support are
made to depend on whether __cpp_lib_is_constant_evaluated is defined.
Signed-off-by: Jonathan Wakely
PR libstdc++/91488
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (__cpp_lib_constexpr_string): Only
define C++20 value when std::is_constant_evaluated is available.
* include/bits/char_traits.h (__cpp_lib_constexpr_char_traits):
Likewise.
(__constant_string_p, __constant_array_p): Give external
linkage.
* include/std/version (__cpp_lib_constexpr_char_traits)
(__cpp_lib_constexpr_string): Only define C++20 values when
is_constant_evaluated is available.
libitm/ChangeLog:
* testsuite/libitm.c++/libstdc++-pr91488.C: New test.
(cherry picked from commit b376b1ef38971b84975ad1540bf5d2ae0b924e76)
diff --git a/libitm/testsuite/libitm.c++/libstdc++-pr91488.C b/libitm/testsuite/libitm.c++/libstdc++-pr91488.C
new file mode 100644
index 000..e9e82bd1ce2
--- /dev/null
+++ b/libitm/testsuite/libitm.c++/libstdc++-pr91488.C
@@ -0,0 +1,9 @@
+// PR libstdc++/91488 "inlining failed in call to always_inline"
+// { dg-do run }
+// { dg-additional-options "-O1" }
+
+#include
+
+int main() {
+return std::char_traits::length("");
+}
diff --git a/libstdc++-v3/include/bits/basic_string.h b/libstdc++-v3/include/bits/basic_string.h
index 84356adc7ae..037040740ab 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -52,12 +52,13 @@ namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
-#if __cplusplus == 201703L
+#ifdef __cpp_lib_is_constant_evaluated
+// Support P1032R1 in C++20 (but not P0980R1 yet).
+# define __cpp_lib_constexpr_string 201811L
+#elif __cplusplus >= 201703L
// Support P0426R1 changes to char_traits in C++17.
# define __cpp_lib_constexpr_string 201611L
#elif __cplusplus > 201703L
-// Also support P1032R1 in C++20 (but not P0980R1 yet).
-# define __cpp_lib_constexpr_string 201811L
#endif
#if _GLIBCXX_USE_CXX11_ABI
diff --git a/libstdc++-v3/include/bits/char_traits.h b/libstdc++-v3/include/bits/char_traits.h
index 95fb7c1ee89..c143d74a9ba 100644
--- a/libstdc++-v3/include/bits/char_traits.h
+++ b/libstdc++-v3/include/bits/char_traits.h
@@ -237,12 +237,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#if __cplusplus >= 201703L
-#if __cplusplus == 201703L
-// Unofficial macro indicating P0426R1 support
Re: [PATCH] Modula-2 into the GCC tree on master
On 6/18/21 12:26 AM, Gaius Mulley wrote: > > > Hello Richard, David, Matthias and GCC Steering Committee, > > here are a set of patches which merge the gm2 front end into the > GCC tree. The patches have been bootstrapped under aarch64 GNU/Linux > Debian Stretch using make -j 4, x86_64 GNU/Linux Debian Stretch built > using make -j 24 and also under x86_64 GNU/Linux Debian Buster using > make -j 4. > > Tested on Debian Stretch x86_64 > === > > built GCC bootstrap 3 times: > > 1. built vanilla GCC (enabling bootstrap) enabling front ends: > c,c++,go,d,fortran and ran the regression tests. (make -j 4). > > 2. the patches below were applied and associated tarball untarred. > The same front ends c,c++,go,d,fortran (again building from > bootstrap) were enabled (no m2) and ran the regression tests. > There were no changes to the regression test results between 1 and > 2. > > 3. Then it was rebuilt (from bootstrap) enabling the front ends > c,c++,go,d,fortran,m2 and ran the > regression tests and again no extra failures were seen. > > 4. It has been built in source tree (./configure --enable-languages=m2) > and out of source tree with make -j 24. > > Built on Debian Buster x86_64 > = > > 1. built vanilla GCC (enabling bootstrap) enabling front ends: > c,c++,go,d,fortran and ran the regression tests. > > 2. the patches below were applied and associated tarball untarred. > The same front ends c,c++,go,d,fortran (again building from > bootstrap) were enabled (no m2) and ran the regression tests. > There were no changes to the regression test results between 1 and > 2. > > 3. Then it was rebuilt (from bootstrap) enabling the front ends > c,c++,go,d,fortran,m2 and ran the > regression tests and again no extra failures were seen. > > Built a patched tree enabling bootstrap make -j 4 for front ends > c,c++,m2 all compiled and bootstrapped. I checked that with a profiled lto build. The build succeeds with the attached patch to respect the parallel linking limitations, which you can configure with --enable-link-serialization=N However the build fails in the installation step with: [...] Linking stage1/m2/cc1gm2 |--| 0% x86_64-linux-gnu-g++-10 -std=c++11 -no-pie -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-q ual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition -Wc++-compat - fno-common -DHAVE_CONFIG_H -o stage1/m2/cc1gm2 m2/gm2-lang.o m2/stor-layout.o m2/m2pp.o m2/gm2-gcc/m2assert.o m2/gm2-gcc/m2block.o m2/gm2-gcc/m2builtins.o m2/gm2-gcc/m2except.o m2/gm2-gcc/m2convert.o m2/gm2-gcc/m2color.o m2/gm2-gcc/m2decl.o m2/gm2-gcc/m2expr.o m2/gm2-gcc/m2linemap.o m2/gm2-gcc/m2statement.o m2/gm2-gcc/m2type.o m2/gm2-gcc/m2tree.o m2/gm2-gcc/m2treelib.o m2/gm2-gcc/m2top.o m2/gm2-gcc/m2misc.o m2/gm2-gcc/init.o m2/gm2-compiler-boot/m2flex.o \ attribs.o \ m2/gm2-compiler-boot/gm2.a m2/gm2-libs-boot/libgm2.a m2/mc-boot-ch/Glibc.o m2/mc-boot-ch/Gmcrts.o m2/gm2-gcc/rtegraph.o \ libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lisl -lmpc -lmpfr -lgmp -rdynamic -ldl -lz -lzstd lto1: fatal error: bytecode stream in file 'm2/gm2-compiler-boot/m2flex.o' generated with LTO version 12.0 instead of the expected 9.2 compilation terminated. lto-wrapper: fatal error: x86_64-linux-gnu-g++-10 returned 1 exit status compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status Command exited with non-zero status 1 x86_64-linux-gnu-g++-10 is the compiler used for the bootstrap. I haven't checked if that is also seen for a normal bootstrap. Apparently it tries to re-bootstrap the compiler. The build is configured with --with-build-config=bootstrap-lto-lean, built with make profiledbootstrap-lean Matthias 2021-06-18 Matthias Klose * Make-lang.in (m2.serial): New target. (cc1gm2): Depend on $(m2.prev). (stageN/m2/cc1gm2): Call LLINKER, also call LINK_PROGRESS. --- a/gcc/m2/Make-lang.in +++ b/gcc/m2/Make-lang.in @@ -82,6 +82,7 @@ TEXISRC = $(objdir)/m2/images/gnu.eps \ # Define the names for selecting GNU Modula-2 in LANGUAGES. m2 modula-2 modula2: gm2$(exeext) xgcc$(exeext) cc1gm2$(exeext) \ $(GCC_TOOLS_FOR_GM2) +m2.serial = cc1gm2$(exeext) # Tell GNU make to ignore these if they exist. .PHONY: m2 modula-2 modula2 @@ -530,7 +531,7 @@ GM2_LIBS_PARANOID = m2/gm2-compiler-para gm2.paranoid: stage3/m2/cc1gm2$(exeext) gm2.verifyparanoid -cc1gm2$(exeext): stage1/m2/cc1gm2$(exeext) +cc1gm2$(exeext): stage1/m2/cc1gm2$(exeext) $(m2.prev) cp -p $< $@ gm2lcc$(exeext):
[committed] libstdc++: Suppress -Wstringop-overread warning in test
When compiled with -m32 -O2 -D_GLIBCXX_USE_CXX11_ABI=0 we get a warning
for 21_strings/basic_string/cons/char/1.cc:
bits/char_traits.h:409:56: warning: ‘void* __builtin_memcpy(void*, const void*,
unsigned int)’ reading 1073741821 bytes from a region of size 19
[-Wstringop-overread]
The warning is legitimate, even if that line cannot be reached because
we throw std::length_error before getting there. Since the invalid
length is deliberate (and mentioned in a comment) just suppress the
warning, so that the test can verify we get the exception.
Also remove an unused typedef that produces another warning.
libstdc++-v3/ChangeLog:
* testsuite/21_strings/basic_string/cons/char/1.cc: Use
diagnostic pragma to suppress -Wstringop-overread error.
Signed-off-by: Jonathan Wakely
Tested x86_64-linux. Committed to trunk.
commit 92edc4a7684cdad5d30e197b976c35b2257f7bed
Author: Jonathan Wakely
Date: Fri Jun 18 11:08:19 2021
libstdc++: Suppress -Wstringop-overread warning in test
When compiled with -m32 -O2 -D_GLIBCXX_USE_CXX11_ABI=0 we get a warning
for 21_strings/basic_string/cons/char/1.cc:
bits/char_traits.h:409:56: warning: ‘void* __builtin_memcpy(void*, const
void*, unsigned int)’ reading 1073741821 bytes from a region of size 19
[-Wstringop-overread]
The warning is legitimate, even if that line cannot be reached because
we throw std::length_error before getting there. Since the invalid
length is deliberate (and mentioned in a comment) just suppress the
warning, so that the test can verify we get the exception.
Also remove an unused typedef that produces another warning.
libstdc++-v3/ChangeLog:
* testsuite/21_strings/basic_string/cons/char/1.cc: Use
diagnostic pragma to suppress -Wstringop-overread error.
Signed-off-by: Jonathan Wakely
diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/1.cc
b/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/1.cc
index 5549094553e..099921f0941 100644
--- a/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/1.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/1.cc
@@ -36,7 +36,6 @@ using namespace std;
void test01(void)
{
typedef string::size_type csize_type;
- typedef string::iterator citerator;
csize_type npos = string::npos;
csize_type csz01;
@@ -68,6 +67,8 @@ void test01(void)
// basic_string(const char* s, size_type n, alloc)
csz01 = str01.max_size();
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wstringop-overread"
// NB: As strlen(str_lit01) != csz01, this test is undefined. It
// should not crash, but what gets constructed is a bit arbitrary.
try {
@@ -94,6 +95,7 @@ void test01(void)
catch(...) {
VERIFY( false );
}
+#pragma GCC diagnostic pop
// Build a maxsize - 1 lengthed string consisting of all A's
try {
Re: [PATCH] Merge vec_addsub patterns
On Fri, 18 Jun 2021, Uros Bizjak wrote:
> On Fri, Jun 18, 2021 at 11:13 AM Richard Biener wrote:
> >
> > This merges the vec_addsub3 patterns using a mode attribute
> > for the vec_merge merge operand.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> >
> > I'd appreciate an extra eye since this is the first time I'm
> > doing such.
>
> The calculation of attributes is a bit more complex, please see inline.
>
> > OK as a followup to the addsub pattern renaming?
>
> OK with fixed attribute calculation.
>
> Thanks,
> Uros.
>
> >
> > Thanks,
> > Richard.
> >
> > 2021-06-18 Richard Biener
> >
> > * config/i386/sse.md (vec_addsubv4df3, vec_addsubv2df3,
> > vec_addsubv8sf3, vec_addsubv4sf3): Merge into ...
> > (vec_addsub3): ... using a new addsub_cst mode attribute.
> > ---
> > gcc/config/i386/sse.md | 72 --
> > 1 file changed, 14 insertions(+), 58 deletions(-)
> >
> > diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> > index 038e2cd90d4..930e777ec08 100644
> > --- a/gcc/config/i386/sse.md
> > +++ b/gcc/config/i386/sse.md
> > @@ -2396,69 +2396,25 @@
> > (set_attr "prefix" "")
> > (set_attr "mode" "")])
> >
> > -(define_insn "vec_addsubv4df3"
> > - [(set (match_operand:V4DF 0 "register_operand" "=x")
> > - (vec_merge:V4DF
> > - (minus:V4DF
> > - (match_operand:V4DF 1 "register_operand" "x")
> > - (match_operand:V4DF 2 "nonimmediate_operand" "xm"))
> > - (plus:V4DF (match_dup 1) (match_dup 2))
> > - (const_int 5)))]
> > - "TARGET_AVX"
> > - "vaddsubpd\t{%2, %1, %0|%0, %1, %2}"
> > - [(set_attr "type" "sseadd")
> > - (set_attr "prefix" "vex")
> > - (set_attr "mode" "V4DF")])
> > -
> > -(define_insn "vec_addsubv2df3"
> > - [(set (match_operand:V2DF 0 "register_operand" "=x,x")
> > - (vec_merge:V2DF
> > - (minus:V2DF
> > - (match_operand:V2DF 1 "register_operand" "0,x")
> > - (match_operand:V2DF 2 "vector_operand" "xBm,xm"))
> > - (plus:V2DF (match_dup 1) (match_dup 2))
> > - (const_int 1)))]
> > - "TARGET_SSE3"
> > - "@
> > - addsubpd\t{%2, %0|%0, %2}
> > - vaddsubpd\t{%2, %1, %0|%0, %1, %2}"
> > - [(set_attr "isa" "noavx,avx")
> > - (set_attr "type" "sseadd")
> > - (set_attr "atom_unit" "complex")
> > - (set_attr "prefix" "orig,vex")
> > - (set_attr "mode" "V2DF")])
> > -
> > -(define_insn "vec_addsubv8sf3"
> > - [(set (match_operand:V8SF 0 "register_operand" "=x")
> > - (vec_merge:V8SF
> > - (minus:V8SF
> > - (match_operand:V8SF 1 "register_operand" "x")
> > - (match_operand:V8SF 2 "nonimmediate_operand" "xm"))
> > - (plus:V8SF (match_dup 1) (match_dup 2))
> > - (const_int 85)))]
> > - "TARGET_AVX"
> > - "vaddsubps\t{%2, %1, %0|%0, %1, %2}"
> > - [(set_attr "type" "sseadd")
> > - (set_attr "prefix" "vex")
> > - (set_attr "mode" "V8SF")])
> > -
> > -(define_insn "vec_addsubv4sf3"
> > - [(set (match_operand:V4SF 0 "register_operand" "=x,x")
> > - (vec_merge:V4SF
> > - (minus:V4SF
> > - (match_operand:V4SF 1 "register_operand" "0,x")
> > - (match_operand:V4SF 2 "vector_operand" "xBm,xm"))
> > - (plus:V4SF (match_dup 1) (match_dup 2))
> > - (const_int 5)))]
> > +(define_mode_attr addsub_cst [(V4DF "5") (V2DF "1")
> > + (V4SF "5") (V8SF "85")])
>
> space here, please
>
> > +(define_insn "vec_addsub3"
> > + [(set (match_operand:VF_128_256 0 "register_operand" "=x,x")
> > +(vec_merge:VF_128_256
> > + (minus:VF_128_256
> > + (match_operand:VF_128_256 1 "register_operand" "0,x")
> > + (match_operand:VF_128_256 2 "vector_operand" "xBm, xm"))
> > + (plus:VF_128_256 (match_dup 1) (match_dup 2))
> > + (const_int )))]
> >"TARGET_SSE3"
> >"@
> > - addsubps\t{%2, %0|%0, %2}
> > - vaddsubps\t{%2, %1, %0|%0, %1, %2}"
> > + addsub\t{%2, %0|%0, %2}
> > + vaddsub\t{%2, %1, %0|%0, %1, %2}"
> >[(set_attr "isa" "noavx,avx")
> > (set_attr "type" "sseadd")
> > + (set_attr "atom_unit" "other,complex")
>
>(set (attr "atom_unit")
>(if_then_else
> (match_test "mode == V2DFmode")
> (const_string "complex")
> (const_string "*")))
>
> > (set_attr "prefix" "orig,vex")
> > - (set_attr "prefix_rep" "1,*")
>
>(set (attr "prefix_rep")
> (if_then_else
> (and (match_test "mode == V4SFmode")
>(eq_attr "alternative" "0"))
> (const_string "1")
> (const_string "*")))
Oops, missed that one.
Thanks for the fixes, I have queued the updated patch.
Richard.
> > - (set_attr "mode" "V4SF")])
> > + (set_attr "mode" "")])
> >
> > (define_split
> >[(set (match_operand:VF_128_256 0 "register_operand")
> > --
> > 2.26.2
>
Re: [PATCH] Merge vec_addsub patterns
On Fri, Jun 18, 2021 at 11:13 AM Richard Biener wrote:
>
> This merges the vec_addsub3 patterns using a mode attribute
> for the vec_merge merge operand.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> I'd appreciate an extra eye since this is the first time I'm
> doing such.
The calculation of attributes is a bit more complex, please see inline.
> OK as a followup to the addsub pattern renaming?
OK with fixed attribute calculation.
Thanks,
Uros.
>
> Thanks,
> Richard.
>
> 2021-06-18 Richard Biener
>
> * config/i386/sse.md (vec_addsubv4df3, vec_addsubv2df3,
> vec_addsubv8sf3, vec_addsubv4sf3): Merge into ...
> (vec_addsub3): ... using a new addsub_cst mode attribute.
> ---
> gcc/config/i386/sse.md | 72 --
> 1 file changed, 14 insertions(+), 58 deletions(-)
>
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index 038e2cd90d4..930e777ec08 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -2396,69 +2396,25 @@
> (set_attr "prefix" "")
> (set_attr "mode" "")])
>
> -(define_insn "vec_addsubv4df3"
> - [(set (match_operand:V4DF 0 "register_operand" "=x")
> - (vec_merge:V4DF
> - (minus:V4DF
> - (match_operand:V4DF 1 "register_operand" "x")
> - (match_operand:V4DF 2 "nonimmediate_operand" "xm"))
> - (plus:V4DF (match_dup 1) (match_dup 2))
> - (const_int 5)))]
> - "TARGET_AVX"
> - "vaddsubpd\t{%2, %1, %0|%0, %1, %2}"
> - [(set_attr "type" "sseadd")
> - (set_attr "prefix" "vex")
> - (set_attr "mode" "V4DF")])
> -
> -(define_insn "vec_addsubv2df3"
> - [(set (match_operand:V2DF 0 "register_operand" "=x,x")
> - (vec_merge:V2DF
> - (minus:V2DF
> - (match_operand:V2DF 1 "register_operand" "0,x")
> - (match_operand:V2DF 2 "vector_operand" "xBm,xm"))
> - (plus:V2DF (match_dup 1) (match_dup 2))
> - (const_int 1)))]
> - "TARGET_SSE3"
> - "@
> - addsubpd\t{%2, %0|%0, %2}
> - vaddsubpd\t{%2, %1, %0|%0, %1, %2}"
> - [(set_attr "isa" "noavx,avx")
> - (set_attr "type" "sseadd")
> - (set_attr "atom_unit" "complex")
> - (set_attr "prefix" "orig,vex")
> - (set_attr "mode" "V2DF")])
> -
> -(define_insn "vec_addsubv8sf3"
> - [(set (match_operand:V8SF 0 "register_operand" "=x")
> - (vec_merge:V8SF
> - (minus:V8SF
> - (match_operand:V8SF 1 "register_operand" "x")
> - (match_operand:V8SF 2 "nonimmediate_operand" "xm"))
> - (plus:V8SF (match_dup 1) (match_dup 2))
> - (const_int 85)))]
> - "TARGET_AVX"
> - "vaddsubps\t{%2, %1, %0|%0, %1, %2}"
> - [(set_attr "type" "sseadd")
> - (set_attr "prefix" "vex")
> - (set_attr "mode" "V8SF")])
> -
> -(define_insn "vec_addsubv4sf3"
> - [(set (match_operand:V4SF 0 "register_operand" "=x,x")
> - (vec_merge:V4SF
> - (minus:V4SF
> - (match_operand:V4SF 1 "register_operand" "0,x")
> - (match_operand:V4SF 2 "vector_operand" "xBm,xm"))
> - (plus:V4SF (match_dup 1) (match_dup 2))
> - (const_int 5)))]
> +(define_mode_attr addsub_cst [(V4DF "5") (V2DF "1")
> + (V4SF "5") (V8SF "85")])
space here, please
> +(define_insn "vec_addsub3"
> + [(set (match_operand:VF_128_256 0 "register_operand" "=x,x")
> +(vec_merge:VF_128_256
> + (minus:VF_128_256
> + (match_operand:VF_128_256 1 "register_operand" "0,x")
> + (match_operand:VF_128_256 2 "vector_operand" "xBm, xm"))
> + (plus:VF_128_256 (match_dup 1) (match_dup 2))
> + (const_int )))]
>"TARGET_SSE3"
>"@
> - addsubps\t{%2, %0|%0, %2}
> - vaddsubps\t{%2, %1, %0|%0, %1, %2}"
> + addsub\t{%2, %0|%0, %2}
> + vaddsub\t{%2, %1, %0|%0, %1, %2}"
>[(set_attr "isa" "noavx,avx")
> (set_attr "type" "sseadd")
> + (set_attr "atom_unit" "other,complex")
(set (attr "atom_unit")
(if_then_else
(match_test "mode == V2DFmode")
(const_string "complex")
(const_string "*")))
> (set_attr "prefix" "orig,vex")
> - (set_attr "prefix_rep" "1,*")
(set (attr "prefix_rep")
(if_then_else
(and (match_test "mode == V4SFmode")
(eq_attr "alternative" "0"))
(const_string "1")
(const_string "*")))
> - (set_attr "mode" "V4SF")])
> + (set_attr "mode" "")])
>
> (define_split
>[(set (match_operand:VF_128_256 0 "register_operand")
> --
> 2.26.2
Re: [EXTERNAL] Re: [PATCH] tree-optimization: Optimize division followed by multiply [PR95176]
On Wed, Jun 16, 2021 at 8:49 PM Victor Tong wrote:
>
> Hi Richard,
>
> Thanks for the feedback. From what you said, I can think of two possible
> solutions (though I'm not sure if either is feasible/fully correct):
>
> Option 1: Have the new X * (Y / X) --> Y - (Y % X) optimization only run in
> scenarios that don't interfere with the existing X - (X / Y) * Y --> X % Y
> optimization.
>
> This would involve checking the expression one level up to see if there's a
> subtraction that would trigger the existing optimization. I looked through
> the match.pd file and couldn't find a bail condition like this. It doesn't
> seem like there's a link from an expression to its parent expression one
> level up. This also feels a bit counter-intuitive since it would be doing the
> opposite of the bottom-up expression matching where the compiler would like
> to match a larger expression rather than a smaller one.
Yes, that option is not really possible from match.pd.
> Option 2: Add a new pattern to support scenarios that the existing
> nop_convert pattern bails out on.
>
> Existing pattern:
>
> (simplify
>(minus (nop_convert1? @0) (nop_convert2? (minus (nop_convert3? @@0) @1)))
>(view_convert @1))
>
> New pattern to add:
>
> /* X - (X - Y) --> Y */
> (simplify
> (minus @0 (convert? (minus @@0 @1)))
> (if (INTEGRAL_TYPE_P (type)
> && TYPE_OVERFLOW_UNDEFINED(type)
> && INTEGRAL_TYPE_P (TREE_TYPE(@1))
> && TYPE_OVERFLOW_UNDEFINED(TREE_TYPE(@1))
> && !TYPE_UNSIGNED (TREE_TYPE (@1))
> && !TYPE_UNSIGNED (type)
> && TYPE_PRECISION (TREE_TYPE (@1)) <= TYPE_PRECISION (type))
> (convert @1)))
>
> I think the truncation concerns that you brought up should be covered if the
> external expression type precision is greater than or equal to the internal
> expression type. There may be a sign extension operation (which is why the
> nop_convert check fails) but that shouldn't affect the value of the
> expression. And if the types involved are signed integers where
> overflow/underflow results in undefined behavior, the X - (X - Y) --> Y
> optimization should be legal.
>
> Please correct me if I'm wrong with either one of these options, or if you
> can think of a better option to fix the regression.
So to recap, we're looking to simplify 42 - (long int) (42 - 42 % x)
(simplified from gcc.dg/fold-minus-6.c), or
simply (new testcase):
long
fn1 (int x)
{
return 42L - (long)(42 - x);
}
where the existing pattern does not apply because the conversion is
not a NOP one:
(simplify
(minus (nop_convert1? (minus (nop_convert2? @0) @1)) @0)
(if (!ANY_INTEGRAL_TYPE_P (type)
|| TYPE_OVERFLOW_WRAPS (type))
(negate (view_convert @1))
(view_convert (negate @1
so let's consider replacing nop_convert1? with convert1? and thus obtain
(simplify
(minus (convert1? (minus (nop_convert2? @0) @1)) @0)
(if (!ANY_INTEGRAL_TYPE_P (type)
|| TYPE_OVERFLOW_WRAPS (type))
(negate (view_convert @1))
(view_convert (negate @1
given we still require a matching @0 (as in operand_requal_p) it looks like
a convert1 that is not the inverse of the nop_convert2, and thus also
a nop_convert
is only possible for constants (because operand_equal_p does not verify type
equality). Now - can we construct any testcase for which this conversion would
be wrong?
Richard.
> Thanks,
> Victor
>
>
>
>
> From: Richard Biener
> Sent: Monday, June 7, 2021 1:25 AM
> To: Victor Tong
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [EXTERNAL] Re: [PATCH] tree-optimization: Optimize division
> followed by multiply [PR95176]
>
> On Wed, Jun 2, 2021 at 10:55 PM Victor Tong wrote:
> >
> > Hi Richard,
> >
> > Thanks for reviewing my patch. I did a search online and you're right --
> > there isn't a vector modulo instruction. I'll remove the X * (Y / X) --> Y
> > - (Y % X) pattern and the existing X - (X / Y) * Y --> X % Y from
> > triggering on vector types.
> >
> > I looked into why the following pattern isn't triggering:
> >
> > (simplify
> >(minus @0 (nop_convert1? (minus (nop_convert2? @0) @1)))
> >(view_convert @1))
> >
> > The nop_converts expand into tree_nop_conversion_p checks. In fn2() of the
> > testsuite/gcc.dg/fold-minus-6.c, the expression during generic matching
> > looks like:
> >
> > 42 - (long int) (42 - 42 % x)
> >
> > When looking at the right-hand side of the expression (the (long int) (42 -
> > 42 % x)), the tree_nop_conversion_p check fails because of the type
> > precision difference. The expression inside of the cast has a 32-bit
> > precision and the outer expression has a 64-bit precision.
> >
> > I looked around at other patterns and it seems like nop_convert and
> > view_convert are used because of underflow/overflow concerns. I'm not
> > familiar with the two constructs. What's the difference between using them
> > and checking TYPE_OVERFLOW_UNDEFINED? In the scenario above, since
> >
Re: [PATCH] stor-layout: Don't create DECL_BIT_FIELD_REPRESENTATIVE for QUAL_UNION_TYPE [PR101062]
On Fri, 18 Jun 2021, Jakub Jelinek wrote:
> On Wed, Jun 16, 2021 at 09:45:17AM +0200, Jakub Jelinek via Gcc-patches wrote:
> > The following patch does create them, but treats all such bitfields as if
> > they were in a structure where the particular bitfield is the only field.
>
> While the patch passed bootstrap/regtest on the trunk, when trying to
> backport it to 11 branch the bootstrap failed with
> atree.ads:3844:34: size for "Node_Record" too small
> errors. Turns out the error is not about size being too small, but actually
> about size being non-constant, and comes from:
> /* In a FIELD_DECL of a RECORD_TYPE, this is a pointer to the storage
>representative FIELD_DECL. */
> #define DECL_BIT_FIELD_REPRESENTATIVE(NODE) \
> (FIELD_DECL_CHECK (NODE)->field_decl.qualifier)
>
> /* For a FIELD_DECL in a QUAL_UNION_TYPE, records the expression, which
>if nonzero, indicates that the field occupies the type. */
> #define DECL_QUALIFIER(NODE) (FIELD_DECL_CHECK (NODE)->field_decl.qualifier)
> so by setting up DECL_BIT_FIELD_REPRESENTATIVE in QUAL_UNION_TYPE we
> actually set or modify DECL_QUALIFIER and then construct size as COND_EXPRs
> with those bit field representatives (e.g. with array type) as conditions
> which doesn't fold into constant.
>
> The following patch fixes it by not creating DECL_BIT_FIELD_REPRESENTATIVEs
> for QUAL_UNION_TYPE as there is nowhere to store them,
>
> Bootstrapped/regtested on x86_64-linux and i686-linux (both trunk and
> 11 branch - there on top of the earlier patch backport). Ok for trunk and
> the backport?
>
> Shall we change tree.h to document that DECL_BIT_FIELD_REPRESENTATIVE
> is valid also on UNION_TYPE?
I think so.
> I see:
> tree-ssa-alias.c- if (TREE_CODE (type1) == RECORD_TYPE
> tree-ssa-alias.c: && DECL_BIT_FIELD_REPRESENTATIVE (field1))
> tree-ssa-alias.c:field1 = DECL_BIT_FIELD_REPRESENTATIVE (field1);
> tree-ssa-alias.c- if (TREE_CODE (type2) == RECORD_TYPE
> tree-ssa-alias.c: && DECL_BIT_FIELD_REPRESENTATIVE (field2))
> tree-ssa-alias.c:field2 = DECL_BIT_FIELD_REPRESENTATIVE (field2);
> Shall we change that to || == UNION_TYPE or do we assume all fields
> are overlapping in a UNION_TYPE already?
We don't assume that - for example the Fortran FE uses union types
to lay out equivalences which have multiple members at non-zero offsets,
eventually partly overlapping. IIRC at least.
But Fortran doesn't have bitfields (does it?). Still I guess updating
the checks would be prefered.
> At other spots (asan, ubsan, expr.c) it is unclear what will happen
> if they see a QUAL_UNION_TYPE with a DECL_QUALIFIER (or does the Ada FE
> lower that somehow)?
I don't think we see implicit uses of DECL_QUALIFIER, instead I think
that's reflected into DECL_FIELD_OFFSET.
OK.
Richard.
> 2021-06-18 Jakub Jelinek
>
> PR middle-end/101062
> * stor-layout.c (finish_bitfield_layout): Don't add bitfield
> representatives in QUAL_UNION_TYPE.
>
> --- gcc/stor-layout.c.jj 2021-06-16 12:17:49.254221954 +0200
> +++ gcc/stor-layout.c 2021-06-17 11:36:13.011822974 +0200
> @@ -2172,6 +2172,9 @@ finish_bitfield_layout (tree t)
>tree field, prev;
>tree repr = NULL_TREE;
>
> + if (TREE_CODE (t) == QUAL_UNION_TYPE)
> +return;
> +
>for (prev = NULL_TREE, field = TYPE_FIELDS (t);
> field; field = DECL_CHAIN (field))
> {
>
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
[PATCH] Merge vec_addsub patterns
This merges the vec_addsub3 patterns using a mode attribute
for the vec_merge merge operand.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
I'd appreciate an extra eye since this is the first time I'm
doing such.
OK as a followup to the addsub pattern renaming?
Thanks,
Richard.
2021-06-18 Richard Biener
* config/i386/sse.md (vec_addsubv4df3, vec_addsubv2df3,
vec_addsubv8sf3, vec_addsubv4sf3): Merge into ...
(vec_addsub3): ... using a new addsub_cst mode attribute.
---
gcc/config/i386/sse.md | 72 --
1 file changed, 14 insertions(+), 58 deletions(-)
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 038e2cd90d4..930e777ec08 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -2396,69 +2396,25 @@
(set_attr "prefix" "")
(set_attr "mode" "")])
-(define_insn "vec_addsubv4df3"
- [(set (match_operand:V4DF 0 "register_operand" "=x")
- (vec_merge:V4DF
- (minus:V4DF
- (match_operand:V4DF 1 "register_operand" "x")
- (match_operand:V4DF 2 "nonimmediate_operand" "xm"))
- (plus:V4DF (match_dup 1) (match_dup 2))
- (const_int 5)))]
- "TARGET_AVX"
- "vaddsubpd\t{%2, %1, %0|%0, %1, %2}"
- [(set_attr "type" "sseadd")
- (set_attr "prefix" "vex")
- (set_attr "mode" "V4DF")])
-
-(define_insn "vec_addsubv2df3"
- [(set (match_operand:V2DF 0 "register_operand" "=x,x")
- (vec_merge:V2DF
- (minus:V2DF
- (match_operand:V2DF 1 "register_operand" "0,x")
- (match_operand:V2DF 2 "vector_operand" "xBm,xm"))
- (plus:V2DF (match_dup 1) (match_dup 2))
- (const_int 1)))]
- "TARGET_SSE3"
- "@
- addsubpd\t{%2, %0|%0, %2}
- vaddsubpd\t{%2, %1, %0|%0, %1, %2}"
- [(set_attr "isa" "noavx,avx")
- (set_attr "type" "sseadd")
- (set_attr "atom_unit" "complex")
- (set_attr "prefix" "orig,vex")
- (set_attr "mode" "V2DF")])
-
-(define_insn "vec_addsubv8sf3"
- [(set (match_operand:V8SF 0 "register_operand" "=x")
- (vec_merge:V8SF
- (minus:V8SF
- (match_operand:V8SF 1 "register_operand" "x")
- (match_operand:V8SF 2 "nonimmediate_operand" "xm"))
- (plus:V8SF (match_dup 1) (match_dup 2))
- (const_int 85)))]
- "TARGET_AVX"
- "vaddsubps\t{%2, %1, %0|%0, %1, %2}"
- [(set_attr "type" "sseadd")
- (set_attr "prefix" "vex")
- (set_attr "mode" "V8SF")])
-
-(define_insn "vec_addsubv4sf3"
- [(set (match_operand:V4SF 0 "register_operand" "=x,x")
- (vec_merge:V4SF
- (minus:V4SF
- (match_operand:V4SF 1 "register_operand" "0,x")
- (match_operand:V4SF 2 "vector_operand" "xBm,xm"))
- (plus:V4SF (match_dup 1) (match_dup 2))
- (const_int 5)))]
+(define_mode_attr addsub_cst [(V4DF "5") (V2DF "1")
+ (V4SF "5") (V8SF "85")])
+(define_insn "vec_addsub3"
+ [(set (match_operand:VF_128_256 0 "register_operand" "=x,x")
+(vec_merge:VF_128_256
+ (minus:VF_128_256
+ (match_operand:VF_128_256 1 "register_operand" "0,x")
+ (match_operand:VF_128_256 2 "vector_operand" "xBm, xm"))
+ (plus:VF_128_256 (match_dup 1) (match_dup 2))
+ (const_int )))]
"TARGET_SSE3"
"@
- addsubps\t{%2, %0|%0, %2}
- vaddsubps\t{%2, %1, %0|%0, %1, %2}"
+ addsub\t{%2, %0|%0, %2}
+ vaddsub\t{%2, %1, %0|%0, %1, %2}"
[(set_attr "isa" "noavx,avx")
(set_attr "type" "sseadd")
+ (set_attr "atom_unit" "other,complex")
(set_attr "prefix" "orig,vex")
- (set_attr "prefix_rep" "1,*")
- (set_attr "mode" "V4SF")])
+ (set_attr "mode" "")])
(define_split
[(set (match_operand:VF_128_256 0 "register_operand")
--
2.26.2
ipa-modref: merge flags when adding escape
While working on some function splitting changes, I've got a
miscompilation in stagefeedback that I've tracked down to a
complicated scenario:
- ipa-modref miscomputes a function parameter as having EAF_DIRECT,
because it's dereferenced and passed on to another function, but
add_escape_point does not update the flags for the dereferenced
SSA_NAME passed as a parameter, and the EAF_UNUSED in the value that
first initializes it, that remains unchanged throughout, causes
deref_flags to set EAF_DIRECT, among other flags.
- structalias, seeing the EAF_DIRECT in the parameter for that
function, refrains from mak[ing]_transitive_closure_constraints for
a pointer passed in that parameter.
- tree dse2 concludes the initializer of the pointed-to variable is a
dead store and removes it.
The test depends on gimple passes's processing of functions in a
certain order to expose parm flag miscomputed by ipa-modref. A
different order may enable the non-ipa modref2 pass to compute flags
differently and avoid the problem.
I've arranged for add_escape_point to merge flags, as the non-ipa path
does. I've also caught and fixed an error in the dumping of escaping
flags.
The problem affects at least trunk and gcc-11. I've so far bootstrapped
GCC 11, and I'm now regstrapping trunk. Ok to install if it passes?
for gcc/ChangeLog
* ipa-modref.c (modref_lattice::add_escape_point): Merge
min_flags into flags.
(modref_lattice::dump): Fix escape_point's min_flags dumping.
for gcc/testsuite/ChangeLog
* c-c++-common/modref-dse.c: New.
---
gcc/ipa-modref.c|4 ++-
gcc/testsuite/c-c++-common/modref-dse.c | 38 +++
2 files changed, 40 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/c-c++-common/modref-dse.c
diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index d5a8332fb5559..3b0830cb8759c 100644
--- a/gcc/ipa-modref.c
+++ b/gcc/ipa-modref.c
@@ -1392,7 +1392,7 @@ modref_lattice::dump (FILE *out, int indent) const
fprintf (out, "%*s Arg %i (%s) min flags", indent, "",
escape_points[i].arg,
escape_points[i].direct ? "direct" : "indirect");
- dump_eaf_flags (out, flags, false);
+ dump_eaf_flags (out, escape_points[i].min_flags, false);
fprintf (out, " in call ");
print_gimple_stmt (out, escape_points[i].call, 0);
}
@@ -1411,7 +1411,7 @@ modref_lattice::add_escape_point (gcall *call, int arg,
int min_flags,
/* If we already determined flags to be bad enough,
* we do not need to record. */
- if ((flags & min_flags) == flags)
+ if (!merge (min_flags))
return false;
FOR_EACH_VEC_ELT (escape_points, i, ep)
diff --git a/gcc/testsuite/c-c++-common/modref-dse.c
b/gcc/testsuite/c-c++-common/modref-dse.c
new file mode 100644
index 0..5f64e8f4b5942
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/modref-dse.c
@@ -0,0 +1,38 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-dse2-details" } */
+/* { dg-final { scan-tree-dump-not "Deleted dead store" "dse2" } } */
+
+struct foo { unsigned long bar; };
+
+unsigned y;
+
+static int __attribute__ ((__noinline__, __noclone__))
+wrapped (struct foo *p, int i);
+
+static int wrapper (struct foo *p);
+
+static int __attribute__ ((__noclone__))
+wrapper (struct foo *p) {
+ return wrapped (p, 1);
+}
+
+static int __attribute__ ((__noinline__, __noclone__))
+dind (struct foo **pp);
+
+int __attribute__ ((__noclone__, __no_reorder__))
+xfn () {
+ struct foo x = { 0xBADC0FFE };
+ struct foo *p =
+ return dind ();
+}
+
+static int __attribute__ ((__noinline__, __no_reorder__))
+wrapped (struct foo *p, int i) {
+ return p->bar + i == y++;
+}
+
+static int __attribute__ ((__noinline__, __noclone__, __no_reorder__))
+dind (struct foo **pp) {
+ wrapper (*pp);
+ return 0;
+}
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts. Ask me about
[Ada] Fix detection of overlapping actuals with renamings
Routine Denotes_Same_Object wrongly handled renamings of renamings. In a code like this: B : Integer renames A; C : Integer renames B; names "B" and "C" differ and their renamed object names "A" and "B" differ too. This patch rewrites this routine to literally follow the RM, which fixes the problem with renamings. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * sem_util.adb (Denotes_Same_Object): Explicitly test for node kinds being the same; deal with renamings one-by-one; adjust numbers in references to the Ada RM.diff --git a/gcc/ada/sem_util.adb b/gcc/ada/sem_util.adb --- a/gcc/ada/sem_util.adb +++ b/gcc/ada/sem_util.adb @@ -7388,84 +7388,46 @@ package body Sem_Util is return True; end Is_Valid_Renaming; - -- Local variables - - Obj1 : Node_Id := A1; - Obj2 : Node_Id := A2; - -- Start of processing for Denotes_Same_Object begin - -- Both names statically denote the same stand-alone object or parameter - -- (RM 6.4.1(6.5/3)) + -- Both names statically denote the same stand-alone object or + -- parameter (RM 6.4.1(6.6/3)). - if Is_Entity_Name (Obj1) -and then Is_Entity_Name (Obj2) -and then Entity (Obj1) = Entity (Obj2) + if Is_Entity_Name (A1) +and then Is_Entity_Name (A2) +and then Entity (A1) = Entity (A2) then return True; - end if; - - -- For renamings, the prefix of any dereference within the renamed - -- object_name is not a variable, and any expression within the - -- renamed object_name contains no references to variables nor - -- calls on nonstatic functions (RM 6.4.1(6.10/3)). - - if Is_Renaming (Obj1) then - if Is_Valid_Renaming (Obj1) then -Obj1 := Renamed_Entity (Entity (Obj1)); - else -return False; - end if; - end if; - - if Is_Renaming (Obj2) then - if Is_Valid_Renaming (Obj2) then -Obj2 := Renamed_Entity (Entity (Obj2)); - else -return False; - end if; - end if; - - -- No match if not same node kind (such cases are handled by - -- Denotes_Same_Prefix) - - if Nkind (Obj1) /= Nkind (Obj2) then - return False; - - -- After handling valid renamings, one of the two names statically - -- denoted a renaming declaration whose renamed object_name is known - -- to denote the same object as the other (RM 6.4.1(6.10/3)) - - elsif Is_Entity_Name (Obj1) then - if Is_Entity_Name (Obj2) then -return Entity (Obj1) = Entity (Obj2); - else -return False; - end if; -- Both names are selected_components, their prefixes are known to -- denote the same object, and their selector_names denote the same - -- component (RM 6.4.1(6.6/3)). + -- component (RM 6.4.1(6.7/3)). - elsif Nkind (Obj1) = N_Selected_Component then - return Denotes_Same_Object (Prefix (Obj1), Prefix (Obj2)) + elsif Nkind (A1) = N_Selected_Component +and then Nkind (A2) = N_Selected_Component + then + return Denotes_Same_Object (Prefix (A1), Prefix (A2)) and then - Entity (Selector_Name (Obj1)) = Entity (Selector_Name (Obj2)); + Entity (Selector_Name (A1)) = Entity (Selector_Name (A2)); -- Both names are dereferences and the dereferenced names are known to - -- denote the same object (RM 6.4.1(6.7/3)) + -- denote the same object (RM 6.4.1(6.8/3)). - elsif Nkind (Obj1) = N_Explicit_Dereference then - return Denotes_Same_Object (Prefix (Obj1), Prefix (Obj2)); + elsif Nkind (A1) = N_Explicit_Dereference +and then Nkind (A2) = N_Explicit_Dereference + then + return Denotes_Same_Object (Prefix (A1), Prefix (A2)); -- Both names are indexed_components, their prefixes are known to denote -- the same object, and each of the pairs of corresponding index values -- are either both static expressions with the same static value or both - -- names that are known to denote the same object (RM 6.4.1(6.8/3)) + -- names that are known to denote the same object (RM 6.4.1(6.9/3)). - elsif Nkind (Obj1) = N_Indexed_Component then - if not Denotes_Same_Object (Prefix (Obj1), Prefix (Obj2)) then + elsif Nkind (A1) = N_Indexed_Component +and then Nkind (A2) = N_Indexed_Component + then + if not Denotes_Same_Object (Prefix (A1), Prefix (A2)) then return False; else declare @@ -7473,8 +7435,8 @@ package body Sem_Util is Indx2 : Node_Id; begin - Indx1 := First (Expressions (Obj1)); - Indx2 := First (Expressions (Obj2)); + Indx1 := First (Expressions (A1)); + Indx2 := First (Expressions (A2));
[Ada] Additional error checking on index constraints with fixed-lower-bound ranges
Error checks are added to disallow index constraints given with a
mixture of constrained and fixed-lower-bound ranges, and also to
disallow an index constraint with a fixed-lower-bound index applied to a
type or subtype with fixed-lower-bound indexes.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_ch3.adb (Constrain_Array): Add error checking for
fixed-lower-bound and constrained index ranges applied
inappropriately on subtypes of unconstrained and
fixed-lower-bound array types.
(Constrain_Index): Correct and refine comment related to
fixed-lower-bound index ranges.diff --git a/gcc/ada/sem_ch3.adb b/gcc/ada/sem_ch3.adb
--- a/gcc/ada/sem_ch3.adb
+++ b/gcc/ada/sem_ch3.adb
@@ -13373,8 +13373,40 @@ package body Sem_Ch3 is
-- entity will need to be marked as being a fixed-lower-bound
-- array subtype.
- if Is_Fixed_Lower_Bound_Index_Subtype (Etype (S)) then
- Is_FLB_Array_Subtype := True;
+ if S = First (Constraints (C)) then
+ Is_FLB_Array_Subtype :=
+Is_Fixed_Lower_Bound_Index_Subtype (Etype (S));
+
+ -- If the parent subtype (or should this be Etype of that?)
+ -- is an FLB array subtype, we flag an error, because we
+ -- don't currently allow subtypes of such subtypes to
+ -- specify a fixed lower bound for any of their indexes,
+ -- even if the index of the parent subtype is a "range <>"
+ -- index.
+
+ if Is_FLB_Array_Subtype
+and then Is_Fixed_Lower_Bound_Array_Subtype (T)
+ then
+ Error_Msg_NE
+ ("index with fixed lower bound not allowed for subtype "
+ & "of fixed-lower-bound }", S, T);
+
+ Is_FLB_Array_Subtype := False;
+ end if;
+
+ elsif Is_FLB_Array_Subtype
+ and then not Is_Fixed_Lower_Bound_Index_Subtype (Etype (S))
+ then
+ Error_Msg_NE
+("constrained index not allowed for fixed-lower-bound "
+ & "subtype of}", S, T);
+
+ elsif not Is_FLB_Array_Subtype
+ and then Is_Fixed_Lower_Bound_Index_Subtype (Etype (S))
+ then
+ Error_Msg_NE
+("index with fixed lower bound not allowed for "
+ & "constrained subtype of}", S, T);
end if;
Next (Index);
@@ -14396,9 +14428,9 @@ package body Sem_Ch3 is
Set_First_Rep_Item (Def_Id, First_Rep_Item (T));
-- If this is a range for a fixed-lower-bound subtype, then set the
- -- index itype's lower bound to the FLB and the index type's upper bound
- -- to the high bound of the index subtype's high bound, mark the itype
- -- as an FLB index subtype, and set the range's Etype to the itype.
+ -- index itype's low bound to the FLB and the index itype's upper bound
+ -- to the high bound of the parent array type's index subtype. Also,
+ -- mark the itype as an FLB index subtype.
if Nkind (S) = N_Range and then Is_FLB_Index then
Set_Scalar_Range
[Ada] Fix detection of overlapping slices indexed by characters
Slices that denote the same objects can be indexed either by integer or character literals, but the latter was not detected. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * sem_util.adb (Denotes_Same_Object): Handle character literals just like integer literals.diff --git a/gcc/ada/sem_util.adb b/gcc/ada/sem_util.adb --- a/gcc/ada/sem_util.adb +++ b/gcc/ada/sem_util.adb @@ -7504,13 +7504,20 @@ package body Sem_Util is then return Denotes_Same_Object (A1, Renamed_Entity (Entity (A2))); - -- In the recursion, literals appear as slice bounds + -- In the recursion, integer literals appear as slice bounds elsif Nkind (A1) = N_Integer_Literal and then Nkind (A2) = N_Integer_Literal then return Intval (A1) = Intval (A2); + -- Likewise for character literals + + elsif Nkind (A1) = N_Character_Literal +and then Nkind (A2) = N_Character_Literal + then + return Char_Literal_Value (A1) = Char_Literal_Value (A2); + else return False; end if;
[Ada] Ada2020: AI12-0195 overriding class-wide pre/post conditions
This patch does not modify the functionality of the frontend; it ensures the correct decoration of wrappers of class-wide pre/post conditions required for AI12-0195. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * contracts.adb (Process_Spec_Postconditions): Add missing support for aliased subprograms and handle wrappers of class-wide pre/post conditions. (Process_Inherited_Preconditions): Add missing support for aliased subprograms and handle wrappers of class-wide pre/post conditions. * einfo.ads (Class_Wide_Clone): Fix typo. (Is_Class_Wide_Clone): Removed since it is not referenced. (Is_Wrapper): Documenting new flag. (LSP_Subprogram): Documenting new attribute. * exp_ch3.adb (Make_Controlling_Function_Wrappers): Decorate wrapper as Is_Wrapper and adjust call to Override_Dispatching_Operation. * freeze.adb (Build_Inherited_Condition_Pragmas): Fix typo in documentation. (Check_Inherited_Conditions): Handle LSP wrappers; ensure correct decoration of LSP wrappers. * gen_il-fields.ads (Is_Class_Wide_Clone): Removed. (Is_Wrapper): Added. (LSP_Subprogram): Added. * gen_il-gen-gen_entities.adb (Is_Class_Wide_Clone): Removed. (Is_Wrapper): Added. (LSP_Subprogram): Added. * gen_il-internals.adb (Image): Adding uppercase image of LSP_Subprogram. * sem_ch6.adb (New_Overloaded_Entity): Fix decoration of LSP wrappers. * sem_disp.ads (Override_Dispatching_Operation): Remove parameter Is_Wrapper; no longer needed. * sem_disp.adb (Check_Dispatching_Operation): Adjust assertion. (Override_Dispatching_Operation): Remove parameter Is_Wrapper; no longer needed. * treepr.adb (Image): Adding uppercase image of LSP_Subprogram.diff --git a/gcc/ada/contracts.adb b/gcc/ada/contracts.adb --- a/gcc/ada/contracts.adb +++ b/gcc/ada/contracts.adb @@ -2610,7 +2610,21 @@ package body Contracts is for Index in Subps'Range loop Subp_Id := Subps (Index); - Items := Contract (Subp_Id); + + if Present (Alias (Subp_Id)) then + Subp_Id := Ultimate_Alias (Subp_Id); + end if; + + -- Wrappers of class-wide pre/post conditions reference the + -- parent primitive that has the inherited contract. + + if Is_Wrapper (Subp_Id) + and then Present (LSP_Subprogram (Subp_Id)) + then + Subp_Id := LSP_Subprogram (Subp_Id); + end if; + + Items := Contract (Subp_Id); if Present (Items) then Prag := Pre_Post_Conditions (Items); @@ -2892,7 +2906,21 @@ package body Contracts is for Index in Subps'Range loop Subp_Id := Subps (Index); - Items := Contract (Subp_Id); + + if Present (Alias (Subp_Id)) then + Subp_Id := Ultimate_Alias (Subp_Id); + end if; + + -- Wrappers of class-wide pre/post conditions reference the + -- parent primitive that has the inherited contract. + + if Is_Wrapper (Subp_Id) + and then Present (LSP_Subprogram (Subp_Id)) + then + Subp_Id := LSP_Subprogram (Subp_Id); + end if; + + Items := Contract (Subp_Id); if Present (Items) then Prag := Pre_Post_Conditions (Items); diff --git a/gcc/ada/einfo.ads b/gcc/ada/einfo.ads --- a/gcc/ada/einfo.ads +++ b/gcc/ada/einfo.ads @@ -612,7 +612,7 @@ package Einfo is --Class_Wide_Clone -- Defined on subprogram entities. Set if the subprogram has a class-wide --- ore- or postcondition, and the expression contains calls to other +-- pre- or postcondition, and the expression contains calls to other -- primitive funtions of the type. Used to implement properly the -- semantics of inherited operations whose class-wide condition may -- be different from that of the ancestor (See AI012-0195). @@ -2385,12 +2385,6 @@ package Einfo is -- Defined in all entities. Set only for defining entities of program -- units that are child units (but False for subunits). ---Is_Class_Wide_Clone --- Defined on subprogram entities. Set for subprograms built in order --- to implement properly the inheritance of class-wide pre- or post- --- conditions when the condition contains calls to other primitives --- of the ancestor type. Used to implement AI12-0195. - --Is_Class_Wide_Equivalent_Type -- Defined in record types and subtypes. Set to True, if the type acts -- as a class-wide equivalent type, i.e. the Equivalent_Type field of @@ -3408,6 +3402,11 @@ package Einfo
[Ada] Make "gcc -gnatDGL" handle unterminated last lines properly
This patch fixes a bug in which "gcc -gnatDGL" raises an unhandled
Constraint_Error in checks-on mode if the last line in the file is not
terminated with a line terminator.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sprint.adb (Write_Source_Line): Check for EOF in
Line_Terminator loop. Note that when a source file is read in,
an EOF character is added to the end.diff --git a/gcc/ada/sprint.adb b/gcc/ada/sprint.adb
--- a/gcc/ada/sprint.adb
+++ b/gcc/ada/sprint.adb
@@ -4847,7 +4847,10 @@ package body Sprint is
Write_Int (Int (L));
Write_Str (": ");
- while Src (Loc) not in Line_Terminator loop
+ -- We need to check for EOF here, in case the last line of the source
+ -- file does not have a Line_Terminator.
+
+ while Src (Loc) not in Line_Terminator | EOF loop
Write_Char (Src (Loc));
Loc := Loc + 1;
end loop;
[Ada] Avoid passing Enum_Lit'Size to the back end
Constant fold Enum_Lit'Size so the back end won't see it. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * sem_attr.adb (Eval_Attribute): For Enum_Lit'Size, use Enum_Type'Object_Size.diff --git a/gcc/ada/sem_attr.adb b/gcc/ada/sem_attr.adb --- a/gcc/ada/sem_attr.adb +++ b/gcc/ada/sem_attr.adb @@ -7983,14 +7983,27 @@ package body Sem_Attr is end if; end; - -- For Size, give size of object if available, otherwise we - -- cannot fold Size. - elsif Id = Attribute_Size then +-- For Enum_Lit'Size, use Enum_Type'Object_Size. Taking the 'Size +-- of a literal is kind of a strange thing to do, so we don't want +-- to pass this oddity on to the back end. Note that Etype of an +-- enumeration literal is always a (base) type, never a +-- constrained subtype, so the Esize is always known. + if Is_Entity_Name (P) - and then Known_Static_Esize (Entity (P)) + and then Ekind (Entity (P)) = E_Enumeration_Literal +then + pragma Assert (Known_Static_Esize (Etype (P))); + Compile_Time_Known_Attribute (N, Esize (Etype (P))); + +-- Otherwise, if Size is available, use that + +elsif Is_Entity_Name (P) and then Known_Static_Esize (Entity (P)) then Compile_Time_Known_Attribute (N, Esize (Entity (P))); + +-- Otherwise, we cannot fold + else Check_Expressions; end if;
[Ada] Premature freezing of types
GNAT was freezing prematurely any type referenced in a subprogram profile as part of freezing, regardless of the scope involved, causing premature freezing of types and therefore preventing declaration of additional primitive operations. This is now almost fully fixed. There is one remaining catch related to the handling of expression functions whose body sometimes perform dispatching calls: when these dispatching calls involve types in the relevant scope, we still have to perform an early freeze in order to properly build the dispatch table which would otherwise be unavailable and cause many errors down the path. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * exp_ch4.adb (Expand_N_Quantified_Expression): Ensure the type of the name of a "for of" loop is frozen. * exp_disp.adb (Check_Premature_Freezing): Complete condition to take into account a private type completed by another private type now that the freezing rule are better implemented. * freeze.adb (Freeze_Entity.Freeze_Profile): Do not perform an early freeze on types if not in the proper scope. Special case expression functions that requires access to the dispatch table. (Should_Freeze_Type): New. * sem_ch13.adb (Resolve_Aspect_Expressions): Prevent assert failure in case of an invalid tree (previous errors detected). * sem_res.adb (Resolve): Remove kludge related to entities causing incorrect premature freezing. * sem_util.adb (Ensure_Minimum_Decoration): Add protection against non base types.diff --git a/gcc/ada/exp_ch4.adb b/gcc/ada/exp_ch4.adb --- a/gcc/ada/exp_ch4.adb +++ b/gcc/ada/exp_ch4.adb @@ -10851,10 +10851,11 @@ package body Exp_Ch4 is Var : Entity_Id; begin - -- Ensure that the bound variable is properly frozen. We must do - -- this before expansion because the expression is about to be - -- converted into a loop, and resulting freeze nodes may end up - -- in the wrong place in the tree. + -- Ensure that the bound variable as well as the type of Name of the + -- Iter_Spec if present are properly frozen. We must do this before + -- expansion because the expression is about to be converted into a + -- loop, and resulting freeze nodes may end up in the wrong place in the + -- tree. if Present (Iter_Spec) then Var := Defining_Identifier (Iter_Spec); @@ -10869,6 +10870,10 @@ package body Exp_Ch4 is P := Parent (P); end loop; + if Present (Iter_Spec) then +Freeze_Before (P, Etype (Name (Iter_Spec))); + end if; + Freeze_Before (P, Etype (Var)); end; diff --git a/gcc/ada/exp_disp.adb b/gcc/ada/exp_disp.adb --- a/gcc/ada/exp_disp.adb +++ b/gcc/ada/exp_disp.adb @@ -4052,6 +4052,7 @@ package body Exp_Disp is if Present (N) and then Is_Private_Type (Typ) and then No (Full_View (Typ)) + and then not Has_Private_Declaration (Typ) and then not Is_Generic_Type (Typ) and then not Is_Tagged_Type (Typ) and then not Is_Frozen (Typ) @@ -4070,6 +4071,7 @@ package body Exp_Disp is if not Is_Tagged_Type (Typ) and then Present (Comp) and then not Is_Frozen (Comp) + and then not Has_Private_Declaration (Comp) and then not Is_Actual_For_Formal_Incomplete_Type (Comp) then Error_Msg_Sloc := Sloc (Subp); diff --git a/gcc/ada/freeze.adb b/gcc/ada/freeze.adb --- a/gcc/ada/freeze.adb +++ b/gcc/ada/freeze.adb @@ -186,6 +186,72 @@ package body Freeze is -- the designated type. Otherwise freezing the access type does not freeze -- the designated type. + function Should_Freeze_Type (Typ : Entity_Id; E : Entity_Id) return Boolean; + -- If Typ is in the current scope or in an instantiation, then return True. + -- ???Expression functions (represented by E) shouldn't freeze types in + -- general, but our current expansion and freezing model requires an early + -- freezing when the dispatch table is needed or when building an aggregate + -- with a subtype of Typ, so return True also in this case. + -- Note that expression function completions do freeze and are + -- handled in Sem_Ch6.Analyze_Expression_Function. + + + -- Should_Freeze_Type -- + + + function Should_Freeze_Type + (Typ : Entity_Id; E : Entity_Id) return Boolean + is + function Is_Dispatching_Call_Or_Aggregate +(N : Node_Id) return Traverse_Result; + -- Return Abandon if N is a dispatching call to a subprogram + -- declared in the same scope as Typ or an aggregate whose type + -- is Typ. + + -- + -- Is_Dispatching_Call_Or_Aggregate -- +
[Ada] Remove AAMP from compiler sources
AAMP is no longer supported. This patch removes AAMP-specific code. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * ada_get_targ.adb, aspects.ads, checks.adb, cstand.adb, einfo.ads, exp_attr.adb, freeze.adb, get_targ.adb, libgnat/a-textio.ads, libgnat/g-memdum.ads, libgnat/s-scaval__128.adb, libgnat/s-scaval.adb, make.adb, osint.ads, par-prag.adb, sem_ch13.adb, sem_prag.adb, sem_prag.ads, set_targ.adb, set_targ.ads, snames.ads-tmpl, targparm.ads, types.ads: Remove AAMP-specific code. * switch.ads: Minor reformatting. * gen_il-fields.ads, gen_il-gen.adb, gen_il-gen-gen_entities.adb, gen_il-types.ads, einfo-utils.adb, einfo-utils.ads: Package Types now contains "type Float_Rep_Kind is (IEEE_Binary);", which used to also have an enumeral AAMP. Gen_IL can't handle fields of this type, which would be zero sized. Therefore, we move the Float_Rep field into Einfo.Utils as a synthesized attribute. (We do not delete the field altogether, in case we want new floating-point representations in the future.) * doc/gnat_rm/implementation_defined_pragmas.rst, doc/gnat_rm/implementation_defined_aspects.rst, doc/gnat_ugn/building_executable_programs_with_gnat.rst, doc/gnat_ugn/the_gnat_compilation_model.rst: Remove AAMP-specific documentation. * gnat_rm.texi, gnat_ugn.texi: Regenerate. patch.diff.gz Description: application/gzip
[Ada] Fix inaccuracies in signal handler trampoline for aarch64-vxworks
Fix a couple of inaccuracies in the VxWorks signal handler trampoline
for aarch64:
- REGNO_PC_OFFSET, used as the cfi return column number, is better
sync'ed with the back-end's DWARF_ALT_FRAME_RETURN_COLUMN.
- R18 is used by VxWorks for internal purposes so is best left out of
the CFI notes telling the unwinder where to find values to restore.
Figured out of code reading after observing failures of tests attempting
to catch exceptions expected to be raised out of signals triggered on
purpose. The tests pass after the change.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sigtramp-vxworks-target.inc (__aarch64__): Sync
REGNO_PC_OFFSET with the back-end DWARF_ALT_FRAME_RETURN_COLUMN.
In CFI_COMMON_REGS, leave r18 alone, VxWorks private.diff --git a/gcc/ada/sigtramp-vxworks-target.inc b/gcc/ada/sigtramp-vxworks-target.inc
--- a/gcc/ada/sigtramp-vxworks-target.inc
+++ b/gcc/ada/sigtramp-vxworks-target.inc
@@ -100,7 +100,7 @@
#define FUNCTION "%function"
#ifdef __aarch64__
-#define REGNO_PC_OFFSET 80 /* aka V16, a scratch register */
+#define REGNO_PC_OFFSET 96 /* DWARF_ALT_FRAME_RETURN_COLUMN */
#else
#define REGNO_PC_OFFSET 15 /* PC_REGNUM */
#endif
@@ -375,7 +375,7 @@ TCR(COMMON_CFI(G_REG_OFFSET(14))) \
TCR(COMMON_CFI(G_REG_OFFSET(15))) \
TCR(COMMON_CFI(G_REG_OFFSET(16))) \
TCR(COMMON_CFI(G_REG_OFFSET(17))) \
-TCR(COMMON_CFI(G_REG_OFFSET(18))) \
+CR("# Leave alone R18, VxWorks reserved\n") \
TCR(COMMON_CFI(G_REG_OFFSET(19))) \
TCR(COMMON_CFI(G_REG_OFFSET(20))) \
TCR(COMMON_CFI(G_REG_OFFSET(21))) \
[Ada] Error issued on string literal assigned to fixed-lower-bound array
The compiler incorrectly flags a string literal used to initialize an array object with a nominal fixed-lower-bound array subtype (and in other fixed-lower-bound sliding contexts). String literals will already be given proper bounds when in such contexts based on the applicable constraint, so no sliding conversion is needed. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * exp_util.adb (Expand_Sliding_Conversion): Move test of Is_Fixed_Lower_Bound_Subtype to an assertion. Exclude string literals from sliding expansion.diff --git a/gcc/ada/exp_util.adb b/gcc/ada/exp_util.adb --- a/gcc/ada/exp_util.adb +++ b/gcc/ada/exp_util.adb @@ -5323,7 +5323,8 @@ package body Exp_Util is procedure Expand_Sliding_Conversion (N : Node_Id; Arr_Typ : Entity_Id) is pragma Assert (Is_Array_Type (Arr_Typ) - and then not Is_Constrained (Arr_Typ)); + and then not Is_Constrained (Arr_Typ) + and then Is_Fixed_Lower_Bound_Array_Subtype (Arr_Typ)); Constraints : List_Id; Index : Node_Id := First_Index (Arr_Typ); @@ -5342,7 +5343,10 @@ package body Exp_Util is All_FLBs_Match : Boolean := True; begin - if Is_Fixed_Lower_Bound_Array_Subtype (Arr_Typ) then + -- Sliding should never be needed for string literals, because they have + -- their bounds set according to the applicable index constraint. + + if Nkind (N) /= N_String_Literal then Constraints := New_List; Act_Subt := Get_Actual_Subtype (N);
[Ada] Missing check for assigning too-large array to fixed-lower-bound object
The compiler was failing to perform a check on a conversion of an array that has a length that exceeds the range of the index subtype of the target subtype of the conversion when the target subtype is an unconstrained array subtype with a fixed lower bound (FLB). The FLB array subtype's index range had its subtype set to the base type of the parent array type's index subtype rather than the index subtype itself, resulting in failure to impose a proper range check on the conversion. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * sem_ch3.adb (Constrain_Index): Set the High_Bound of a fixed-lower-bound subtype's range to T (the subtype of the FLB index being constrained) rather than Base_Type (T).diff --git a/gcc/ada/sem_ch3.adb b/gcc/ada/sem_ch3.adb --- a/gcc/ada/sem_ch3.adb +++ b/gcc/ada/sem_ch3.adb @@ -14397,7 +14397,7 @@ package body Sem_Ch3 is -- If this is a range for a fixed-lower-bound subtype, then set the -- index itype's lower bound to the FLB and the index type's upper bound - -- to the high bound of the index base type's high bound, mark the itype + -- to the high bound of the index subtype's high bound, mark the itype -- as an FLB index subtype, and set the range's Etype to the itype. if Nkind (S) = N_Range and then Is_FLB_Index then @@ -14405,7 +14405,7 @@ package body Sem_Ch3 is (Def_Id, Make_Range (Sloc (S), Low_Bound => Low_Bound (S), - High_Bound => Type_High_Bound (Base_Type (T; + High_Bound => Type_High_Bound (T))); Set_Is_Fixed_Lower_Bound_Index_Subtype (Def_Id); else
[Ada] Warn about overlapping actuals in all versions of Ada
Overlapping actuals of elementary types are illegal since Ada 2012; all other overlapping actuals are now reported as warnings regardless of the Ada version (because they are equally suspicious). We even had a comment: "Overlap is only illegal in Ada 2012 in the case of elementary types (passed by copy). For other types we always have a warning in all versions." but it was not really implemented until now. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * sem_warn.adb (Warn_On_Overlapping_Actuals): Cleanup conditions related to Ada_Version.diff --git a/gcc/ada/sem_warn.adb b/gcc/ada/sem_warn.adb --- a/gcc/ada/sem_warn.adb +++ b/gcc/ada/sem_warn.adb @@ -3725,11 +3725,6 @@ package body Sem_Warn is -- Start of processing for Warn_On_Overlapping_Actuals begin - - if Ada_Version < Ada_2012 and then not Warn_On_Overlap then - return; - end if; - -- Exclude calls rewritten as enumeration literals if Nkind (N) not in N_Subprogram_Call | N_Entry_Call_Statement then @@ -3823,14 +3818,13 @@ package body Sem_Warn is then null; - -- Under Ada 2012 we only report warnings on overlapping - -- arrays and record types if switch is set. + -- We only report warnings on overlapping arrays and record + -- types if switch is set. - elsif Ada_Version >= Ada_2012 + elsif not Warn_On_Overlap and then not (Is_Elementary_Type (Etype (Form1)) and then Is_Elementary_Type (Etype (Form2))) -and then not Warn_On_Overlap then null; @@ -3844,7 +3838,7 @@ package body Sem_Warn is Ada_Version < Ada_2012 - -- Overlap is only illegal in Ada 2012 in the case of + -- Overlap is only illegal since Ada 2012 and only for -- elementary types (passed by copy). For other types -- we always have a warning in all versions. This is -- clarified by AI12-0216.
[Ada] Correct A'First (N) where N is an object name
This patch corrects a bug in A'First (N), where N is not a literal or named number -- the compiler would think N = 1, even when it is 2 or more. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * sem_attr.adb (Check_Array_Or_Scalar_Type): Use Expr_Value instead of Intval, because the latter only exists in literals. Remove Set_Etype on E1; setting the type is done elsewhere.diff --git a/gcc/ada/sem_attr.adb b/gcc/ada/sem_attr.adb --- a/gcc/ada/sem_attr.adb +++ b/gcc/ada/sem_attr.adb @@ -1603,7 +1603,6 @@ package body Sem_Attr is -- Local variables - Dims : Int; Index : Entity_Id; -- Start of processing for Check_Array_Or_Scalar_Type @@ -1667,14 +1666,16 @@ package body Sem_Attr is Set_Etype (N, Base_Type (Etype (Index))); else - Dims := UI_To_Int (Intval (E1)); - - for J in 1 .. Dims - 1 loop - Next_Index (Index); - end loop; + declare + Udims : constant Uint := Expr_Value (E1); + Dims : constant Int := UI_To_Int (Udims); + begin + for J in 1 .. Dims - 1 loop + Next_Index (Index); + end loop; + end; Set_Etype (N, Base_Type (Etype (Index))); - Set_Etype (E1, Standard_Integer); end if; end if; end Check_Array_Or_Scalar_Type;
[Ada] Fix handling of gnat check/test commands
These days, gnat check should always call gnatcheck
[--target=prefix], same for gnat test.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* gnatcmd.adb: Fix handling of check and test commands.diff --git a/gcc/ada/gnatcmd.adb b/gcc/ada/gnatcmd.adb
--- a/gcc/ada/gnatcmd.adb
+++ b/gcc/ada/gnatcmd.adb
@@ -472,6 +472,15 @@ begin
Program := new String'(Command_List (The_Command).Unixcmd.all);
+ elsif The_Command in Check | Test then
+ Program := new String'(Command_List (The_Command).Unixcmd.all);
+ Find_Program_Name;
+
+ if Name_Len > 5 then
+First_Switches.Append
+ (new String'
+ ("--target=" & Name_Buffer (1 .. Name_Len - 5)));
+ end if;
else
Program :=
Program_Name (Command_List (The_Command).Unixcmd.all, "gnat");
@@ -481,13 +490,7 @@ begin
-- instead of gnatmake/gnatclean.
-- Ditto for gnatname -> gprname and gnatls -> gprls.
- if The_Command = Make
- or else The_Command = Compile
- or else The_Command = Bind
- or else The_Command = Link
- or else The_Command = Clean
- or else The_Command = Name
- or else The_Command = List
+ if The_Command in Make | Compile | Bind | Link | Clean | Name | List
then
declare
Switch: String_Access;
@@ -588,23 +591,23 @@ begin
end if;
-- For FIND and XREF, look for switch -P. If it is specified, then
- -- report an error indicating that the command is no longer supporting
- -- project files.
+ -- report an error indicating that the command does not support project
+ -- files.
- if The_Command = Find or else The_Command = Xref then
+ if The_Command in Find | Xref then
declare
Argv : String_Access;
begin
for Arg_Num in 1 .. Last_Switches.Last loop
Argv := Last_Switches.Table (Arg_Num);
- if Argv'Length >= 2 and then
- Argv (Argv'First .. Argv'First + 1) = "-P"
+ if Argv'Length >= 2
+ and then Argv (Argv'First .. Argv'First + 1) = "-P"
then
if The_Command = Find then
- Fail ("'gnat find -P' is no longer supported;");
+ Fail ("'gnat find -P' is not supported;");
else
- Fail ("'gnat xref -P' is no longer supported;");
+ Fail ("'gnat xref -P' is not supported;");
end if;
end if;
end loop;
[Ada] Fix asymmetries in detection of overlapping actuals
When detecting overlapping actuals we were only examining the type of the first formal parameter, so that errors and warnings were depending on the order of parameters. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * sem_warn.adb (Warn_On_Overlapping_Actuals): Examine types of both formal parameters; refactor a complex detection of by-reference types.diff --git a/gcc/ada/sem_warn.adb b/gcc/ada/sem_warn.adb --- a/gcc/ada/sem_warn.adb +++ b/gcc/ada/sem_warn.adb @@ -3669,6 +3669,9 @@ package body Sem_Warn is - procedure Warn_On_Overlapping_Actuals (Subp : Entity_Id; N : Node_Id) is + function Explicitly_By_Reference (Formal_Id : Entity_Id) return Boolean; + -- Returns True iff the type of Formal_Id is explicitly by-reference + function Refer_Same_Object (Act1 : Node_Id; Act2 : Node_Id) return Boolean; @@ -3680,6 +3683,24 @@ package body Sem_Warn is -- object_name is known to refer to the same object as the other name -- (RM 6.4.1(6.11/3)) + - + -- Explicitly_By_Reference -- + - + + function Explicitly_By_Reference +(Formal_Id : Entity_Id) + return Boolean + is + Typ : constant Entity_Id := Underlying_Type (Etype (Formal_Id)); + begin + if Present (Typ) then +return Is_By_Reference_Type (Typ) + or else Convention (Typ) = Convention_Ada_Pass_By_Reference; + else +return False; + end if; + end Explicitly_By_Reference; + --- -- Refer_Same_Object -- --- @@ -3792,17 +3813,13 @@ package body Sem_Warn is then null; - -- If type is explicitly not by-copy, assume that - -- aliasing is intended. + -- If type is explicitly by-reference, then it is not + -- covered by the legality rule, which only applies to + -- elementary types. Actually, the aliasing is most + -- likely intended, so don't emit a warning either. - elsif -Present (Underlying_Type (Etype (Form1))) - and then -(Is_By_Reference_Type - (Underlying_Type (Etype (Form1))) - or else -Convention (Underlying_Type (Etype (Form1))) = - Convention_Ada_Pass_By_Reference) + elsif Explicitly_By_Reference (Form1) +or else Explicitly_By_Reference (Form2) then null; @@ -3810,7 +3827,9 @@ package body Sem_Warn is -- arrays and record types if switch is set. elsif Ada_Version >= Ada_2012 -and then not Is_Elementary_Type (Etype (Form1)) +and then not (Is_Elementary_Type (Etype (Form1)) +and then + Is_Elementary_Type (Etype (Form2))) and then not Warn_On_Overlap then null;
[Ada] Warn on 'in out' param containing access in private type
Normally the warnings: warning: formal parameter "..." is not modified warning: mode could be "in" instead of "in out" are disabled if the type contains components of an access type. A previous patch enabled such warnings if the only such components are in internal private types. This patch goes further, to all private types, whether or not internal. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * sem_util.ads, sem_util.adb (Has_Access_Values): Remove Include_Internal parameter that was added in previous change. * sem_warn.adb (Warnings_Off_E1): Back out E_Out_Parameter ==> Formal_Kind change made previously. Check Is_Private_Type to avoid warnings on private types. Misc cleanup. * sem_attr.adb (Attribute_Has_Access_Values): Remove Include_Internal parameter.diff --git a/gcc/ada/sem_attr.adb b/gcc/ada/sem_attr.adb --- a/gcc/ada/sem_attr.adb +++ b/gcc/ada/sem_attr.adb @@ -8830,9 +8830,7 @@ package body Sem_Attr is when Attribute_Has_Access_Values => Rewrite (N, New_Occurrence_Of - (Boolean_Literals - (Has_Access_Values (P_Root_Type, Include_Internal => True)), - Loc)); + (Boolean_Literals (Has_Access_Values (P_Root_Type)), Loc)); Analyze_And_Resolve (N, Standard_Boolean); --- diff --git a/gcc/ada/sem_util.adb b/gcc/ada/sem_util.adb --- a/gcc/ada/sem_util.adb +++ b/gcc/ada/sem_util.adb @@ -11555,14 +11555,13 @@ package body Sem_Util is -- Has_Access_Values -- --- - function Has_Access_Values - (T : Entity_Id; Include_Internal : Boolean) return Boolean + function Has_Access_Values (T : Entity_Id) return Boolean is Typ : constant Entity_Id := Underlying_Type (T); begin -- Case of a private type which is not completed yet. This can only - -- happen in the case of a generic format type appearing directly, or + -- happen in the case of a generic formal type appearing directly, or -- as a component of the type to which this function is being applied -- at the top level. Return False in this case, since we certainly do -- not know that the type contains access types. @@ -11570,17 +11569,11 @@ package body Sem_Util is if No (Typ) then return False; - elsif not Include_Internal -and then T /= Typ -and then In_Internal_Unit (Typ) - then - return False; - elsif Is_Access_Type (Typ) then return True; elsif Is_Array_Type (Typ) then - return Has_Access_Values (Component_Type (Typ), Include_Internal); + return Has_Access_Values (Component_Type (Typ)); elsif Is_Record_Type (Typ) then declare @@ -11595,7 +11588,7 @@ package body Sem_Util is -- Check for access component, tag field does not count, even -- though it is implemented internally using an access type. - if Has_Access_Values (Etype (Comp), Include_Internal) + if Has_Access_Values (Etype (Comp)) and then Chars (Comp) /= Name_uTag then return True; diff --git a/gcc/ada/sem_util.ads b/gcc/ada/sem_util.ads --- a/gcc/ada/sem_util.ads +++ b/gcc/ada/sem_util.ads @@ -1312,18 +1312,14 @@ package Sem_Util is -- limited, packed array and other implementation types. If Include_PAT -- is False, don't look inside packed array types. - function Has_Access_Values - (T : Entity_Id; Include_Internal : Boolean) return Boolean; - -- Returns true if type or subtype T is an access type, or has a component - -- (at any recursive level) that is an access type. This is a conservative - -- predicate, if it is not known whether or not T contains access values - -- (happens for generic formals in some cases), then False is returned. - -- Note that tagged types return False. Even though the tag is implemented - -- as an access type internally, this function tests only for access types - -- known to the programmer. See also Has_Tagged_Component. - -- - -- If Include_Internal is False, we return False for internal private types - -- whose full type contains access types. + function Has_Access_Values (T : Entity_Id) return Boolean; + -- Returns true if the underlying type of T is an access type, or has a + -- component (at any recursive level) that is an access type. This is a + -- conservative predicate, if it is not known whether or not T contains + -- access values (happens for generic formals in some cases), then False is + -- returned. Note that tagged types return False. Even though the tag is + -- implemented as an access type internally, this function tests only for + -- access types known to the programmer. See also Has_Tagged_Component. function Has_Anonymous_Access_Discriminant (Typ : Entity_Id)
[Ada] New debug switch to disable large static aggregates
This patch adds the -gnatd_g switch, which lowers the threshold for computing static aggregates at compile time. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * debug.adb: Document switch. * exp_aggr.adb: If -gnatd_g was given, then do not bump the limit to 500_000.diff --git a/gcc/ada/debug.adb b/gcc/ada/debug.adb --- a/gcc/ada/debug.adb +++ b/gcc/ada/debug.adb @@ -145,7 +145,7 @@ package body Debug is -- d_d -- d_e Ignore entry calls and requeue statements for elaboration -- d_f Issue info messages related to GNATprove usage - -- d_g + -- d_g Disable large static aggregates -- d_h Disable the use of (perfect) hash functions for enumeration Value -- d_i Ignore activations and calls to instances for elaboration -- d_j Read JSON files and populate Repinfo tables (opposite of -gnatRjs) @@ -965,6 +965,10 @@ package body Debug is -- beginners find them confusing. Set automatically by GNATprove when -- switch --info is used. + -- d_g Disable large static aggregates. The maximum size for a static + -- aggregate will be fairly modest, which is useful if the compiler + -- is using too much memory and time at compile time. + -- d_h The compiler does not make use of (perfect) hash functions in the -- implementation of the Value attribute for enumeration types. diff --git a/gcc/ada/exp_aggr.adb b/gcc/ada/exp_aggr.adb --- a/gcc/ada/exp_aggr.adb +++ b/gcc/ada/exp_aggr.adb @@ -684,9 +684,11 @@ package body Exp_Aggr is begin -- We bump the maximum size unless the aggregate has a single component -- association, which will be more efficient if implemented with a loop. + -- The -gnatd_g switch disables this bumping. - if No (Expressions (N)) -and then No (Next (First (Component_Associations (N + if (No (Expressions (N)) +and then No (Next (First (Component_Associations (N) +or else Debug_Flag_Underscore_G then Max_Aggr_Size := Max_Aggregate_Size (N); else
[Ada] Remove dead code for overlapping actuals in prefix notation
Detection of overlapping actuals doesn't need to be special-cased for
prefix notation, because it is done after prefixed calls have been
rewritten into ordinary calls, both in normal compilation and semantic
checking mode (with switch -gnatc).
Behaviour is unaffected; the removed code was dead.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_warn.adb (Warn_On_Overlapping_Actuals): Remove dead branch
for overlapping actuals in prefix notation.diff --git a/gcc/ada/sem_warn.adb b/gcc/ada/sem_warn.adb
--- a/gcc/ada/sem_warn.adb
+++ b/gcc/ada/sem_warn.adb
@@ -3839,45 +3839,15 @@ package body Sem_Warn is
or else Error_To_Warning;
- -- If the call was written in prefix notation, and thus
- -- its prefix before rewriting was a selected component,
- -- count only visible actuals in call.
-
- if Is_Entity_Name (First_Actual (N))
- and then Nkind (Original_Node (N)) = Nkind (N)
- and then Nkind (Name (Original_Node (N))) =
- N_Selected_Component
- and then
- Is_Entity_Name (Prefix (Name (Original_Node (N
- and then
- Entity (Prefix (Name (Original_Node (N =
- Entity (First_Actual (N))
- then
-if Act1 = First_Actual (N) then
- Error_Msg_FE
- ("
[Ada] Relax null exclusion mismatch check in Relaxed_RM_Semantics mode
This is useful for e.g. CodePeer usage.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_ch6.adb (Null_Exclusions_Match): Relax null exclusion
mismatch check when Relaxed_RM_Semantics is set.diff --git a/gcc/ada/sem_ch6.adb b/gcc/ada/sem_ch6.adb
--- a/gcc/ada/sem_ch6.adb
+++ b/gcc/ada/sem_ch6.adb
@@ -6265,7 +6265,9 @@ package body Sem_Ch6 is
-- Null exclusion must match
-if not Null_Exclusions_Match (Old_Formal, New_Formal) then
+if not Relaxed_RM_Semantics
+ and then not Null_Exclusions_Match (Old_Formal, New_Formal)
+then
Conformance_Error
("\null exclusion for& does not match", New_Formal);
[Ada] Do not clear Is_True_Constant flag on imported constants
The flag is first set on them as for any other constants but then cleared when the import pragma is processed. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * sem_prag.adb (Process_Import_Or_Interface): Do not artificially record a possible modification for a constant.diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb --- a/gcc/ada/sem_prag.adb +++ b/gcc/ada/sem_prag.adb @@ -9136,7 +9136,10 @@ package body Sem_Prag is Def_Id := Entity (Def_Id); Kill_Size_Check_Code (Def_Id); -Note_Possible_Modification (Get_Pragma_Arg (Arg1), Sure => False); +if Ekind (Def_Id) /= E_Constant then + Note_Possible_Modification + (Get_Pragma_Arg (Arg1), Sure => False); +end if; else Process_Convention (C, Def_Id); @@ -9146,7 +9149,10 @@ package body Sem_Prag is Mark_Ghost_Pragma (N, Def_Id); Kill_Size_Check_Code (Def_Id); -Note_Possible_Modification (Get_Pragma_Arg (Arg2), Sure => False); +if Ekind (Def_Id) /= E_Constant then + Note_Possible_Modification + (Get_Pragma_Arg (Arg2), Sure => False); +end if; end if; -- Various error checks
[Ada] Implement basic support for -fdiagnostics-format=json
This commit implements basic support for the -fdiagnostics-format=json
option that GCC has. When GNAT finds this argument in the command line,
error messages such as:
tmp.adb:4:12: "My_Var" is undefined
Will be printed as:
[
{
"kind": "error",
"locations": [
{
"caret": {
"file": "tmp.adb",
"line": 4,
"column": 12
},
"finish": {
"file": "tmp.adb",
"line": 4,
"column": 17
}
}
],
"message": "\"My_Var\" is undefined"
}
]
This will make the task of interfacing with GNAT easier. Support for
GCC's other message attributes, such as "fixits", "option" and
"option_url" will be implemented in a later commit.
Design decision: while -fdiagnostics-format=json inhibits regular
printing of messages, it doesn't do so if -gnatv or -gnatl are present.
This is for two reasons:
- Combining -fdiagnostics-format=json with -gnatv makes comparing the
output of both options easier.
- While combining these options is likely to be a mistake from the user,
printing both kinds of output will make the issue more obvious than
silently silencing one of the two.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* back_end.adb (Scan_Back_End_Switches): Set Opt.JSON_Output to
True if -fdiagnostics-format=json option is found.
* back_end.ads (Scan_Compiler_Arguments): Mention
Opt.JSON_Output.
* errout.adb (Output_JSON_Message): New procedure.
(Output_Messages): If Opt.JSON_Output is True, print messages
with new Output_JSON_Message procedure.
* opt.ads: Declare JSON_Output variable.
* doc/gnat_ugn/building_executable_programs_with_gnat.rst:
Mention new -fdiagnostics-format option.
* gnat_ugn.texi: Regenerate.diff --git a/gcc/ada/back_end.adb b/gcc/ada/back_end.adb
--- a/gcc/ada/back_end.adb
+++ b/gcc/ada/back_end.adb
@@ -281,6 +281,14 @@ package body Back_End is
elsif Switch_Chars (First .. Last) = "fpreserve-control-flow" then
Opt.Suppress_Control_Flow_Optimizations := True;
+-- Back end switch -fdiagnostics-format=json tells the frontend to
+-- output its error and warning messages in the same format GCC
+-- uses when passed -fdiagnostics-format=json.
+
+elsif Switch_Chars (First .. Last) = "fdiagnostics-format=json"
+then
+ Opt.JSON_Output := True;
+
-- Back end switch -fdump-scos, which exists primarily for C, is
-- also accepted for Ada as a synonym of -gnateS.
diff --git a/gcc/ada/back_end.ads b/gcc/ada/back_end.ads
--- a/gcc/ada/back_end.ads
+++ b/gcc/ada/back_end.ads
@@ -70,6 +70,7 @@ package Back_End is
--Opt.Suppress_Control_Float_Optimizations
--Opt.Generate_SCO
--Opt.Generate_SCO_Instance_Table
+ --Opt.JSON_Output
--Opt.Stack_Checking_Enabled
--Opt.No_Stdinc
--Opt.No_Stdlib
diff --git a/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst b/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst
--- a/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst
+++ b/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst
@@ -1233,6 +1233,13 @@ Alphabetical List of All Switches
marker is specified, the callgraph is decorated with information about
dynamically allocated objects.
+.. index:: -fdiagnostics-format (gcc)
+
+:switch:`-fdiagnostics-format=json`
+ Makes GNAT emit warning and error messages as JSON. Inhibits printing of
+ text warning and errors messages except if :switch:`-gnatv` or
+ :switch:`-gnatl` are present.
+
.. index:: -fdump-scos (gcc)
diff --git a/gcc/ada/errout.adb b/gcc/ada/errout.adb
--- a/gcc/ada/errout.adb
+++ b/gcc/ada/errout.adb
@@ -130,6 +130,11 @@ package body Errout is
-- or if it refers to an Etype that has an error posted on it, or if
-- it references an Entity that has an error posted on it.
+ procedure Output_JSON_Message (Error_Id : Error_Msg_Id);
+ -- Output error message Error_Id and any subsequent continuation message
+ -- using a JSON format similar to the one GCC uses when passed
+ -- -fdiagnostics-format=json.
+
procedure Output_Source_Line
(L : Physical_Line_Number;
Sfile : Source_File_Index;
@@ -2055,6 +2060,133 @@ package body Errout is
end if;
end OK_Node;
+ -
+ -- Output_JSON_Message --
+ -
+
+ procedure Output_JSON_Message (Error_Id : Error_Msg_Id) is
+
+ procedure Write_JSON_Escaped_String (Str : String_Ptr);
+ -- Write each character of Str, taking care of preceding each quote and
+ -- backslash with a backslash. Note that this escaping differs from what
+ -- GCC does.
+ --
+ -- Indeed, the JSON specification mandates encoding wide characters
+ -- either as
[Ada] Replace Opt.Extensions_Allowed by Ada_Version
Code cleanup: add a new value in Ada_Version_Type to represent the
latest version of Ada with GNAT extensions instead of using a separate
flag.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* fe.h, opt.adb, opt.ads, par-prag.adb, sem_prag.adb,
switch-c.adb (Extensions_Allowed): Replace by a function.
(Ada_Version_Type): Add new value Ada_With_Extensions, to
replace setting of Extensions_Allowed. Update setting of
Extensions_Allowed.diff --git a/gcc/ada/fe.h b/gcc/ada/fe.h
--- a/gcc/ada/fe.h
+++ b/gcc/ada/fe.h
@@ -203,7 +203,7 @@ extern Boolean In_Extended_Main_Code_Unit (Entity_Id);
#define Suppress_Checks opt__suppress_checks
typedef enum {
- Ada_83, Ada_95, Ada_2005, Ada_2012, Ada_2022
+ Ada_83, Ada_95, Ada_2005, Ada_2012, Ada_2022, Ada_With_Extensions
} Ada_Version_Type;
typedef enum {
diff --git a/gcc/ada/opt.adb b/gcc/ada/opt.adb
--- a/gcc/ada/opt.adb
+++ b/gcc/ada/opt.adb
@@ -84,7 +84,6 @@ package body Opt is
Default_SSO_Config:= Default_SSO;
Dynamic_Elaboration_Checks_Config := Dynamic_Elaboration_Checks;
Exception_Locations_Suppressed_Config := Exception_Locations_Suppressed;
- Extensions_Allowed_Config := Extensions_Allowed;
External_Name_Exp_Casing_Config := External_Name_Exp_Casing;
External_Name_Imp_Casing_Config := External_Name_Imp_Casing;
Fast_Math_Config := Fast_Math;
@@ -123,7 +122,6 @@ package body Opt is
Default_SSO:= Save.Default_SSO;
Dynamic_Elaboration_Checks := Save.Dynamic_Elaboration_Checks;
Exception_Locations_Suppressed := Save.Exception_Locations_Suppressed;
- Extensions_Allowed := Save.Extensions_Allowed;
External_Name_Exp_Casing := Save.External_Name_Exp_Casing;
External_Name_Imp_Casing := Save.External_Name_Imp_Casing;
Fast_Math := Save.Fast_Math;
@@ -165,7 +163,6 @@ package body Opt is
Default_SSO=> Default_SSO,
Dynamic_Elaboration_Checks => Dynamic_Elaboration_Checks,
Exception_Locations_Suppressed => Exception_Locations_Suppressed,
- Extensions_Allowed => Extensions_Allowed,
External_Name_Exp_Casing => External_Name_Exp_Casing,
External_Name_Imp_Casing => External_Name_Imp_Casing,
Fast_Math => Fast_Math,
@@ -204,7 +201,6 @@ package body Opt is
Ada_Version_Pragma := Empty;
Default_SSO := ' ';
Dynamic_Elaboration_Checks := False;
- Extensions_Allowed := True;
External_Name_Exp_Casing:= As_Is;
External_Name_Imp_Casing:= Lowercase;
No_Component_Reordering := False;
@@ -263,7 +259,6 @@ package body Opt is
Check_Policy_List := Check_Policy_List_Config;
Default_SSO := Default_SSO_Config;
Dynamic_Elaboration_Checks := Dynamic_Elaboration_Checks_Config;
- Extensions_Allowed := Extensions_Allowed_Config;
External_Name_Exp_Casing:= External_Name_Exp_Casing_Config;
External_Name_Imp_Casing:= External_Name_Imp_Casing_Config;
Fast_Math := Fast_Math_Config;
diff --git a/gcc/ada/opt.ads b/gcc/ada/opt.ads
--- a/gcc/ada/opt.ads
+++ b/gcc/ada/opt.ads
@@ -68,17 +68,20 @@ package Opt is
-- the default values.
Latest_Ada_Only : Boolean := False;
- -- If True, the only value valid for Ada_Version is Ada_Version_Type'Last,
- -- trying to specify other values will be ignored (in case of pragma
+ -- If True, the only value valid for Ada_Version is Ada_2012 or later.
+ -- Trying to specify other values will be ignored (in case of pragma
-- Ada_xxx) or generate an error (in case of -gnat83/95/xx switches).
- type Ada_Version_Type is (Ada_83, Ada_95, Ada_2005, Ada_2012, Ada_2022);
+ type Ada_Version_Type is
+ (Ada_83, Ada_95, Ada_2005, Ada_2012, Ada_2022, Ada_With_Extensions);
pragma Ordered (Ada_Version_Type);
pragma Convention (C, Ada_Version_Type);
-- Versions of Ada for Ada_Version below. Note that these are ordered,
-- so that tests like Ada_Version >= Ada_95 are legitimate and useful.
-- Think twice before using "="; Ada_Version >= Ada_2012 is more likely
-- what you want, because it will apply to future versions of the language.
+ -- Note that Ada_With_Extensions should always be last since it should
+ -- always be a superset of the latest Ada version.
-- WARNING: There is a matching C declaration of this type in fe.h
@@ -108,7 +111,7 @@ package Opt is
-- remains set to Ada_Version_Default). This is used in the rare cases
-- (notably pragma Obsolescent) where we want the explicit version set.
- Ada_Version_Runtime :
[Ada] Update comments related to TBD
We use ??? when relevant, not TBD in GNAT comments Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * exp_aggr.adb, exp_dist.adb, exp_unst.adb, sa_messages.ads, sem_ch13.adb, sem_ch3.adb, sem_ch5.adb, sem_eval.adb, sem_util.adb, sem_util.ads, sinfo.ads: Update comments.diff --git a/gcc/ada/exp_aggr.adb b/gcc/ada/exp_aggr.adb --- a/gcc/ada/exp_aggr.adb +++ b/gcc/ada/exp_aggr.adb @@ -7167,7 +7167,7 @@ package body Exp_Aggr is return Build_Siz_Exp (First (Discrete_Choices (Comp))); elsif Nkind (Comp) = N_Iterated_Element_Association then -return -1;-- TBD, build expression for size of the domain +return -1;-- ??? build expression for size of the domain else return -1; diff --git a/gcc/ada/exp_dist.adb b/gcc/ada/exp_dist.adb --- a/gcc/ada/exp_dist.adb +++ b/gcc/ada/exp_dist.adb @@ -10906,8 +10906,8 @@ package body Exp_Dist is raise Program_Error; end if; --- TBD: fixed point types??? --- TBverified numeric types with a biased representation??? +-- What about fixed point types and numeric types with a biased +-- representation??? end Find_Numeric_Representation; diff --git a/gcc/ada/exp_unst.adb b/gcc/ada/exp_unst.adb --- a/gcc/ada/exp_unst.adb +++ b/gcc/ada/exp_unst.adb @@ -1566,7 +1566,7 @@ package body Exp_Unst is -- A subprogram instantiation does not have an explicit -- body. If unused, we could remove the corresponding - -- wrapper package and its body (TBD). + -- wrapper package and its body. if Present (STJ.Bod) then Spec := Corresponding_Spec (STJ.Bod); diff --git a/gcc/ada/sa_messages.ads b/gcc/ada/sa_messages.ads --- a/gcc/ada/sa_messages.ads +++ b/gcc/ada/sa_messages.ads @@ -96,7 +96,7 @@ package SA_Messages is -- Contract_Cases, Default_Initial_Condition, Initial_Condition, -- Loop_Invariant, Loop_Variant, Refined_Post, and Subprogram_Variant. -- - -- TBD: it might be nice to distinguish these different kinds of assertions + -- It might be nice to distinguish these different kinds of assertions -- as is done in SPARK's VC_Kind enumeration type, but any distinction -- which isn't already present in CP's BE_Message_Subkind enumeration type -- would require more work on the CP side. diff --git a/gcc/ada/sem_ch13.adb b/gcc/ada/sem_ch13.adb --- a/gcc/ada/sem_ch13.adb +++ b/gcc/ada/sem_ch13.adb @@ -2623,7 +2623,7 @@ package body Sem_Ch13 is end if; end loop; - -- ??? TBD: Must check that "for result type R, if the + -- ??? Must check that "for result type R, if the -- function is a boundary entity for type R (see 7.3.2), -- no type invariant applies to type R; if R has a -- component type C, a similar rule applies to C." @@ -15068,7 +15068,7 @@ package body Sem_Ch13 is -- For now we only deal with aspects that do not generate -- subprograms, or that may mention current instances of - -- types. These will require special handling (???TBD). + -- types. These will require special handling???. when Aspect_Invariant | Aspect_Predicate diff --git a/gcc/ada/sem_ch3.adb b/gcc/ada/sem_ch3.adb --- a/gcc/ada/sem_ch3.adb +++ b/gcc/ada/sem_ch3.adb @@ -2827,7 +2827,7 @@ package body Sem_Ch3 is -- to the first encountered body. -- ??? A cleaner approach may be possible and/or this solution --- could be extended to general-purpose late primitives, TBD. +-- could be extended to general-purpose late primitives. if Present (Ctrl_Typ) then @@ -3055,7 +3055,7 @@ package body Sem_Ch3 is end if; end if; - -- TBD : other nonoverridable aspects. + -- What about other nonoverridable aspects??? end Check_Nonoverridable_Aspects; diff --git a/gcc/ada/sem_ch5.adb b/gcc/ada/sem_ch5.adb --- a/gcc/ada/sem_ch5.adb +++ b/gcc/ada/sem_ch5.adb @@ -1542,7 +1542,6 @@ package body Sem_Ch5 is elsif Extensions_Allowed and then Is_Overloaded (Exp) then - -- TBD: Generate better ambiguity diagnostics here. -- It would be nice if we could generate all the right error -- messages by calling "Resolve (Exp, Any_Type);" in the -- same way that they are generated a few lines below by the diff --git a/gcc/ada/sem_eval.adb b/gcc/ada/sem_eval.adb --- a/gcc/ada/sem_eval.adb +++ b/gcc/ada/sem_eval.adb @@ -6223,7 +6223,7 @@ package body Sem_Eval is end; else --- TBD:
[Ada] GNAT.Compiler_Version and LTO
When mixing GNAT.Compiler_Version and LTO, a warning about a type
mismatch between the import and export of __gnat_version is generated.
Fixed by introducing a level of indirection.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* bindgen.adb (Gen_Output_File_Ada): Generate a new constant
GNAT_Version_Address.
* libgnat/g-comver.adb (GNAT_Version_Address): New;
(GNAT_Version): Use GNAT_Version_Address to disable LTO warning.diff --git a/gcc/ada/bindgen.adb b/gcc/ada/bindgen.adb
--- a/gcc/ada/bindgen.adb
+++ b/gcc/ada/bindgen.adb
@@ -2388,7 +2388,11 @@ package body Bindgen is
Gnat_Version_String &
""" & ASCII.NUL;");
WBI (" pragma Export (C, GNAT_Version, ""__gnat_version"");");
-
+WBI ("");
+WBI (" GNAT_Version_Address : constant System.Address := " &
+ "GNAT_Version'Address;");
+WBI (" pragma Export (C, GNAT_Version_Address, " &
+ """__gnat_version_address"");");
WBI ("");
Set_String (" Ada_Main_Program_Name : constant String := """);
Get_Name_String (Units.Table (First_Unit_Entry).Uname);
diff --git a/gcc/ada/libgnat/g-comver.adb b/gcc/ada/libgnat/g-comver.adb
--- a/gcc/ada/libgnat/g-comver.adb
+++ b/gcc/ada/libgnat/g-comver.adb
@@ -33,6 +33,8 @@
-- GNAT compiler used to compile the program. It relies on the generated
-- constant in the binder generated package that records this information.
+with System;
+
package body GNAT.Compiler_Version is
Ver_Len_Max : constant := 256;
@@ -43,8 +45,15 @@ package body GNAT.Compiler_Version is
-- This is logically a reference to Gnatvsn.Ver_Prefix but we cannot
-- import this directly since run-time units cannot WITH compiler units.
+ GNAT_Version_Address : constant System.Address;
+ pragma Import (C, GNAT_Version_Address, "__gnat_version_address");
+
GNAT_Version : constant String (1 .. Ver_Len_Max + Ver_Prefix'Length);
- pragma Import (C, GNAT_Version, "__gnat_version");
+ pragma Import (Ada, GNAT_Version);
+ for GNAT_Version'Address use GNAT_Version_Address;
+ -- Use a level of indirection via __gnat_version_address to avoid LTO
+ -- type mismtch warnings between two string objects of potentially
+ -- different size.
-
-- Version --
