On Tue, 22 Feb 2022, Hongtao Liu wrote:
> On Mon, Feb 21, 2022 at 5:10 PM Richard Biener wrote:
> >
> > On Mon, 21 Feb 2022, Hongtao Liu wrote:
> >
> > > On Fri, Feb 18, 2022 at 10:01 PM Richard Biener via Gcc-patches
> > > wrote:
> > > >
> > > > This uses the now passed SLP node to the
On Tue, Feb 22, 2022 at 5:01 AM Zhao Wei Liew via Gcc-patches
wrote:
>
> On Tue, 22 Feb 2022 at 11:57, Zhao Wei Liew wrote:
> >
> > Hi,
> >
> > This is a partial optimization for PR103855.
> >
> > Initially, I looked into optimizing RTL generation or a more complex
> > GIMPLE transformation so
On Tue, 22 Feb 2022, Jiufu Guo wrote:
> Hi,
>
> For constants, there are some codes to check: if it is able to put
> to instruction as an immediate operand or it is profitable to load from
> mem. There are still some places that could be improved for platforms.
>
> This patch could handle
Hi,
For constants, there are some codes to check: if it is able to put
to instruction as an immediate operand or it is profitable to load from
mem. There are still some places that could be improved for platforms.
This patch could handle PR63281/57836. This patch does not change
too much on
Hi Uros,
This patch is to update Intel architectures ISA support in documentation.
Since the ISA supported by Intel architectures in the documentation
are inconsistent with the actual, modify them all.
OK for master?
gcc/Changelog:
* gcc/doc/invoke.texi: Update documents for Intel
Hello,
Can you please review the patch and let me know the feedback?
Thanks,
Sundeep K.
-Original Message-
From: sundeep.kokko...@gmail.com
Sent: Friday, February 4, 2022 9:30 AM
To: 'Andrew Pinski'
Cc: 'GCC Patches'
Subject: RE: [PATCH] Fix for GCC '-MF' option cannot deal with
On Mon, Feb 21, 2022 at 5:10 PM Richard Biener wrote:
>
> On Mon, 21 Feb 2022, Hongtao Liu wrote:
>
> > On Fri, Feb 18, 2022 at 10:01 PM Richard Biener via Gcc-patches
> > wrote:
> > >
> > > This uses the now passed SLP node to the vectorizer costing hook
> > > to adjust vector construction
On Tue, 22 Feb 2022 at 11:57, Zhao Wei Liew wrote:
>
> Hi,
>
> This is a partial optimization for PR103855.
>
> Initially, I looked into optimizing RTL generation or a more complex
> GIMPLE transformation so that we could optimize other cases as well,
> such as ((unsigned long long) short / int).
Hi,
This is a partial optimization for PR103855.
Initially, I looked into optimizing RTL generation or a more complex
GIMPLE transformation so that we could optimize other cases as well,
such as ((unsigned long long) short / int).
However, that is a bit too complex for now. While I continue to
On Tue, Feb 22, 2022 at 12:46 AM Jakub Jelinek wrote:
>
> Hi!
>
> We ICE on the following testcase for -m32 since r12-3435. because
> operands[2] is (subreg:SF (reg:DI ...) 0) and
According to validate_subreg, (subreg:V4SF (reg:DI ...) 0) should be
valid(but not sure if it really works )
For
Hi,
As PR104024 shows, currently the option -mpower10-fusion isn't guarded
under -mcpu=power10, so compiler can optimize some patterns unexpectedly.
As the option is undocumented, this patch just simply unmasks it.
For some define_insns in fusion.md which have constraint v, they don't
have the
On Tue, Feb 22, 2022 at 2:35 AM H.J. Lu wrote:
>
> On Sun, Feb 20, 2022 at 6:01 PM Hongtao Liu wrote:
> >
> > On Thu, Feb 17, 2022 at 9:56 PM H.J. Lu wrote:
> > >
> > > On Thu, Feb 17, 2022 at 08:51:31AM +0100, Uros Bizjak wrote:
> > > > On Thu, Feb 17, 2022 at 6:25 AM Hongtao Liu via
on 2022/2/22 上午9:11, HAO CHEN GUI wrote:
>
> Kewen,
> Thanks so much for your advice.
>
> On 21/2/2022 下午 5:42, Kewen.Lin wrote:
>> Hi Haochen,
>>
>> Some minor comments are inlined.
>>
>> on 2022/2/16 下午4:42, HAO CHEN GUI via Gcc-patches wrote:
>>> Hi,
>>>This patch enables absolute jump
Kewen,
Thanks so much for your advice.
On 21/2/2022 下午 5:42, Kewen.Lin wrote:
> Hi Haochen,
>
> Some minor comments are inlined.
>
> on 2022/2/16 下午4:42, HAO CHEN GUI via Gcc-patches wrote:
>> Hi,
>>This patch enables absolute jump tables on PPC AIX and Linux. For AIX,
>> the jump
>>
From: Sören Tempel
Since commit c163647ffbc9a20c8feb6e079dbecccfe016c82e -fsplit-stack
is only supported on glibc targets. However, this original commit
required some fixups. As part of the fixup, the changes to the
gnu-user-common.h and gnu.h were partially reverted in commit
Dear Fortranners,
a recently introduced shape validation for an array constructor
against the declared shape of a DT component failed to punt if
the shape of the constructor cannot be determined at compile time.
Suggested solution: skip the shape check in those cases.
Regtested on
On 21/02/22 21:54, Jonathan Wakely wrote:
On Mon, 21 Feb 2022 at 18:00, François Dumont via Libstdc++
mailto:libstdc%2b...@gcc.gnu.org>> wrote:
Gentle reminder, it is important to have this for gcc 12.
Well, it's been broken since 4.8, so another year wouldn't be the end
of the world
Also adjust DejaGnu directives, as specifically requiring "powerpc*-*-*" is no
longer required.
2021-02-21 Paul A. Clarke
gcc/testsuite
* g++.dg/debug/dwarf2/const2.C: Move to g++.target/powerpc.
* g++.dg/other/darwin-minversion-1.C: Likewise.
*
On Sun, Feb 20, 2022 at 2:13 PM Rainer Orth
wrote:
>
> > This patch updates libgo to the Go1.18rc1 release. Bootstrapped and
> > ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
>
> this broke Solaris bootstrap:
>
> ld: fatal: file runtime/internal/.libs/syscall.o: open failed:
Also adjust DejaGnu directives, as specifically requiring "powerpc*-*-*" is no
longer required.
2021-02-21 Paul A. Clarke
gcc/testsuite
* g++.dg/ext/altivec-1.C: Move to g++.target/powerpc, adjust dg
directives.
* g++.dg/ext/altivec-2.C: Likewise.
*
Also adjust DejaGnu directives, as specifically requiring "powerpc*-*-*" is no
longer required.
2021-02-21 Paul A. Clarke
gcc/testsuite
* g++.dg/pr65240.h: Move to g++.target/powerpc.
* g++.dg/pr93974.C: Likewise.
* g++.dg/pr65240-1.C: Move to g++.target/powerpc,
Some tests in g++.dg are target-specific for powerpc. Move those to
g++.target/powerpc. Update the DejaGnu directives as needed, since
the target restriction is perhaps no longer needed when residing in the
target-specific powerpc subdirectory.
Tested with Linux on Power9, full "make check".
OK
On Mon, 21 Feb 2022 at 19:39, Patrick Palka via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
OK, thanks.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/ranges_base.h (__detail::__is_initializer_list):
> Define.
>
On Mon, 21 Feb 2022 at 18:00, François Dumont via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Gentle reminder, it is important to have this for gcc 12.
>
Well, it's been broken since 4.8, so another year wouldn't be the end of
the world ;-)
I did start reviewing it, but I was trying to find a
Dan Li writes:
> Shadow Call Stack can be used to protect the return address of a
> function at runtime, and clang already supports this feature[1].
>
> To enable SCS in user mode, in addition to compiler, other support
> is also required (as discussed in [2]). This patch only adds basic
>
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (__detail::__is_initializer_list):
Define.
(viewable_range): Adjust as per P2415R2.
* include/std/ranges (owning_view): Define as per P2415R2.
On Mon, Feb 21, 2022 at 6:33 PM Jakub Jelinek wrote:
>
> On Mon, Feb 21, 2022 at 06:01:00PM +0100, Uros Bizjak wrote:
> > I remember the same issue in the past, so it looks like the fresh
> > pseudo as destination gives RA some more freedom to do its magic. So,
> > it is better to do:
> >
> >
Hi Jakub,
On 21.02.22 18:47, Jakub Jelinek wrote:
Where ME is involved is
!$omp requires atomic_default_mem_order(whatever) vs.
!$omp declare variant ...atomic_default_mem_order(whatever).
Ups, missed that case. (Also because there wasn't 'declare variant' when
implementing 'requires' in
On Sun, Feb 20, 2022 at 6:01 PM Hongtao Liu wrote:
>
> On Thu, Feb 17, 2022 at 9:56 PM H.J. Lu wrote:
> >
> > On Thu, Feb 17, 2022 at 08:51:31AM +0100, Uros Bizjak wrote:
> > > On Thu, Feb 17, 2022 at 6:25 AM Hongtao Liu via Gcc-patches
> > > wrote:
> > > >
> > > > On Thu, Feb 17, 2022 at 12:26
On 2/21/2022 3:55 AM, Richard Biener via Gcc-patches wrote:
On Mon, Feb 21, 2022 at 9:31 AM Roger Sayle wrote:
Hi Marc,
I'm assuming that the use (semantics) of a REDUC_PLUS expr allow the
reduction to be done in any order, for example the testcase requires
-ffast-math to allow the
Christophe Lyon writes:
> diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
> index 9c645722230..dd537ec1679 100644
> --- a/gcc/config/arm/arm-builtins.c
> +++ b/gcc/config/arm/arm-builtins.c
> @@ -1553,11 +1553,25 @@ arm_init_simd_builtin_types (void)
>tree
Gentle reminder, it is important to have this for gcc 12.
On 15/02/22 10:05, François Dumont wrote:
We have a regression regarding management of types convertible to
value_type. It is an occurrence of PR 56112 but for the insert method.
libstdc++: [_Hashtable] Insert range of types
On Mon, Feb 21, 2022 at 06:02:06PM +0100, Tobias Burnus wrote:
> I wonder whether there is a real problem in terms of the ME, but maybe
> there is.
>
> For atomic_default_mem_order: That's purely handle by the FEs by
> setting the default – and just using it when parsing the 'atomic'
> directive,
On Mon, Feb 21, 2022 at 06:01:00PM +0100, Uros Bizjak wrote:
> I remember the same issue in the past, so it looks like the fresh
> pseudo as destination gives RA some more freedom to do its magic. So,
> it is better to do:
>
> emit_move_insn (dest, gen_lowpart (wmode, t3));
>
> then play
Note for gofrontend-dev: on gcc-patches only Andreas Schwab suggested
using uc_regs instead of regs, which does look correct to me.
Ian
On Mon, Feb 21, 2022 at 8:47 AM Sören Tempel wrote:
>
> Ping.
>
> Summary: Fix build of libgo on PPC with musl libc and libucontext by
> explicitly including
> Am 21.02.2022 um 17:15 schrieb Jakub Jelinek via Gcc-patches
> :
>
> Hi!
>
> The following testcase is miscompiled since r12-3328.
> That change assumed that if rhs1 of a GIMPLE_ASSIGN is COMPLEX_CST, then
> that is the value of the lhs of the stmt, but that is not the case always,
> only
Hi Jakub, hi Abid, hi all,
On 21.02.22 16:50, Jakub Jelinek via Fortran wrote:
The thing is, omp_requires_mask was added for C/C++ from the C/C++ notion of
translation units (and a question is how does that cope with C++20 modules),
with the assumption that once certain #pragma omp requires is
On Mon, Feb 21, 2022 at 5:46 PM Jakub Jelinek wrote:
>
> Hi!
>
> We ICE on the following testcase for -m32 since r12-3435. because
> operands[2] is (subreg:SF (reg:DI ...) 0) and
> lowpart_subreg (V4SFmode, operands[2], SFmode)
> returns NULL, and that is what we use in AND etc. insns we emit.
>
Fixes:
gcc/cp/pt.cc:13755:23: warning: suggest braces around initialization of
subobject [-Wmissing-braces]
tree_vec_map in = { fn, nullptr };
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/cp/ChangeLog:
* pt.cc
Hi!
We ICE on the following testcase for -m32 since r12-3435. because
operands[2] is (subreg:SF (reg:DI ...) 0) and
lowpart_subreg (V4SFmode, operands[2], SFmode)
returns NULL, and that is what we use in AND etc. insns we emit.
The following patch (non-attached) fixes that by calling force_reg
On Mon, Feb 21, 2022 at 10:29 AM Hongyu Wang wrote:
>
> Hi,
>
> For cmpxchg, it is commonly used in spin loop, and several user code
> such as pthread directly takes cmpxchg as loop condition, which cause
> huge cache bouncing.
>
> This patch extends previous implementation to relax all cmpxchg
>
Hi!
The following testcase is miscompiled since r12-3328.
That change assumed that if rhs1 of a GIMPLE_ASSIGN is COMPLEX_CST, then
that is the value of the lhs of the stmt, but that is not the case always,
only if it is a GIMPLE_SINGLE_RHS stmt. If it is e.g.
GIMPLE_UNARY_RHS or
The following fixes an omission in bool pattern detection that
makes it fail when check_bool_pattern fails for COND_EXPR. That's
not what it should do, instead it should still pattern recog
to var != 0 even if no further adjustments to the def chain are
necessary when var is not a mask already.
On Mon, Feb 21, 2022 at 02:24:40PM +, Hafiz Abid Qadeer wrote:
> This patch fixes an issue that although gfortran accepts
> 'requires dynamic_allocators', it does not set the omp_requires_mask
> accordingly.
>
> gcc/fortran/ChangeLog:
>
> * parse.cc (gfc_parse_file): Set
Hi Jakub,
as encountered in cases where a program constructs its own deep-copying
for arrays-of-pointers, e.g:
#pragma omp target enter data map(to:level->vectors[:N])
for (i = 0; i < N; i++)
#pragma omp target enter data map(to:level->vectors[i][:N])
We need to treat the part of the
On Mon, Feb 21, 2022 at 2:47 PM Tom de Vries wrote:
>
> On 2/21/22 08:54, Richard Biener wrote:
> > On Sun, Feb 20, 2022 at 11:50 PM Tom de Vries via Gcc-patches
> > wrote:
> >>
> >> Hi,
> >>
> >> With nvptx target, driver version 510.47.03 and board GT 1030 I, we run
> >> into:
> >> ...
> >>
The a1 and a2 case were fixed (by diagnosing the invalid expression)
with r11-434, and the a3 case with r8-7625.
PR c++/85493
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/decltype80.C: New test.
---
gcc/testsuite/g++.dg/cpp0x/decltype80.C | 16
1 file changed, 16
This patch fixes an issue that although gfortran accepts
'requires dynamic_allocators', it does not set the omp_requires_mask
accordingly.
gcc/fortran/ChangeLog:
* parse.cc (gfc_parse_file): Set OMP_REQUIRES_DYNAMIC_ALLOCATORS
bit in omp_requires_mask.
---
gcc/fortran/parse.cc |
On 2/21/22 08:54, Richard Biener wrote:
On Sun, Feb 20, 2022 at 11:50 PM Tom de Vries via Gcc-patches
wrote:
Hi,
With nvptx target, driver version 510.47.03 and board GT 1030 I, we run into:
...
FAIL: gcc.c-torture/execute/pr53465.c -O1 execution test
FAIL: gcc.c-torture/execute/pr53465.c
This patch resolves PR c++/95999 which is an ICE-after-error regression
in the g++ front-end. When parsing an enumerator list, the C++ parser
assumes that cp_parser_constant_expression always returns either an
INTEGER_CST or error_mark_node, but in testcase reported in the PR
actually returns a
On Fri, Feb 18, 2022 at 7:20 PM Roger Sayle wrote:
>
>
> This patch improves GCC's scalar evolution and final value replacement
> optimizations by supporting triangular/quadratic/trapezoid chrecs which
> resolves both PR middle-end/65855 and PR c/80852, but alas not (yet)
> PR
Hi,
This patch adds two new OpenMP runtime routines: omp_target_memcpy_async and
omp_target_memcpy_rect_async. Both functions are introduced in OpenMP 5.1 as
asynchronous variants of omp_target_memcpy and omp_target_memcpy_rect.
In contrast to the synchronous variants, the asynchronous
On Mon, Feb 21, 2022 at 9:31 AM Roger Sayle wrote:
>
>
> Hi Marc,
> I'm assuming that the use (semantics) of a REDUC_PLUS expr allow the
> reduction to be done in any order, for example the testcase requires
> -ffast-math to allow the REDUC_PLUS to be introduced in the first place.
> This also
Iain Sandoe writes:
> Hi Folks.
>> On 14 Feb 2022, at 16:58, Vladimir Makarov wrote:
>> On 2022-02-14 11:00, Richard Sandiford wrote:
>
>>> Vladimir Makarov via Gcc-patches writes:
Hi, Richard. Change LRA is mine and I approved it for Iain's patch.
I think there is no
On Mon, 21 Feb 2022, Richard Sandiford wrote:
> Richard Biener writes:
> > This adjusts the vectorizer costing API to allow passing down the
> > SLP node the vector stmt is created from.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, I've built
> > aarch64 and rs6000 cc1 crosses.
>
Richard Biener writes:
> This adjusts the vectorizer costing API to allow passing down the
> SLP node the vector stmt is created from.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, I've built
> aarch64 and rs6000 cc1 crosses.
>
> OK?
Not sure about the stmt_info + no node overload.
Richard Biener writes:
> This simplifies the vectorizer cost API by providing overloads
> to add_stmt_cost and record_stmt_cost suitable for scalar stmt
> and branch stmt costing which do not need information like
> a vector type or alignment. It also fixes two mistakes where
> costs for
Hi Haochen,
Some minor comments are inlined.
on 2022/2/16 下午4:42, HAO CHEN GUI via Gcc-patches wrote:
> Hi,
>This patch enables absolute jump tables on PPC AIX and Linux. For AIX, the
> jump
> table is placed in data section. For Linux, it is placed in RELRO section when
> relocation is
Hi,
For cmpxchg, it is commonly used in spin loop, and several user code
such as pthread directly takes cmpxchg as loop condition, which cause
huge cache bouncing.
This patch extends previous implementation to relax all cmpxchg
instruction under -mrelax-cmpxchg-loop with an extra atomic load,
On Mon, 21 Feb 2022, Hongtao Liu wrote:
> On Fri, Feb 18, 2022 at 10:01 PM Richard Biener via Gcc-patches
> wrote:
> >
> > This uses the now passed SLP node to the vectorizer costing hook
> > to adjust vector construction costs for the cost of moving an
> > integer component from a GPR to a
Hi Marc,
I'm assuming that the use (semantics) of a REDUC_PLUS expr allow the
reduction to be done in any order, for example the testcase requires
-ffast-math to allow the REDUC_PLUS to be introduced in the first place.
This also applies explains why the patch doesn't need to distinguish
Hi!
The new expression constant expression evaluation right now tries to
deduce how many elts the array it uses for the heap or heap [] vars
should have (or how many elts should its trailing array have if it has
cookie at the start). As new is lowered at that point to
(some_type *) ::operator
On Mon, 21 Feb 2022, Roger Sayle wrote:
+/* Fold REDUC (@0 op VECTOR_CST) as REDUC (@0) op REDUC (VECTOR_CST). */
+(for reduc (IFN_REDUC_PLUS IFN_REDUC_MAX IFN_REDUC_MIN IFN_REDUC_FMAX
+IFN_REDUC_FMIN IFN_REDUC_AND IFN_REDUC_IOR IFN_REDUC_XOR)
+ op (plus max min IFN_FMAX
63 matches
Mail list logo
