Hi,
V4: Update define_expand names as optab name changes.
V3: Update the define_expand as optab changes.
BR,
Kewen
-
gcc/ChangeLog:
2020-MM-DD Kewen Lin
* config/rs6000/vsx.md (len_load_): New define_expand.
(len_store_): Likewise.
diff --git
Hi Richard,
Thanks for your comments!
on 2020/6/23 上午3:59, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> @@ -5167,6 +5167,24 @@ mode @var{n}.
>>
>> This pattern is not allowed to @code{FAIL}.
>>
>> +@cindex @code{lenload@var{m}} instruction pattern
>> +@item @samp{lenload@var{m}}
>>
On 6/22/20 10:01 PM, Marek Polacek wrote:
On Mon, Jun 22, 2020 at 09:42:51PM -0400, Nicholas Krause via Gcc-patches wrote:
From: Nicholas Krause
This fixs the PR95672 by adding the missing TYPE_PACK_EXPANSION case in
cxx_incomplete_type_diagnostic in order to avoid ICES on diagnosing
convert_like issues errors about bad_p conversions at the beginning
of the function, but in the ck_ref_bind case, it only issues them
after we've called convert_like on the next conversion.
This doesn't work as expected since r10-7096 because when we see
a conversion from/to class type in a
On Mon, Jun 22, 2020 at 09:42:51PM -0400, Nicholas Krause via Gcc-patches wrote:
> From: Nicholas Krause
>
> This fixs the PR95672 by adding the missing TYPE_PACK_EXPANSION case in
> cxx_incomplete_type_diagnostic in order to avoid ICES on diagnosing
> incomplete template pack expansion cases.
From: Nicholas Krause
This fixs the PR95672 by adding the missing TYPE_PACK_EXPANSION case in
cxx_incomplete_type_diagnostic in order to avoid ICES on diagnosing
incomplete template pack expansion cases. In v2, add the missing required
test case for all new patches. v3 Fixes both the test case
On 6/22/20 7:47 PM, Marek Polacek wrote:
On Mon, Jun 22, 2020 at 06:55:01PM -0400, Nicholas Krause via Gcc-patches wrote:
On 6/22/20 5:51 PM, Jason Merrill wrote:
On 6/22/20 4:01 PM, Nicholas Krause wrote:
From: Nicholas Krause
This fixs the PR95672 by adding the missing
On Mon, Jun 22, 2020 at 06:55:01PM -0400, Nicholas Krause via Gcc-patches wrote:
>
>
> On 6/22/20 5:51 PM, Jason Merrill wrote:
> > On 6/22/20 4:01 PM, Nicholas Krause wrote:
> > > From: Nicholas Krause
> > >
> > > This fixs the PR95672 by adding the missing TYPE_PACK_EXPANSION case in
> > >
Hi!
On Sat, Jun 20, 2020 at 05:25:23PM +0100, Roger Sayle wrote:
> It's great to hear from you again. It's been a while.
And from you! Yes, wow, it is 2020 now, how did that happen!
> >On Fri, Jun 19, 2020 at 09:42:54PM +0100, Roger Sayle wrote:
> >> My recent patch to add scalar integer
On 6/22/20 5:51 PM, Jason Merrill wrote:
On 6/22/20 4:01 PM, Nicholas Krause wrote:
From: Nicholas Krause
This fixs the PR95672 by adding the missing TYPE_PACK_EXPANSION case in
cxx_incomplete_type_diagnostic in order to avoid ICES on diagnosing
incomplete template pack expansion cases. In
On 6/22/20 12:55 PM, Jason Merrill wrote:
On 6/22/20 1:25 PM, Martin Sebor wrote:
The attached fix parallels the one for the equivalent C bug 95580
where the pretty printers don't correctly handle MEM_REF arguments
with type void* or other pointers to an incomplete type.
The incorrect handling
Hi!
On Mon, Jun 22, 2020 at 08:59:48PM +0100, Richard Sandiford wrote:
> "Kewen.Lin" writes:
> > @@ -5167,6 +5167,24 @@ mode @var{n}.
> >
> > This pattern is not allowed to @code{FAIL}.
> >
> > +@cindex @code{lenload@var{m}} instruction pattern
> > +@item @samp{lenload@var{m}}
> > +Perform
On 6/22/20 4:01 PM, Nicholas Krause wrote:
From: Nicholas Krause
This fixs the PR95672 by adding the missing TYPE_PACK_EXPANSION case in
cxx_incomplete_type_diagnostic in order to avoid ICES on diagnosing
incomplete template pack expansion cases. In v2, add the missing required
test case for
Hi folks,
On 5/26/20 8:15 PM, Gerald Pfeifer wrote:
Okay to backport c00568f376078129196740d83946d54dc5437401 to the GCC 9
branch, Jakub?
I don't see it yet on 9, so if 9 is still open for pushes I'd like too to
see that commit applied to 9 (it should apply cleanly). For the records,
the
On Sat, 20 Jun 2020, Hans-Peter Nilsson wrote:
> Hi! Good to see you "back"!
>
> On Sat, 20 Jun 2020, Roger Sayle wrote:
> > Thanks to you too. Alas, my credentials from the CVS days of GCC almost
> > certainly don't
> > work any more (in git),
>
> My guess is that your credentials are fine
From: Nicholas Krause
This fixs the PR95672 by adding the missing TYPE_PACK_EXPANSION case in
cxx_incomplete_type_diagnostic in order to avoid ICES on diagnosing
incomplete template pack expansion cases. In v2, add the missing required
test case for all new patches. v3 Fixes both the test case
"Kewen.Lin" writes:
> @@ -5167,6 +5167,24 @@ mode @var{n}.
>
> This pattern is not allowed to @code{FAIL}.
>
> +@cindex @code{lenload@var{m}} instruction pattern
> +@item @samp{lenload@var{m}}
> +Perform a vector load with length from memory operand 1 of mode @var{m}
> +into register operand
Hi Roger,
Thanks for the update and sorry for the slow reply.
"Roger Sayle" writes:
> As suggested by Richard Sandiford, this patch splits out the
> previous RTL simplification, of (X)^(Y) to (X^Y), to its
> own function, simplify_distributive_operation, and calls it when
> appropriate for IOR,
Gerald Pfeifer writes:
> On Thu, 18 Jun 2020, Sebastian Huber wrote:
>> b952c2cfcd74c284970e1b9bf1fca58f5f69ab23 on 10th of June. I build GCC
>> roughly once per week.
>
> I have daily builds running on i386-unknown-freebsd11.3 (since this is
> the flavor most likely to trigger issues) and the
David Edelsohn writes:
> On Sun, Mar 29, 2020 at 6:44 AM Richard Sandiford
> wrote:
>> Well, this is all about what (symbol_ref NAME) means for a TLS symbol
>> (with NAME always assumed to be TLS below). For all GCC ports it means
>> the actual address of NAME for the current thread. AIUI that
On 6/21/20 3:00 PM, Nicholas Krause wrote:
From: Nicholas Krause
This fixs the PR95672 by adding the missing TYPE_PACK_EXPANSION case in
cxx_incomplete_type_diagnostic in order to avoid ICES on diagnosing
incomplete template pack expansion cases. In v2, add the missing required
test case for
On 6/22/20 1:25 PM, Martin Sebor wrote:
The attached fix parallels the one for the equivalent C bug 95580
where the pretty printers don't correctly handle MEM_REF arguments
with type void* or other pointers to an incomplete type.
The incorrect handling was exposed by the recent change to
On Sun, Mar 29, 2020 at 6:44 AM Richard Sandiford
wrote:
>
> David Edelsohn writes:
> > On Sat, Mar 28, 2020 at 6:42 AM Richard Sandiford
> > wrote:
> >>
> >> David Edelsohn via Gcc-patches writes:
> >> > This patch is for an AIX problem, but the only robust solution is in
> >> > common code:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547415.html
Jason already approved the C++ changes (with a couple of minor
tweaks). I'm still looking for an approval of the corresponding
middle end diff.
On 6/5/20 1:41 PM, Martin Sebor wrote:
The caret location C++ -Wnonnull
The attached fix parallels the one for the equivalent C bug 95580
where the pretty printers don't correctly handle MEM_REF arguments
with type void* or other pointers to an incomplete type.
The incorrect handling was exposed by the recent change to
-Wuninitialized which includes such expressions
Hello,
In GCC testsuite the MVE scalar shift execution tests
(mve_scalar_shifts[1-4].c) are failings
because of executing them on target hardware which doesn't support MVE
instructions. This patch
restricts those tests to execute only on target hardware that support MVE
instructions.
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 18 June 2020 14:29
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC] arm: Fix the failing mve scalar shift execution tests.
>
> Hello,
>
> In GCC testsuite the MVE scalar shift execution tests
>
On Jun 22, 2020, Tobias Burnus wrote:
> On 6/22/20 8:08 AM, Alexandre Oliva wrote:
>>> I additionally did run the test case manually → files.log for the
>>> produced files.
>> This is with -save-temps, right?
> Yes. Without, there are no files left under /tmp and only
>
As mentioned in the parent email, this patch adds diagnostics for
probably-broken code that updates (host/device) or copies-out blocks
that still have attached pointers. Several new tests have been added.
OK?
Julian
ChangeLog
libgomp/
* oacc-mem.c (update_dev_host): Raise
Investigating PR95590, I realised that we can do better at diagnosing
some potentially troublesome usage of OpenACC "attach" behaviour, namely
updating blocks with attached pointers. Updating either the host copy
or device copy of such a block is problematic -- for a host update,
the host may get
As mentioned in the parent email, this is a fix for PR95590 that detects
updates of attached pointers in blocks, and rewrites the attached pointer
and resets its attachment counter appropriately. I am however not entirely
sure this is desirable or required by the spec: points against are:
- To
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
Richard.
p
Description: Binary data
This patch ensures that programs using vector extensions to pass vectors
to functions pass the vectors in memory.
Even though we could technically do this in registers, the ABI would
have to be reworked to do so, and there's no call for that yet (maybe if
we want vector libgcc/libm).
This
On Sun, Jun 21, 2020 at 2:32 AM Yichao Yu via Gcc-patches
wrote:
>
> On Sat, Jun 20, 2020 at 8:16 PM Yichao Yu wrote:
> >
> > On Sat, Jun 20, 2020 at 3:41 PM Yichao Yu wrote:
> > >
> > > On Sat, Jun 20, 2020 at 3:26 PM Yichao Yu wrote:
> > > >
> > > > On Sat, Jun 20, 2020 at 3:25 PM H.J. Lu
On Sun, Jun 21, 2020 at 1:06 AM H.J. Lu via Gcc-patches
wrote:
>
> Skip EXT_REX_SSE_REG_P for vzeroupper optimization since upper 16 vector
> registers don't trigger SSE <-> AVX transition penalty.
OK.
Richard.
> gcc/
>
> PR target/95791
> * config/i386/i386.c
On Sat, Jun 20, 2020 at 6:17 PM Yichao Yu via Gcc-patches
wrote:
>
>
> The current logic seems to be comparing the whole attribute tree between the
> callee
> and caller (or at least the tree starting from the target attribute).
> This is unnecessary and causes strange dependency of the
Hi!
This patch handles the compile time computation of number of loop
iterations.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2020-06-22 Jakub Jelinek
* omp-general.c (omp_extract_for_data): For triangular loops with
all loop invariant
Hi,
v4: Update len_load_direct/len_store_direct to align with direct optab.
v3: Get rid of length mode hook.
Thanks for reviewing!
BR,
Kewen
---
gcc/ChangeLog:
2020-MM-DD Kewen Lin
* doc/md.texi (lenload@var{m}): Document.
(lenstore@var{m}): Likewise.
*
Hi,
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 boundaries. The reason this happens is because these
Hi,
v5 changes against v4:
- Updated the conditions of clearing LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P
in vectorizable_condition (which fixed the aarch reg failure).
- Rebased and updated some macro and function names as the
renaming/refactoring patch.
- Updated some comments and
Hi all,
here the latest version of the patch to enable Armv8.1-M Mainline
LOB (low overhead branch) extension low overhead loops (LOL) feature
using the 'loop-doloop' pass.
I posted a previous version of it during stage 4.
Given the following function:
void
loop (int *a)
{
for (int i = 0; i
On 6/22/20 8:08 AM, Alexandre Oliva wrote:
I additionally did run the test case manually → files.log for the
produced files.
This is with -save-temps, right?
Yes. Without, there are no files left under /tmp and only
nvptx-merged-loop.xnvptx-none.mkoffload.309r.mach
nvptx-merged-loop.exe
Gentle remider.
On 11/06/20 8:32 am, François Dumont wrote:
As we are on patching algos we still have this old one.
From the original patch I only kept the memory optimization part
as the new performance test was not showing good result for the other
part to change pivot value. I also
On Jun 19, 2020, Tobias Burnus wrote:
> Done; nvptx compiled but for AMDGCN I got a compile error:
> in one function 'argv_obstack' was lacking a 'cc_' prefix ('cc_argv_obstack'),
> see attached patch (vs. mainline, not vs. either of your patches).
Ah, I see, cut, different obstacks. Thanks
44 matches
Mail list logo
