Hi Bin,
I've updated the patch to punt ainc_use candidates as below:
> + /* Skip AINC candidate since it contains address update itself,
> +the replicated AINC computations when unrolling still have
> +updates, unlike reg_offset_p candidates ca
On Linux/x86_64,
0c344a649d803a83ed35f629d292b98143935ffa is the first bad commit
commit 0c344a649d803a83ed35f629d292b98143935ffa
Author: Martin Sebor
Date: Tue Sep 1 16:02:19 2020 -0600
Use the determined lower bound of the range of offsets in a PLUS_EXPR.
caused
FAIL: gcc.dg/pr89350.c
On Wed, Sep 2, 2020 at 11:50 AM Kewen.Lin wrote:
>
> Hi Bin,
>
> >> 2) This case makes me think we should exclude ainc candidates in function
> >> mark_reg_offset_candidates. The justification is that: ainc candidate
> >> handles step update itself and when we calculate the cost for it against
>
Hi Bin,
>> 2) This case makes me think we should exclude ainc candidates in function
>> mark_reg_offset_candidates. The justification is that: ainc candidate
>> handles step update itself and when we calculate the cost for it against
>> its ainc_use, the cost_step has been reduced. When unrolling
Hi Segher,
on 2020/9/1 上午3:41, Segher Boessenkool wrote:
> Hi!
>
> Just a note:
>
> On Tue, Aug 25, 2020 at 08:46:55PM +0800, Kewen.Lin wrote:
>> 1) Currently address_cost hook on rs6000 always return zero, but at least
>> from Power7, pre_inc/pre_dec kind instructions are cracked, it means we
>
On Linux/x86_64,
0c344a649d803a83ed35f629d292b98143935ffa is the first bad commit
commit 0c344a649d803a83ed35f629d292b98143935ffa
Author: Martin Sebor
Date: Tue Sep 1 16:02:19 2020 -0600
Use the determined lower bound of the range of offsets in a PLUS_EXPR.
caused
FAIL: gcc.dg/pr89350.c
Hi,
This corrects an issue with the powerpc vector long long subtypes.
As reported by SjMunroe in PR96139. When building some code with -Wall
and attempting to print an element of a "long long vector" with a long long
printf format string, we will report a error because the vector sub-type
was
On Tue, Sep 1, 2020 at 6:11 PM Jakub Jelinek wrote:
>
> On Tue, Sep 01, 2020 at 05:55:18PM +0800, Hongtao Liu wrote:
> > I tried define_split, but there's too many of them(considering usage
> > of define_subst for mask).
> > Also for new added instructions which support embedded broadcast,
> > cor
Hello.
This WIP patch implements new reflection functions in the C API as
mentioned in bug 96889.
I'm looking forward for feedbacks on this patch.
It's WIP because I'll probably add a few more reflection functions.
Thanks.
>From 23ab738c0d9202f6798a38fb4aa15edfcc67d11c Mon Sep 17 00:00:00 2001
F
On 9/1/20 4:22 PM, Jeff Law wrote:
On Tue, 2020-09-01 at 16:13 -0600, Martin Sebor wrote:
On 9/1/20 2:09 AM, Christophe Lyon wrote:
On Mon, 31 Aug 2020 at 23:50, Martin Sebor wrote:
On 8/31/20 4:51 AM, Christophe Lyon wrote:
Hi,
...
I pushed a small aarch64 patch as obvious:
2020-0
Hi Roger,
This change is fine. PR middle-end/87256 remains resolved.
I'll have to tweak the shadd-2 test again. The number of sh*add instructions
dropped
to three but the total number of instruction dropped by one.
Thanks,
Dave
On 2020-08-27 12:42 p.m., Roger Sayle wrote:
> Hi Dave (and Jeff
On Tue, Sep 01, 2020 at 05:33:43PM -0400, Jason Merrill via Gcc-patches wrote:
> On 9/1/20 3:41 PM, Marek Polacek wrote:
> > On Tue, Sep 01, 2020 at 03:27:36PM -0400, Jason Merrill via Gcc-patches
> > wrote:
> > > On 9/1/20 12:10 PM, Marek Polacek wrote:
> > > > Currently, we allow new char[]{"foo
This patch nails down the remaining P0960 case in PR92812:
struct A {
int ar[2];
A(): ar(1, 2) {} // doesn't work without this patch
};
Note that when the target object is not of array type, this already
works:
struct S { int x, y; };
struct A {
S s;
A(): s(1, 2) { } // O
This WIP patchlet introduces means for machines that implicitly clobber
cc flags in asm statements, but that have machinery to output flags
(namely x86, non-thumb arm and aarch64), to state that the asm statement
does NOT clobber cc flags. That's accomplished by using "=@ccC" in the
output const
On Tue, 2020-09-01 at 16:13 -0600, Martin Sebor wrote:
> On 9/1/20 2:09 AM, Christophe Lyon wrote:
> > On Mon, 31 Aug 2020 at 23:50, Martin Sebor wrote:
> > > On 8/31/20 4:51 AM, Christophe Lyon wrote:
> > > > Hi,
> > > >
> > > ...
> > > > I pushed a small aarch64 patch as obvious:
> > > >
On 9/1/20 2:09 AM, Christophe Lyon wrote:
On Mon, 31 Aug 2020 at 23:50, Martin Sebor wrote:
On 8/31/20 4:51 AM, Christophe Lyon wrote:
Hi,
...
I pushed a small aarch64 patch as obvious:
2020-08-31 Christophe Lyon
gcc/testsuite/
* gcc.target/aarch64/strcmpopt_
ILP32 failures in a test added for the new -Wstringop-overread
option exposed an unnecessarily restrictive handling of offsets
in ranges with an upper bound that's apparently less than
the lower bound. I have relaxed the handling of this case to
avoid these failures and improve the efficacy of bo
On 9/1/20 3:41 PM, Marek Polacek wrote:
On Tue, Sep 01, 2020 at 03:27:36PM -0400, Jason Merrill via Gcc-patches wrote:
On 9/1/20 12:10 PM, Marek Polacek wrote:
Currently, we allow new char[]{"foo"}, but not new char[4]{"foo"}.
We should accept the latter too: [dcl.init.list]p3.3 says to treat
t
On 26/08/20 17:48 +0100, Jonathan Wakely wrote:
This change evaluates __glibcxx_assert checks unconditionally when a
function is being constant evaluated (when std::is_constant_evaluated()
is true). If the check fails, compilation will fail with an error.
If the function isn't being constant eva
On Tue, Sep 01, 2020 at 03:27:36PM -0400, Jason Merrill via Gcc-patches wrote:
> On 9/1/20 12:10 PM, Marek Polacek wrote:
> > Currently, we allow new char[]{"foo"}, but not new char[4]{"foo"}.
> > We should accept the latter too: [dcl.init.list]p3.3 says to treat
> > this as [dcl.init.string].
> >
On 9/1/20 12:10 PM, Marek Polacek wrote:
Currently, we allow new char[]{"foo"}, but not new char[4]{"foo"}.
We should accept the latter too: [dcl.init.list]p3.3 says to treat
this as [dcl.init.string].
We were rejecting this code because we never called reshape_init before
the digest_init in bui
On 8/11/20 12:19 PM, Martin Sebor via Gcc-patches wrote:
-Wplacement-new handles array indices and pointer offsets the same:
by adjusting them by the size of the element. That's correct for
the latter but wrong for the former, causing false positives when
the element size is greater than one.
I
On 9/1/20 12:38 PM, Segher Boessenkool wrote:
>> This passed bootstrap and regtesting on powerpc64le-linux with no
>> regressions.
>> Raji has also done some runtime testing of her MMA tests using this patch
>> and they all showed no regressions either. Ok for trunk and GCC 10 after
>> a couple o
On 8/25/20 5:19 AM, Mark Wielaard wrote:
On Mon, 2020-08-24 at 17:38 -0400, Jason Merrill wrote:
This looks incorrect to me, that is a workaround for a real GCC bug.
Shouldn't we instead do something like (untested) following patch?
I mean, for DWARF < 5 the static data members were using DW_TA
Hi!
On Tue, Sep 01, 2020 at 12:00:50PM -0500, Peter Bergner wrote:
> When we expand our MMA built-ins into gimple, we (me!) erroneously reused
> the accumulator memory reference for both the source input value as well as
> the destination output value. This led to a tree sharing error.
> The solu
The chrono::duration constructor that converts from another duration
type is meant to be constrained so that it doesn't participate in
overload resolution if the ratio of the periods cannot be represented as
a std::ratio.
Because our std::ratio_divide is not SFINAE-friendly the evaluation of
__is_
When we expand our MMA built-ins into gimple, we (me!) erroneously reused
the accumulator memory reference for both the source input value as well as
the destination output value. This led to a tree sharing error.
The solution is to create separate memory references for the input
and output values
Hi!
On Mon, Aug 31, 2020 at 11:46:07AM +0800, Kewen.Lin wrote:
> This patch is to backport the fix for PR92923 and its sequent fix for
> PR93136 to GCC-9 branch. We found the builtin functions needlessly
> using VIEW_CONVERT_EXPRs on their operands can probably cause
> remarkable performance issu
BPF is an ELF-based target, so it definitely benefits from using
elfos.h. This patch makes the target to use it, and removes
superfluous definitions from bpf.h which are better defined in
elfos.h.
Note that BPF, despite being an ELF target, doesn't use DWARF. At
some point it will generate DWARF
Currently, we allow new char[]{"foo"}, but not new char[4]{"foo"}.
We should accept the latter too: [dcl.init.list]p3.3 says to treat
this as [dcl.init.string].
We were rejecting this code because we never called reshape_init before
the digest_init in build_new_1. reshape_init handles [dcl.init.s
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r11-2968-g49bfbf18c0bb9d83934f0ce765dc031ebfbda38e.
gcc/analyzer/ChangeLog:
PR analyzer/96792
* region-model.cc (region_model::deref_rvalue): Add the constraint
that PTR_SVAL is non-NULL.
gc
On Tue, 2020-09-01 at 13:47 +0200, Martin Liška wrote:
> Hello.
>
> There's a new version of the patch attempt. I mentioned couple of
> issues with the v1 here:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542821.html
>
> The patch addresses the biggest blocker which fact that the
> opt
>> >> gcc/
>> >> PR tree-optimization/94234
>> >> * tree-ssa-forwprop.c (simplify_binary_with_convert): New
>> >> function.
>> >> * (fwprop_ssa_val): Move it before its new caller.
>>
>> > No * at this line. There's an entry for (pass_forwprop::execute) missing.
>> OK.
>>
On 8/31/20 10:01 AM, Richard Biener wrote:
On Fri, Aug 28, 2020 at 4:18 PM Martin Liška wrote:
Hey.
The patch is about VEC_COND_EXP comparison of a SSA_NAME with a constant
that is artifact of -fno-tree-ccp.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be
> The patch is about usage of MiB in memory allocation reports.
> I see it much better readable than values displayed in KiB:
>
> Reading object files: tramp3d-v4.o {GC released 1 MiB} {GC 19 MiB -> 19 MiB}
> {GC 19 MiB} {heap 12 MiB}
> Reading the symbol table:
> Merging declarations: {GC relea
On Tue, Sep 01, 2020 at 04:09:53PM +0800, luoxhu wrote:
> On 2020/9/1 01:04, Segher Boessenkool wrote:
> > For v a V4SI, x a SI, j some int, what do we generate for
> >v[j&3] = x;
> > ?
> > This should be exactly the same as we generate for
> >vec_insert(x, v, j);
> > (the builtin does a m
And there's one more piece needed for -ftime-report:
Time variable usr sys wall
GGC
phase setup: 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 1%)
2 MiB ( 6%)
phase opt and generate : 0.25
[resending this 3rd patch since keep not seeing it on the list,
pardon if this gets duplicated]
This patch is the changes to libgomp and testcases.
There is now (again) a need to indicate OpenACC/OpenMP and
an 'enter data' style directive, so the associated changes to
'enum gomp_map_vars_kind'.
On 01/09/20 14:06 +0200, François Dumont wrote:
Hi
No chance to review this small patch ?
I did review it, and I wasn't convinced it was a good change. It only
helps a particular usage pattern, and might hurt in other cases.
I don't agree with your assertion that you use std::deque when you
Hi Jakub,
this patch set implements parts of the target mapping changes introduced
in OpenMP 5.0, mainly the attachment requirements for pointer-based
list items, and the clause ordering.
The first patch here are the C/C++ front-end changes.
The entire set of changes has been tested for without
These are the middle-end gimplifier and omp-low changes.
Compiler testcases are also included in this patch.
For attach/detach clauses, I'm currently using the clause tree expression
itself as the key for lookup, to solve the "same-decl" problem when
multiple clauses have the same OMP_CLAUSE_DECL
On Tue, Sep 1, 2020 at 10:11 AM luoxhu via Gcc-patches
wrote:
>
> Hi,
>
> On 2020/9/1 01:04, Segher Boessenkool wrote:
> > Hi!
> >
> > On Mon, Aug 31, 2020 at 04:06:47AM -0500, Xiong Hu Luo wrote:
> >> vec_insert accepts 3 arguments, arg0 is input vector, arg1 is the value
> >> to be insert, arg2
Previously, the SEH version of _Unwind_Backtrace did unwind
the stack and call the provided callback function as intended,
but there was little the caller could do within the callback to
actually get any info about that particular level in the unwind.
Set the ra pointer, which is used by _Unwind_G
This fixes compilation of codepaths for dos-like filesystems
with Clang. When built with clang, it treats C input files as C++
when the compiler driver is invoked in C++ mode, triggering errors
when the return value of strchr() on a pointer to const is assigned
to a pointer to non-const variable.
On Tue, Sep 1, 2020 at 1:26 PM Martin Liška wrote:
>
> On 8/27/20 10:54 AM, Richard Biener wrote:
> > On Wed, Aug 26, 2020 at 11:02 PM Jeff Law wrote:
> >>
> >> On Tue, 2020-08-11 at 13:37 +0200, Martin Liška wrote:
> >>> From cc1d41a469d76f2f8e4f44bed788ace77a1c6d62 Mon Sep 17 00:00:00 2001
> >
On 9/1/20 1:41 PM, Tobias Burnus wrote:
> Hi Tom, hello all,
>
> it turned out that the testcase fails on PowerPC (but not x86_64)
> as the nvptx lto complains: unresolved symbol
> __sync_val_compare_and_swap_16
>
> The testcase uses int128 – and that's the culprit, but I have no idea
> why it on
The patch is about usage of MiB in memory allocation reports.
I see it much better readable than values displayed in KiB:
Reading object files: tramp3d-v4.o {GC released 1 MiB} {GC 19 MiB -> 19 MiB}
{GC 19 MiB} {heap 12 MiB}
Reading the symbol table:
Merging declarations: {GC released 1 MiB mad
The last patch is a refactoring using ONE_* macros.
Thoughts?
Thanks,
Martin
>From 999a1969e7325efa0072d0ee893fcb6aa7178997 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Tue, 1 Sep 2020 14:24:20 +0200
Subject: [PATCH 3/3] Use more ONE_? in GGC functions.
gcc/ChangeLog:
* ggc-common.c (ggc
Hey.
I've just applied to patches to glibc introducing a new mallinfo2 function.
Limitation of the current function mallinfo is usage of int type which overflows
for allocation > 2GB.
The patch adds configure detection and usage of the new one. And it prints heap
usage
in MiB.
Ready to be inst
When I commit the small series of patches on _Hashtable I realize that I
miss a part on the one regarding reservation management on range
insertion. I've added a comment saying that we consider that all
initializer_list elements will be inserted.
For the moment it is true only for assignement
On Tue, Sep 01, 2020 at 01:52:21PM +0200, Richard Biener wrote:
> OK, I'll see to do that (or fixup the RTL expansion side somehow).
>
> Note that clang and gcc disagree about the return value ABI for
>
> typedef double v1df __attribute__((vector_size(8)));
>
> v1df foo (v1df x)
> {
> return x
Hi
No chance to review this small patch ?
François
On 30/06/20 10:33 pm, François Dumont wrote:
Hi
Any feedback regarding this patch ?
François
On 17/01/20 6:27 pm, François Dumont wrote:
On 1/17/20 11:01 AM, Jonathan Wakely wrote:
On 20/05/19 07:39 +0200, François Dumont wrote:
Hi
On Tue, 1 Sep 2020, Jakub Jelinek wrote:
> On Tue, Sep 01, 2020 at 11:50:32AM +0200, Richard Biener wrote:
> > While IMHO it makes very much sense to map V1{S,D,T}F types
> > to {S,D,T}Fmode if there's no special vector mode for it the
> > question is whether we can make this "change" for the sake
Hello.
There's a new version of the patch attempt. I mentioned couple of issues with
the v1 here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542821.html
The patch addresses the biggest blocker which fact that the optimization was
done unconditionally.
Now the transformation happens o
Hi,
On 2020/9/1 00:47, will schmidt wrote:
>> + tmode = TYPE_MODE (TREE_TYPE (arg0));
>> + mode1 = TYPE_MODE (TREE_TYPE (TREE_TYPE (arg0)));
>> + mode2 = TYPE_MODE ((TREE_TYPE (arg2)));
>> + gcc_assert (VECTOR_MODE_P (tmode));
>> +
>> + op0 = expand_expr (arg0, NULL_RTX, tmode, EXPAND_NORMAL)
Hi Tom, hello all,
it turned out that the testcase fails on PowerPC (but not x86_64)
as the nvptx lto complains: unresolved symbol __sync_val_compare_and_swap_16
The testcase uses int128 – and that's the culprit, but I have no idea
why it only fails with PowerPC and not with x86-64.
Unless some
On Tue, 1 Sep 2020, Jakub Jelinek via Gcc-patches wrote:
On Tue, Sep 01, 2020 at 11:50:32AM +0200, Richard Biener wrote:
While IMHO it makes very much sense to map V1{S,D,T}F types
to {S,D,T}Fmode if there's no special vector mode for it the
question is whether we can make this "change" for the
On 8/28/20 4:56 PM, Gerald Pfeifer wrote:
On Tue, 25 Aug 2020, Martin Liška wrote:
I noticed your continual effort to change http:// links to https://.
I've written a simple script that can do that in automatic way.
Thanks, Martin! My missions isn't actually changing http:// to https://
where
On 8/27/20 10:54 AM, Richard Biener wrote:
On Wed, Aug 26, 2020 at 11:02 PM Jeff Law wrote:
On Tue, 2020-08-11 at 13:37 +0200, Martin Liška wrote:
From cc1d41a469d76f2f8e4f44bed788ace77a1c6d62 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Mon, 10 Aug 2020 12:09:19 +0200
Subject: [PATCH
On Tue, Aug 25, 2020 at 8:47 PM Kewen.Lin wrote:
>
> Hi Bin,
>
> >>
> >> For one particular case like:
> >>
> >> for (i = 0; i < SIZE; i++)
> >> y[i] = a * x[i] + z[i];
> >>
> >> we will mark reg_offset_p for IV candidates on x as below:
> >>- (unsigned long) (x_18(D)
On Tue, Sep 01, 2020 at 11:50:32AM +0200, Richard Biener wrote:
> While IMHO it makes very much sense to map V1{S,D,T}F types
> to {S,D,T}Fmode if there's no special vector mode for it the
> question is whether we can make this "change" for the sake
> of the ABIs? The alternative is to make vector
On Tue, Sep 1, 2020 at 11:54 AM Feng Xue OS wrote:
>
>
> >> gcc/
> >> PR tree-optimization/94234
> >> * tree-ssa-forwprop.c (simplify_binary_with_convert): New function.
> >> * (fwprop_ssa_val): Move it before its new caller.
>
> > No * at this line. There's an entry for (
On Tue, 1 Sep 2020, Jakub Jelinek via Gcc-patches wrote:
As discussed in the PR, fold-const.c punts on floating point constant
evaluation if the result is inexact and -frounding-math is turned on.
/* Don't constant fold this floating point operation if the
result may dependent upon
On Tue, Sep 01, 2020 at 05:55:18PM +0800, Hongtao Liu wrote:
> I tried define_split, but there's too many of them(considering usage
> of define_subst for mask).
> Also for new added instructions which support embedded broadcast,
> corresponding define_split needs to be added.
One pass that could (
OG10 = devel/omp/gcc-10
* Merged GCC 10 into branch
PLUS:
commit a34d8b2eb7686ef8580f8f0d0c6bfccc8b953fdf
Fortran: Add 'device_type' clause to OpenMP's declare target
(cherry picked from commit d58e7173ef964ddac3ab3ad8cc97de8f9f3b32ee)
commit 4552dbc17494c9cc8185c789b8f17bf52617bf3e
On Thu, Aug 27, 2020 at 8:24 PM Jakub Jelinek wrote:
>
> On Thu, Jul 09, 2020 at 04:33:46PM +0800, Hongtao Liu via Gcc-patches wrote:
> > +static void
> > +replace_constant_pool_with_broadcast (rtx_insn* insn)
> > +{
> > + subrtx_ptr_iterator::array_type array;
> > + FOR_EACH_SUBRTX_PTR (iter, a
>> gcc/
>> PR tree-optimization/94234
>> * tree-ssa-forwprop.c (simplify_binary_with_convert): New function.
>> * (fwprop_ssa_val): Move it before its new caller.
> No * at this line. There's an entry for (pass_forwprop::execute) missing.
OK.
> I don't think the transfor
This maps single-element vectors to the component mode when the
single-element vector mode is not available. This is what happens
for integer element modes already via mapping to a same-sized
scalar mode (which also covers multi-element vectors).
This avoids ICEing when expanding bit-inserts of s
Hi,
On 2020/9/1 01:04, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Aug 31, 2020 at 04:06:47AM -0500, Xiong Hu Luo wrote:
>> vec_insert accepts 3 arguments, arg0 is input vector, arg1 is the value
>> to be insert, arg2 is the place to insert arg1 to arg0. This patch adds
>> __builtin_vec_insert_v
On Mon, 31 Aug 2020 at 23:50, Martin Sebor wrote:
>
> On 8/31/20 4:51 AM, Christophe Lyon wrote:
> > Hi,
> >
> ...
> >
> > I pushed a small aarch64 patch as obvious:
> > 2020-08-31 Christophe Lyon
> >
> > gcc/testsuite/
> > * gcc.target/aarch64/strcmpopt_6.c: Suppress -Ws
On Tue, Aug 4, 2020 at 2:18 PM Roger Sayle wrote:
>
>
> This middle-end patch teaches fold/match to recognize the idiom for
> a highpart multiplication and represent it internally as a
> MULT_HIGHPART_EXPR tree code. At RTL expansion time, the compiler
> will trying using an appropriate instructi
Hi!
As discussed in the PR, fold-const.c punts on floating point constant
evaluation if the result is inexact and -frounding-math is turned on.
/* Don't constant fold this floating point operation if the
result may dependent upon the run-time rounding mode and
flag_rounding
On Tue, Jun 30, 2020 at 12:38 AM Roger Sayle wrote:
>
>
> It turns out that the ICE diagnosed/fixed in my earlier nvptx patch, caused by
> TYPE_SIZE(type) being zero during error handling in gcc.dg/attr-vector_size.c
> is actually fairly common among backends, and is known in bugzilla as
> PR midd
On Wed, Aug 19, 2020 at 11:17 AM Feng Xue OS
wrote:
>
> As Richard's comment, this patch is composed to simplify generalized
> binary-with-convert pattern like ((T) X) OP ((T) Y). Instead of creating
> almost duplicated rules into match.pd, we try to transform it to (T) (X OP Y),
> and apply simpl
Hi!
The C++ macro performs a PARM_DECL_CHECK, so will ICE if not tested on a
PARM_DECL,
C_ARRAY_PARAMETER doesn't, but probably should, otherwise it is testing e.g.
C_DECL_VARIABLE_SIZE on VAR_DECLs.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk.
2020-0
On Thu, 27 Aug 2020, Richard Biener wrote:
> This carries over the PR87609 fix also to RTL loop unrolling. The
> gcc.dg/torture/pr90328.c testcase otherwise is miscompiled with
> the tree-ssa-address.c hunk (or alternatively with -fno-ivopts
> on master). I've tried to find the correct abstracti
76 matches
Mail list logo
