Hi Joshua, Jim:
> > +/* Implement TARGET_ASAN_SHADOW_OFFSET. */
> > +
> > +static unsigned HOST_WIDE_INT
> > +riscv_asan_shadow_offset (void)
> > +{
> > + return HOST_WIDE_INT_UC (0x1000);
> > +}
>
> Is there a reason why you used 0x1000?
>
> Looking at other targets, it appears the conv
Power10: Add BRH, BRW, BRD support.
The power10 processor adds 3 new instructions (BRH, BRW, BRD) that byte swaps
half-words, words, and double-words within a GPR register. This patch adds
support for these instructions. I have applied the suggestions from the
previous times I have submitted thi
On Tue, Aug 4, 2020 at 6:28 PM Kirill Yukhin wrote:
>
> On 04 авг 13:26, Kirill Yukhin wrote:
> > Could you please clarify, how your patch relared to [1]?
> > I see from the bug that it describes perf issue w.r.t. scalar
> > operations.
>
Sorry for Typo, it's pr96243.
https://gcc.gnu.org/bugzilla/
On Tue, Aug 04, 2020 at 03:53:50PM -0700, Mike Stump wrote:
> On Aug 4, 2020, at 3:16 PM, Marek Polacek via Gcc-patches
> wrote:
> >
> > The benefit of dg-accepts-invalid was that you would
> > get an XPASS even for a test that should not be accepted, but you didn't
> > know
> > what line to ex
On Tue, Aug 04, 2020 at 03:33:23PM -0700, Mike Stump wrote:
> I think the read of the room is that people think it would be generally
> useful, so let approve the general plan.
Cool.
> So, now we are down to the fine details. Please do see just how far you can
> stretch the existing mechanisms
On Thu, Jul 30, 2020 at 5:31 AM Joshua via Gcc-patches
wrote:
> +/* Implement TARGET_ASAN_SHADOW_OFFSET. */
> +
> +static unsigned HOST_WIDE_INT
> +riscv_asan_shadow_offset (void)
> +{
> + return HOST_WIDE_INT_UC (0x1000);
> +}
Is there a reason why you used 0x1000?
Looking at other ta
On 8/4/20 3:23 PM, Aldy Hernandez wrote:
On 8/4/20 9:34 PM, Martin Sebor wrote:
On 8/4/20 5:33 AM, Aldy Hernandez via Gcc-patches wrote:
This patch adapts the strlen pass to use the irange API.
I wasn't able to remove the one annoying use of VR_ANTI_RANGE, because
I'm not sure what to do. P
On Thu, Jul 30, 2020 at 6:28 AM Martin Liška wrote:
> What's the reason for sending the same patch multiple times
> from a different sender?
I see 3 in the gcc.gnu.org email archive, and I saw 3 on the NNTP feed
from gmane, but it seems only one of them ended up in my gmail inbox.
The other two a
On Tue, 4 Aug 2020, Patrick Palka wrote:
> In the testcase below, we never substitute function-template arguments
> into f15's placeholder-return-type constraint, which leads to us
> incorrectly rejecting this instantiation in do_auto_deduction due to
> satisfaction failure (of the constraint Same
On Aug 4, 2020, at 3:16 PM, Marek Polacek via Gcc-patches
wrote:
>
> The benefit of dg-accepts-invalid was that you would
> get an XPASS even for a test that should not be accepted, but you didn't know
> what line to expect an error on, so you put a dg-error at the end of the test.
I think for
On 8/4/20 2:20 PM, Roger Sayle wrote:
>
> This patch adds support for signed and unsigned, HImode, SImode and
> DImode highpart multiplications to the nvptx backend. Without the
> middle-end patch that I've just posted, the middle-end is able to
> (easily) make use of the narrow four of the six i
On Aug 4, 2020, at 3:08 PM, Marek Polacek via Gcc-patches
wrote:
>
> That works well if you know where to expect an error. But if you don't, it's
> worse. E.g.,
>
> // { dg-xfail-if "" { *-*-* } }
> int i = nothere; // demonstrates something that errors out
> // { dg-error "" } didn't know wh
On Thu, Jul 30, 2020 at 11:54:23AM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Jul 28, 2020 at 05:44:47PM -0400, Marek Polacek via Gcc-patches wrote:
> > We will still have a surfeit of bugs that we've given short shrift to, but
> > let's at least automate what we can. The initial additi
I think the read of the room is that people think it would be generally useful,
so let approve the general plan.
So, now we are down to the fine details. Please do see just how far you can
stretch the existing mechanisms to cover what you need to do. I think the
existing mechanisms should be
On Thu, Jul 30, 2020 at 11:08:03AM +0200, Martin Liška wrote:
> Hello.
>
> I support the initiative!
> What would be nice to add leading 'PR component/12345'
> to a git commit so that these test additions are linked to bugzilla issues.
Thanks! Yes, it should be clear which test tests a PR that h
On Wed, Jul 29, 2020 at 04:00:27PM -0600, Martin Sebor wrote:
> I've created a much more rudimentary setup for myself to deal
> with the same problem. I copy tests from Bugzilla, sometimes
> with tweaks, and compile them from time to time as I revisit
> unresolved bugs. I've also thought about ad
On Wed, Jul 29, 2020 at 04:37:03PM -0400, Jason Merrill wrote:
> On Tue, Jul 28, 2020 at 5:45 PM Marek Polacek via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
>
> > In Bugzilla, for the c++ component, we currently have over 3200 open
> > bugs. In
> > my experience, a good amount of them have
On Wed, Jul 29, 2020 at 09:40:35AM +0100, Richard Sandiford wrote:
> Thanks for doing this. +1 for the best fix being to add XFAILing tests
> to the main testsute, enabled by default. I don't see any other realistic
> way of ensuring that fixes are matched with PRs at the time that the fix
> is m
On 8/4/20 11:23 PM, Aldy Hernandez wrote:
On 8/4/20 9:34 PM, Martin Sebor wrote:
On 8/4/20 5:33 AM, Aldy Hernandez via Gcc-patches wrote:
This patch adapts the strlen pass to use the irange API.
I wasn't able to remove the one annoying use of VR_ANTI_RANGE, because
I'm not sure what to do
On Tue, Jul 28, 2020 at 09:02:17PM -0600, Jeff Law wrote:
> On Tue, 2020-07-28 at 17:44 -0400, Marek Polacek via Gcc-patches wrote:
> > In Bugzilla, for the c++ component, we currently have over 3200 open bugs.
> > In
> > my experience, a good amount of them have already been fixed; my periodical
Hi Mike,
thanks for your comments.
On Tue, Jul 28, 2020 at 06:37:26PM -0700, Mike Stump via Gcc-patches wrote:
> I'll punt to the the C++ front-end folks to chime in. Usually we only check
> in bugs that are fixed, as they are fixed, this is what makes it a regression
> suite. Doing this does
On 8/4/20 9:34 PM, Martin Sebor wrote:
On 8/4/20 5:33 AM, Aldy Hernandez via Gcc-patches wrote:
This patch adapts the strlen pass to use the irange API.
I wasn't able to remove the one annoying use of VR_ANTI_RANGE, because
I'm not sure what to do. Perhaps Martin can shed some light. The
c
On 8/4/20 5:33 AM, Aldy Hernandez via Gcc-patches wrote:
This patch adapts the strlen pass to use the irange API.
I wasn't able to remove the one annoying use of VR_ANTI_RANGE, because
I'm not sure what to do. Perhaps Martin can shed some light. The
current code has:
else if (rng == VR_ANT
In the testcase below, we never substitute function-template arguments
into f15's placeholder-return-type constraint, which leads to us
incorrectly rejecting this instantiation in do_auto_deduction due to
satisfaction failure (of the constraint SameAs).
The fact that we incorrectly reject this tes
Hello world,
the attached patch issues an error for something that I am sure most
people did at least once (I know I did), something like
do i=1,10
call foo
end do
...
contains
subroutine foo
do i=1,5
...
end do
which is, of course, illegal, but the programmer's fault. We
On 8/4/20 1:30 PM, Jason Merrill via Gcc-patches wrote:
On 8/4/20 10:05 AM, Marek Polacek wrote:
In r9-4235 I tried to make sure that the template keyword follows
a nested-name-specifier. :: is a valid nested-name-specifier, so
I also have to check 'globalscope' before giving the error.
Bootst
On Tue, 4 Aug 2020, Jason Merrill wrote:
> On 8/4/20 9:45 AM, Patrick Palka wrote:
> > On Mon, 3 Aug 2020, Patrick Palka wrote:
> >
> > > On Mon, 3 Aug 2020, Jason Merrill wrote:
> > >
> > > > On 8/3/20 2:45 PM, Patrick Palka wrote:
> > > > > On Mon, 3 Aug 2020, Jason Merrill wrote:
> > > > >
>
On Tue, Aug 4, 2020 at 12:35 AM Richard Biener wrote:
>
> On Mon, 3 Aug 2020, Qing Zhao wrote:
>
> > Hi, Uros,
> >
> > Thanks a lot for your review on X86 parts.
> >
> > Hi, Richard,
> >
> > Could you please take a look at the middle-end part to see whether the
> > rewritten addressed your previou
On Tue, Aug 04, 2020 at 01:46:49AM -0400, Michael Meissner wrote:
> The following 6 patches backport the tests on the master branch that were
> added
> to test the new prefixed instructions being added to the Power10 processor.
> These patches include changes made by David Edelsohn to make the pat
On 8/4/20 10:05 AM, Marek Polacek wrote:
In r9-4235 I tried to make sure that the template keyword follows
a nested-name-specifier. :: is a valid nested-name-specifier, so
I also have to check 'globalscope' before giving the error.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/10/
On 8/4/20 9:45 AM, Patrick Palka wrote:
On Mon, 3 Aug 2020, Patrick Palka wrote:
On Mon, 3 Aug 2020, Jason Merrill wrote:
On 8/3/20 2:45 PM, Patrick Palka wrote:
On Mon, 3 Aug 2020, Jason Merrill wrote:
On 8/3/20 8:53 AM, Patrick Palka wrote:
On Mon, 3 Aug 2020, Patrick Palka wrote:
In
On Sun, Aug 2, 2020 at 1:00 PM Rainer Orth
wrote:
>
> Hi Ian,
>
> > This libgo patch updates the sources to the go1.15rc1 release
> > candidate. As usual, the changes for this update are too large to
> > include in an e-mail message. I've just included the highlights and
> > changes to GCC-spec
This is just an obvious code cleanup; the relocation defines have been
unused since the move to HSACOv3. They were just left in by mistake.
Andrew
amdgcn: Remove dead defines from gcn-run
Nothing uses these since the switch to HSACOv3.
gcc/ChangeLog:
* config/gcn/gcn-run.c (R_AMDGPU_NONE): D
On Fri, 31 Jul 2020, Richard Biener wrote:
This adds a ! marker to result expressions that should simplify
(and if not fail the simplification). This can for example be
used like
(simplify
(plus (vec_cond:s @0 @1 @2) @3)
(vec_cond @0 (plus! @1 @3) (plus! @2 @3)))
to make the simplification
Hi Omar,
Ok, thanks.
I've pushed this to master.
Kyrill
From: Omar Tahir
Sent: 04 August 2020 17:10
To: Kyrylo Tkachov ; ni...@redhat.com; Ramana
Radhakrishnan ; Richard Earnshaw
; gcc-patches@gcc.gnu.org
Subject: [PATCH 1/5][Arm] Modify default tuning of armv8.1-m.main to use
Cortex-M55
Pre
Hu Jiangping writes:
> Hi,
>
> This patch deletes 2 unnecessary codes in function
> aarch64_if_then_else_costs, which were duplicated
> where the function starts.
Thanks, pushed to trunk.
Richard
>
> Tested on aarch64. OK for trunk?
>
> Regards!
> Hujp
>
> ---
> gcc/config/aarch64/aarch64.c |
I noticed that we could leak parser->num_template_parameter_lists with
erroneous specializations. We'd increment, notice a problem and then
bail out. This refactors cp_parser_explicit_specialization to avoid
that code path. A couple of tests get different diagnostics because of
the fix. pr3
xiezhiheng writes:
>> > Sorry, I should have used it. And I prepare a patch to use FLOAT_MODE_P
>> > macro and add a flag FLAG_SUPPRESS_FP_EXCEPTIONS to suppress
>> > FLAG_RAISE_FP_EXCEPTIONS for certain intrinsics in future.
>>
>> The same thing is true for reading FPCR as well, so I think the
This patch adds a new pattern, *cmovsi_insn, for generating CSEL, CSET and
CSETM instructions. It also generates CSINV and CSINC instructions in specific
cases where one of the operands is constant.
To facilitate this, one new predicate and two new constraints are added, and
*compare_scc is restri
This patch adds a new pattern, *thumb2_csneg, for generating CSNEG
instructions. It also restricts *if_neg_move and *thumb2_negscc to only match
if !TARGET_COND_ARITH which prevents undesirable matches during ifcvt.
Regression tested on arm-none-eabi.
2020-07-30: Sudakshina Das
Omar
On Tue, Aug 04, 2020 at 05:54:18PM +0200, Tobias Burnus wrote:
> I am not sure whether the following code is supposed
> to work but the "x = 5" is never converted into
> tree-code in gfc_trans_omp_do – hence, it makes sense
> to error out. (I have the feeling that this needs to
> be revisited for O
This patch adds a new pattern, *thumb2_csinc, for generating CSINC
instructions. It also modifies an existing pattern, *thumb2_cond_arith, to
output CINC when the operation is an addition and TARGET_COND_ARITH is true.
Regression tested on arm-none-eabi.
2020-07-30: Sudakshina Das
O
This patch adds a new pattern, *thumb2_csinv, for generating CSINV nstructions.
This pattern relies on a few general changes that will be used throughout
the following patches:
- A new macro, TARGET_COND_ARITH, which is only true on 8.1-M
Mainline
and represents
Previously, compiling with -march=armv8.1-m.main would tune for Cortex-M7.
However, the Cortex-M7 only supports up to Armv7e-M. The Cortex-M55 is the
earliest CPU that supports Armv8.1-M Mainline so is more appropriate. This
also has the effect of changing the branch cost function used, which will
Hi all,
This patch series provides support for the following instructions that were
added in Armv8.1-M Mainline [1]:
- CSEL
- CSET
- CSETM
- CSNEG
- CSINV
- CSINC
- CINC
The patch serie
I am not sure whether the following code is supposed
to work but the "x = 5" is never converted into
tree-code in gfc_trans_omp_do – hence, it makes sense
to error out. (I have the feeling that this needs to
be revisited for OpenMP 5.x.)
(The equivalent C/C++ code is rejected, see PR.)
!$omp
Kirill Yukhin 于2020年8月4日周二 下午10:47写道：
>
> Hello,
>
> On 06 июл 09:58, Hongyu Wang via Gcc-patches wrote:
> > Hi:
> >
> > This patch is about to support Intel Advanced Matrix Extensions (AMX)
> > which will be enabled in GLC.
> >
> > AMX is a new 64-bit programming paradigm consisting of two
> > co
On Mon, 3 Aug 2020, Richard Biener wrote:
On Sat, Aug 1, 2020 at 9:29 AM Marc Glisse wrote:
Hello,
this transformation is quite straightforward, without overflow, 3*X==15 is
the same as X==5 and 3*X==5 cannot happen. Adding a single_use restriction
for the first case didn't seem necessary, a
Hi,
This patch adds code generation for generating a temporary for, and
pre-filling struct and array literals with zeroes before assigning, so
that alignment holes don't cause objects to produce a non-deterministic
hash value. A new field has been added to the expression visitor to
track whether
On 8/4/20 2:46 AM, Jakub Jelinek wrote:
Hi!
When looking at the symver attr documentation in html, I found there is no
name to refer to for it.
The following patch fixes that, bootstrapped on x86_64-linux, ok for trunk
and 10.3?
2020-08-04 Jakub Jelinek
* doc/extend.texi (symver): A
This patch implements scalar TImode shifts using hardware DImode shifts.
The middle-end cannot synthesize these because BITS_PER_WORD is 32, on
this architecture, meaning it would try to use SImode shifts, and only
double-word shifts are implemented.
This fixes a large number of test failures
Hello
I posted a revised patchset about two weeks ago at:
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550291.html
Are you able to take a look at it?
Thanks
Kwok
On binaries compiled against gcc5 the impl_type parameter is None,
which results in an exception being raised by is_specialization_of()
These versions of std::unique_ptr have the tuple as a root element.
---
Hi,
I ran into this issue when debugging a binary built using gcc5.
I'm not very famili
Hello,
On 06 июл 09:58, Hongyu Wang via Gcc-patches wrote:
> Hi:
>
> This patch is about to support Intel Advanced Matrix Extensions (AMX)
> which will be enabled in GLC.
>
> AMX is a new 64-bit programming paradigm consisting of two
> compo nents: a set of 2-dimensional registers (tiles) repres
On 8/4/20 8:11 AM, Aldy Hernandez wrote:
On Tue, Aug 4, 2020 at 3:59 PM Martin Sebor wrote:
On 8/4/20 5:21 AM, Aldy Hernandez via Gcc-patches wrote:
This is a rather obvious patch, but I'd like a nod before committing.
Martin, I've removed your anti-range check, as it is subsumed by the
lowe
Hi all,
I'd like to submit the following patch to fix PR96375 ([11 regression]
arm/lob[2-5].c fail on some configurations).
It fix the observed regression making sure -mthumb is always used and
allowing Low Overhead Loop tests to be executed only on cortex-M profile
targets.
Does not introduce r
On Tue, Aug 4, 2020 at 3:27 PM Richard Biener
wrote:
>
> On Tue, Aug 4, 2020 at 2:05 PM Aldy Hernandez via Gcc-patches
> wrote:
> >
> > I've abstracted out the parts of the code that had nothing to do with
> > value_range_equiv into an externally visible range_of_var_in_loop().
> > This way, it c
On Tue, Aug 4, 2020 at 3:59 PM Martin Sebor wrote:
>
> On 8/4/20 5:21 AM, Aldy Hernandez via Gcc-patches wrote:
> > This is a rather obvious patch, but I'd like a nod before committing.
> >
> > Martin, I've removed your anti-range check, as it is subsumed by the
> > lower_bound/upper_bound code.
In r9-4235 I tried to make sure that the template keyword follows
a nested-name-specifier. :: is a valid nested-name-specifier, so
I also have to check 'globalscope' before giving the error.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/10/9?
gcc/cp/ChangeLog:
PR c++/96082
On 8/4/20 5:21 AM, Aldy Hernandez via Gcc-patches wrote:
This is a rather obvious patch, but I'd like a nod before committing.
Martin, I've removed your anti-range check, as it is subsumed by the
lower_bound/upper_bound code. However, you will have to adapt the code
for multi-ranges if desired.
On Mon, 3 Aug 2020, Patrick Palka wrote:
> On Mon, 3 Aug 2020, Jason Merrill wrote:
>
> > On 8/3/20 2:45 PM, Patrick Palka wrote:
> > > On Mon, 3 Aug 2020, Jason Merrill wrote:
> > >
> > > > On 8/3/20 8:53 AM, Patrick Palka wrote:
> > > > > On Mon, 3 Aug 2020, Patrick Palka wrote:
> > > > >
> >
This adds a stopgap measure to avoid performing code-hoisting
on mixed type loads when the load we'd insert in the hoisting
position would be a floating point one. This is because certain
targets (hello x87) cannot perform floating point loads without
possibly altering the bit representation and t
On Tue, Aug 4, 2020 at 2:05 PM Aldy Hernandez via Gcc-patches
wrote:
>
> I've abstracted out the parts of the code that had nothing to do with
> value_range_equiv into an externally visible range_of_var_in_loop().
> This way, it can be called with any range.
>
> adjust_range_with_scev still works
Andrea Corallo writes:
> Hi Kyrill,
>
> thanks for catching that.
>
> The attached is committed into master as d2b86e14c14.
>
> Andrea
And backported in releases/gcc-10 as e5907f3b631.
Andrea
On Tue, Aug 04, 2020 at 02:26:45PM +0200, Tobias Burnus wrote:
> Follow-up to my 'lastprivate(conditional:' patch for
> a left-over problem which I kind mostly missed.
> Checking the dump also shows that it now works
> as expected.
>
> OK?
Ok, thanks.
Note, we'll need to remove the warning when w
Follow-up to my 'lastprivate(conditional:' patch for
a left-over problem which I kind mostly missed.
Checking the dump also shows that it now works
as expected.
OK?
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB
This patch adds support for signed and unsigned, HImode, SImode and
DImode highpart multiplications to the nvptx backend. Without the
middle-end patch that I've just posted, the middle-end is able to
(easily) make use of the narrow four of the six instructions, but
with that patch, all six of the
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 instruction (sequence) provided
by the backend, but if that fails, this
PING^3
Hongyu Wang 于2020年7月24日周五 下午1:41写道：
>
> PING^2
>
> Hongyu Wang 于2020年7月17日周五 下午1:40写道：
> >
> > Update for SAPPHIRERAPIDS and PING
> >
> > Hongyu Wang 于2020年7月7日周二 上午11:24写道：
> >
> > >
> > > Hi Kirill, could you help review this patch?
> > >
> > > Hongyu Wang 于2020年7月6日周一 上午9:58写道：
> > >
I've abstracted out the parts of the code that had nothing to do with
value_range_equiv into an externally visible range_of_var_in_loop().
This way, it can be called with any range.
adjust_range_with_scev still works as before, intersecting with a
known range. Due to the way value_range_equiv::in
This is in line with the statement context that we have for get_value()
in the substitute_and_fold_engine class.
---
gcc/vr-values.c | 64 ++---
gcc/vr-values.h | 14 +--
2 files changed, 41 insertions(+), 37 deletions(-)
diff --git a/gcc/vr-val
The goal here is to disassociate adjust_range_from_scev from vr_values,
and value_range_equiv while we're at it.
We've already done something similar with simplify_using_ranges, where we
take in a "store" which is a class providing get_value_range(). Initially
we set it up to take a vr_values, bu
This patch removes all uses of VR_ANTI_RANGE in DOM. It required
minor surgery in the switch handling code.
In doing so, I was able to abstract all the code handling the cases
with ranges into its own function. Interestingly, there is an exact
copy of this function in VRP, so I was able to use t
This patch adapts the strlen pass to use the irange API.
I wasn't able to remove the one annoying use of VR_ANTI_RANGE, because
I'm not sure what to do. Perhaps Martin can shed some light. The
current code has:
else if (rng == VR_ANTI_RANGE)
{
wide_int maxobjsize = wi::to_wi
This is a rather obvious patch, but I'd like a nod before committing.
Martin, I've removed your anti-range check, as it is subsumed by the
lower_bound/upper_bound code. However, you will have to adapt the code
for multi-ranges if desired. For example, you may want to loop through the
sub-ranges
Hi Richard
> -Original Message-
> From: Richard Sandiford
> Sent: 31 July 2020 16:14
> To: Sudakshina Das
> Cc: gcc-patches@gcc.gnu.org; Kyrylo Tkachov
> Subject: Re: [PATCH V2] aarch64: Use Q-reg loads/stores in movmem
> expansion
>
> Sudakshina Das writes:
> > Hi
> >
> > This is my
On 04 авг 13:26, Kirill Yukhin wrote:
> Could you please clarify, how your patch relared to [1]?
> I see from the bug that it describes perf issue w.r.t. scalar
> operations.
[1] - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96226
>
> --
> Regards, Kirill Yukhin
Hello,
On 20 июл 13:46, Hongtao Liu wrote:
> Hi:
> For rtx like (eq:HI (V8SI 90) (V8SI 91)), cse will take it as a
> boolean value and try to do some optimization. But it is not true for
> vector compare, also other places in rtl passes hold the same
> assumption.
>
> Bootstrap is ok, regressio
Kyrylo Tkachov writes:
> I just remembered a recurring bit of review feedback from Ramana on my
> patches...
> New effective target checks need to be documented in doc/sourcebuild.texi.
>
> Ok with the documentation.
> Thanks,
> Kyrill
Hi Kyrill,
thanks for catching that.
The attached is comm
Hi,
With the pr96628-part1.f90 source and -ftree-slp-vectorize, we run into an
ICE due to the fact that V2DI mode is not handled in nvptx_gen_shuffle.
Fix this by adding handling of V2DI as well as V2SI mode in
nvptx_gen_shuffle.
Build and reg-tested on x86_64 with nvptx accelerator.
Committed
On 8/4/20 8:58 AM, Richard Biener wrote:
On Tue, Aug 4, 2020 at 8:40 AM Aldy Hernandez via Gcc-patches
wrote:
gcc/ChangeLog:
* vr-values.c (test_for_singularity): Use irange API.
(simplify_using_ranges::simplify_cond_using_ranges_1): Do not
special case VR_RANGE.
On 8/4/20 8:55 AM, Richard Biener wrote:
On Tue, Aug 4, 2020 at 8:39 AM Aldy Hernandez via Gcc-patches
wrote:
It seems to me that we should also check for [0,0] and [1,1] in the
range, but I am leaving things as is to avoid functional changes.
gcc/ChangeLog:
* vr-values.c (simpli
Hi Richard
Thanks for your help.
> Would you like the patch to be backported further than GCC 10?
> Does the attached patch to document the addition to GCC 10.3 look OK?
I will reply to you after the internal discussion.
Regards,
Qian
Richard Sandiford writes:
>Qian Jianhua writes:
>> This pa
On 8/4/20 8:55 AM, Richard Biener wrote:
On Tue, Aug 4, 2020 at 8:40 AM Aldy Hernandez via Gcc-patches
wrote:
VR_RANGE of [-INF,+INF] is canonicalized to VARYING at creation.
That is why the test now becomes varying_p().
gcc/ChangeLog:
* vr-values.c (simplify_using_ranges::vrp_eva
On 8/4/20 8:52 AM, Richard Biener wrote:
On Tue, Aug 4, 2020 at 8:37 AM Aldy Hernandez via Gcc-patches
wrote:
gcc/ChangeLog:
* fold-const.c (expr_not_equal_to): Adjust for irange API.
---
gcc/fold-const.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
On Tue, 4 Aug 2020, Jakub Jelinek wrote:
> Hi!
>
> .VEC_CONVERT is a const internal call, so normally if the lhs is not used,
> we'd DCE it far before getting to veclower, but with -O0 (or perhaps
> -fno-tree-dce and some other -fno-* options) it can happen.
> But as the internal fn needs the lhs
On Tue, 4 Aug 2020, Jakub Jelinek wrote:
> Hi!
>
> In debug stmts, we are less strict about what is and what is not accepted
> there, so this patch just punts on optimization of a debug stmt rather than
> ICEing.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
Rich
Hi!
This patch computes number of loop iterations for (so far signed only)
non-rectangular loops where only a single loop in the nest depends on an
outer loop iterator.
Bootstrapped/regtested on x86_64-linux, committed to trunk.
2020-08-04 Jakub Jelinek
* omp-expand.c (expand_omp_for
Hi,
This patch deletes 2 unnecessary codes in function
aarch64_if_then_else_costs, which were duplicated
where the function starts.
Tested on aarch64. OK for trunk?
Regards!
Hujp
---
gcc/config/aarch64/aarch64.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/gcc/config/aarch64/aarch64.c
Jakub Jelinek via Gcc-patches writes:
> Hi!
>
> .VEC_CONVERT is a const internal call, so normally if the lhs is not used,
> we'd DCE it far before getting to veclower, but with -O0 (or perhaps
> -fno-tree-dce and some other -fno-* options) it can happen.
> But as the internal fn needs the lhs to
Hi!
When looking at the symver attr documentation in html, I found there is no
name to refer to for it.
The following patch fixes that, bootstrapped on x86_64-linux, ok for trunk
and 10.3?
2020-08-04 Jakub Jelinek
* doc/extend.texi (symver): Add @cindex for symver function attribute.
Hi!
.VEC_CONVERT is a const internal call, so normally if the lhs is not used,
we'd DCE it far before getting to veclower, but with -O0 (or perhaps
-fno-tree-dce and some other -fno-* options) it can happen.
But as the internal fn needs the lhs to know the type to which the
conversion is done (and
Hi!
In debug stmts, we are less strict about what is and what is not accepted
there, so this patch just punts on optimization of a debug stmt rather than
ICEing.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2020-08-04 Jakub Jelinek
PR debug/96354
* gim
Hi Matthew,
> -Original Message-
> From: Matthew Malcomson
> Sent: 24 July 2020 17:03
> To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Ross Burton
> ; Richard Sandiford
> Subject: Re: SLS Mitigation patches backported for GCC9
>
> On 24/07/2020 12:01, Kyrylo Tkach
Hi Andrea,
> -Original Message-
> From: Andrea Corallo
> Sent: 04 August 2020 09:28
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Earnshaw
> ; Richard Sandiford
>
> Subject: Re: [PATCH] Aarch64: Add missing clobber for fjcvtzs
>
> Hi all,
>
> looking into the regression
Hi all,
looking into the regression I realized I've got the condition into the
effective target test wrong (== vs !=). Apologies for the noise.
Bootstrapped on aarch64-none-linux-gnu and regresssioned on
aarch64-none-elf.
Still okay for trunk and to backport on gcc-10?
Thanks
Andrea
gcc/Ch
Hi,
This patch detects the pattern for pointer substraction in the front-end
AST and uses EXACT_DIV_EXPR rather than TRUNC_DIV_EXPR.
Bootstrapped and regression tested on x86_64-linux-gnu with multilib
configurations -m32/-mx32. Committed to mainline.
Regards
Iain
---
gcc/d/ChangeLog:
ping ^2
On Mon, Jul 27, 2020 at 5:31 PM Hongtao Liu wrote:
>
> ping
>
> On Wed, Jul 22, 2020 at 3:57 PM Hongtao Liu wrote:
> >
> > Bootstrap is ok, regression test is ok for i386 backend.
> >
> > gcc/
> > PR target/96262
> > * config/i386/i386-expand.c
> > (ix86_expand_
ping ^2
On Mon, Jul 27, 2020 at 5:31 PM Hongtao Liu wrote:
>
> ping
>
> On Wed, Jul 22, 2020 at 12:59 PM Hongtao Liu wrote:
> >
> > Those two define_insns have same pattern, and
> > _load_mask would always be matched since it show up
> > earlier in the md file, and it may lose some opportunity
ping^2
On Mon, Jul 27, 2020 at 5:31 PM Hongtao Liu wrote:
>
> ping
>
> On Mon, Jul 20, 2020 at 4:40 PM Hongtao Liu wrote:
> >
> > Correct PR number in ChangeLog
> > it's pr96243.
> >
> > On Mon, Jul 20, 2020 at 1:46 PM Hongtao Liu wrote:
> > >
> > > Hi:
> > > For rtx like (eq:HI (V8SI 90) (V8
1 - 100 of 103 matches
Mail list logo
