On 7/1/21 10:14 PM, Martin Sebor wrote:
On 6/30/21 5:35 PM, David Malcolm wrote:
On Wed, 2021-06-30 at 13:45 -0600, Martin Sebor wrote:
On 6/30/21 9:39 AM, Martin Sebor wrote:
@@ -90,8 +90,8 @@ NOIPA void warn_g2 (struct A *p)
g2 (p);
}
-// { dg-message "inlined from 'g2'" "" { targ
On Fri, 2 Jul 2021, Richard Biener wrote:
> On Thu, 1 Jul 2021, Michael Matz wrote:
>
> > Hello,
> >
> > On Thu, 1 Jul 2021, Richard Biener wrote:
> >
> > > diff --git a/gcc/gimple-loop-interchange.cc
> > > b/gcc/gimple-loop-interchange.cc
> > > index 43045c5455e..43ef112a2d0 100644
> > > ---
On Thu, Jul 1, 2021 at 7:10 PM Uros Bizjak wrote:
>
> [Sorry for double post, gcc-patches address was wrong in original post]
>
> On Thu, Jul 1, 2021 at 7:48 AM liuhongt wrote:
> >
> > Hi:
> > AVX512FP16 is disclosed, refer to [1].
> > There're 100+ instructions for AVX512FP16, 67 gcc patches
On Thu, 1 Jul 2021, Michael Matz wrote:
> Hello,
>
> On Thu, 1 Jul 2021, Richard Biener wrote:
>
> > diff --git a/gcc/gimple-loop-interchange.cc b/gcc/gimple-loop-interchange.cc
> > index 43045c5455e..43ef112a2d0 100644
> > --- a/gcc/gimple-loop-interchange.cc
> > +++ b/gcc/gimple-loop-interchan
On 2021-07-02 08:51, Bin.Cheng wrote:
On Thu, Jul 1, 2021 at 10:15 PM guojiufu via Gcc-patches
wrote:
On 2021-07-01 20:35, Richard Biener wrote:
> On Thu, 1 Jul 2021, Jiufu Guo wrote:
>
>> For code like:
>> unsigned foo(unsigned val, unsigned start)
>> {
>> unsigned cnt = 0;
>> for (unsign
Updated patch with minor change to move the variable declaration after comment.
Hongtao, could you help check-in the patch?
Hongyu Wang 于2021年7月1日周四 下午4:16写道：
>
> > Change some keylocker insn to Keylocker aesenc/aesdec in comments.
> > others LGTM.
>
> Changed.
>
> Forgot to mention bootstrapped
On 2021-07-02, Kito Cheng wrote:
It was undocument before, but already used in linux kernel, so LLVM
community suggest we should document that, so that make it become
supported/documented/non-internal machine constraints.
gcc/ChangeLog:
PR target/101275
* doc/md.text (Machine Co
It was undocument before, but already used in linux kernel, so LLVM
community suggest we should document that, so that make it become
supported/documented/non-internal machine constraints.
gcc/ChangeLog:
PR target/101275
* doc/md.text (Machine Constraints): Document the 'S' constr
Hi,
With Hongtao's help (thanks), we got the SPEC2017 performance
evaluation result on x86_64 (see [1]), this new parameter
ira-consider-dup-in-all-alts has negative effects on i386.
Since we observed it can benefit ports aarch64 and rs6000, the
param is set as 1 by default, this patch is to disab
Hi Richard,
on 2021/6/30 下午11:42, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> on 2021/6/28 下午3:20, Hongtao Liu wrote:
>>> On Mon, Jun 28, 2021 at 3:12 PM Hongtao Liu wrote:
On Mon, Jun 28, 2021 at 2:50 PM Kewen.Lin wrote:
>
> Hi!
>
> on 2021/6/9 下午1:18, Kewen.Lin
Hi Vladimir,
on 2021/6/30 下午11:24, Vladimir Makarov wrote:
>
> On 2021-06-28 2:26 a.m., Kewen.Lin wrote:
>> Hi!
>>
>> on 2021/6/9 下午1:18, Kewen.Lin via Gcc-patches wrote:
>>> Hi,
>>>
>>> PR100328 has some details about this issue, I am trying to
>>> brief it here. In the hottest function LBM_per
Add the tests for _mm_ceil_pd, _mm_ceil_ps, _mm_ceil_sd, _mm_ceil_ss.
Copy a test for _mm_ceil_pd and _mm_ceil_ps from
gcc/testsuite/gcc.target/i386.
Define __VSX_SSE2__ to pick up some union definitons in
m128-check.h.
2021-07-01 Paul A. Clarke
gcc/testsuite/ChangeLog:
* gcc/testsui
2021-07-01 Paul A. Clarke
gcc/ChangeLog:
* config/rs6000/smmintrin.h (_mm_ceil_pd, _mm_ceil_ps,
_mm_ceil_sd, _mm_ceil_ss): New.
---
gcc/config/rs6000/smmintrin.h | 28
1 file changed, 28 insertions(+)
diff --git a/gcc/config/rs6000/smmintrin.h b/gc
Instead of copying some tests from gcc/testsuite/gcc.target/i386,
I created new tests. The i386 tests in question used rand() to
generate the input data and assembly to compute the rounded values.
Using rand() for testing seems wrong, and the assembly is obviously
not portable. I use static data,
On Thu, Jul 1, 2021 at 8:19 PM Richard Biener
wrote:
>
> On Mon, Jun 7, 2021 at 4:35 PM Richard Biener
> wrote:
> >
> > On Sun, Jun 6, 2021 at 12:01 PM Bin.Cheng wrote:
> > >
> > > On Wed, Jun 2, 2021 at 3:28 PM Richard Biener via Gcc-patches
> > > wrote:
> > > >
> > > > On Tue, Jun 1, 2021 at
-Wvla-parameter relies on operand_equal_p() with OEP_LEXICOGRAPHIC
set to compare VLA bounds for equality. But operand_equal_p()
doesn't consider decl names, and so nontrivial expressions that
refer to the same function parameter are considered unequal by
the function, leading to false positives.
On Thu, Jul 1, 2021 at 10:15 PM guojiufu via Gcc-patches
wrote:
>
> On 2021-07-01 20:35, Richard Biener wrote:
> > On Thu, 1 Jul 2021, Jiufu Guo wrote:
> >
> >> For code like:
> >> unsigned foo(unsigned val, unsigned start)
> >> {
> >> unsigned cnt = 0;
> >> for (unsigned i = start; i > val; +
On Thu, Jul 01, 2021 at 11:40:55AM -0400, David Malcolm via Gcc-patches wrote:
> On Thu, 2021-07-01 at 14:53 +0200, Richard Biener wrote:
> > On Thu, Jul 1, 2021 at 12:16 PM Trevor Saunders <
> > tbsau...@tbsaunde.org> wrote:
> > >
> > > On Wed, Jun 30, 2021 at 11:13:23AM -0400, David Malcolm wrot
On Thu, Jul 01, 2021 at 04:47:21PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Jul 01, 2021 at 10:59:15PM +0930, Alan Modra wrote:
> > * lib/target-supports.exp (check_effective_target_has_arch_pwr10): New.
>
> Mike added this already, please make sure to not add it twice :-)
Yup, reb
On 7/1/2021 4:40 PM, Eugene Rozenfeld wrote:
gen_autofdo_event.py was stumbling on models with stepping so
I updated the script to handle this case similar to the code in
https://github.com/andikleen/pmu-tools/blob/c6a5f63aede19def8886d6a8b74d7a55c38ca947/event_download.py
The second change wa
gen_autofdo_event.py was stumbling on models with stepping so
I updated the script to handle this case similar to the code in
https://github.com/andikleen/pmu-tools/blob/c6a5f63aede19def8886d6a8b74d7a55c38ca947/event_download.py
The second change was to tolerate cases when the CPU supports PEBS bu
On Thu, Jul 1, 2021, 15:28 H.J. Lu via llvm-dev
wrote:
> On Thu, Jul 1, 2021 at 3:10 PM Joseph Myers
> wrote:
> >
> > On Thu, 1 Jul 2021, H.J. Lu via Gcc-patches wrote:
> >
> > > 2. Return _Float16 and _Complex _Float16 values in %xmm0/%xmm1
> registers.
> >
> > That restricts use of _Float16 to
On Thu, Jul 1, 2021 at 4:02 PM H.J. Lu via llvm-dev
wrote:
> On Thu, Jul 1, 2021 at 3:40 PM Joseph Myers
> wrote:
> >
> > On Thu, 1 Jul 2021, H.J. Lu wrote:
> >
> > > BTW, _Float16 software emulation may require more than just SSE
> > > since we need to do _Float16 load and store with XMM regist
On Thu, Jul 1, 2021 at 3:40 PM Joseph Myers wrote:
>
> On Thu, 1 Jul 2021, H.J. Lu wrote:
>
> > BTW, _Float16 software emulation may require more than just SSE
> > since we need to do _Float16 load and store with XMM registers.
> > There is no 16bit load/store for XMM registers without AVX512FP16.
On Thu, 1 Jul 2021, H.J. Lu wrote:
> BTW, _Float16 software emulation may require more than just SSE
> since we need to do _Float16 load and store with XMM registers.
> There is no 16bit load/store for XMM registers without AVX512FP16.
You should be able to make the move go via general-purpose re
On Thu, Jul 1, 2021 at 3:10 PM Joseph Myers wrote:
>
> On Thu, 1 Jul 2021, H.J. Lu via Gcc-patches wrote:
>
> > 2. Return _Float16 and _Complex _Float16 values in %xmm0/%xmm1 registers.
>
> That restricts use of _Float16 to processors with SSE. Is that what we
> want in the ABI, or should _Float1
On 6/28/2021 10:21 AM, Aldy Hernandez wrote:
This is is the main basic block path solver for use in the ranger-based
backwards threader. Given a path of BBs, the class can solve the final
conditional or any SSA name used in calculating the final conditional.
The main API is:
// This class i
On Thu, 1 Jul 2021, H.J. Lu via Gcc-patches wrote:
> 2. Return _Float16 and _Complex _Float16 values in %xmm0/%xmm1 registers.
That restricts use of _Float16 to processors with SSE. Is that what we
want in the ABI, or should _Float16 be available with base 32-bit x86
architecture features only
This moves some global state from input.c to a new file_cache class,
of which an instance is owned by global_dc. Various state is also
made private.
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as b544c348e13ad33d55f0d954370ab1fb0f
On Thu, 1 Jul 2021, Richard Biener via Gcc-patches wrote:
> > C++ FE doesn't support _FLoat16, and the place float/double are
> > handled is in convert.c(which is GENERIC?), that's why I decided to do
> > it in the backend.
I think there ought to be a preliminary patch series adding whatever
_Fl
Hi!
On Thu, Jul 01, 2021 at 10:59:15PM +0930, Alan Modra wrote:
> * lib/target-supports.exp (check_effective_target_has_arch_pwr10): New.
Mike added this already, please make sure to not add it twice :-)
[...]
> gcc.target/powerpc/pr86731-fwrapv-longlong.c: Match power10 insns.
(It
On Thu, 1 Jul 2021, H.J. Lu via Gcc-patches wrote:
> The main issue is complex _Float16 functions in libgcc. If _Float16 doesn't
> require -mavx512fp16, we need to compile complex _Float16 functions in
> libgcc without -mavx512fp16. Complex _Float16 performance is very
> important for our _Float
On Thu, 1 Jul 2021, liuhongt via Gcc-patches wrote:
> +/* Optimize for code like (_Float16) __builtin_ceif ((float) f16)
> + since it's not handled in frontend. */
Much the same comments apply as for sqrt. But in this case, the
conversion code is in match.pd - right now, specific to pairs of
On Thu, 1 Jul 2021, liuhongt via Gcc-patches wrote:
> +/* Optimize for code like (_Float16) __builtin_sqrtf ((float) f16)
> + since it's not handled in frontend. */
If correct, it *should* be handled in front end (well, middle-end). See
what convert.c:convert_to_real_1 does, with a long comm
1. Pass _Float16 and _Complex _Float16 values on stack.
2. Return _Float16 and _Complex _Float16 values in %xmm0/%xmm1 registers.
---
low-level-sys-info.tex | 57 +-
1 file changed, 40 insertions(+), 17 deletions(-)
diff --git a/low-level-sys-info.tex b/low
Some general comments, following what I said on libc-alpha:
1. Can you confirm that the ABI being used for 64-bit, for _Float16 and
_Complex _Float16 argument passing and return, follows the current x86_64
ABI document?
2. Can you confirm that if you build with this instruction set extension
On Thu, Jul 1, 2021 at 1:12 PM Jeff Law wrote:
>
>
>
> On 7/1/2021 1:28 PM, H.J. Lu via Gcc-patches wrote:
> > This patch is updating soft-fp from glibc:
> >
> > 1. Add __extendhfxf2 to return an IEEE half converted to IEEE extended.
> > 2. Add __truncxfhf2 to truncate IEEE extended into IEEE half
On 6/30/21 5:35 PM, David Malcolm wrote:
On Wed, 2021-06-30 at 13:45 -0600, Martin Sebor wrote:
On 6/30/21 9:39 AM, Martin Sebor wrote:
Ping. Attached is the same patch rebased on top the latest trunk.
Please see the attached patch instead. The previous one had typo
in it.
As discussed i
On 7/1/2021 1:28 PM, H.J. Lu via Gcc-patches wrote:
This patch is updating soft-fp from glibc:
1. Add __extendhfxf2 to return an IEEE half converted to IEEE extended.
2. Add __truncxfhf2 to truncate IEEE extended into IEEE half.
These are needed by x86 _Float16 support.
Presumably these are
On 7/1/21 1:01 PM, Segher Boessenkool wrote:
> On Wed, Jun 30, 2021 at 04:56:04PM -0500, Peter Bergner wrote:
>> LLVM added the __builtin_vsx_lxvp and __builtin_vsx_stxvp built-ins.
>> The following patch adds support for them to GCC so that we stay in sync
>> with LLVM.
>
> This should be documen
On 6/30/21 4:55 PM, David Malcolm wrote:
On Tue, 2021-06-15 at 17:00 -0600, Martin Sebor wrote:
On 6/11/21 11:04 AM, David Malcolm wrote:
On Thu, 2021-06-10 at 17:26 -0600, Martin Sebor wrote:
This diff introduces the diagnostic infrastructure changes to
support
controlling warnings at any cal
On 7/1/21 11:08 AM, Tobias Burnus wrote:
Hi all,
this patch came up when discussing Sandra's TS29113 patch internally.
There is presumably also some overlap with José's patches.
This patch tries to rectify the BIND(C) CHARACTER handling on the
diagnostic side, only. That is: what to accept and
This patch is updating soft-fp from glibc:
1. Add __extendhfxf2 to return an IEEE half converted to IEEE extended.
2. Add __truncxfhf2 to truncate IEEE extended into IEEE half.
These are needed by x86 _Float16 support.
---
libgcc/soft-fp/extendhfxf2.c | 53
l
On 7/1/21 1:01 PM, Segher Boessenkool wrote:
> On Wed, Jun 30, 2021 at 04:56:04PM -0500, Peter Bergner wrote:
>> LLVM added the __builtin_vsx_lxvp and __builtin_vsx_stxvp built-ins.
>> The following patch adds support for them to GCC so that we stay in sync
>> with LLVM.
>
> This should be documen
Hi!
On Wed, Jun 30, 2021 at 04:56:04PM -0500, Peter Bergner wrote:
> LLVM added the __builtin_vsx_lxvp and __builtin_vsx_stxvp built-ins.
> The following patch adds support for them to GCC so that we stay in sync
> with LLVM.
This should be documented somewhere.
> + else if (fncode == VSX_BUILT
This attempst to improve the doxygen output to work around what seems to
be some bugs in doxygen (issues 8635 and 8638).
The @addtogroup command doesn't work for entities inside a nested
namespace (see 8635) so we need to close and reopen groups on entering
and leaving nested namespaces. This fixe
On July 1, 2021 4:40:11 PM GMT+02:00, Michael Matz wrote:
>Hello,
>
>I haven't followed this thread too closely, in particular I haven't
>seen
>why the current form of the .DEFERRED_INIT call was chosen or
>suggested,
>but it triggered my "well, that's obviously wrong" gut feeling; so
>sorry
>f
Add BTF_KIND_FLOAT, a new BTF type kind which has recently stabilized in
the linux kernel [1]. This kind is used for encoding floating point
types, and is of particular use when generating BTF for some s390
arch-specific kernel headers.
Also update some BTF tests which previously used floating poi
Now committed as 5c17042e880a5d1a3eb261f73e1b9da0c1aa2641
https://gcc.gnu.org/gcc-12/changes.html
Tobias
On 29.06.21 18:38, Julian Brown wrote:
On Tue, 29 Jun 2021 17:34:00 +0200
Tobias Burnus wrote:
This documents AMD GCN's new much-more complete TI-mode
(__int128_t) support, that was as v2
Hi all,
this patch came up when discussing Sandra's TS29113 patch internally.
There is presumably also some overlap with José's patches.
This patch tries to rectify the BIND(C) CHARACTER handling on the
diagnostic side, only. That is: what to accept and what
to reject for which Fortran standard.
> Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org
> From: Martin Liška
> Date: Thu, 1 Jul 2021 18:04:24 +0200
>
> > Emacs doesn't hide the period. But there shouldn't be a period to
> > begin with, since it's the middle of a sentence. The correct way of
> > writing this i
Hi,
a big difference between ELF and PE-COFF is that, with the latter, you can
build position-independent executables or DLLs without generating PIC; as a
matter of fact, flag_pic has historically been forced to 0 for 32-bit:
/* Don't allow flag_pic to propagate since gas may produce invalid co
Hi, Richard,
> On Jul 1, 2021, at 11:23 AM, Richard Sandiford
> wrote:
>
> Michael Matz writes:
>> Hello,
>>
>> On Thu, 1 Jul 2021, Richard Sandiford wrote:
>>
>>> Well, it does feel like this is pressing the reset button on a thread
>>> whose message count is already in the high double figu
> > I think this version addresses most of your concerns.
>
> Thanks, looking good. I'll fuss with it a bit and commit it soon.
Awesome!
Andrew
Michael Matz writes:
> Hello,
>
> On Thu, 1 Jul 2021, Richard Sandiford wrote:
>
>> Well, it does feel like this is pressing the reset button on a thread
>> whose message count is already in the high double figures. There's a
>> risk that restarting the discussion now is going to repeat a lot of
This is a minor regression present on mainline and 11 branch, whereby the
value of the Enum_Rep attribute is always unsigned.
Tested on x86-64/Linux, applied on the mainline and 11 branch.
2021-07-01 Eric Botcazou
PR ada/101094
* exp_attr.adb (Get_Integer_Type): Return an in
This extends the type name conflict detection mechanism to variables.
Tested on x86-64/Linux, applied on the mainline.
2021-07-01 Eric Botcazou
c-family/
* c-ada-spec.c (check_name): Rename into...
(check_type_name_conflict): ...this. Minor tweak.
(dump_ada_function_
We cannot fully support packed record layout in -fdump-ada-spec, as packing
in C and Ada does not behave the same, so we issue a warning. But some simple
cases are OK and can actually be handled without much work.
Tested on x86-64/Linux, applied on the mainline.
2021-07-01 Eric Botcazou
c
Hello,
On Thu, 1 Jul 2021, Richard Sandiford wrote:
> Well, it does feel like this is pressing the reset button on a thread
> whose message count is already in the high double figures. There's a
> risk that restarting the discussion now is going to repeat a lot of the
> same ground, probably at
On Thu, 2021-07-01 at 11:40 -0400, David Malcolm wrote:
> On Thu, 2021-07-01 at 14:53 +0200, Richard Biener wrote:
> > On Thu, Jul 1, 2021 at 12:16 PM Trevor Saunders <
> > tbsau...@tbsaunde.org> wrote:
> > >
> > > On Wed, Jun 30, 2021 at 11:13:23AM -0400, David Malcolm wrote:
> > > > On Wed, 2021
On 7/1/21 5:44 PM, Eli Zaretskii wrote:
Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org
From: Martin Liška
Date: Thu, 1 Jul 2021 16:14:30 +0200
If I understand the notes correct, the '.' should be also hidden by e.g. Emacs.
No, it doesn't. The actual text in the Info
Hi,
This is a placeholder name ahead of any CTF implementation on
LLVM (which sets Darwin ABI). Ideally, we would get agreement
on this choice (or any replacement) before GCC12 is shipped.
tested on Darwin18,
pushed to master, thanks,
Iain
PR debug/101283 - Several tests fail on Darwin with -gc
> Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org
> From: Martin Liška
> Date: Thu, 1 Jul 2021 16:14:30 +0200
>
> >> If I understand the notes correct, the '.' should be also hidden by e.g.
> >> Emacs.
> >
> > No, it doesn't. The actual text in the Info file is:
> >
> >
Hi, Michael,
> On Jul 1, 2021, at 9:40 AM, Michael Matz wrote:
>
> Hello,
>
> I haven't followed this thread too closely, in particular I haven't seen
> why the current form of the .DEFERRED_INIT call was chosen or suggested,
> but it triggered my "well, that's obviously wrong" gut feeling; s
On Thu, 2021-07-01 at 14:53 +0200, Richard Biener wrote:
> On Thu, Jul 1, 2021 at 12:16 PM Trevor Saunders <
> tbsau...@tbsaunde.org> wrote:
> >
> > On Wed, Jun 30, 2021 at 11:13:23AM -0400, David Malcolm wrote:
> > > On Wed, 2021-06-30 at 01:35 -0400, Trevor Saunders wrote:
> > > > This makes it
Michael Matz writes:
> Hello,
>
> I haven't followed this thread too closely, in particular I haven't seen
> why the current form of the .DEFERRED_INIT call was chosen or suggested,
> but it triggered my "well, that's obviously wrong" gut feeling; so sorry
> for stating something which might be
On Thu, 1 Jul 2021, Jason Merrill wrote:
> On 6/30/21 5:27 PM, Patrick Palka wrote:
> > Here any_template_parm_r is failing to mark the template parameters
> > that're implicitly used by the unqualified use of 'd' inside the constraint,
> > because the code to do so assumes each level of a templat
> On Jul 1, 2021, at 9:09 AM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
>>> On Jul 1, 2021, at 1:48 AM, Richard Biener
>>> wrote:
>>>
>>> On Wed, Jun 30, 2021 at 9:15 PM Qing Zhao via Gcc-patches
>>> wrote:
> On Jun 30, 2021, at 1:59 PM, Richard Biener wrote:
> On Jul 1, 2021, at 9:04 AM, Richard Biener wrote:
>
> On Thu, Jul 1, 2021 at 3:45 PM Qing Zhao wrote:
>>
>>
>>
>>> On Jul 1, 2021, at 1:48 AM, Richard Biener
>>> wrote:
>>>
>>> On Wed, Jun 30, 2021 at 9:15 PM Qing Zhao via Gcc-patches
>>> wrote:
> On Jun 30, 2021
* gcc.target/i386/pieces-memcpy-10.c: New test.
* gcc.target/i386/pieces-memcpy-11.c: Likewise.
* gcc.target/i386/pieces-memcpy-12.c: Likewise.
* gcc.target/i386/pieces-memcpy-13.c: Likewise.
* gcc.target/i386/pieces-memcpy-14.c: Likewise.
* gcc.targe
Also pass -mno-sse to vect8-ret.c to disable XMM load/store when running
GCC tests with "-march=x86-64 -m32".
* gcc.target/i386/vect8-ret.c: Also pass -mno-sse.
---
gcc/testsuite/gcc.target/i386/vect8-ret.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/
Expect no stack realignment since we no longer realign stack when
copying data.
* gcc.target/i386/incoming-11.c: Expect no stack realignment.
---
gcc/testsuite/gcc.target/i386/incoming-11.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386/i
Also pass -mno-avx to sw-1.c for ia32 since copying data with YMM or ZMM
registers disables shrink-wrapping when the second argument is passed on
stack.
* gcc.target/i386/sw-1.c: Also pass -mno-avx for ia32.
---
gcc/testsuite/gcc.target/i386/sw-1.c | 1 +
1 file changed, 1 insertion(+)
d
We can use TImode/OImode/XImode integers for piecewise move and store.
1. Define MAX_MOVE_MAX to 64, which is the constant maximum number of
bytes that a single instruction can move quickly between memory and
registers or between two memory locations.
2. Define MOVE_MAX to MOVE_MAX_PIECES, which i
Also pass -mno-avx to pr72839.c to avoid copying data with YMM or ZMM
registers.
* gcc.target/i386/pr72839.c: Also pass -mno-avx.
---
gcc/testsuite/gcc.target/i386/pr72839.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386/pr72839.c
b/gcc/
PR middle-end/90773
* gcc.target/i386/pr90773-20.c: New test.
* gcc.target/i386/pr90773-21.c: Likewise.
* gcc.target/i386/pr90773-22.c: Likewise.
* gcc.target/i386/pr90773-23.c: Likewise.
* gcc.target/i386/pr90773-26.c: Likewise.
---
gcc/testsuite/gc
Changes in the v5 patches:
1. Add TARGET_GEN_MEMSET_SCRATCH_RTX to allow the backend to use a hard
scratch register to avoid stack realignment when expanding memset.
2. Use vec_duplicate, instead of adding TARGET_READ_MEMSET_VALUE and
TARGET_GEN_MEMSET_VALUE, to expand memset if available.
Change
Also pass -mno-avx to pr72839.c to avoid copying data with YMM or ZMM
registers.
* gcc.target/i386/cold-attribute-1.c: Also pass -mno-avx.
---
gcc/testsuite/gcc.target/i386/cold-attribute-1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386
Define TARGET_GEN_MEMSET_SCRATCH_RTX to ix86_gen_scratch_sse_rtx to
return a scratch SSE register for memset.
gcc/
PR middle-end/90773
* config/i386/i386.c (TARGET_GEN_MEMSET_SCRATCH_RTX): New.
gcc/testsuite/
PR middle-end/90773
* gcc.target/i386/pr90773-15.c: Ne
1. Rewrite builtin_memset_read_str/builtin_memset_gen_str to use vector
broadcast to duplicate QI value to TI/OI/XI value for memmset.
2. Add TARGET_GEN_MEMSET_SCRATCH_RTX to allow the backend to use a hard
scratch register to avoid stack realignment when expanding memset.
PR middle-end/90
To avoid stack realignment, use SCRATCH_SSE_REG to copy data from one
memory location to another.
gcc/
* config/i386/i386-expand.c (ix86_expand_vector_move): Call
ix86_gen_scratch_sse_rtx to get a scratch SSE register to copy
data from one memory location to another.
gcc/
On 7/1/21 5:28 AM, Matthias Kretz wrote:
On Tuesday, 22 June 2021 22:12:42 CEST Jason Merrill wrote:
On 6/22/21 4:01 PM, Matthias Kretz wrote:
On Tuesday, 22 June 2021 21:52:16 CEST Jason Merrill wrote:
For alias templates, you probably want the attribute only on the
templated class, not on th
On 6/30/21 5:27 PM, Patrick Palka wrote:
Here any_template_parm_r is failing to mark the template parameters
that're implicitly used by the unqualified use of 'd' inside the constraint,
because the code to do so assumes each level of a template parameter
list points to the corresponding primary t
Currently, if we look at the debug information for offload kernel
regions, it looks something like this:
void foo (void)
{
#pragma acc kernels
{
}
}
DW_TAG_compile_unit
DW_AT_name("")
DW_TAG_subprogram // notional parent function (foo) with no code range
DW_TAG_subprogram // of
On 6/26/21 10:23 AM, Andrew Sutton wrote:
Hi Jason,
I ended up taking over this work from Jeff (CC'd on his existing email
address). I scraped all the contracts changes into one big patch
against master. See attached. The ChangeLog.contracts files list the
sum of changes for the patch, not the f
Hello,
On Thu, 1 Jul 2021, Martin Liška wrote:
> On 7/1/21 3:33 PM, Eli Zaretskii wrote:
> > > Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org
> > > From: Martin Liška
> > > Date: Thu, 1 Jul 2021 14:44:10 +0200
> > >
> > > > It helps some, but not all of the issues disapp
On 7/1/2021 8:55 AM, Uros Bizjak via Gcc-patches wrote:
No functional changes.
2021-07-01 Uroš Bizjak
gcc/
* recog.c (general_operand): Return true/false instead of 1/0.
(register_operand): Ditto.
(immediate_operand): Ditto.
(const_int_operand): Ditto.
(const_scal
No functional changes.
2021-07-01 Uroš Bizjak
gcc/
* config/i386/predicates.md (ix86_endbr_immediate_operand):
Return true/false instead of 1/0.
(movq_parallel): Ditto.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Pushed to master.
Uros.
diff --git a/gcc/confi
No functional changes.
2021-07-01 Uroš Bizjak
gcc/
* recog.c (general_operand): Return true/false instead of 1/0.
(register_operand): Ditto.
(immediate_operand): Ditto.
(const_int_operand): Ditto.
(const_scalar_int_operand): Ditto.
(const_double_operand): Ditto.
(pu
Hello,
On Thu, 1 Jul 2021, Richard Biener wrote:
> diff --git a/gcc/gimple-loop-interchange.cc b/gcc/gimple-loop-interchange.cc
> index 43045c5455e..43ef112a2d0 100644
> --- a/gcc/gimple-loop-interchange.cc
> +++ b/gcc/gimple-loop-interchange.cc
> @@ -1043,8 +1043,11 @@ tree_loop_interchange::val
On 7/1/21 2:01 AM, Christophe LYON wrote:
On 30/06/2021 21:56, Martin Sebor via Gcc-patches wrote:
On 6/11/21 8:46 AM, Martin Sebor wrote:
On 6/11/21 3:58 AM, Richard Sandiford wrote:
Martin Sebor via Gcc-patches writes:
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 7b37e1b
Hello,
I haven't followed this thread too closely, in particular I haven't seen
why the current form of the .DEFERRED_INIT call was chosen or suggested,
but it triggered my "well, that's obviously wrong" gut feeling; so sorry
for stating something which might be obvious to thread participants h
On 7/1/21 3:33 PM, Eli Zaretskii wrote:
Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org
From: Martin Liška
Date: Thu, 1 Jul 2021 14:44:10 +0200
It helps some, but not all of the issues disappear. For example,
stuff like this is still hard to read:
To select this st
On 2021-07-01 20:35, Richard Biener wrote:
On Thu, 1 Jul 2021, Jiufu Guo wrote:
For code like:
unsigned foo(unsigned val, unsigned start)
{
unsigned cnt = 0;
for (unsigned i = start; i > val; ++i)
cnt++;
return cnt;
}
The number of iterations should be about UINT_MAX - start.
For
On Thu, Jul 1, 2021 at 2:42 PM H.J. Lu wrote:
>
> Hi Uros,
>
> On Thu, Jul 1, 2021 at 1:32 AM Hongtao Liu wrote:
> >
> > On Tue, Jun 29, 2021 at 6:16 AM H.J. Lu wrote:
> > >
> > > 1. Update move expanders to convert the CONST_WIDE_INT and CONST_VECTOR
> > > operands to vector broadcast from an i
Qing Zhao writes:
>> On Jul 1, 2021, at 1:48 AM, Richard Biener
>> wrote:
>>
>> On Wed, Jun 30, 2021 at 9:15 PM Qing Zhao via Gcc-patches
>> wrote:
>>>
>>>
>>>
On Jun 30, 2021, at 1:59 PM, Richard Biener wrote:
On June 30, 2021 8:07:43 PM GMT+02:00, Qing Zhao
wrote:
On Thu, Jul 1, 2021 at 3:45 PM Qing Zhao wrote:
>
>
>
> > On Jul 1, 2021, at 1:48 AM, Richard Biener
> > wrote:
> >
> > On Wed, Jun 30, 2021 at 9:15 PM Qing Zhao via Gcc-patches
> > wrote:
> >>
> >>
> >>
> >>> On Jun 30, 2021, at 1:59 PM, Richard Biener wrote:
> >>>
> >>> On June 30, 2021 8:07
> On Jul 1, 2021, at 1:48 AM, Richard Biener wrote:
>
> On Wed, Jun 30, 2021 at 9:15 PM Qing Zhao via Gcc-patches
> wrote:
>>
>>
>>
>>> On Jun 30, 2021, at 1:59 PM, Richard Biener wrote:
>>>
>>> On June 30, 2021 8:07:43 PM GMT+02:00, Qing Zhao
>>> wrote:
> On Jun 30, 202
> Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org
> From: Martin Liška
> Date: Thu, 1 Jul 2021 14:44:10 +0200
>
> > It helps some, but not all of the issues disappear. For example,
> > stuff like this is still hard to read:
> >
> >To select this standard in GCC, use o
Bootstrapped and regression tested powerpc64le-linux power9 and
power10. OK for mainline?
* lib/target-supports.exp (check_effective_target_has_arch_pwr10): New.
* gcc.dg/pr56727-2.c,
gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c,
gcc.target/powerpc/fold-
1 - 100 of 171 matches
Mail list logo
