On 7/23/21 8:21 AM, Sebastian Huber wrote:
On 23/07/2021 07:31, Martin Liška wrote:
+static void *
+allocate_handler (unsigned size, void *unused)
+{
+ (void)unused;
+ return xmalloc (size);
+}
+#endif /* NEED_L_GCOV */
+
+#if defined(NEED_L_GCOV) || defined(NEED_L_GCOV_INFO_TO_GCDA)
+static i
On 7/23/21 8:14 AM, Sebastian Huber wrote:
On 23/07/2021 07:31, Martin Liška wrote:
write_topn_counters (const struct gcov_ctr_info *ci_ptr,
unsigned t_ix,
- gcov_unsigned_t n_counts)
+ gcov_unsigned_t n_counts,
+ void (*dump) (const void *, u
On 7/23/21 8:10 AM, Sebastian Huber wrote:
Hallo Martin,
Hello.
thanks for your review.
On 23/07/2021 07:31, Martin Liška wrote:
On 7/13/21 10:15 PM, Sebastian Huber wrote:
Hello.
Thanks for working on that, there's my review:
Add __gcov_info_to_gcda() to libgcov to get the gcda data f
On Fri, Jul 23, 2021 at 7:53 AM Segher Boessenkool
wrote:
>
> On Wed, Jul 14, 2021 at 05:14:16PM +0800, bin.cheng via Gcc-patches wrote:
> > Hi,
> > I ran into a wrong code bug in code with deep template instantiation when
> > working on sdx::simd.
> > The root cause as described in commit summar
On 23/07/2021 07:31, Martin Liška wrote:
+static void *
+allocate_handler (unsigned size, void *unused)
+{
+ (void)unused;
+ return xmalloc (size);
+}
+#endif /* NEED_L_GCOV */
+
+#if defined(NEED_L_GCOV) || defined(NEED_L_GCOV_INFO_TO_GCDA)
+static inline void
Likewise here.
+dump_unsigned
On 23/07/2021 07:31, Martin Liška wrote:
write_topn_counters (const struct gcov_ctr_info *ci_ptr,
unsigned t_ix,
- gcov_unsigned_t n_counts)
+ gcov_unsigned_t n_counts,
+ void (*dump) (const void *, unsigned, void *),
+ void *(*allo
Hallo Martin,
thanks for your review.
On 23/07/2021 07:31, Martin Liška wrote:
On 7/13/21 10:15 PM, Sebastian Huber wrote:
Hello.
Thanks for working on that, there's my review:
Add __gcov_info_to_gcda() to libgcov to get the gcda data for a gcda
info in a
freestanding environment. It is i
On Fri, 2021-07-23 at 11:18 +0800, Xi Ruoyao wrote:
> On Fri, 2021-07-23 at 04:21 +0200, Maciej W. Rozycki wrote:
> > On Fri, 9 Jul 2021, Richard Sandiford via Gcc-patches wrote:
> >
> > > > > > > The "smallest fix" is simply adding -fno-inline into
> > > > > > > mips.exp.
> > > > > > > However
>
On 7/12/21 7:20 PM, Segher Boessenkool wrote:
On Mon, Jun 28, 2021 at 02:19:03PM +0200, Martin Liška wrote:
On 6/24/21 12:46 AM, Segher Boessenkool wrote:
As mentioned in the "Fallout: save/restore target options in
handle_optimize_attribute"
thread, we need to support target option restore of
As mentioned in the "Fallout: save/restore target options in
handle_optimize_attribute"
thread, we need to support target option restore
of rs6000_long_double_type_size == FLOAT_PRECISION_TFmode.
gcc/ChangeLog:
* config/rs6000/rs6000.c (rs6000_option_override_internal): When
a ta
On 7/13/21 10:15 PM, Sebastian Huber wrote:
Hello.
Thanks for working on that, there's my review:
Add __gcov_info_to_gcda() to libgcov to get the gcda data for a gcda info in a
freestanding environment. It is intended to be used with the
-fprofile-info-section option. A crude test program wh
On Thu, Jul 1, 2021 at 2:18 PM liuhongt wrote:
>
> From: "H.J. Lu"
>
> 1. FP16 vector xor/ior/and/andnot/abs/neg
> 2. FP16 scalar abs/neg/copysign/xorsign
>
> gcc/ChangeLog:
>
> * config/i386/i386-expand.c (ix86_expand_fp_absneg_operator):
> Handle HFmode.
> (ix86_expand_c
On Thu, Jul 1, 2021 at 2:18 PM liuhongt wrote:
>
> gcc/ChangeLog:
>
> * config/i386/i386-features.c (i386-features.c): Handle
> E_HFmode.
> * config/i386/i386.md (sqrthf2): New expander.
> (*sqrt2_sse): Extend to MODEFH.
> * config/i386/sse.md
> (*_v
On Fri, Jul 23, 2021 at 10:41 AM H.J. Lu via Gcc-patches
wrote:
>
> Don't return hard register in ix86_gen_scratch_sse_rtx when LRA is in
> progress to avoid ICE when there are no available hard registers for
> LRA.
>
LGTM.
> gcc/
>
> PR target/101504
> * config/i386/i386.c (ix86_g
On 2021-06-21 20:36, Richard Biener wrote:
On Mon, 21 Jun 2021, guojiufu wrote:
On 2021-06-21 14:19, guojiufu via Gcc-patches wrote:
> On 2021-06-09 19:18, guojiufu wrote:
>> On 2021-06-09 17:42, guojiufu via Gcc-patches wrote:
>>> On 2021-06-08 18:13, Richard Biener wrote:
On Fri, 4 Jun 2
On Fri, 2021-07-23 at 04:21 +0200, Maciej W. Rozycki wrote:
> On Fri, 9 Jul 2021, Richard Sandiford via Gcc-patches wrote:
>
> > > > > > The "smallest fix" is simply adding -fno-inline into
> > > > > > mips.exp.
> > > > > > However
> > > > > > I don't like it because I agree with you that mips.ex
On Thu, Jul 22, 2021 at 7:17 PM Hongtao Liu wrote:
>
> On Thu, Jul 22, 2021 at 8:34 PM H.J. Lu via Gcc-patches
> wrote:
> >
> > For
> >
> > (set (reg:V32QI 108)
> > (const_vector:V32QI [
> > (const_int -1 [0x]) repeated x32
> > ])) "x.c":15:5 15
Don't return hard register in ix86_gen_scratch_sse_rtx when LRA is in
progress to avoid ICE when there are no available hard registers for
LRA.
gcc/
PR target/101504
* config/i386/i386.c (ix86_gen_scratch_sse_rtx): Don't return
hard register when LRA is in progress.
gcc/t
This patch fixes various false positives seen when using -fanalyzer
on the Linux kernel.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as 60933a148ab33c82915b40690b3ced6abc32a1bf.
gcc/analyzer/ChangeLog:
* diagnostic-manager.cc
(class auto_disable_
On Fri, 9 Jul 2021, Richard Sandiford via Gcc-patches wrote:
> >> > > The "smallest fix" is simply adding -fno-inline into mips.exp.
> >> > > However
> >> > > I don't like it because I agree with you that mips.exp shouldn't
> >> > > care
> >> > > about dg-options, at least don't do it too much.
>
On Thu, Jul 22, 2021 at 8:34 PM H.J. Lu via Gcc-patches
wrote:
>
> For
>
> (set (reg:V32QI 108)
> (const_vector:V32QI [
> (const_int -1 [0x]) repeated x32
> ])) "x.c":15:5 1573 {movv32qi_internal}
> (expr_list:REG_EQUIV (const_vector:V32QI [
Segher,
Thanks for your advice. I tested it. "{ dg-final {
scan-rtl-dump-times {\(compare:CC \((?:and|zero_extend):(?:DI)
\((?:sub)?reg:[SD]I} 1 "combine" } }" works well.
On 22/7/2021 上午 6:51, Segher Boessenkool wrote:
Hi!
On Tue, Jul 06, 2021 at 11:11:05AM +0800, HAO CHEN GUI wrote:
On Wed, Jul 14, 2021 at 05:14:16PM +0800, bin.cheng via Gcc-patches wrote:
> Hi,
> I ran into a wrong code bug in code with deep template instantiation when
> working on sdx::simd.
> The root cause as described in commit summary is we skip prologue insns in
> init_alias_analysis.
> This simple pa
Hi!
On Thu, Jul 22, 2021 at 03:04:32PM +0200, Richard Biener wrote:
> On Thu, Jul 22, 2021 at 9:02 AM Bin.Cheng via Gcc-patches
> wrote:
> >
> > Gentle ping. Any suggestions would be appreciated.
Bin: I never received your messages. And my replies to you @alibaba are
refused by the mail system
From: Sergei Trofimovich
r12-1804 ("cp: add support for per-location warning groups.") among other
things removed warning suppression from a few places including ptrmemfuncs.
Currently ptrmemfuncs don't have valid BINFO attached which causes ICEs
in access checks:
crash_signal
gcc/t
I have added tests for memset and memcpy.
Additionally, I have added a test to ensure that -mstrict-align is
still working.
I've run the complete GCC test suite with and without the resulting
patch with no regressions
(rv32imac/ilp32/medlow, rv32imafdc/ilp32d/medlow,
rv64imac/lp64/medlow, rv64imafd
On Mon, 19 Jul 2021, Tobias Burnus wrote:
> Update the OpenMP feature list.
>
> Comments? Remarks?
I'd slightly tweak this
; so far, they can be specified on statements and
block-local variables, only.
to
. So far they can be specified on statements and
block-local variables.
mak
This patch enables the overlap-by-pieces feature of the by-pieces
infrastructure for inlining builtins in case the target has set
riscv_slow_unaligned_access_p to false.
An example to demonstrate the effect for targets with fast unaligned
access (target's that have slow_unaligned_access set to fal
Passing a pointer to a built-in function escapes it, which in
turn causes objects pointed to by other potentially aliased
pointers to be assumed to be modified by other built-in calls.
This leads to a class of false negative -Wuninitialized
warnings that can be avoided by the warning code and with
The code that computes the size of an access to an object in
-Wuninitialized is limited to declared objects and so doesn't
apply to allocated objects, and doesn't correctly account for
an offset into the object and the access size. This causes
false positives.
The attached fix tested on x86_64-l
Hi Tobias,
I am afraid we're really opening a can of worms here
> Additionally, I wonder whether that will work with:
>
> integer, pointer :: ptr
> integer function f()
>pointer :: f
>f = ptr
> end
> allocate(A, stat=f())
>
> The f() is a variable and definable – but I am currently
Hi Tobias,
you are right in that I was barking up the wrong tree.
I was focussed too much on the testcase in the PR.
> I think that one is wrong. While CLASS_DATA (e) accesses
> e->ts.u.derived->components,
> which always works, your code assumes that there is only 'c' and not 'x%c'
> where
> '
On 20/07/21 16:26 +0100, Jonathan Wakely wrote:
On 02/06/21 13:35 +0100, Jonathan Wakely wrote:
The allocator, hash function and equality function should all be
value-initialized by the default constructor of an unordered container.
Do it in the EBO helper, so we don't have to get it right in mu
On 7/21/21 11:18 PM, Richard Biener wrote:
On Wed, 21 Jul 2021, Indu Bhagat wrote:
Hello,
Wanted to follow up on the CTF/BTF debug info + LTO workings.
To summarize, the current status/workflow on trunk is:
- The CTF container is written out in the ctfout.c or btfout.c via the
ctf_debug_fina
On Thu, Jul 22, 2021 at 7:27 PM Palmer Dabbelt wrote:
>
> On Thu, 22 Jul 2021 06:29:46 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
> > Could you add a testcase? Otherwise LGTM.
> >
> > Option: -O2 -mtune=thead-c906 -march=rv64gc -mabi=lp64
> > void foo(char *dst){
> >__builtin_memset(dst, 0, 1
Tamar Christina writes:
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>
> Ok for master?
>
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-simd-builtins.def (sdot, udot): Rename to..
> (sdot_prod, udot_prod): ... This.
> * config/aarch64/aarc
Tamar Christina writes:
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>
> Ok for master?
>
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-builtins.c (TYPES_TERNOP_SUSS,
> aarch64_types_ternop_suss_qualifiers): New.
> * config/aarch64/aarch64
On 7/22/21 6:34 AM, Richard Biener wrote:
We can improve uninit warnings from the early pass by looking
at PHI arguments on fallthru edges that are uninitialized and
have uses that are before a possible loop exit. This catches
some cases earlier that we'd only warn in a more confusing
way after
On 21.07.21 22:36, Harald Anlauf via Gcc-patches wrote:
Anyway, here's a straightforward fix for a NULL pointer dereference for
an invalid argument to STAT. For an alternative patch by Steve see PR.
Regtested on x86_64-pc-linux-gnu. OK for mainline / 11-branch when it
reopens?
..
Fortran: I
Jonathan Wright writes:
> Hi,
>
> As a general principle, vec_duplicate should be as close to the root
> of an expression as possible. Where unary operations have
> vec_duplicate as an argument, these operations should be pushed
> inside the vec_duplicate.
>
> This patch modifies unary operation s
On Thu, 22 Jul 2021 06:29:46 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
Could you add a testcase? Otherwise LGTM.
Option: -O2 -mtune=thead-c906 -march=rv64gc -mabi=lp64
void foo(char *dst){
__builtin_memset(dst, 0, 15);
}
I'd like to see:
* Test results. This is only on for one target ri
Jonathan Wright writes:
> Hi,
>
> The Neon multiply/multiply-accumulate/multiply-subtract instructions
> can take various forms - multiplying full vector registers of values
> or multiplying one vector by a single element of another. Regardless
> of the form used, these instructions have the same
Hi Harald,
On 21.07.21 22:22, Harald Anlauf via Fortran wrote:
Another one of Gerhard's infamous testcases. We did not properly detect
and reject array elements of type CLASS as argument to an intrinsic when
it should be an array.
Regtested on x86_64-pc-linux-gnu. OK for mainline / 11-branch
Well, arbitrarily allowing everything caused some -Wnonnull
regressions. I've changed the check to !r.zero_p() && !r.nonzero_p(),
as the only reasonable ranges for pointers besides varying/undefined
are zero and non-zero.
Attached is the final version of the patch I have pushed.
Tested on x86-64
AIX math.h provides C++ overloaded inlined math functions, which should
not be present for G++. The definitions have been guaded by
__COMPATMATH__, but that macro had other uses in IBM xlC++. A new
macro has been introduced with the sole purpose of guarding the functions.
This p
On 22/07/2021 14:47, Prathamesh Kulkarni via Gcc-patches wrote:
On Thu, 22 Jul 2021 at 17:28, Richard Earnshaw
wrote:
On 22/07/2021 12:32, Prathamesh Kulkarni wrote:
On Thu, 22 Jul 2021 at 16:03, Richard Earnshaw
wrote:
On 22/07/2021 08:45, Prathamesh Kulkarni via Gcc-patches wrote:
On Thu, 22 Jul 2021 at 17:28, Richard Earnshaw
wrote:
>
>
>
> On 22/07/2021 12:32, Prathamesh Kulkarni wrote:
> > On Thu, 22 Jul 2021 at 16:03, Richard Earnshaw
> > wrote:
> >>
> >>
> >>
> >> On 22/07/2021 08:45, Prathamesh Kulkarni via Gcc-patches wrote:
> >>> Hi,
> >>> The attached patch remove
On 20/07/21 20:43 +0100, Jonathan Wakely wrote:
Clang provides __builtin_operator_new and __builtin_operator_delete,
which have the same semantics as ::operator new and ::operator delete
except that the compiler is allowed to elide calls to them. This changes
std::allocator to use those built-in
Make the ranges::uninitialized_xxx algorithms use std::addressof to
protect against iterator types that overload operator&.
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
PR libstdc++/101571
* include/bits/ranges_uninitialized.h (_DestroyGuard): Change
constructo
On Thu, 22 Jul 2021 at 11:03, Jonathan Wakely wrote:
>
> On Thu, 22 Jul 2021 at 10:23, Stephan Bergmann via Libstdc++
> wrote:
> >
> > Compared to GCC 11 (at least gcc-c++-11.1.1-3.fc34.x86_64), recent GCC
> > 12 trunk emits two "unhelpful" -Wmaybe-uninitialized for
> >
> > > $ cat test.cc
> > > #
As the PR points out, we removed the debug version of std::array without
any period of deprecation. Although std::array contains all the actual
debug checks now, removing the header breaks any code
that was using that explicitly. The manual still lists doing that as
supported.
This restores the
Could you add a testcase? Otherwise LGTM.
Option: -O2 -mtune=thead-c906 -march=rv64gc -mabi=lp64
void foo(char *dst){
__builtin_memset(dst, 0, 15);
}
On Thu, Jul 22, 2021 at 8:53 PM Christoph Muellner via Gcc-patches
wrote:
>
> This patch enables the overlap-by-pieces feature of the by-pieces
On Thu, Jul 22, 2021 at 9:02 AM Bin.Cheng via Gcc-patches
wrote:
>
> Gentle ping. Any suggestions would be appreciated.
So just to say something - does the existing code mean that any use of
the alias info on prologue/epilogue insns is wrong? We have
/* The prologue/epilogue insns are not th
On Thu, Jul 22, 2021 at 2:56 PM Richard Biener
wrote:
>
> On Tue, Jul 20, 2021 at 4:37
> PM Kewen.Lin wrote:
> >
> > Hi,
> >
> > This v2 has addressed some review comments/suggestions:
> >
> > - Use "!=" instead of "<" in function operator!= (const Iter &rhs)
> > - Add new CTOR loops_list (st
On Tue, Jul 20, 2021 at 4:37
PM Kewen.Lin wrote:
>
> Hi,
>
> This v2 has addressed some review comments/suggestions:
>
> - Use "!=" instead of "<" in function operator!= (const Iter &rhs)
> - Add new CTOR loops_list (struct loops *loops, unsigned flags)
> to support loop hierarchy tree rat
Equivalences and relations are stored in dominator order. If they are
registered in non-dominator order, we sometimes get a little out of sync.
This may miss the occasional optimization opportunity, but is not
incorrect. When transitive relations are added, the intent is to
"beef-up" the Impl
On Thu, Jul 22, 2021 at 2:27 PM Christoph Müllner wrote:
>
> On Thu, Jul 22, 2021 at 11:29 AM Kito Cheng wrote:
> >
> > Sounds like we could just use !tune_param->slow_unaligned_access for
> > TARGET_OVERLAP_OP_BY_PIECES_P?
> > since it improves both performance and code size if we have cheap
> >
Can't ask for the type of an UNDEFINED value.
Bootstrapped on x86_64 & powerpc64-unknown-linux-gnu with no
regressions. Pushed.
Andrew
>From ea789238b2c24eedf70b56257235adf3d33c5a0a Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Mon, 19 Jul 2021 15:16:25 -0400
Subject: [PATCH 2/3] Chec
Resolve the issue of nonsensical conditions resolving differently than
vrp_visit_cond_stmt expects by resolving range_of_stmt first.
this resolves an issue where ranger was using equality between two
values to choose a branch when the ranges specified a different branch.
Its in unreachable c
This patch enables the overlap-by-pieces feature of the by-pieces
infrastructure for inlining builtins in case the target has set
riscv_slow_unaligned_access_p to false.
To demonstrate the effect for targets with fast unaligned access,
the following code sequences are generated for a 15-byte memse
Hi,
On Tue, Jul 20 2021, Martin Jambor wrote:
> On Tue, Jul 20 2021, Richard Biener wrote:
>> On Tue, Jul 20, 2021 at 10:54 AM JiangNing OS via Gcc-patches
>> wrote:
[...]
>>> > this patch has been motivated by SPEC 2017's 544.nab_r in which there is a
>>> > static variable which is never written
We can improve uninit warnings from the early pass by looking
at PHI arguments on fallthru edges that are uninitialized and
have uses that are before a possible loop exit. This catches
some cases earlier that we'd only warn in a more confusing
way after early inlining as seen by testcase adjustmen
For
(set (reg:V32QI 108)
(const_vector:V32QI [
(const_int -1 [0x]) repeated x32
])) "x.c":15:5 1573 {movv32qi_internal}
(expr_list:REG_EQUIV (const_vector:V32QI [
(const_int -1 [0x]) repeated x32
]
On Thu, Jul 22, 2021 at 11:29 AM Kito Cheng wrote:
>
> Sounds like we could just use !tune_param->slow_unaligned_access for
> TARGET_OVERLAP_OP_BY_PIECES_P?
> since it improves both performance and code size if we have cheap
> unaligned accesses.
Fine for me as well.
I'll prepare a v2, that uses
On Wed, Jul 21, 2021 at 9:43 AM liuhongt wrote:
>
> gcc/ChangeLog:
>
> * optabs-query.c (get_best_extraction_insn): Use word_mode for
> HF field.
>
> libgcc/ChangeLog:
>
> * config/i386/32/sfp-machine.h (_FP_NANFRAC_H): New macro.
> * config/i386/64/sfp-machine.h (_
Hi,
v2 now properly gets the reversed CC comparison. It also handles a cost2
== 0 situation that would prefer an empty seq2 before.
Regards
Robin
>From 12b796c4e081ba8a2e136958f4bf919c63516de6 Mon Sep 17 00:00:00 2001
From: Robin Dapp
Date: Thu, 24 Jun 2021 15:22:42 +0200
Subject: [PATCH v2
It might make sense to move:
/* Don't even try if the comparison operands are weird
except that the target supports cbranchcc4. */
if (! general_operand (cmp_a, GET_MODE (cmp_a))
|| ! general_operand (cmp_b, GET_MODE (cmp_b)))
{
if (!have_cbranchcc4
|| GE
It looks like this is an existing (potential) problem,
but default_noce_conversion_profitable_p uses seq_cost, which in turn
uses insn_cost. And insn_cost has an optional target hook behind it,
which allows for costing based on insn attributes etc. For a true
apples-with-apples comparison we sho
Hi Richard,
thanks for going through the patch set.
A hash_set might be simpler, given that the code only enters insns
for which the bool is false. “rtx_insn *” would be better than rtx.
Right, changed that.
Do you mean the sets might be removed or that the checks might be
removed?
It's
On Mon, Jul 19, 2021 at 12:03 AM Marc Glisse wrote:
>
> On Sun, 18 Jul 2021, Roger Sayle wrote:
>
> > +(if (GIMPLE || !TREE_SIDE_EFFECTS (@0))
>
> I don't think you need to worry about that, the general genmatch machinery
> is already supposed to take care of it. All the existing cases in matc
On 22/07/2021 12:32, Prathamesh Kulkarni wrote:
On Thu, 22 Jul 2021 at 16:03, Richard Earnshaw
wrote:
On 22/07/2021 08:45, Prathamesh Kulkarni via Gcc-patches wrote:
Hi,
The attached patch removes calls to builtins from vshl_n intrinsics,
and replacing them
with left shift operator. The
On Wed, Jul 21, 2021 at 9:43 AM liuhongt wrote:
>
> gcc/ChangeLog:
>
> * config/i386/i386-modes.def (FLOAT_MODE): Define ieee HFmode.
> * config/i386/i386.c (enum x86_64_reg_class): Add
> X86_64_SSEHF_CLASS.
> (merge_classes): Handle X86_64_SSEHF_CLASS.
> (e
On Wed, Jul 21, 2021 at 9:30 PM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> The problem here is we try to an initialized value
> from a scalar constant. For vectors we need to do
> a vect_dup instead. This fixes that issue by using
> build_{one,zero}_cst instead of integer_{one
On Thu, Jul 22, 2021 at 1:48 PM Jakub Jelinek wrote:
>
> On Thu, Jul 22, 2021 at 01:43:49PM +0200, Richard Biener wrote:
> > So I think we need to get to an agreement between the debug info
> > producer and consumer here.
> > Usually the DWARF spec is not of much help here.
>
> It is something tha
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
* config/aarch64/aarch64-simd-builtins.def (sdot, udot): Rename to..
(sdot_prod, udot_prod): ... This.
* config/aarch64/aarch64-simd.md (aarch64_dot): Merged
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
* config/aarch64/aarch64-builtins.c (TYPES_TERNOP_SUSS,
aarch64_types_ternop_suss_qualifiers): New.
* config/aarch64/aarch64-simd-builtins.def (usdot_prod): Use it
On Thu, Jul 22, 2021 at 01:43:49PM +0200, Richard Biener wrote:
> So I think we need to get to an agreement between the debug info
> producer and consumer here.
> Usually the DWARF spec is not of much help here.
It is something that needs to be discussed for DWARF 6, currently indeed can
be solved
On Wed, Jul 21, 2021 at 7:55 PM Hafiz Abid Qadeer
wrote:
>
> On 19/07/2021 17:41, Richard Biener wrote:
> > On July 19, 2021 6:13:40 PM GMT+02:00, Hafiz Abid Qadeer
> > wrote:
> >> On 19/07/2021 11:45, Richard Biener wrote:
> >>> On Fri, Jul 16, 2021 at 10:23 PM Hafiz Abid Qadeer
> >>> wrote:
>
On Thu, 22 Jul 2021 at 16:03, Richard Earnshaw
wrote:
>
>
>
> On 22/07/2021 08:45, Prathamesh Kulkarni via Gcc-patches wrote:
> > Hi,
> > The attached patch removes calls to builtins from vshl_n intrinsics,
> > and replacing them
> > with left shift operator. The patch passes bootstrap+test on
> >
Ping.
On 13/06/2021 14:27, Hafiz Abid Qadeer wrote:
> Add support for architectures such as AMD GCN, in which the pointer size is
> larger than the register size. This allows the CFI information to include
> multi-register locations for the stack pointer, frame pointer, and return
> address.
>
>
This avoids using multiple_of_p in niter analysis when its behavior
to assume the tested expression does not invoke integer overflow
produces wrong niter analysis results. For the cases multiple_of_p
handles power-of-two values of bottom look safe which should also be
the majority of cases we care
On 22/07/2021 08:45, Prathamesh Kulkarni via Gcc-patches wrote:
Hi,
The attached patch removes calls to builtins from vshl_n intrinsics,
and replacing them
with left shift operator. The patch passes bootstrap+test on
arm-linux-gnueabihf.
Altho, I noticed, that the patch causes 3 extra registe
Sounds like we could just use !tune_param->slow_unaligned_access for
TARGET_OVERLAP_OP_BY_PIECES_P?
since it improves both performance and code size if we have cheap
unaligned accesses.
On Thu, Jul 22, 2021 at 5:23 PM Christoph Müllner via Gcc-patches
wrote:
>
> On Thu, Jul 22, 2021 at 10:53 AM K
On Thu, Jul 22, 2021 at 10:53 AM Kito Cheng wrote:
>
> It's my first time seeing this hook :p Did you mind describing when we
> need to set it to true?
> I mean when a CPU has some feature then we can/should set it to true?
The by-pieces infrastructure allows to inline builtins quite well and
use
- Original Message -
> From: "Jonathan Wakely"
> To: "Marc Poulhies"
> Cc: "libstdc++" , "gcc-patches"
> , "Luc Michel"
> Sent: Wednesday, July 21, 2021 5:53:52 PM
> Subject: Re: [NEWS] libstdc++: Fix testsuite for skipping gdb tests on
> remote/non-native target
> Thanks for the patc
It's my first time seeing this hook :p Did you mind describing when we
need to set it to true?
I mean when a CPU has some feature then we can/should set it to true?
On Thu, Jul 22, 2021 at 7:33 AM Christoph Muellner via Gcc-patches
wrote:
>
> This patch adds the field overlap_op_by_pieces to the
On Wed, Jul 21, 2021 at 9:44 AM liuhongt wrote:
>
> From: "Guo, Xuepeng"
>
> gcc/ChangeLog:
>
> * common/config/i386/cpuinfo.h (get_available_features):
> Detect FEATURE_AVX512FP16.
> * common/config/i386/i386-common.c
> (OPTION_MASK_ISA_AVX512FP16_SET,
> O
On 16.07.21 05:46, Sandra Loosemore wrote:
When I was reading code in conjunction with fixing PR101317, I noticed
an unrelated bug in the implementation of CFI_allocate and
CFI_select_part: they were mis-handling the CFI_signed_char type as
if it were a Fortran character type for the purposes o
Hi Sandra,
On 21.07.21 20:01, Sandra Loosemore wrote:
Hmmm. CFI_establish explicitly says that the elem_len has to be
greater than zero. It seems somewhat confusing that it's inconsistent
with the other functions that take an elem_len argument.
Congratulation – we have found a bug in the spec
Hi,
The attached patch removes calls to builtins from vshl_n intrinsics,
and replacing them
with left shift operator. The patch passes bootstrap+test on
arm-linux-gnueabihf.
Altho, I noticed, that the patch causes 3 extra registers to spill
using << instead
of the builtin for vshl_n.c. Could that
Gentle ping. Any suggestions would be appreciated.
Thanks,
bin
On Wed, Jul 14, 2021 at 5:15 PM bin.cheng via Gcc-patches
wrote:
>
> Hi,
> I ran into a wrong code bug in code with deep template instantiation when
> working on sdx::simd.
> The root cause as described in commit summary is we skip
91 matches
Mail list logo
