On Tue, Sep 20, 2022 at 4:24 AM liuhongt via Gcc-patches
wrote:
>
> The codes in vectorizable_induction for slp_node assume all phi_info
> have same induction type(vect_step_op_add), but since we support
> nonlinear induction, it could be wrong handled.
> So the patch return false when slp_node ha
On Tue, Sep 20, 2022 at 9:18 AM Surya Kumari Jangala via Gcc-patches
wrote:
>
> Hi Jeff, Richard,
> Thank you for reviewing the patch!
> I have committed the patch to the gcc repo.
> Can I backport this patch to prior versions of gcc, as this is an easy patch
> to backport and the issue exists in
On Tue, Sep 20, 2022 at 2:55 PM Martin Liška wrote:
>
> On 7/1/22 09:20, Fangrui Song via Gcc-patches wrote:
> > On 2022-07-01, Andrew Pinski wrote:
> >> On Thu, Jun 30, 2022 at 11:58 PM Fangrui Song via Gcc-patches
> >> wrote:
> >>>
> >>> From: Fangrui Song
> >>>
> >>> SHF_COMPRESSED style zlib
On Tue, Sep 20, 2022 at 8:23 PM Aldy Hernandez via Gcc-patches
wrote:
>
> Undefined ranges have undefined NAN bits. We can't depend on them,
> as they may contain garbage.
Ick ;) Can you add a comment at least?
> This patch returns false from
> maybe_isnan() for undefined ranges (the empty set
On Wed, Sep 21, 2022 at 1:41 AM liuhongt via Gcc-patches
wrote:
>
> When init_expr is INTEGER_CST or REAL_CST, can_vec_perm_const_p is not
> necessary since there's no real vec_perm needed, but
> vec_gen_perm_mask_checked will gcc_assert (can_vec_perm_const_p). So
> it's better to use vec_gen_perm
On Wed, Sep 21, 2022 at 3:41 PM Richard Biener via Gcc-patches
wrote:
>
> On Wed, Sep 21, 2022 at 1:41 AM liuhongt via Gcc-patches
> wrote:
> >
> > When init_expr is INTEGER_CST or REAL_CST, can_vec_perm_const_p is not
> > necessary since there's no real vec_perm needed, but
> > vec_gen_perm_mask
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
The header should be included explicitly to use std::initializer_list.
With the upcoming changes to make available for freestanding
this becomes an error, because is no longer provided
by any of the other headers involved here.
libstdc++-v3/C
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
When I added std::_Exit to the freestanding declarations in I
should also have added it to .
libstdc++-v3/ChangeLog:
* include/c_compatibility/stdlib.h [!_GLIBCXX_HOSTED]: Add
using-declaration for _Exit.
---
libstdc++-v3/inc
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/documentation_hacking.xml: Remove trailing
whitespace.
* doc/xml/manual/policy_data_structures.xml: Likewise.
---
.../doc/xml/manual/documentation_hacking.xml | 4 ++--
Hi Tom,
I had a patch submitted earlier, where I reported that the current way of
implementing
barriers in libgomp on nvptx created a quite significant performance drop on
some SPEChpc2021
benchmarks:
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600818.html
That previous patch wasn'
Hi Tom, following the first patch.
This new barrier implementation I posted in the first patch uses the 'bar.red'
instruction.
Usually this could've been easily done with a single line of inline assembly.
However I quickly
realized that because the NVPTX GCC port is implemented with all virtual
On Wed, Sep 21, 2022 at 12:37 AM Richard Biener
wrote:
>
> On Tue, Sep 20, 2022 at 2:55 PM Martin Liška wrote:
> >
> > On 7/1/22 09:20, Fangrui Song via Gcc-patches wrote:
> > > On 2022-07-01, Andrew Pinski wrote:
> > >> On Thu, Jun 30, 2022 at 11:58 PM Fangrui Song via Gcc-patches
> > >> wrote:
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
This test includes so should use std::abort not ::abort.
libstdc++-v3/ChangeLog:
* testsuite/18_support/uncaught_exception/14026.cc: Qualify
call to std::abort.
---
libstdc++-v3/testsuite/18_support/uncaught_exception/14026.c
On 9/21/22 09:36, Richard Biener wrote:
> If it's all configure time what's the point in
> "deprecating" it?
Note it's one of our options -gz where 'zlib-gnu' is one of the possible option
values.
Martin
The reason the flags were uninitialized was because they were unused,
similarly for m_type. But you're right, it is icky and prone to bugs.
I just thought it was cheap to set_undefined by just flipping
m_kind=VR_UNDEFINED, but it smells like premature optimization.
How about this?
Aldy
On Wed,
Hi all,
ping^2 for patches 9/15 7/15 11/15 12/15 and 10/15 V2 of this series.
Andrea
I forgot to include the gfortran.map part of the patch, and so the test failed
on platforms that have symbol versioning.
Fix below committed to master.
FX
commit ce8aed75a38b468490ecab4c318e3eb08d468608 (HEAD -> master)
Author: Francois-Xavier Coudert
Date: 2022-09-21 10:04:22 +0200
Fo
On Wed, Sep 21, 2022 at 03:45:36PM +0800, Chung-Lin Tang via Gcc-patches wrote:
> Hi Tom,
> I had a patch submitted earlier, where I reported that the current way of
> implementing
> barriers in libgomp on nvptx created a quite significant performance drop on
> some SPEChpc2021
> benchmarks:
> ht
Since NANs can be inserted by other passes even for -ffinite-math-only,
we can't depend on the flag to determine if a NAN is a possiblity.
Instead, we must explicitly check for them.
In the case of -ffinite-math-only, paths leading up to a NAN are
undefined and can be considered unreachable. I ha
Hi all,
We have received requests to improve the out-of-the box experience and
performance of AArch64 GCC users, particularly those porting software from other
architectures. This has many aspects. One such aspect are apps built natively
with an -march=native used as a tuning flag in the Makefile.
Follow-up patch, including a test, committed as attached.
FX
0001-Fortran-handle-RADIX-kind-in-IEEE_SET_ROUNDING_MODE.patch
Description: Binary data
> Thank you. Can you please also add a testcase that tests for this.
> So you modify imagemagick marking attribute hot on the specific inline?
Thanks Honza. Added the testcase. I didn't modify source code of 538.imagic_r,
the original source code has attribute like:
#define magick_hot_spot __a
Hi Haochen,
on 2022/6/24 10:02, HAO CHEN GUI wrote:
> Hi,
> This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
> Tests show that outputs of xs[min/max]dp are consistent with the standard
> of C99 fmin/max.
>
> This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max
On Wed, Sep 21, 2022 at 9:49 AM Martin Liška wrote:
>
> On 9/21/22 09:36, Richard Biener wrote:
> > If it's all configure time what's the point in
> > "deprecating" it?
>
> Note it's one of our options -gz where 'zlib-gnu' is one of the possible
> option values.
I see. Not sure if deprecating i
On Wed, Sep 21, 2022 at 9:52 AM Aldy Hernandez wrote:
>
> The reason the flags were uninitialized was because they were unused,
> similarly for m_type. But you're right, it is icky and prone to bugs.
> I just thought it was cheap to set_undefined by just flipping
> m_kind=VR_UNDEFINED, but it sme
Pushed to wwwdocs.
---
htdocs/gcc-13/changes.html | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 390193ca..a7d88038 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -158
Finding the docs for the GCC-specific diagnostic formats isn't easy.
This might help.
OK for wwwdocs?
---
htdocs/codingconventions.html | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
index e4d30510..f1d1f165 100
ping*2
0001-Add-__builtin_iseqsig.patch
Description: Binary data
> Le 9 sept. 2022 à 19:55, FX a écrit :
>
> ping
>
>
>> Le 1 sept. 2022 à 23:02, FX a écrit :
>>
>> Attached patch adds __builtin_iseqsig() to the middle-end and C family
>> front-ends.
>> Testing does not currently check
Hi Harald,
I think I understand much of what is said, but I feel that I do
not really understand what *clobber* means for the different
beasts we are discussing (although I have an impression of what
it means for a scalar object).
Obviously, "clobber" means taking a big stick and hitting the
On 2022/9/21 5:01 PM, Jakub Jelinek wrote:
On Wed, Sep 21, 2022 at 03:45:36PM +0800, Chung-Lin Tang via Gcc-patches wrote:
Hi Tom,
I had a patch submitted earlier, where I reported that the current way of
implementing
barriers in libgomp on nvptx created a quite significant performance drop
On Mon, 19 Sep 2022, Andrew MacLeod wrote:
> Yeah, currently the internal cache isnt really wired into the fold_using_range
> as its is suppose to be a consistent internal state. so its not currently
> expecting to work in a situation here what it thinks is global state might
> change.
>
> I fig
The following adjusts a missed spot in TSAN for the RHS COND_EXPR
GIMPLE IL rework.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/106984
* tsan.cc (instrument_builtin_call): Build the COND_EXPR condition in
a separate statement.
On platforms that support multiarch, such as Debian,
the filesystem hierarchy doesn't fellow the old Irix style:
lib & lib/ for native
lib64 for N64 on N32/O32 systems
lib32 for N32 on N64/O32 systems
libo32 for O32 on N64/N32 systems
Thus we cannot
#define STANDAR
Richard, this is what you suggested. Thanks.
Explicit NANs in the IL can be treated as undefined for
flag_finite_math_only. This causes all the right things to happen wrt
threading, folding, etc. It also saves us special casing throughout.
It occurs to me that we should do something similar fo
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* testsuite/20_util/headers/memory/synopsis.cc: Add declarations
from C++11 and later.
---
.../20_util/headers/memory/synopsis.cc| 66 +--
1 file changed, 59 insertions(+), 7 dele
Tested x86_64-linux, pushed to trunk.
-- >8 --
It looks like I committed the testcase for std::function twice, instead
of one for std::function and one for std::is_invocable_r. This replaces
the is_invocable_r one with the example from the PR.
libstdc++-v3/ChangeLog:
PR libstdc++/91456
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* testsuite/17_intro/headers/c++1998/all_attributes.cc: Remove
unnecessary main function.
* testsuite/17_intro/headers/c++2011/all_attributes.cc:
Likewise.
* testsuite/17_intro/hea
On Wed, 2022-09-21 at 11:31 +, YunQiang Su wrote:
> On platforms that support multiarch, such as Debian,
> the filesystem hierarchy doesn't fellow the old Irix style:
> lib & lib/ for native
> lib64 for N64 on N32/O32 systems
> lib32 for N32 on N64/O32 systems
>
On Wed, 21 Sep 2022, Xi Ruoyao wrote:
> > diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
> > index 74b6e11aabb..fe7f5b274b9 100644
> > --- a/gcc/config/mips/mips.h
> > +++ b/gcc/config/mips/mips.h
> > @@ -3427,6 +3427,7 @@ struct GTY(()) machine_function {
> >
> > /* If we are *n
With partial variable template specializations, it looks like we
stream the VAR_DECL (i.e. the DECL_TEMPLATE_RESULT of the corresponding
TEMPLATE_DECL) since process_partial_specialization adds it to the
specializations table, but end up never streaming the corresponding
TEMPLATE_DECL itself that a
Dear all,
I intend to commit the attached, obvious patch for a NULL pointer
dereference until tomorrow unless there are comments or objections.
We better skip initialization for a symbol which is an associate name.
Regtested on x86_64-pc-linux-gnu.
Thanks,
Harald
From 0259762271b2eb430e058b0bff
On 9/21/22 06:13, Richard Biener wrote:
On Mon, 19 Sep 2022, Andrew MacLeod wrote:
It looks like you created a fur_source to manually adjust PHIs within the
fold_stmt query to ignore edges that are not marked executable.
Yes, and use the current values from the VN lattice when looking at
st
Le 21/09/2022 à 11:57, Thomas Koenig a écrit :
Hi Harald,
I think I understand much of what is said, but I feel that I do
not really understand what *clobber* means for the different
beasts we are discussing (although I have an impression of what
it means for a scalar object).
Obviously, "cl
Hi Mikael,
Am 21.09.22 um 20:56 schrieb Mikael Morin:
Le 21/09/2022 à 11:57, Thomas Koenig a écrit :
Hi Harald,
I think I understand much of what is said, but I feel that I do
not really understand what *clobber* means for the different
beasts we are discussing (although I have an impression
I stopped my research to find out if those types ever existed in 2001.
Clearly they do not exist now.
libstdc++: Remove useless gdb printer registrations.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py: Remove printer
registration for non-existing
ty
Hi.
On the high level, I'd be highly uncomfortable with this. I guess we are in
vague agreement that it cannot be efficiently implemented. It also goes
against the good practice of accelerator programming, which requires queueing
work on the accelerator and letting it run asynchronously with the
If shadow stack is enabled, when unwinding stack, we count how many stack
frames we pop to reach the landing pad and adjust shadow stack by the same
amount. When counting the stack frame, we compare the return address on
normal stack against the return address on shadow stack. If they don't
match
On Wed, 21 Sept 2022 at 20:57, François Dumont via Libstdc++
wrote:
>
> I stopped my research to find out if those types ever existed in 2001.
> Clearly they do not exist now.
>
> libstdc++: Remove useless gdb printer registrations.
>
> libstdc++-v3/ChangeLog:
>
> * python/l
Dear all,
the patch for this PR was submitted for review by Jose here:
https://gcc.gnu.org/pipermail/fortran/2021-April/055934.html
but unfortunately was never reviewed.
I verified that it works on mainline and x86_64-pc-linux-gnu,
and I think that it is fine.
Although the above mail suggest
Hello,
Here is a patch that fixes an ICE in gfortran triggered by an invalid
end statement at the end of an OMP metadirective:
```
!$OMP metadirective ...
...
!$OMP end ...
```
Does this fix look correct?
Thanks,
--
Paul-Antoine ArrasFrom 73ecbc2672a5352a08260f7a9d0de6d2c29ea
Hi!
On Fri, Jun 24, 2022 at 10:02:19AM +0800, HAO CHEN GUI wrote:
> This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max instead
> of smin/max. So the builtins always generate xs[min/max]dp on all
> platforms.
But how does this not blow up with -ffast-math?
In the other direction I am
On Sat, Jul 9, 2022 at 8:59 AM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 6/21/2022 12:12 PM, Noah Goldstein via Gcc-patches wrote:
> > This patch allows for strchr(x, c) to the replace with memchr(x, c,
> > strlen(x) + 1) if strlen(x) has already been computed earlier in the
> > tree.
> >
> > Han
On Wed, Sep 7, 2022 at 10:03 AM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 9/2/2022 8:36 AM, H.J. Lu via Gcc-patches wrote:
> > CONCAT and CONCATN never appear in the insn chain. They are only used
> > in debug insn. Ignore debug insns with CONCAT and CONCATN for insn
> > scheduling to avoid dif
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Verify 526.blend_r can be rebuilt with the fix.
Ok for trunk?
gcc/ChangeLog:
PR target/106994
* config/i386/mmx.md (floorv2sf2): Fix typo, use
register_operand instead of vector_operand for operands[1].
gcc/testsu
On Thu, Sep 22, 2022 at 9:17 AM liuhongt wrote:
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Verify 526.blend_r can be rebuilt with the fix.
>
> Ok for trunk?
>
> gcc/ChangeLog:
>
> PR target/106994
> * config/i386/mmx.md (floorv2sf2): Fix typo, use
> reg
Hi,
PR100645 exposes one latent bug in define_expand vec_shr_
that the current condition TARGET_ALTIVEC is too loose. The
mode iterator VEC_L contains a few modes, they are not always
supported as vector mode, VECTOR_UNIT_ALTIVEC_OR_VSX_P should
be used like some other VEC_L usages.
Bootstrappe
Hi,
As PR96072 shows, the code adding REG_CFA_DEF_CFA reg note
makes one assumption that we have emitted one insn which
restores the frame pointer previously. That part of code
was guarded with flag frame_pointer_needed before, it was
consistent, but later it was replaced with flag
frame_pointer_
on 2022/9/22 05:56, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Jun 24, 2022 at 10:02:19AM +0800, HAO CHEN GUI wrote:
>> This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max instead
>> of smin/max. So the builtins always generate xs[min/max]dp on all
>> platforms.
>
> But how does this
On 9/14/22 12:12, Jakub Jelinek wrote:
If it is pure optimization thing and purely keyed on the definition,
all the simd clones should be local to the TU, never exported from it.
OK, here is a revised patch that addresses that. x86_64 target also
generates a different set of clones for funct
Hello Harald,
the patch for this PR was submitted for review by Jose here:
https://gcc.gnu.org/pipermail/fortran/2021-April/055934.html
but unfortunately was never reviewed.
I verified that it works on mainline and x86_64-pc-linux-gnu,
and I think that it is fine.
Although the above mail
On Thu, Sep 22, 2022 at 3:18 AM liuhongt via Gcc-patches
wrote:
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Verify 526.blend_r can be rebuilt with the fix.
>
> Ok for trunk?
This patch is OK as obvious.
Thanks,
Uros.
> gcc/ChangeLog:
>
> PR target/106994
> *
Hi all,
I would like to backport this patch to GCC 12 release branch as machines with
the version of default GCC
is 12.x (which is always using newer kernels), if the patch is not backported,
the amx tests will always fail.
Ok for backport?
BRs,
Haochen
> -Original Message-
> From: Ur
> -Original Message-
> From: Jiang, Haochen
> Sent: Thursday, September 22, 2022 2:23 PM
> To: Uros Bizjak
> Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao
> Subject: RE: [PATCH] i386: Add syscall to enable AMX for latest kernels
>
> Hi all,
>
> I would like to backport this patch to GCC
On Wed, 21 Sep 2022, Andrew MacLeod wrote:
>
> On 9/21/22 06:13, Richard Biener wrote:
> > On Mon, 19 Sep 2022, Andrew MacLeod wrote:
> >
> >
> >> It looks like you created a fur_source to manually adjust PHIs within the
> >> fold_stmt query to ignore edges that are not marked executable.
> > Yes
From: Ju-Zhe Zhong
This patch fix issue: PR 99407
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99407
The enhancement implementation is simple:
1.Search gimple statement in program reverse order.
2.Queue the store statement which may be possible kill the def
of previous store statement.
3.Perfo
65 matches
Mail list logo
