Jakub Jelinek 于2023年12月19日周二 16:40写道：
>
> On Tue, Dec 19, 2023 at 09:30:49AM +0800, YunQiang Su wrote:
> > The function `reconcat` cannot append string(s) to NULL,
> > as the concat process will stop at the first NULL.
> >
> > Let's always put the `ret` to the end, as it may be NULL.
> > We keep u
The function `reconcat` cannot append string(s) to NULL,
as the concat process will stop at the first NULL.
Let's always put the `ret` to the end, as it may be NULL.
We keep use reconcat here, due to that reconcat can make it
easier if we add more hardware features detecting, for example
by hwcap.
Users may wish just use -mtune=native for performance tuning only.
Let's don't make trouble for its case.
gcc/
* config/mips/driver-native.cc (host_detect_local_cpu):
don't add nan2008 option for -mtune=native.
---
gcc/config/mips/driver-native.cc | 3 ++-
1 file changed, 2 inser
On TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true platforms,
if 31 or above bits is polluted by an bitops, we will need an
truncate. Let's emit one, and mark let's use the same hardreg
as in and out, the RTL may like:
(insn 21 20 24 2 (set (subreg/s/u:SI (reg/v:DI 200 [ val ]) 0)
On Dez 23 2023, YunQiang Su wrote:
> diff --git a/gcc/config/mips/driver-native.cc
> b/gcc/config/mips/driver-native.cc
> index afc276f5278..4ef48e14916 100644
> --- a/gcc/config/mips/driver-native.cc
> +++ b/gcc/config/mips/driver-native.cc
> @@ -44,6 +44,8 @@ const char *
> host_detect_local_c
Hi!
On 2023-12-21T13:58:23+0100, Jakub Jelinek wrote:
> On Thu, Dec 21, 2023 at 01:31:19PM +0100, Thomas Schwinge wrote:
>> [...] the gimplification-level code re
>> 'Static locals [...] need to be "omp declare target"' runs *after*
>> 'omp_discover_implicit_declare_target'. Thus my "move" idea
On Sat, 2023-12-23 at 10:29 +0800, chenglulu wrote:
> > The performance drop has nothing to do with this patch. I found that the
> > h264 performance compiled
> > by r14-6787 compared to r14-6421 dropped by 6.4%.
Then I guess we should create a bug report...
> But there is a problem. My regre
On Sat, 2023-12-23 at 18:44 +0800, Xi Ruoyao wrote:
> On Sat, 2023-12-23 at 10:29 +0800, chenglulu wrote:
> > > The performance drop has nothing to do with this patch. I found that the
> > > h264 performance compiled
> > > by r14-6787 compared to r14-6421 dropped by 6.4%.
>
> Then I guess we sh
Thanks all for comments, will have a try for riscv_v and send V2 if everything
goes well.
Pan
From: 钟居哲
Sent: Friday, December 22, 2023 6:44 AM
To: Jeff Law ; Li, Pan2 ; gcc-patches
Cc: Wang, Yanzhang ; kito.cheng
; richard.guenther ; Tamar
Christina
Subject: Re: Re: [PATCH v1] RISC-V: XFa
From: Pan Li
This patch would like to XFAIL the test case pr30957-1.c for the RVV when
build the elf with some configurations (list at the end of the log)
It will be vectorized during vect_transform_loop with a variable factor.
It won't benefit from unrolling/peeling and mark the loop->unroll as
From: Pan Li
This patch would like to XFail the signbit-5 run test case for
the RVV. Given the case has one limitation like "This test does not
work when the truth type does not match vector type." in the beginning
of the test file. Aka, the RVV vector truth type is not integer type.
The targe
On 12/23/23 05:39, pan2...@intel.com wrote:
From: Pan Li
This patch would like to XFail the signbit-5 run test case for
the RVV. Given the case has one limitation like "This test does not
work when the truth type does not match vector type." in the beginning
of the test file. Aka, the RVV
On 12/23/23 01:58, YunQiang Su wrote:
On TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true platforms,
if 31 or above bits is polluted by an bitops, we will need an
truncate. Let's emit one, and mark let's use the same hardreg
as in and out, the RTL may like:
(insn 21 20 24 2 (set (subre
On Sat, 2023-12-23 at 15:00 +0800, chenglulu wrote:
> Hi,
>
> This patch will cause the following tests to fail:
>
> +FAIL: gcc.dg/vect/pr97081-2.c (internal compiler error: in extract_insn, at
> recog.cc:2812)
> +FAIL: gcc.dg/vect/pr97081-2.c (test for excess errors)
> +FAIL: gcc.dg/vect/pr9708
On Sun, 2023-12-24 at 00:56 +0800, Xi Ruoyao wrote:
> On Sat, 2023-12-23 at 15:00 +0800, chenglulu wrote:
> > Hi,
> >
> > This patch will cause the following tests to fail:
> >
> > +FAIL: gcc.dg/vect/pr97081-2.c (internal compiler error: in extract_insn,
> > at recog.cc:2812)
> > +FAIL: gcc.dg/v
On 12/23/23 04:07, pan2...@intel.com wrote:
From: Pan Li
This patch would like to XFAIL the test case pr30957-1.c for the RVV when
build the elf with some configurations (list at the end of the log)
It will be vectorized during vect_transform_loop with a variable factor.
It won't benefit fro
Like r14-2293-g11350734240dba and r14-2289-gb083203f053f16,
reassociation can combine across a few bb and one of the usage
can be an uninitializated variable and if going from an conditional
usage to an unconditional usage can cause wrong code.
This uses maybe_undef_p like other passes where this c
On 12/18/23 17:10, Jason Merrill wrote:
On 12/18/23 16:57, Nathan Sidwell wrote:
On 12/18/23 16:31, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. Does this make sense? Did you have another theory
about how to merge these?
Why isn't push_abi_namespace doing the right setup here? (and I th
This patch series implements __is_const, __is_volatile, __is_pointer,
and __is_unbounded_array built-in traits, which were isolated from my
previous patch series "Optimize type traits compilation performance"
because they contained performance regression. I confirmed that this
patch series does no
This patch implements built-in trait for std::is_const.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_const.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_CONST.
* semantics.cc (trait_expr_value): Likewise.
(finish_trait_expr): Likewise.
gcc/testsuite/Chan
This patch optimizes the compilation performance of std::is_const
by dispatching to the new __is_const built-in trait.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_const): Use __is_const built-in
trait.
(is_const_v): Likewise.
Signed-off-by: Ken Matsui
---
libs
On Sat, Dec 23, 2023 at 1:36 PM Ken Matsui wrote:
>
> This patch implements built-in trait for std::is_const.
>
> gcc/cp/ChangeLog:
>
> * cp-trait.def: Define __is_const.
> * constraint.cc (diagnose_trait_expr): Handle CPTK_IS_CONST.
> * semantics.cc (trait_expr_value): Lik
This patch series implements __is_const, __is_volatile, __is_pointer,
and __is_unbounded_array built-in traits, which were isolated from my
previous patch series "Optimize type traits compilation performance"
because they contained performance regression. I confirmed that this
patch series does no
This patch implements built-in trait for std::is_const.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_const.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_CONST.
* semantics.cc (trait_expr_value): Likewise.
(finish_trait_expr): Likewise.
gcc/testsuite/Chan
This patch optimizes the compilation performance of std::is_const
by dispatching to the new __is_const built-in trait.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_const): Use __is_const built-in
trait.
(is_const_v): Likewise.
Signed-off-by: Ken Matsui
---
libs
This patch implements built-in trait for std::is_volatile.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_volatile.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_VOLATILE.
* semantics.cc (trait_expr_value): Likewise.
(finish_trait_expr): Likewise.
gcc/tests
This patch optimizes the compilation performance of std::is_volatile
by dispatching to the new __is_volatile built-in trait.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_volatile): Use __is_volatile
built-in trait.
(is_volatile_v): Likewise.
Signed-off-by: Ken Ma
This patch optimizes the compilation performance of std::is_pointer
by dispatching to the new __is_pointer built-in trait.
libstdc++-v3/ChangeLog:
* include/bits/cpp_type_traits.h (__is_pointer): Use
__is_pointer built-in trait. Optimize its implementation.
* include/std/
This patch implements built-in trait for std::is_pointer.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_pointer.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_POINTER.
* semantics.cc (trait_expr_value): Likewise.
(finish_trait_expr): Likewise.
gcc/testsuit
This patch implements built-in trait for std::is_unbounded_array.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_unbounded_array.
* constraint.cc (diagnose_trait_expr): Handle
CPTK_IS_UNBOUNDED_ARRAY.
* semantics.cc (trait_expr_value): Likewise.
(finish_trai
This patch optimizes the compilation performance of
std::is_unbounded_array by dispatching to the new
__is_unbounded_array built-in trait.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_unbounded_array_v): Use
__is_unbounded_array built-in trait.
Signed-off-by: Ken Matsui
Jeff Law 于2023年12月24日周日 00:51写道：
>
>
>
> On 12/23/23 01:58, YunQiang Su wrote:
> > On TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true platforms,
> > if 31 or above bits is polluted by an bitops, we will need an
> > truncate. Let's emit one, and mark let's use the same hardreg
> > as in and
I suggest you send the first patch which support theadvector with only adding
"th.".
After it's done, then we can talk about it later.
juzhe.zh...@rivai.ai
发件人： joshua
发送时间： 2023-12-23 11:37
收件人： juzhe.zh...@rivai.ai; gcc-patches
抄送： Jim Wilson; palmer; andrew; philipp.tomsich; jeffreyalaw; c
This patch uses _GLIBCXX_USE_BUILTIN_TRAIT macro instead of __has_builtin
in the type_traits header for traits that have a corresponding fallback
non-built-in implementation. This macro supports to toggle the use of
built-in traits in the type_traits header through
_GLIBCXX_DO_NOT_USE_BUILTIN_TRAI
One of the cool features of the H8 backend is its use of tables to select
optimal shift implementations for different CPU variants. This patch
borrows (plagiarizes) that idiom for SImode left shifts in the ARC backend
(for CPUs without a barrel-shifter). This provides a convenient mechanism
for
No test-case, but the regress-367 from r14-6674-g4759383245ac97 is
"back" to regress-10 for cris-elf+cris-sim with this patch applied
to gcc from that revision.
Also, I wonder why none of those other targets with a MEM for
EH_RETURN_HANDLER_RTX with an address relative to
frame_pointer_rtx (as opp
Hi YunQiang (and Jeff),
> MIPS claims TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true
> based on that the hard register is always sign-extended, but here
> the hard register is polluted by zero_extract.
I suspect that the bug here is that the MIPS backend shouldn't be returning
true for
> There's a PR in Bugzilla around this representational issue on MIPS, but I
can't find
> it straight away.
Found it. It's PR rtl-optimization/104914, where we've already
discussed this in comments #15 and #16.
> -Original Message-
> From: Roger Sayle
> Sent: 24 December 2023 00:50
> To
Documentation part.
The makeinfo gcc/fortran/gfortran.texi does not seem to have any new warnings.
Is there a specific reason thy -fc-prototypes (Interoperability
Options section) is excluded from manpage?
Regards,
Rimvydas
From 3adb6cd8a2aa1576a8ff63b280239e725f1f112e Mon Sep 17 00:00:00 2001
Fro
Committed, thanks Jeff.
Pan
-Original Message-
From: Jeff Law
Sent: Saturday, December 23, 2023 11:38 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; Wang, Yanzhang ;
kito.ch...@gmail.com; richard.guent...@gmail.com; tamar.christ...@arm.com
Subject: Re: [PATCH v2] R
Thanks Jeff for comments.
> Isn't this going to XPASS for non-vector configurations?
Yes, I think we still need something like riscv_v here.
> If I understand correctly, the test requires loop unrolling and its
> associated variable expansion to trigger the desired behavior. VLA
> style vecto
On 12/23/23 15:46, YunQiang Su wrote:
Jeff Law 于2023年12月24日周日 00:51写道：
On 12/23/23 01:58, YunQiang Su wrote:
On TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true platforms,
if 31 or above bits is polluted by an bitops, we will need an
truncate. Let's emit one, and mark let's use th
On 12/23/23 17:49, Roger Sayle wrote:
Hi YunQiang (and Jeff),
MIPS claims TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) ==
true based on that the hard register is always sign-extended, but
here the hard register is polluted by zero_extract.
I suspect that the bug here is that the MIPS b
43 matches
Mail list logo
