On Wed, Sep 15, 2021 at 10:10 AM wrote:
>
> From: "H.J. Lu"
>
> Simply memcpy and memset inline strategies to avoid branches for
> -mtune=tremont:
>
> 1. Create Tremont cost model from generic cost model.
> 2. With MOVE_RATIO and CLEAR_RATIO == 17, GCC will use integer/vector
>load and store
On Wed, Sep 15, 2021 at 10:09 AM wrote:
>
> From: "H.J. Lu"
>
> Initial -mtune=tremont update
>
> 1. Use Haswell scheduling model.
> 2. Assume that stack engine allows to execute push&pop instructions in
> parall.
> 3. Prepare for scheduling pass as -mtune=generic.
> 4. Use the same issue rate as
On Wed, Sep 15, 2021 at 10:10 AM wrote:
>
> From: "H.J. Lu"
>
> 1. Replace TARGET_SSE_PARTIAL_REG_DEPENDENCY with
> TARGET_SSE_PARTIAL_REG_FP_CONVERTS_DEPENDENCY in SSE FP to FP splitters.
> 2. Replace TARGET_SSE_PARTIAL_REG_DEPENDENCY with
> TARGET_SSE_PARTIAL_REG_CONVERTS_DEPENDENCY in SSE INT
On Wed, Sep 15, 2021 at 10:10 AM wrote:
>
> From: "H.J. Lu"
>
> Check TARGET_USE_VECTOR_FP_CONVERTS or TARGET_USE_VECTOR_CONVERTS when
> handling avx_partial_xmm_update attribute. Don't convert AVX partial
> XMM register update if vector packed SSE conversion should be used.
>
> gcc/
>
>
Ping.
Bootstrapped and regtest on x86_64-linux-gnu{-m32,},
aarch64-unknown-linux-gnu{-m32,}
Ok for trunk?
gcc/ChangeLog:
PR middle-end/102080
* match.pd: Check mask type when doing cond_op related gimple
simplification.
* tree.c (is_truth_type_for): New funct
Hello Harald,
As nicely described in the PR, we mishandled the case of passing
optional allocatable DT arguments with allocatable components
when the INTENT was declared as INTENT(OUT), as we unconditionally
tried to deallocate these components even when the argument was not
present. The obviou
> On 15 Sep 2021, at 18:45, Alexandre Oliva wrote:
>
> On Sep 15, 2021, Alexandre Oliva wrote:
>
>> Regstrapped on x86_64-linux-gnu. Patch pre-approved by Olivier Hainque.
>
> Uhh, actually, Olivier had only seen and approved these changes:
>
>> for gcc/ada/ChangeLog
>
>> * gcc-int
I'm going to check in 6 patches
[PATCH 24/62] AVX512FP16: Add vmovw/vmovsh.
[PATCH 25/62] AVX512FP16: Add testcase for vmovsh/vmovw.
[PATCH 26/62] AVX512FP16: Add
vcvtph2dq/vcvtph2qq/vcvtph2w/vcvtph2uw/vcvtph2uqq/vcvtph2udq
[PATCH 27/62] AVX512FP16: Add testcase for
vcvtph2w/vcvtph2uw/vcvtph2dq/vc
Ping
rebased on latest trunk.
gcc/ChangeLog:
* common.opt (ftree-vectorize): Add Var(flag_tree_vectorize).
* doc/invoke.texi (Options That Control Optimization): Update
documents.
* opts.c (default_options_table): Enable auto-vectorization at
O2 with very-c
> I find the other_cond support a bit confusing. Is this for -mcmodel
> perhaps? Why not just say that if so?
I suppose we might have other multilib options other than -march,
-mabi and -mcmodel,
so I keep the flexibility here.
> riscv_multi_lib_info_t::parse
> Calls riscv_subset_list::parse tw
On Wed, 15 Sep 2021, Thomas Schwinge wrote:
>> The program for the GNU Tools Track at Linux Plumbers Conference is
>> published:
>>
>> https://linuxplumbersconf.org/event/11/sessions/109/
> This may qualify "as obvious", but I better get reviewed what I change on
> our front page to the Internet
Hi Martin,
Thanks for the review comments!
on 2021/9/15 下午8:51, Martin Jambor wrote:
> Hi,
>
> since this is inlining-related, I would somewhat prefer Honza to have a
> look too, but I have the following comments:
>
> On Wed, Sep 08 2021, Kewen.Lin wrote:
>>
>
> [...]
>
>> diff --git a/gcc/ip
On Wed, Sep 15, 2021 at 4:54 PM Cui, Lili wrote:
>
>
>
> > -Original Message-
> > From: H.J. Lu
> > Sent: Wednesday, September 15, 2021 10:14 PM
> > To: Cui, Lili
> > Cc: Uros Bizjak ; GCC Patches > patc...@gcc.gnu.org>; Liu, Hongtao
> > Subject: Re: [PATCH 4/4] [PATCH 4/4] x86: Add
>
Hi,
This patch follows the discussion here[1], where Segher pointed
out the existing way to guard the extra penalized cost for
strided/elementwise loads with a magic bound doesn't scale.
The way with nunits * stmt_cost can get one much exaggerated
penalized cost, such as: for V16QI on P8, it's 16
> -Original Message-
> From: H.J. Lu
> Sent: Wednesday, September 15, 2021 10:14 PM
> To: Cui, Lili
> Cc: Uros Bizjak ; GCC Patches patc...@gcc.gnu.org>; Liu, Hongtao
> Subject: Re: [PATCH 4/4] [PATCH 4/4] x86: Add
> TARGET_SSE_PARTIAL_REG_[FP_]CONVERTS_DEPENDENCY
>
> There is no nee
On 8/31/21 09:55, nick huang via Gcc-patches wrote:
These bugs are considered duplicate cases of PR51851 which has been suspended
since 2012, an issue known as "core1001/1322". Considering this background,
it deserves a long comment to explain.
Many people believed the root cause of this family
doc: improve -fsanitize=undefined description
gcc/ChangeLog:
* doc/invoke.texi: add link to UndefinedBehaviorSanitizer
documentation,
mention UBSAN_OPTIONS, similar to what is done for AddressSanitizer.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index
On 9/6/21 08:10, wangpc via Gcc-patches wrote:
This patch adds type checking for static local vector variable in
C++ template, both AArch64 SVE and RISCV RVV are of sizeless type
and thay all have this issue.
2021-08-06 wangpc
gcc/cp/ChangeLog
* pt.c (tsubst_decl): Add type checkin
From: Andrew Pinski
The error message is obvious -funconfigured-libstdc++-v3 is used
on the g++ command line. So we just add the dependancy.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
ChangeLog:
* Makefile.def: Have configure-target-libffi depend on
a
On 9/14/21 04:29, Michel Morin via Gcc-patches wrote:
On Tue, Sep 14, 2021 at 7:14 AM David Malcolm wrote:
On Tue, 2021-09-14 at 03:35 +0900, Michel Morin via Gcc-patches wrote:
Hi,
PR77565 reports that, with the code `typdef int Int;`, GCC emits
"did you mean 'typeof'?" instead of "did you
While looking at PR96184 I noticed that we were recognizing the situation of
parsing a function declarator based on current_binding_level, and that we
ought to make that a predicate function. This patch is just refactoring,
but I just suggested using it in a review of another patch.
Tested x86_64
> On Sep 13, 2021, at 3:31 AM, Richard Biener wrote:
>
> This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
> is not specified by the target and NO_DEBUG if DWARF is not supported.
As I'm looking at questions about old debug formats, it brings up the question
of old object
On 9/15/21 14:59, Jakub Jelinek wrote:
On Tue, Sep 14, 2021 at 10:50:32AM -0400, Jason Merrill wrote:
Note, if the flexible array member is initialized only with non-constant
initializers, we have a worse bug that this patch doesn't solve, the
splitting of initializers into constant and dynamic
On 9/15/21 14:32, Iain Sandoe wrote:
Hi Jason,
On 15 Sep 2021, at 18:32, Jason Merrill wrote:
On 9/14/21 11:36, Iain Sandoe wrote:
Hi
Some small code cleanups that allow us to have just one place that
we handle a statement with await expression(s) embedded. Also we
can reduce the work done
On 9/14/21 00:31, Barrett Adair wrote:
I reworked the fix today based on feedback from Jason and Jakub (thank
you), and the subject line is now outdated. I added another test for a
closely related bug that's also fixed here (dependent-expr11.C -- this
one would even fail without the second decl
N.B. Please CC *both* the libstdc++ list and the gcc-patches list, as
per https://gcc.gnu.org/lists.html
On Wed, 15 Sept 2021 at 14:02, 刘可 wrote:
>
> Thank you for your review, and I apologize for my mistake. I have updated and
> tested it！
Hmm, it doesn't work though. How did you test it?
For
Hi folks,
> On 27 Aug 2021, at 14:00, Iain Sandoe wrote:
>
> +Jeff
>
> (it’s probably borderline obvious - but in the top level Makefile .. so)
>
>> On 17 Aug 2021, at 21:53, David Malcolm wrote:
>>
>> On Tue, 2021-08-17 at 19:59 +0100, Iain Sandoe wrote:
>>> Hi,
>>>
>>> For those of us who
On 9/15/21 20:40, David Edelsohn wrote:
This needs an additional adjustment. The encoding decoration needs to
be applied if the decl isn't an alias. That means both a null summary
*OR* the decl is not explicitly an alias.
Oh, sorry, I made a stupid thinko.
Please install the patch.
Martin
On Wed, Sep 15, 2021 at 11:12:18AM +0200, Richard Biener wrote:
> On Tue, Sep 14, 2021 at 11:13 PM Dimitar Dimitrov wrote:
> >
> > Hi,
> >
> > I'm sending this patch to get feedback for a new PRU CPU port feature.
> > My intention is to push it to master by end of September, so that it gets
> > in
On Tue, Sep 14, 2021 at 10:50:32AM -0400, Jason Merrill wrote:
> > Note, if the flexible array member is initialized only with non-constant
> > initializers, we have a worse bug that this patch doesn't solve, the
> > splitting of initializers into constant and dynamic initialization removes
> > the
This needs an additional adjustment. The encoding decoration needs to
be applied if the decl isn't an alias. That means both a null summary
*OR* the decl is not explicitly an alias.
I'm proposing the following:
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index d0830a950
Hi Jason,
> On 15 Sep 2021, at 18:32, Jason Merrill wrote:
>
> On 9/14/21 11:36, Iain Sandoe wrote:
>> Hi
>> Some small code cleanups that allow us to have just one place that
>> we handle a statement with await expression(s) embedded. Also we
>> can reduce the work done to figure out whether a
> On Sep 11, 2021, at 3:03 AM, Jakub Jelinek wrote:
>
> Note, the gcc.dg/i386/auto-init* tests fail also, just don't have time to
> deal with that right now, just try
> make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
> i386.exp=auto-init*'
It’s strange that the above testing on
On 9/12/21 15:45, Patrick Palka wrote:
The r12-3346 patch makes us avoid computing excess argument conversions
during overload resolution, but only when it turns out there's a
strictly viable candidate in the overload set. If there is no such
candidate then we still need to compute more conversi
On 9/14/21 11:36, Iain Sandoe wrote:
Hi
Some small code cleanups that allow us to have just one place that
we handle a statement with await expression(s) embedded. Also we
can reduce the work done to figure out whether a statement contains
any such expressions.
tested on x86_64,powerpc64le-lin
> On Sep 15, 2021, at 11:55 AM, John David Anglin wrote:
>
> On 2021-09-15 10:06 a.m., Richard Biener wrote:
>>> Is there a simple way to enable -gstabs in build?
>> Currently not. If we're retaining more than pdp11 with a non-DWARF
>> config I'm considering to allow STABS by default for thos
On Sep 15, 2021, Alexandre Oliva wrote:
> Regstrapped on x86_64-linux-gnu. Patch pre-approved by Olivier Hainque.
Uhh, actually, Olivier had only seen and approved these changes:
> for gcc/ada/ChangeLog
> * gcc-interface/utils.c: Include opts.h.
> (handle_zero_call_used_regs_attr
On 15/09/2021 17:13, Christophe Lyon via Gcc-patches wrote:
On Wed, Sep 15, 2021 at 2:49 PM Richard Earnshaw via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
On 15/09/2021 13:26, Christophe LYON via Gcc-patches wrote:
On 15/09/2021 13:02, Richard Earnshaw wrote:
On 26/08/2021 16:53,
On 9/14/21 15:16, Patrick Palka wrote:
In grok_special_member_properties we need to set TYPE_HAS_COPY_CTOR,
TYPE_HAS_DEFAULT_CONSTRUCTOR and TYPE_HAS_LIST_CTOR independently
from each other because a single constructor can be both a default and
list constructor (as in the first testcase), or both
Make the zero_call_used_regs attribute usable as a Machine_Attribute
pragma.
Regstrapped on x86_64-linux-gnu. Patch pre-approved by Olivier Hainque.
for gcc/ada/ChangeLog
* gcc-interface/utils.c: Include opts.h.
(handle_zero_call_used_regs_attribute): New.
(gnat_inte
On Wed, Sep 15, 2021 at 5:39 PM Jason Merrill via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On Wed, Sep 15, 2021 at 11:37 AM Jeff Law wrote:
>
> >
> >
> > On 9/15/2021 9:31 AM, Jason Merrill via Gcc-patches wrote:
> > > Most any compilation on ARM/AArch64 was warning because the default L1
On Wed, Sep 15, 2021 at 2:49 PM Richard Earnshaw via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
>
>
> On 15/09/2021 13:26, Christophe LYON via Gcc-patches wrote:
> >
> > On 15/09/2021 13:02, Richard Earnshaw wrote:
> >>
> >>
> >> On 26/08/2021 16:53, Christophe Lyon via Gcc-patches wrote:
> >>>
On 2021-09-15 10:06 a.m., Richard Biener wrote:
>> Is there a simple way to enable -gstabs in build?
> Currently not. If we're retaining more than pdp11 with a non-DWARF
> config I'm considering to allow STABS by default for those without
> diagnostics for GCC 12.
>
> With GCC 13 we'll definitely
Hi.
In g:f23881fcf081a6edd538d6d54fa0068d716973d7 I replaced TARGET_* macros
with TARGET_CPU_P.
Pushed as obvious.
Martin
PR target/102351
gcc/ChangeLog:
* config/i386/vxworks.h: Use new macro TARGET_CPU_P.
---
gcc/config/i386/vxworks.h | 24
1 file c
On Wed, Sep 15, 2021 at 11:37 AM Jeff Law wrote:
>
>
> On 9/15/2021 9:31 AM, Jason Merrill via Gcc-patches wrote:
> > Most any compilation on ARM/AArch64 was warning because the default L1
> cache
> > line size of 32B was smaller than the default
> > std::hardware_constructive_interference_size o
On 9/15/2021 9:31 AM, Jason Merrill via Gcc-patches wrote:
Most any compilation on ARM/AArch64 was warning because the default L1 cache
line size of 32B was smaller than the default
std::hardware_constructive_interference_size of 64B. This is mostly due to
inaccurate --param l1-cache-line-siz
On 9/15/21 8:31 AM, Martin Liška wrote:
On 9/14/21 09:56, Christophe LYON via Gcc-patches wrote:
So adjustment is needed for both arm and aarch64 targets
Hello.
I noticed the same problem and I've got a patch candidate for it.
What do you think about it?
I've now silenced the warning for i
Most any compilation on ARM/AArch64 was warning because the default L1 cache
line size of 32B was smaller than the default
std::hardware_constructive_interference_size of 64B. This is mostly due to
inaccurate --param l1-cache-line-size, but it's not helpful to complain to a
user that didn't set th
Hello.
The patch is approved by David and fixes the issue described in the PR.
Martin
PR target/102349
gcc/ChangeLog:
* config/rs6000/rs6000.c (rs6000_xcoff_encode_section_info):
Check that we have a symbol summary for a symbol.
---
gcc/config/rs6000/rs6000.c | 1 +
1
Hi!
On 2021-09-10T09:10:23+0100, Jeremy Bennett wrote:
> The program for the GNU Tools Track at Linux Plumbers Conference is
> published:
>
> https://linuxplumbersconf.org/event/11/sessions/109/
Yay!
This may qualify "as obvious", but I better get reviewed what I change on
our front page to t
contrib/ChangeLog:
* gcc-changelog/git_commit.py: Check commit email.
* gcc-changelog/test_email.py: Add new test.
* gcc-changelog/test_patches.txt: Likewise.
---
contrib/gcc-changelog/git_commit.py| 10 ++
contrib/gcc-changelog/test_email.py| 5 +
co
On Wed, Sep 15, 2021 at 6:18 AM David Edelsohn via Gcc-patches
wrote:
>
> Clement,
>
> GCC libffi cherry-picks / backports patches from upstream, but it does
> not maintain local patches, so we need to find another solution.
>
Please take a look at my libffi patches:
https://gcc.gnu.org/pipermai
Hi!
Please do not send patches as attachments to replies. Each patch (or
patch series) starts its own thread. New versions of patches (or patch
series) are new threads.
> From: Xionghu Luo
> Date: Tue, 27 Apr 2021 01:07:25 -0500
> Subject: [PATCH 1/2] rs6000: Fix wrong code generation for vec_
There is no need to add [PATCH N/4] in the first line of the git
commit message. "git format-patch" or "git send-email" will
add them automatically.
On Wed, Sep 15, 2021 at 1:10 AM wrote:
>
> From: "H.J. Lu"
>
> 1. Replace TARGET_SSE_PARTIAL_REG_DEPENDENCY with
> TARGET_SSE_PARTIAL_REG_FP_CONVE
This adds the capability to analyze the dependence of mixed
pointer/array accesses. The example is from where using a masked
load/store creates the pointer-based access when an otherwise
unconditional access is array based. Other examples would include
accesses to an array mixed with accesses fro
On Wed, 15 Sep 2021, John David Anglin wrote:
> On 2021-09-15 2:26 a.m., Richard Biener wrote:
> >> I believe the 32-bit SOM target should be deprecated. I'm the only one
> >> maintaining it and I had some health issues earlier this year.
> >> The current versions should suffice for several year
This fixes a similar issue for powerpc-lynxos as fixed for i686-lynxos
already.
Build-tested for powerpc-lynxos.
2021-09-15 Richard Biener
PR target/102348
* config/rs6000/lynx.h: Remove undef of PREFERRED_DEBUGGING_TYPE
to inherit from elfos.h
---
gcc/config/rs6000/l
On 2021-09-15 2:26 a.m., Richard Biener wrote:
>> I believe the 32-bit SOM target should be deprecated. I'm the only one
>> maintaining it and I had some health issues earlier this year.
>> The current versions should suffice for several years.
> Do you think it's worth keeping the 32bit pa hpux
Clement,
GCC libffi cherry-picks / backports patches from upstream, but it does
not maintain local patches, so we need to find another solution.
Thanks, David
On Wed, Sep 15, 2021 at 9:14 AM CHIGOT, CLEMENT wrote:
>
> Hi David,
>
> The problem is that it has no meaning in libffi itself...
> Thi
On Wed, Sep 15, 2021 at 4:41 AM Kewen.Lin wrote:
>
> Hi,
>
> Gentle ping this patch:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578553.html
>
>
> BR,
> Kewen
>
> on 2021/9/1 下午2:56, Kewen.Lin via Gcc-patches wrote:
> > Hi!
> >
> > Option toc-fusion was intended for Power9 toc fus
Hi David,
The problem is that it has no meaning in libffi itself...
This patch is specific to gcc because the multilib part is specific
to gcc.
I'll ask the community but the patch cannot be merged inside
libffi.
Thanks,
Clément
From: David Edelsohn
Sent: Wednesd
Hi, Xionhu
Should "altivec_vsel2" .. 3 .. 4 be "*altivec_vsel2", etc.
because they are combiner patterns and never referenced by name? Only
the first, named pattern is referenced by the builtin code.
Other than that question / suggestion, this patch is okay. Please
coordinate with Bill and his
Hello.
I noticed the change likely caused the following failure when building
x86_64-linux-gnu cross compiler:
g++ -fno-PIE -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwri
Clement,
GCC is not the primary repository for libffi. This patch must be
submitted to the libffi project first, not GCC. If it is accepted in
libffi, then you can ask for a backport to GCC.
https://github.com/libffi/libffi
Thanks, David
On Wed, Sep 15, 2021 at 7:20 AM CHIGOT, CLEMENT wrote:
Hi,
since this is inlining-related, I would somewhat prefer Honza to have a
look too, but I have the following comments:
On Wed, Sep 08 2021, Kewen.Lin wrote:
>
[...]
> diff --git a/gcc/ipa-fnsummary.h b/gcc/ipa-fnsummary.h
> index 78399b0b9bb..300b8da4507 100644
> --- a/gcc/ipa-fnsummary.h
> +
On 15/09/2021 13:26, Christophe LYON via Gcc-patches wrote:
On 15/09/2021 13:02, Richard Earnshaw wrote:
On 26/08/2021 16:53, Christophe Lyon via Gcc-patches wrote:
g++.dg/eh/arm-vfp-unwind.C uses an asm statement relying on
double-precision FPU support, but does not make sure it is actua
On 9/14/21 09:56, Christophe LYON via Gcc-patches wrote:
So adjustment is needed for both arm and aarch64 targets
Hello.
I noticed the same problem and I've got a patch candidate for it.
What do you think about it?
MartinFrom 2ecedfe5cc421dd36f5770b04553343ecebd3430 Mon Sep 17 00:00:00 2001
F
On 15/09/2021 13:02, Richard Earnshaw wrote:
On 26/08/2021 16:53, Christophe Lyon via Gcc-patches wrote:
g++.dg/eh/arm-vfp-unwind.C uses an asm statement relying on
double-precision FPU support, but does not make sure it is actually
supported by the target.
Check (__ARM_FP & 8) to ensure thi
On Wed, Sep 15, 2021 at 12:25 PM Richard Earnshaw via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
>
>
> On 14/09/2021 08:56, Christophe LYON via Gcc-patches wrote:
> >
> > On 10/09/2021 15:16, Jason Merrill via Gcc-patches wrote:
> >> OK, time to finish this up. The main change relative to the
Even if GCC64 is able to bootstrap without libffi being a
FAT library on AIX, the tests for "-maix32" are not working
without it.
libffi/ChangeLog:
2021-09-10 Clément Chigot
* Makefile.am (tmake_file): Build and install AIX-style FAT
libraries.
* Makefile.in: Regenera
Thank you for reviewing the patches! I will address your comments and
push the patches after testing.
Thanks again,
Daniel
On 2021-09-15 12:18, Eric Botcazou wrote:
The LEON5 can often dual issue instructions from the same 64-bit aligned
double word if there are no data dependencies. Add sched
On 26/08/2021 16:53, Christophe Lyon via Gcc-patches wrote:
g++.dg/eh/arm-vfp-unwind.C uses an asm statement relying on
double-precision FPU support, but does not make sure it is actually
supported by the target.
Check (__ARM_FP & 8) to ensure this.
2021-08-26 Christophe Lyon
gcc/
> gcc/ChangeLog:
>
> * config/sparc/sparc.md: Add NOP to prevent sensitive sequence for
> B2BST errata workaround.
OK everywhere, but the ChangeLog entry should be:
* config/sparc/sparc.md (stack_protect_set32): Add NOP...
Note that it's stack_protect_set32 on mainline a
> gcc/ChangeLog:
>
> * config/sparc/sparc.c (sparc_do_work_around_errata): Do not begin
> functions with atomic instruction in the UT700 errata workaround.
OK everywhere.
--
Eric Botcazou
> gcc/ChangeLog:
>
> * config/sparc/sparc.c (next_active_non_empty_insn): New function
> that returns next active non empty assembly instruction.
> (sparc_do_work_around_errata): Use new function.
OK everywhere, modulo a couple of nits:
> +rtx_insn *
> +next_active_non_em
On 14/09/2021 08:56, Christophe LYON via Gcc-patches wrote:
On 10/09/2021 15:16, Jason Merrill via Gcc-patches wrote:
OK, time to finish this up. The main change relative to the last
patch I sent
to the list is dropping the -finterference-tune flag and making that
behavior
the default. A
> gcc/ChangeLog:
>
> * config/sparc/sparc.c (store_insn_p): Add predicate for store
> attributes.
> (load_insn_p): Add predicate for load attributes.
> (sparc_do_work_around_errata): Use new predicates.
OK everywhere on principle, but can we avoid the multiple call
> gcc/ChangeLog:
>
> * config/sparc/sparc.c (dump_target_flag_bits): Print bit names for
> LEON and LEON3.
OK everywhere.
--
Eric Botcazou
> The LEON5 can often dual issue instructions from the same 64-bit aligned
> double word if there are no data dependencies. Add scheduling information
> to avoid scheduling unpairable instructions back-to-back.
>
> gcc/ChangeLog:
>
> * config/sparc/sparc-opts.h (enum sparc_processor_type)
Richard Biener via Gcc-patches writes:
> On Wed, 15 Sep 2021, Richard Sandiford wrote:
>> Richard Biener writes:
>> > On Tue, 14 Sep 2021, Richard Sandiford wrote:
>> >
>> >> Richard Biener via Gcc-patches writes:
>> >> > This changes us to maintain and compute (mis-)alignment info for
>> >> > t
On Wed, 15 Sep 2021, Richard Sandiford wrote:
> Richard Biener writes:
> > On Tue, 14 Sep 2021, Richard Sandiford wrote:
> >
> >> Richard Biener via Gcc-patches writes:
> >> > This changes us to maintain and compute (mis-)alignment info for
> >> > the first element of a group only rather than fo
Hi:
The optimization is decribled in PR.
Bootstrapped and regtest on x86_64-linux-gnu{-m32,}.
All avx512fp16 runtest cases passed on SPR.
gcc/ChangeLog:
PR target/102327
* config/i386/i386-expand.c
(ix86_expand_vector_init_interleave): Use puncklwd to pack 2
This is needed to prevent the Store -> (Non-store or load) -> Store
sequence.
gcc/ChangeLog:
* config/sparc/sparc.md: Add NOP to prevent sensitive sequence for
B2BST errata workaround.
---
gcc/config/sparc/sparc.md | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
A call to the function might have a load instruction in the delay slot
and a load followed by an atomic function could cause a deadlock.
gcc/ChangeLog:
* config/sparc/sparc.c (sparc_do_work_around_errata): Do not begin
functions with atomic instruction in the UT700 errata workarou
The LEON5 can often dual issue instructions from the same 64-bit aligned
double word if there are no data dependencies. Add scheduling information
to avoid scheduling unpairable instructions back-to-back.
gcc/ChangeLog:
* config/sparc/sparc-opts.h (enum sparc_processor_type): Add LEON5
This version detects multiple empty assembly statements in a row and also
detects non-memory barrier empty assembly statements (__asm__("")). It
can be used instead of next_active_insn().
gcc/ChangeLog:
* config/sparc/sparc.c (next_active_non_empty_insn): New function
that returns
Check the attribute of instruction to determine if it performs a store
or load operation. This more generic approach sees the last instruction
in the GOTdata_op model as a potential load and treats the memory barrier
as a potential store instruction.
gcc/ChangeLog:
* config/sparc/sparc.c
From: Andreas Larsson
gcc/ChangeLog:
* config/sparc/sparc.c (dump_target_flag_bits): Print bit names for
LEON and LEON3.
---
gcc/config/sparc/sparc.c | 4
1 file changed, 4 insertions(+)
diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index 06f41d7bb53..d5
This refines the fix for PR102226 to do the mode conversion
from V2DI to VNx2DI separately from the sign-conversion, retaining
the signedness of the saved accumulator as before the original fix.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-09-15 Richard Biener
PR t
On Tue, Sep 14, 2021 at 11:13 PM Dimitar Dimitrov wrote:
>
> Hi,
>
> I'm sending this patch to get feedback for a new PRU CPU port feature.
> My intention is to push it to master by end of September, so that it gets
> included in GCC 12.
>
> The PRU architecture provides single-cycle access to GPI
On Wed, 1 Sept 2021 at 10:52, Jonathan Wakely wrote:
>
> On Wed, 1 Sept 2021 at 02:44, Jonathan Yong <10wa...@gmail.com> wrote:
> >
> > On 8/31/21 9:02 AM, Jonathan Wakely wrote:
> > > It looks like my questions about this patch never got an answer, and
> > > it never got applied.
> > >
> > > Coul
Hi,
This patch follows the discussion here[1], where Segher suggested
parameterizing those exact magic constants for density heuristics,
to make it easier to tweak if need.
Since these heuristics are quite internal, I make these parameters
as undocumented and be mainly used by developers.
The ch
Jiufu Guo writes:
I may want to have a gentle ping on this.
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578680.html
BR,
Jiufu
> Changes on V1:
> * Add more test case
> * Add comment for exit-condition transform
> * Removing duplicate setting on niter->control
>
> This patch reset n
Hello.
The patch extends the loop unswitching pass so that gswitch
statements are supported. The pass now uses ranger which marks
switch edges that are known to be unreachable in a versioned loop.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Than
Hi!
Gentle ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578552.html
BR,
Kewen
on 2021/9/1 下午2:55, Kewen.Lin via Gcc-patches wrote:
> Hi!
>
> This patch is to fix the inconsistent behaviors for non-LTO mode
> and LTO mode. As Martin pointed out, currently the funct
Hi,
Gentle ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578553.html
BR,
Kewen
on 2021/9/1 下午2:56, Kewen.Lin via Gcc-patches wrote:
> Hi!
>
> Option toc-fusion was intended for Power9 toc fusion previously,
> but Power9 doesn't support fusion at all eventually, thi
Hi Richard,
Don't we still need this code (without the REG_DEAD handling) for the
case in which…
+ /* As we are transforming
+if (x > y)
+ {
+a = b;
+c = d;
+ }
+into
+ a = (x > y) ...
+ c = (x > y) ...
+
+
Hi!
On 2021-09-14T14:25:20+0200, Tobias Burnus wrote:
> I have created a testcase with all missing ST_OMP_END_* and ST_OACC_END_*;
> I am not quite sure why a different code path is triggered for some, but
> at least here is now a parse check for all.
At least the OpenACC one is explained easily
As gcc on 64bit for AIX is built with "MULTILIB_MATCHES= .=maix32",
"-print-multi-directory" and similar flags aren't returning the
correct directory when used with -maix32: "." is returned instead
of "ppc32".
Libgcc installation script needs to be adjust to bypass this
problem and correctly instal
From: "H.J. Lu"
Check TARGET_USE_VECTOR_FP_CONVERTS or TARGET_USE_VECTOR_CONVERTS when
handling avx_partial_xmm_update attribute. Don't convert AVX partial
XMM register update if vector packed SSE conversion should be used.
gcc/
PR target/101900
* config/i386/i386-features.c (r
1 - 100 of 107 matches
Mail list logo
