Add zero_extendditi2. Improve lxvr*x code generation.
This pattern adds zero_extendditi2 so that if we are extending DImode that
is in a GPR register to TImode in a vector register, the compiler can
generate MTVSRDDD.
In addition the patterns for generating lxvr{b,h,w,d}x were tuned to allow
loa
When i first wrote the relation code, it seemed like reusing some
commonly understood tree codes, like EQ_EXPR, NE_EXPR, LE_EXPR, etc made
sense.
Fore additional values like VREL_NONE and VREL_EMPTY (VREL is Value
RELation, fwiw) I used nearby tree odes such that they formed a
contiguous ra
On Tue, May 10, 2022 at 05:41:38PM +0200, Marcel Vollweiler wrote:
> I removed all the NON_LVALUE_EXPR changes again.
>
> The new version of the patch was tested again on x86_64-linux with nvptx and
> amdgcn offloading. All with no regressions.
Ok, thanks.
> gcc/cp/ChangeLog:
>
> * pt.cc
Szabolcs Nagy via Gcc-patches writes:
> The RA_SIGN_STATE dwarf pseudo-register is normally only set using the
> DW_CFA_AARCH64_negate_ra_state (== DW_CFA_window_save) operation which
> toggles the return address signedness state (the default state is 0).
> (It may be set by remember/restore_state
Hi Sebastian,
>> Note the patch still needs an appropriate commit message.
>
> Added the following ChangeLog entry to the commit message.
>
> * config/aarch64/aarch64-protos.h (atomic_ool_names): Increase
>dimension
> of str array.
> * config/aarch64/aarch64.cc (aarch64_at
On Fri, May 13, 2022 at 11:46 AM Roger Sayle wrote:
>
>
> Hi Uros,
> Now that we're back in stage 1, here's the revised version of the patch I
> submitted here:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593434.html
> incorporating all the suggested improvements from your review here:
This patch updates the aarch64 backend as needed to support DFP modes
(SD, DD and TD).
2022-03-31 Christophe Lyon
gcc/
* config/aarch64/aarch64.cc
(aarch64_split_128bit_move): Handle DFP modes.
(aarch64_mode_valid_for_sched_fusion_p): Likewise.
(aarch64_
Add zero_extendditi2. Improve lxvr*x code generation.
This pattern adds zero_extendditi2 so that if we are extending DImode that
is in a GPR register to TImode in a vector register, the compiler can
generate MTVSRDDD.
In addition the patterns for generating lxvr{b,h,w,d}x were tuned to allow
loa
Optimize multiply/add of DImode extended to TImode, PR target/103109.
On power9 and power10 systems, we have instructions that support doing
64-bit integers converted to 128-bit integers and producing 128-bit
results. This patch adds support to generate these instructions.
Previously GCC had def
Generate vadduqm and vsubuqm for TImode add/subtract
If the TImode variable is in an Altivec register instead of a GPR
register, then generate vadduqm and vsubuqm instead of having to move the
value to the GPR registers and doing the add and subtract with carry
instructions. To do this, we have t
This patch adds support for trunc and extend operations between HF
mode (__fp16) and Decimal Floating Point formats (_Decimal32,
_Decimal64 and _Decimal128).
For simplicity we rely on the implicit conversions inserted by the
compiler between HF and SD/DF/TF modes. The existing bid*_to_binary*
and
Christophe Lyon via Gcc-patches writes:
> @@ -19352,7 +19363,9 @@ aarch64_legitimate_constant_p (machine_mode mode, rtx
> x)
> {
>/* Support CSE and rematerialization of common constants. */
>if (CONST_INT_P (x)
> - || (CONST_DOUBLE_P (x) && GET_MODE_CLASS (mode) == MODE_FLOAT))
>
These tests exercise exception handling with Decimal Floating-Point
type.
dfp-1.C and dfp-2.C check that thrown objects of such types are
properly caught, whether when using C++ classes (decimalXX) or via GCC
mode attributes.
dfp-saves-aarch64.C checks that such objects are properly restored,
and
On Thu, 12 May 2022 18:55:45 PDT (-0700), jia...@iscas.ac.cn wrote:
Similar to patch 593993, RISC-V needs to limit symbols send in sdata.
Thanks for Palmer's help.
gcc/testsuite/ChangeLog:
* g++.dg/opt/const7.C: Don't use small data on RISC-V.
---
gcc/testsuite/g++.dg/opt/const7.C | 1
On Tue, 10 May 2022 08:48:33 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
Thanks Maciej!
Yep. We should have a NEWS entry, though, as this one is user-visible
and may be tricky to sort out if it turns out there is some HW lurking
around that has the old behavior.
On Tue, May 10, 2022 at 10
On Tue, 10 May 2022 18:31:37 PDT (-0700), Kito Cheng wrote:
LGTM, that's only added a new option for RISC-V and won't affect all
other targets, so I assume I can approve that.
I always forget what the rules are, but someone recently reminded me and
yes that's the case. I committed this.
Tha
On Fri, 2022-05-13 at 10:49 -0400, Michael Meissner wrote:
> Optimize vec_splats of constant V2DI/V2DF vec_extract, PR target/99293.
>
> This patch has been previously posted, but it seemed to get lost.:
>
> > Date: Tue, 29 Mar 2022 23:25:31 -0400
> > Subject: [PATCH, V2] Optimize vec_splats of c
On Tue, 10 May 2022 18:34:33 PDT (-0700), Kito Cheng wrote:
LGTM, I think document what we really did in GCC 12 is never too late :P
OK, committed.
On Fri, Apr 29, 2022 at 2:23 AM Palmer Dabbelt wrote:
---
IMO this one is worth documenting too, not sure if it's too late for
gcc-12's doc
Hi All,
Some targets require function parameters to be promoted to a different
type on expand time because the target may not have native instructions
to work on such types. As an example the AArch64 port does not have native
instructions working on integer 8- or 16-bit values. As such it promot
Hi All,
The PROMOTE_MODE always promotes 8 and 16-bit parameters to 32-bits.
This promotion is not required for the ABI which states:
```
C.9 If the argument is an Integral or Pointer Type, the size of the
argument is
less than or equal to 8 bytes and the NGRN is less than 8, the argument i
Hi All,
This removes the xfails from the below tests which now all pass.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues and fixes 209
SVE xfails.
Ok for master?
Thanks,
Tamar
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/acle/asm/abd_s16.c: Remove xfail.
*
Based on sollve_vv's
tests/4.5/target_teams_distribute/test_target_teams_distribute_nowait.F90
As discussed, for simple pointers – like here with nondescriptor array,
instead of alloc:a + pointer assign, a firstprivate + pointer assign makes
more sense.
It also avoids the race exposed by the so
On Tue, 03 May 2022 08:21:45 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
On 4/29/2022 5:44 PM, Palmer Dabbelt wrote:
Some tests check for fenv and then proceed to use fesetround() directly,
but some platforms (at least RISC-V soft-float) have fenv but don't
support rounding modes. This adds a
Some tests check for fenv and then proceed to use fesetround() directly,
but some platforms (at least RISC-V soft-float) have fenv but don't
support rounding modes. This adds a DG check that fesetround() actually
functions, which is then used by all the tests that call fesetround()
explicitly.
gc
On Fri, 2022-05-13 at 10:52 -0400, Michael Meissner wrote:
> Replace UNSPEC with RTL code for extendditi2.
>
Hi,
> When I submitted my patch on March 12th for extendditi2, Segher
> wished I
> had removed the use of the UNSPEC for the vextsd2q instruction. This
> patch rewrites extendditi2_vect
On Fri, May 13, 2022 at 11:08:48AM -0400, Michael Meissner wrote:
> Add zero_extendditi2. Improve lxvr*x code generation.
Nothing in this pass haas anything to do with the subject. Which is a
good thing, because not expanding addti3 etc. to RTL that mimics the
machine insns is not acceptable a
On Fri, May 13, 2022 at 07:21:02PM +0200, Tobias Burnus wrote:
> gcc/fortran/ChangeLog:
>
> * trans-openmp.cc (gfc_trans_omp_clauses): When mapping nondescriptor
> array sections, use GOMP_MAP_FIRSTPRIVATE_POINTER instead of
> GOMP_MAP_POINTER for the pointer attachment.
>
> lib
These tests exercise exception handling with Decimal Floating-Point
type.
dfp-1.C and dfp-2.C check that thrown objects of such types are
properly caught, whether when using C++ classes (decimalXX) or via GCC
mode attributes.
dfp-saves-aarch64.C checks that such objects are properly restored,
and
This patch adds support for trunc and extend operations between HF
mode (__fp16) and Decimal Floating Point formats (_Decimal32,
_Decimal64 and _Decimal128).
For simplicity we rely on the implicit conversions inserted by the
compiler between HF and SD/DF/TF modes. The existing bid*_to_binary*
and
On Fri, 2022-05-13 at 11:08 -0400, Michael Meissner wrote:
> Add zero_extendditi2. Improve lxvr*x code generation.
>
Hi,
> Subject: Re: [PATCH] Delay splitting addti3/subti3 until first split
pass.
Subject does not seem to match contents?
> This pattern adds zero_extendditi2 so that if w
On Fri, 2022-05-13 at 12:13 -0400, Michael Meissner wrote:
> Add zero_extendditi2. Improve lxvr*x code generation.
>
Content here matches what I commented on in the prior email with
subject "Delay splitting addti3...".
> This pattern adds zero_extendditi2 so that if we are extending DIm
On Fri, 2022-05-13 at 12:17 -0400, Michael Meissner wrote:
> Optimize multiply/add of DImode extended to TImode, PR target/103109.
>
> On power9 and power10 systems, we have instructions that support doing
> 64-bit integers converted to 128-bit integers and producing 128-bit
> results. This patch
في الجمعة، ١٣ مايو، ٢٠٢٢ ٣:١٤ م Jakub Jelinek كتب:
> On Tue, May 10, 2022 at 07:40:41AM +0200, Mohamed Atef wrote:
> > --- a/libgomp/env.c
> > +++ b/libgomp/env.c
> > @@ -33,6 +33,7 @@
> > #ifndef LIBGOMP_OFFLOADED_ONLY
> > #include "libgomp_f.h"
> > #include "oacc-int.h"
> > +#include "ompd-s
On Fri, 13 May 2022, Christophe Lyon via Gcc-patches wrote:
> diff --git a/gcc/testsuite/gcc.target/aarch64/convert-dfp-2.c
> b/gcc/testsuite/gcc.target/aarch64/convert-dfp-2.c
I still think the tests should run for x86 as well - that is, for any
target supporting both DFP and _Float16 (with ap
On Fri, May 13, 2022 at 08:22:41PM +0200, Mohamed Atef wrote:
> > As I've tried to explain, this #ifdef __ELF__ doesn't belong
> > to the public header, which should contain just
> > extern void ompd_dll_locations_valid (void) __GOMPD_NOTHROW;
> > The #define should be in some internal header that
On 5/13/22 20:23, Joseph Myers wrote:
On Fri, 13 May 2022, Christophe Lyon via Gcc-patches wrote:
diff --git a/gcc/testsuite/gcc.target/aarch64/convert-dfp-2.c
b/gcc/testsuite/gcc.target/aarch64/convert-dfp-2.c
I still think the tests should run for x86 as well - that is, for any
target s
Earlier patch was picking the type of the expression in a minus
operation from the LHS. When we are folding, the LHS may not be
defined yet.
Instead, pick up the type from operand 1, and ensure it isn't undefined
while we're at it.
Bootstrapped on x86_64-pc-linux-gnu with no regressions.
On Fri, 2022-05-13 at 12:19 -0400, Michael Meissner wrote:
> Generate vadduqm and vsubuqm for TImode add/subtract
>
> If the TImode variable is in an Altivec register instead of a GPR
> register, then generate vadduqm and vsubuqm instead of having to move the
> value to the GPR registers and doing
Hello Jakub,
I am sorry, but should #ifdef __ELF__ put and separate file and also the
actual functions (e.g. extern ompd_dll_location_valid (void))
I mean both in the same files or the functions should be in the omp-tools.h
but with #ifndef __ELF__
Mohamed
On Fri, May 13, 2022 at 8:27 PM Jaku
On Fri, 13 May 2022, Palmer Dabbelt wrote:
> Yep. We should have a NEWS entry, though, as this one is user-visible and may
> be tricky to sort out if it turns out there is some HW lurking around that has
> the old behavior.
Hmm, should we? We only support `-misa-spec=<2.2|20190608|20191213>'
Tested powerpc64l4-linux, pushed to trunk.
-- >8 --
This allows std::rethrow_if_nested to work with -fno-rtti by not
attempting the dynamic_cast if it requires RTTI, since that's ill-formed
with -fno-rtti. The cast will still work if a static upcast to
std::nested_exception is allowed.
Also use
Tested powerpc64l4-linux, pushed to trunk.
-- >8 --
The non-member swap for std::exception_ptr is in a nested namespace and
so can only be found by ADL currently. Add a using-declaration so that
qualified std::swap calls will use the std::exception_ptr::swap member,
instead of the generic std::sw
Tested powerpc64l4-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/future (launch): Make operators noexcept.
---
libstdc++-v3/include/std/future | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/libstdc++-v3/include/std/future b/li
Tested powerpc64l4-linux, pushed to trunk.
-- >8 --
* include/bits/std_thread.h (thread::_State, thread::_State_ptr):
Declare as private unless _GLIBCXX_THREAD_IMPL is defined.
* src/c++11/thread.cc (_GLIBCXX_THREAD_IMPL): Define.
---
libstdc++-v3/include/bits/std_thread.
The Zbb support has introduced ctz and clz to the backend, but some
transformations in GCC need to know what the value of c[lt]z at zero
is. This affects how the optab is generated and may suppress use of
CLZ/CTZ in tree passes.
Among other things, this is needed for the transformation of
table-ba
Added the two nits from Kito's review and … Applied to trunk!
On Fri, 13 May 2022 at 22:16, Philipp Tomsich wrote:
>
> The Zbb support has introduced ctz and clz to the backend, but some
> transformations in GCC need to know what the value of c[lt]z at zero
> is. This affects how the optab is ge
Please see attached the patch back-ported to branches 12, 11, 10, and 9.
Tested on aarch64-linux with bootstrap and regression test.
Ok to commit to the GCC active branches?
Thanks,
SebastianFrom bba8d09284f3478f7d542ca4e7812d4c55e25bd4 Mon Sep 17 00:00:00 2001
From: Sebastian Pop
Date: Mon, 18 A
This adds omp_all_memory handling to Fortran, following C/C++ and shamelessly
coping
the C testcases and adapting them to Fortran.
OK?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäft
This patch to the Go frontend always sorts interface parse methods.
The exporter relies on sorting interface parse methods. It would sort
them as it encountered interface types. However, when an interface
type is an element of a struct or array type, the exporter might
encounter that interface t
On Sat, 7 May 2022, Gerald Pfeifer wrote:
>> +LoongArch
> Okay, thanks.
And here is a markup fix on top, which I just pushed.
Gerald
commit 01a1afc13afd0e2b981262b0a1bf9ba1d7d19f79
Author: Gerald Pfeifer
Date: Sat May 14 00:27:52 2022 +0200
gcc-12: Fix markup in the Loongson section
di
> On 12 May 2022, at 23:38, Segher Boessenkool
> wrote:
> On Mon, Apr 18, 2022 at 12:15:34PM -0500, Paul A. Clarke wrote:
>> -/* { dg-skip-if "" { powerpc*-*-darwin* } } */
>> +/* Never tested on darwin, so skip there. */
>> +/* { dg-skip-if "" { *-*-darwin* } } */
>
> That is probably the reas
On Thu, May 12, 2022 at 05:30:16PM -0500, Segher Boessenkool wrote:
> On Mon, Apr 18, 2022 at 12:15:35PM -0500, Paul A. Clarke wrote:
> > A few tests need not be restricted to 'lp64', so remove the restriction.
> >
> > A few of those need a simple change to the DejaGnu directives to suppress
> > '
On Sat, May 07, 2022 at 06:02:13PM -0400, Jason Merrill wrote:
> On 5/7/22 15:11, Marek Polacek wrote:
> > On Tue, May 03, 2022 at 04:59:38PM -0400, Jason Merrill wrote:
> > > Does this testcase still work with this patch?
> > >
> > > struct A {
> > >const A* p = this;
> > > };
> > >
> > > st
This was fixed by r258755:
PR c++/81311 - wrong C++17 overload resolution.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/81952
gcc/testsuite/ChangeLog:
* g++.dg/overload/conv-op4.C: New test.
---
gcc/testsuite/g++.dg/overload/conv-op4.C | 22 ++
1 fi
I'm abandoning this patch. It was fixed in FreeBSD instead to have
feenableexcept() in libm in
https://cgit.freebsd.org/src/commit/?id=448c505c33cc334193590f3844406d6a74f26e2a
Thanks for your insight!
On 22-05-13 10:59:59, Kewen.Lin wrote:
> on 2022/5/13 04:16, Segher Boessenkool wrote:
> > Hi
101 - 155 of 155 matches
Mail list logo
