Hi All,
Although I had undertaken to concentrate on PDTs, PR99819 so intrigued me
that I became locked into it :-( After extensive, fruitless rummaging
through decl.c and trans-decl.c, I realised that the problem was far
simpler than it seemed and that it lay in class.c. After that PR was fixed,
P
On Fri, Apr 30, 2021 at 4:10 PM Christoph Müllner via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On Sat, May 1, 2021 at 12:48 AM Jeff Law wrote:
> > On 4/26/2021 5:38 AM, Christoph Muellner via Gcc-patches wrote:
> > > [ree] PR rtl-optimization/100264: Handle more PARALLEL SET expressions
>
Gentle ping, thanks.
On 2021/4/16 15:10, Xiong Hu Luo wrote:
fmod/fmodf and remainder/remainderf could be expanded instead of library
call when fast-math build, which is much faster.
fmodf:
fdivs f0,f1,f2
frizf0,f0
fnmsubs f1,f2,f0,f1
remainderf:
fdivs f0,f1,f2
On 2021-05-01 05:37, Segher Boessenkool wrote:
Hi!
On Thu, Apr 29, 2021 at 05:50:48PM +0800, Jiufu Guo wrote:
When there is the possibility that overflow may happen on the loop
index,
a few optimizations would not happen. For example code:
foo (int *a, int *b, unsigned k, unsigned n)
{
whil
On Wed, May 5, 2021 at 12:23 PM Christoph Muellner
wrote:
> gcc/
> PR 100266
> * config/rsicv/riscv.c (riscv_block_move_loop): Simplify.
> * config/rsicv/riscv.md (cbranch4): Generate helpers.
>
OK. Committed. Though I had to fix the ChangeLog entry. It was indente
On 2021-05-01 00:27, Jeff Law wrote:
On 4/29/2021 3:50 AM, Jiufu Guo via Gcc-patches wrote:
When there is the possibility that overflow may happen on the loop
index,
a few optimizations would not happen. For example code:
foo (int *a, int *b, unsigned k, unsigned n)
{
while (++k != n)
On Wed, May 5, 2021 at 12:37 PM Christoph Muellner
wrote:
> The existing CAS implementation uses an INSN definition, which provides
> the core LR/SC sequence. Additionally to that, there is a follow-up code,
> that evaluates the results and calculates the return values.
> This has two drawbacks:
Hi,
The attached patch replaces __builtin_neon_vtst* (a, b) with (a & b) != 0.
Bootstrapped and tested on arm-linux-gnueabihf and cross-tested on arm*-*-*.
OK to commit ?
Thanks,
Prathamesh
vtst-1.diff
Description: Binary data
This patch introduces a dwarf_debuginfo_p predicate that abstracts and
replaces complex checks on write_symbols.
gcc/c-family/ChangeLog:
* c-lex.c (init_c_lex): Use dwarf_debuginfo_p.
gcc/ChangeLog:
* config/c6x/c6x.c (c6x_output_file_unwind): Use dwarf_debuginfo_p.
* dw
To support multiple debug formats, we need to move away from explicit
enumeration of each individual combination of debug formats.
gcc/c-family/ChangeLog:
* c-opts.c (c_common_post_options): Adjust access to debug_type_names.
* c-pch.c (struct c_pch_validity): Use type uint32_t.
Hello,
Over the last year, we have discussed and agreed that in order to support
multiple debug formats, we keep DWARF as the default internal debug format; Any
new debug format to be supported feeds off DWARF dies. This requirement
specification has worked well for addition for CTF/BTF overall.
On Tue, 4 May 2021, Christophe Lyon via Gcc-patches wrote:
> The new test gcc.c-torture/execute/ieee/cdivchkld.c needs fmaxl(),
> which may not be available, for instance on aarch64-elf with newlib.
> As discussed in the PR, requiring c99_runtime enables to skip the test
> in this case.
>
> 2021-
On Wed, 5 May 2021, David Laight via Libc-alpha wrote:
> > __u64 can't be formatted with %llu on all architectures. That's not
> > true for uint64_t, where you have to use %lu on some architectures to
> > avoid compiler warnings (and technically undefined behavior). There are
> > preprocessor ma
This changes godump to use the new htab_eq_string function.
gcc
* godump.c (string_hash_eq): Remove.
(go_finish): Use htab_eq_string.
---
gcc/godump.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/gcc/godump.c b/gcc/godump.c
index 7864d9d63e5
This changes one spot in GCC to use the new htab_eq_string function.
gcc
* gengtype-state.c (read_state): Use htab_eq_string.
(string_eq): Remove.
---
gcc/gengtype-state.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/gcc/gengtype-state.c b/gcc/g
The libiberty hash table defines a hash function for strings, but not
an equality function. This means that various files have had to
implement their own comparison function over the years.
This series resolves this for gcc. Once this is in, I plan to import
the change into binutils-gdb and appl
The libiberty hash table includes a helper function for strings, but
no equality function. Consequently, this equality function has been
reimplemented a number of times in both the gcc and binutils-gdb
source trees. This patch adds the function to the libiberty hash
table, as a step toward the go
On 05/05/21 21:57 +0200, François Dumont via Libstdc++ wrote:
On 05/05/21 2:01 pm, Jonathan Wakely via Libstdc++ wrote:
Passing plain char to isdigit is undefined if the value is negative.
libstdc++-v3/ChangeLog:
* include/std/charconv (__from_chars_alnum): Pass unsigned
char t
/i386.c (ix86_compute_frame_layout): For a SEH target,
always return the establisher frame for __builtin_frame_address (0).
2021-05-05 Eric Botcazou
* gcc.c-torture/execute/20210505-1.c: New test.
--
Eric Botcazoudiff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/10/11?
libstdc++-v3/ChangeLog:
* include/std/ranges (filter_view::_Iterator::base): Make the
const& overload return a const reference and remove its
constraint as per LWG 3533. Make unconditionally noexcept.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/10/11?
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (move_iterator::base): Make the
const& overload return a const reference and remove its
constraint as per LWG 3391. Make unconditionally noexcept.
On 05/05/21 2:01 pm, Jonathan Wakely via Libstdc++ wrote:
Passing plain char to isdigit is undefined if the value is negative.
libstdc++-v3/ChangeLog:
* include/std/charconv (__from_chars_alnum): Pass unsigned
char to std::isdigit.
Tested powerpc64le-linux. Committed to trunk.
Atomic instructions require zero-offset memory addresses.
If we allow all addresses, the nonzero-offset addresses will
be prepared in an extra register in an extra instruction before
the actual atomic instruction.
This patch introduces the predicate "riscv_sync_memory_operand",
which restricts the
The existing CAS implementation uses an INSN definition, which provides
the core LR/SC sequence. Additionally to that, there is a follow-up code,
that evaluates the results and calculates the return values.
This has two drawbacks: a) an extension to sub-word CAS implementations
is not possible (eve
The current model of the LR and SC INSNs requires a sign-extension
to use the generated SImode value for conditional branches, which
only operate on XLEN registers.
However, the sign-extension is actually not required in both cases,
therefore this patch introduces additional INSNs that consume
the
In order to emit LR/SC sequences, let's provide INSNs, which
take care of memory ordering constraints.
gcc/
PR 100266
* config/rsicv/sync.md (UNSPEC_LOAD_RESERVED): New.
* config/rsicv/sync.md (UNSPEC_STORE_CONDITIONAL): New.
* config/riscv/sync.md (riscv_load_r
A recent commit introduced a mechanism to emit proper fences
for RISC-V. Additionally, we already have emit_move_insn ().
Let's reuse this code and provide atomic_load and
atomic_store for RISC-V (as defined in section
"Code Porting and Mapping Guidelines" of the unpriv spec).
Note, that this works
mem_thread_fence gets the desired memory model as operand.
Let's emit fences according to this value (as defined in section
"Code Porting and Mapping Guidelines" of the unpriv spec).
gcc/
PR 100265
* config/riscv/sync.md (mem_thread_fence):
Emit fences according t
Using AMOSWAP as atomic store does not allow us to do sub-word accesses.
Further, it is not consistent with our atomic_load () implementation.
The benefit of AMOSWAP is that the resulting code sequence will be
smaller (comapred to FENCE+STORE), however, this does not weight
out for the lack of sub-
A previous patch took care, that the proper memory ordering suffixes
for AMOs are emitted. Therefore there is no reason to keep the fence
generation mechanism for release operations.
gcc/
PR 100265
* config/riscv/riscv.c (riscv_memmodel_needs_release_fence):
Remove fu
The ratified A extension supports '.aq', '.rl' and '.aqrl' as
memory ordering suffixes. Let's emit them in case we get a '%A'
conversion specifier for riscv_print_operand().
As '%A' was already used for a similar, but restricted, purpose
(only '.aq' was emitted so far), this does not require any o
We don't have any special treatment of MEMMODEL_SYNC_* values,
so let's hide them behind the memmodel_base() function.
gcc/
PR 100265
* config/riscv/riscv.c (riscv_memmodel_needs_amo_acquire):
Ignore MEMMODEL_SYNC_* values.
* config/riscv/riscv.c (riscv_memmod
This series provides a cleanup of the current atomics implementation
of RISC-V:
* PR100265: Use proper fences for atomic load/store
* PR100266: Provide programmatic implementation of CAS
As both are very related, I merged the patches into one series.
The first patch could be squashed into the fo
On Mon, Apr 26, 2021 at 4:40 PM Kito Cheng wrote:
>
> This patch is a good and simple improvement which could be an independent
> patch.
>
> There is only 1 comment from me for this patch, could you also add @
> to cbranch pattern for floating mode, I would prefer make the
> gen_cbranch4 could ha
On RISC-V we are facing the fact, that our conditional branches
require Pmode conditions. Currently, we generate them explicitly
with a check for Pmode and then calling the proper generator
(i.e. gen_cbranchdi4 on RV64 and gen_cbranchsi4 on RV32).
Let's simplify this code by generating the INSN hel
Ping!
On Tue, 20 Apr 2021 at 12:51, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi All,
>
> This is another PDT warm-up patch before tackling the real beast: PR82649.
>
> As the contributor wrote in the PR, "The F08 standard clearly
> distinguishes between type parameter definit
> On May 5, 2021, at 8:45 AM, Segher Boessenkool
> wrote:
>
> Hi~
>
> On Tue, May 04, 2021 at 04:08:22PM +0100, Richard Earnshaw wrote:
>> On 03/05/2021 23:55, Segher Boessenkool wrote:
>>> CC_STATUS_INIT is suggested in final.c to also be useful for ports that
>>> are not CC0, and at least
On Wed, May 5, 2021 at 4:50 PM H.J. Lu wrote:
>
> On Wed, May 05, 2021 at 09:36:16AM +0200, Richard Biener wrote:
> > On Mon, May 3, 2021 at 11:31 AM Ivan Sorokin via Gcc-patches
> > wrote:
> > >
> > > Prior to this commit GCC -O2 generated quite bad code for this
> > > function:
> > >
> > > bool
On Tue, Jan 19, 2021 at 04:10:33PM +, Richard Sandiford via Gcc-patches
wrote:
> Ah, ok, thanks for the extra context.
>
> So AIUI the problem when recording xmm2<-di isn't just:
>
> [A] partial_subreg_p (vd->e[sr].mode, GET_MODE (src))
>
> but also that:
>
> [B] partial_subreg_p (vd->e[
Forgot to CC maintainers..
-Original Message-
From: Tamar Christina
Sent: Wednesday, May 5, 2021 6:39 PM
To: gcc-patches@gcc.gnu.org
Cc: nd
Subject: [PATCH 3/4][AArch32]: Add support for sign differing dot-product usdot
for NEON.
Hi All,
This adds optabs implementing usdot_prod.
Th
Hi All,
This adds testcases to test for auto-vect detection of the new sign differing
dot product.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
* doc/sourcebuild.texi (arm_v8_2a_i8mm_neon_hw): Document.
gcc/testsuite/Chan
Hi All,
This adds optabs implementing usdot_prod.
The following testcase:
#define N 480
#define SIGNEDNESS_1 unsigned
#define SIGNEDNESS_2 signed
#define SIGNEDNESS_3 signed
#define SIGNEDNESS_4 unsigned
SIGNEDNESS_1 int __attribute__ ((noipa))
f (SIGNEDNESS_1 int res, SIGNEDNESS_3 char *restri
Hi All,
This adds optabs implementing usdot_prod.
The following testcase:
#define N 480
#define SIGNEDNESS_1 unsigned
#define SIGNEDNESS_2 signed
#define SIGNEDNESS_3 signed
#define SIGNEDNESS_4 unsigned
SIGNEDNESS_1 int __attribute__ ((noipa))
f (SIGNEDNESS_1 int res, SIGNEDNESS_3 char *restri
Hi All,
This patch adds support for a dot product where the sign of the multiplication
arguments differ. i.e. one is signed and one is unsigned but the precisions are
the same.
#define N 480
#define SIGNEDNESS_1 unsigned
#define SIGNEDNESS_2 signed
#define SIGNEDNESS_3 signed
#define SIGNEDNESS_4
Hi All,
There's no reason that the sign of the operands of dot-product have to all be
the same. The only restriction really is that the sign of the multiplicands
are the same, however the sign between the multiplier and the accumulator need
not be the same.
The type of the overall operations sho
Hi All,
Currently when using -mcpu=native or -march=native on a CPU that is unknown to
the compiler the compiler currently just used -march=armv8-a and enables none
of the extensions.
To make this a bit more useful this patch changes it to still use -march=armv8.a
but to enable the extensions. W
On 5/5/21 1:32 AM, Richard Biener wrote:
On Wed, May 5, 2021 at 4:20 AM Martin Sebor via Gcc-patches
wrote:
Even when explicitly enabled, -Walloca-larger-than doesn't run
unless optimization is enabled as well. This prevents diagnosing
alloca calls with constant arguments in excess of the lim
>
>>
>>> @@ -11950,6 +12088,72 @@ lower_bound_in_type (tree outer, tree inner)
>>>}
>>> }
>>>
>>> +/* Returns true when the given TYPE has padding inside it.
>>> + return false otherwise. */
>>> +bool
>>> +type_has_padding (tree type)
>>
>> Would it be possible to reuse __builtin_clear_p
On 5/5/2021 8:31 AM, Robin Dapp via Gcc-patches wrote:
Hi,
pr56541.c implicitly converts a float vector to an int (bool) vector:
rMin = (rMax>0) ? rMin : rBig;
It fails on some s390 targets because the do not support converting
from vector float to int. Is adding a vect_floatint_cvt as in
On 5/5/2021 8:39 AM, Robin Dapp via Gcc-patches wrote:
Hi,
this patch adds some s390 checks for vect_*_cvts. Is it OK?
Regards
Robin
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Add s390 checks for vect conversions.
OK
jeff
On 05/05/2021 13:34, Richard Biener wrote:
On Wed, 5 May 2021, Andre Vieira (lists) wrote:
I tried to see what IVOPTs would make of this and it is able to analyze the
IVs but it doesn't realize (not even sure it tries) that one IV's end (loop 1)
could be used as the base for the other (loop 2
On Wed, May 05, 2021 at 01:45:29PM +0200, Marc Glisse wrote:
> On Tue, 4 May 2021, Jakub Jelinek via Gcc-patches wrote:
>
> > 2) the pr94589-2.C testcase should be matching just 12 times each, but runs
> > into operator>=(strong_ordering, unspecified) being defined as
> > (_M_value&1)==_M_value
>
Hi all,
looking for some feedback on this, one thing I would like to draw attention to
is the fact that this pattern requires 2 separate dependent reductions in the
epilogue.
The accumulator vector for the maximum/minimum elements can be reduced to a
scalar result trivially with a min/max, but
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 standa
On 5/4/21 1:44 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
genericize_spaceship genericizes i <=> j to approximately
({ int c; if (i == j) c = 0; else if (i < j) c = -1; else c = 1; c; })
for strong ordering and
({ int c; if (i == j) c = 0; else if (i < j) c = -1; else if (i > j) c = 1;
else c
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 avoi
Removes references to CC_STATUS_INIT from the avr port, which should get
it to the point of building again.
Committed to the trunk.
Jeff
commit b927ffdd6cecd0eeda6ef77df2623519870b1e75
Author: Jeff Law
Date: Wed May 5 09:15:42 2021 -0600
Remove cc0 remnants from avr port
g
Hi,
this patch adds vcond_mask patterns with mixed mode for the
condition/mask and source, target so e.g. boolean conditions become
possible:
vtarget = bool_cond ? vsource1 : vsource2.
Is it OK for trunk?
Regards
Robin
gcc/ChangeLog:
* config/s390/vector.md
(vcond_mask_): Add
This patch implements relaxing the requirements when a map with the implicit
attribute encounters
an overlapping existing map. As the OpenMP 5.0 spec describes on page 320,
lines 18-27 (and 5.1 spec,
page 352, lines 13-22):
"If a single contiguous part of the original storage of a list item wit
On Wed, May 05, 2021 at 09:36:16AM +0200, Richard Biener wrote:
> On Mon, May 3, 2021 at 11:31 AM Ivan Sorokin via Gcc-patches
> wrote:
> >
> > Prior to this commit GCC -O2 generated quite bad code for this
> > function:
> >
> > bool f()
> > {
> > return __builtin_cpu_supports("popcnt")
> >
Hi, Richard,
During the change for the 2nd version based on your previous comments, I have
the following questions need your help:
>
>> + sra_stats.subtree_deferred_init++;
>> +}
>> + else if (access->grp_to_be_debug_replaced)
>> +{
>> + /* FIXME, this part might have so
Hi,
this patch adds some s390 checks for vect_*_cvts. Is it OK?
Regards
Robin
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Add s390 checks for vect conversions.
>From 959251d5d2684a9ffebec1b341a4413c2f2328db Mon Sep 17 00:00:00 2001
From: Robin Dapp
Date: Thu, 22 Apr 2021 09:3
Hi,
pr56541.c implicitly converts a float vector to an int (bool) vector:
rMin = (rMax>0) ? rMin : rBig;
It fails on some s390 targets because the do not support converting from
vector float to int. Is adding a vect_floatint_cvt as in the attached
patch the OK thing to do?
Or better an xf
On Wed, 5 May 2021, Jakub Jelinek wrote:
> On Wed, May 05, 2021 at 01:39:32PM +0200, Richard Biener wrote:
> > Can you in the above IL snippets mark COND_BB and MIDDLE_BB?
> ...
>
> Thanks.
> Here is an updated patch (attached) and interdiff from previous patch.
> Ok for trunk if it passes bootst
On Tue, 4 May 2021 at 19:03, Christophe Lyon wrote:
>
> On Tue, 4 May 2021 at 15:43, Christophe Lyon
> wrote:
> >
> > On Tue, 4 May 2021 at 13:48, Andre Vieira (lists)
> > wrote:
> > >
> > > It would be good to also add tests for NEON as you also enable auto-vec
> > > for it. I checked and I do
On Tue, 4 May 2021 at 15:41, Christophe Lyon wrote:
>
> On Tue, 4 May 2021 at 13:29, Andre Vieira (lists)
> wrote:
> >
> > Hi Christophe,
> >
> > On 30/04/2021 15:09, Christophe Lyon via Gcc-patches wrote:
> > > Since MVE has a different set of vector comparison operators from
> > > Neon, we have
cr16 failed to build due to remnants of CC0 support (NOTICE_UPDATE_CC).
This removes the macro and obvious bits necessary to support it.
Committed to the trunk.
Jeff
commit 14cf6aab8578132ec89ccb46e69899ae6008ff63
Author: Jeff Law
Date: Wed May 5 07:49:28 2021 -0600
Remove NOTICE
Hi Eric, hi all,
currently, gcn (amdgcn-amdhsa) bootstrapping fails as Alexandre's
patch to __builtin_memset (applied yesterday) now does more expansions.
The problem is [→ PR100418]
(set(reg:DI)(plus:DI(reg:DI)(const_int))) [= "adddi3"]
This fails with gcn as gcn has two clobbers for "adddi3
Hi,
This is a backport to gcc-10, cleanly applied on the branch.
As reported in bugzilla when the -mcmse option is used while compiling for size
(-Os) with a thumb-1 target the generated code will clear the registers r7-r10.
These however are callee saved and should be preserved accross ABI bound
Hi,
This is a backport to gcc-10, cleanly applied on the branch.
This patch changes the test to use the effective-target machinery disables the
error message "ARMv8-M Security Extensions incompatible with selected FPU" when
-mfloat-abi=soft.
Further changes 'asm' to '__asm__' to avoid failures wi
Implement integer vector compares for 64bit vectors for TARGET_MMX_WITH_SSE.
2021-05-05 Uroš Bizjak
gcc/
PR target/98218
* config/i386/i386-expand.c (ix86_expand_int_sse_cmp):
Handle V8QI, V4HI and V2SI modes.
* config/i386/i386.c (ix86_build_const_vector): Handle V2SImode.
On Wed, May 05, 2021 at 01:39:32PM +0200, Richard Biener wrote:
> Can you in the above IL snippets mark COND_BB and MIDDLE_BB?
...
Thanks.
Here is an updated patch (attached) and interdiff from previous patch.
Ok for trunk if it passes bootstrap/regtest?
--- gcc/tree-ssa-phiopt.c 2021-05-03
Improve GOT addressing by emitting the instructions as a pair. This reduces
register pressure and improves code quality. With -fPIC codesize improves by
0.65% and SPECINT2017 improves by 0.25%.
Passes bootstrap and regress. OK for commit?
ChangeLog:
2021-05-05 Wilco Dijkstra
* confi
On Tue, Mar 23, 2021 at 5:29 PM Markus Böck via Gcc-patches
wrote:
>
> GCC at the moment uses COMDAT groups for things like virtual thunks,
> even on targets that do not support COMDAT groups. This has not been a
> problem as on platforms not supporting these (such as PE COFF on
> Windows), the ba
On Tue, Apr 27, 2021 at 5:29 PM Martin Jambor wrote:
>
> Hi,
>
> IPA-SRA fails to produce (very simple) edge summaries when a caller
> cannot be cloned or its signature cannot be changed which makes it
> less powerful for no good reason. This patch fixes that problem.
>
> Bootstrapped, LTO-bootst
On Tue, May 04, 2021 at 06:30:04PM +0200, Eric Botcazou wrote:
> > Pushed. What is next? :-)
>
> You can finally remove powerpcspe. :-)
Done, thanks!
Segher
Committed.
Segher
---
htdocs/backends.html | 1 -
1 file changed, 1 deletion(-)
diff --git a/htdocs/backends.html b/htdocs/backends.html
index 8034a5776360..f80378b90170 100644
--- a/htdocs/backends.html
+++ b/htdocs/backends.html
@@ -103,7 +103,6 @@ nios2 | C ia
nvptx
Hi~
On Tue, May 04, 2021 at 04:08:22PM +0100, Richard Earnshaw wrote:
> On 03/05/2021 23:55, Segher Boessenkool wrote:
> >CC_STATUS_INIT is suggested in final.c to also be useful for ports that
> >are not CC0, and at least arm seems to use it for something. So I am
> >leaving that alone, but most
Hi Richard,
> -Original Message-
> From: Richard Earnshaw
> Sent: 05 May 2021 11:15
> To: Srinath Parvathaneni ; gcc-
> patc...@gcc.gnu.org
> Cc: Richard Earnshaw
> Subject: Re: [GCC][PATCH] arm: Remove duplicate definitions from
> arm_mve.h (pr100419).
>
>
>
> On 05/05/2021 10:56, Sr
On Wed, May 05, 2021 at 02:19:27PM +0200, Eric Botcazou wrote:
> > At least for NOTE_INSN_BASIC_BLOCK skipping more than one might
> > be problematic, because that would mean we've skipped into a different basic
> > block and it wouldn't surprise me if split_block in that case crashed or
> > did so
On Wed, 5 May 2021, Andre Vieira (lists) wrote:
> Hi Richi,
>
> So I'm trying to look at what IVOPTs does right now and how it might be able
> to help us. Looking at these two code examples:
> #include
> #if 0
> int foo(short * a, short * b, unsigned int n)
> {
> int sum = 0;
> for (unsi
Dear Prospective Panelist,
You have been selected as a Customer Satisfaction Analyst to participate in our
short exclusive 10-15 minutes paid project study on Walmart,Walgreens & CVS
stores within your area.
REWARDS: You will earn $500.00 for each completed survey project.
SURVEY [#53779-1001
> At least for NOTE_INSN_BASIC_BLOCK skipping more than one might
> be problematic, because that would mean we've skipped into a different basic
> block and it wouldn't surprise me if split_block in that case crashed or
> did something weird (if the first argument is not BLOCK_FOR_INSN of the
> sec
libstdc++-v3/ChangeLog:
* testsuite/20_util/function_objects/invoke/3.cc: Check feature
test macro.
* testsuite/20_util/function_objects/invoke/version.cc: New test.
Tested powerpc64le-linux. Committed to trunk.
commit 29745bf06276b9628d08ef1c9e28890cc56df4aa
Author: Jona
Passing plain char to isdigit is undefined if the value is negative.
libstdc++-v3/ChangeLog:
* include/std/charconv (__from_chars_alnum): Pass unsigned
char to std::isdigit.
Tested powerpc64le-linux. Committed to trunk.
commit d0d6ca019717305df0ef41e3fe1da48f7f561fac
Author: Jon
On Tue, 4 May 2021, Jakub Jelinek via Gcc-patches wrote:
2) the pr94589-2.C testcase should be matching just 12 times each, but runs
into operator>=(strong_ordering, unspecified) being defined as
(_M_value&1)==_M_value
rather than _M_value>=0. When not honoring NaNs, the 2 case should be
unreac
On Tue, 4 May 2021, Jakub Jelinek wrote:
> Hi!
>
> genericize_spaceship genericizes i <=> j to approximately
> ({ int c; if (i == j) c = 0; else if (i < j) c = -1; else c = 1; c; })
> for strong ordering and
> ({ int c; if (i == j) c = 0; else if (i < j) c = -1; else if (i > j) c = 1;
> else c =
On Wed, May 05, 2021 at 01:21:20PM +0200, Eric Botcazou wrote:
> > I mean, can't we have just one while loop that skips over all debug insns,
> > NOTE_INSN_BASIC_BLOCK_P, NOTE_INSN_PROLOGUE_END and NOTE_INSN_FUNCTION_BEG
> > and stops on anything else, or, if we want to skip at most one of some or
Hi Richi,
So I'm trying to look at what IVOPTs does right now and how it might be
able to help us. Looking at these two code examples:
#include
#if 0
int foo(short * a, short * b, unsigned int n)
{
int sum = 0;
for (unsigned int i = 0; i < n; ++i)
sum += a[i] + b[i];
retur
On 24/04/21 15:46 +0200, François Dumont via Libstdc++ wrote:
Hi
Here is the patch to add backtrace generation on _GLIBCXX_DEBUG
assertions thanks to libbacktrace.
In addition to this integration I am also improving the generation
of the assertion message thanks to the "%.*s" printf
> I mean, can't we have just one while loop that skips over all debug insns,
> NOTE_INSN_BASIC_BLOCK_P, NOTE_INSN_PROLOGUE_END and NOTE_INSN_FUNCTION_BEG
> and stops on anything else, or, if we want to skip at most one of some or
> all of those note kinds, do some tracking if we've already skipped
On Wed, May 05, 2021 at 01:00:35PM +0200, Eric Botcazou wrote:
> 2021-05-05 Eric Botcazou
>
> PR rtl-optimization/100411
> * cfgcleanup.c (try_crossjump_to_edge): Also skip end of prologue
> and beginning of function markers.
>
> --
> Eric Botcazou
> diff --git a/gcc/cfgcle
Hi,
this is the bootstrap failure of GCC 11 on MinGW64 configured with --enable-
tune=nocona. The bottom line is that SEH does not support CFI for epilogues
but the x86 back-end nevertheless attaches it to instructions, so we have to
filter it out and this is done by detecting the end of the pr
> For move2add_valid_value_p we also have to ask the target whether a
> register can be accessed in a different mode than it was set before.
>
> gcc/ChangeLog:
>
> PR rtl-optimization/100263
> * postreload.c (move2add_valid_value_p): Ensure register can
> change mode.
>
> Boots
On 05/05/2021 10:56, Srinath Parvathaneni via Gcc-patches wrote:
Hi All,
This patch removes several duplicated intrinsic definitions from
arm_mve.h mentioned in PR100419 and also fixes the wrong arguments
in few of intrinsics polymorphic variants.
Regression tested and found no issues.
Ok f
> OK.
Thanks.
> I suppose there's no easy way to build a gnat.dg "guality" testcase for
> this?
On all the platforms I test, I have a bunch of guality failures so I'm not
really thrilled by the idea... This should be covered by the GDB testsuite
run with -fgnat-encodings=minimal but it's actu
On Wed, May 5, 2021 at 11:36 AM Richard Biener
wrote:
>
> On Tue, Mar 16, 2021 at 6:13 PM Stefan Schulze Frielinghaus
> wrote:
> >
> > [snip]
> >
> > Please find attached a new version of the patch. A major change compared to
> > the previous patch is that I created a separate pass which hopeful
On 04/05/21 08:03 +0200, François Dumont wrote:
On 03/05/21 11:06 pm, Jonathan Wakely wrote:
On 03/05/21 22:17 +0200, François Dumont via Libstdc++ wrote:
Is it too early to consider this patch ? Or just lack of time ?
I haven't had time to review it yet, but my general feeling hasn't
changed
Hi All,
This patch removes several duplicated intrinsic definitions from
arm_mve.h mentioned in PR100419 and also fixes the wrong arguments
in few of intrinsics polymorphic variants.
Regression tested and found no issues.
Ok for master ? GCC-11 and GCC-10 branch backports?
gcc/ChangeLog:
2021-0
Found with amdgcn – silences a build warning there.
Committed as r12-509-gdee371fdd4ae25f837b9b2ded7789d07ed739c9e
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
c
1 - 100 of 147 matches
Mail list logo
