Tested powerpc64le-linux.
Pushed to trunk. I'll backport to gcc-13 too.
-- >8--
This fixes a couple of errors in the printers for chrono types, and adds
tests to ensure they keep working.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (StdChronoDurationPrinter):
Prin
Honza,
Thanks a lot for your comments.
> On May 9, 2023, at 6:22 AM, Jan Hubicka wrote:
>
>
> From my understanding, -fprofile-partial-training is one important option
> for PGO performance.
I don't think so, speed benefit would be rather small I guess.
>>> I saw some
On 5/5/23 4:42 PM, Jakub Jelinek wrote:
> On Thu, May 04, 2023 at 02:29:34PM -0500, Peter Bergner wrote:
>> Merged from upstream libffi commit: 464b4b66e3cf3b5489e730c1466ee1bf825560e0
>>
>> 2023-05-03 Dan Horák
>>
>> libffi/
>> PR libffi/109447
>> * src/powerpc/ffi_linux64.c (ffi_prep_
Duuh! There's even a choice :-)
Paul
On Tue, 9 May 2023 at 19:29, Harald Anlauf wrote:
> Hi Paul,
>
> On 5/9/23 18:00, Paul Richard Thomas via Gcc-patches wrote:
> > Hi All,
> >
> > This problem caused the gimplifier failure because the reference chain
> > ending in an inquiry_len still retain
On 5/9/23 15:23, Jakub Jelinek wrote:
On Tue, May 09, 2023 at 01:17:09PM -0400, Jason Merrill wrote:
How about changing cp_parser_std_attribute to set TREE_VALUE to
error_mark_node if it skips arguments?
In limited testing that seems to work (tried
GXX_TESTSUITE_STDS=98,11,14,17,20,2b make -j3
On Sat, 6 May 2023, Roger Sayle wrote:
> An analysis of backend UNSPECs reveals that two of the most common UNSPECs
> across target backends are for copysign and bit reversal. This patch
> adds RTX codes for these expressions to allow their representation to
> be standardized, and them to optimiz
On Mai 09 2023, Peter Bergner via Gcc-patches wrote:
> It's almost as if the top level build machinery
> adds a LD_LIBRARY_PATH=...
See how the toplevel Makefile sets LD_LIBRARY_PATH (via RPATH_ENVVAR) if
gcc-bootstrap is set.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578
On 5/9/23 3:50 PM, Andreas Schwab wrote:
> On Mai 09 2023, Peter Bergner via Gcc-patches wrote:
>
>> It's almost as if the top level build machinery
>> adds a LD_LIBRARY_PATH=...
>
> See how the toplevel Makefile sets LD_LIBRARY_PATH (via RPATH_ENVVAR) if
> gcc-bootstrap is set.
I'm sorry to be
>> free_dominance_info (CDI_DOMINATORS); @@ -1674,7 +1677,7 @@
>> auto_profile (void)
>> pop_cfun ();
>>}
>>
>> - return TODO_rebuild_cgraph_edges;
>> + return 0;
>This change isn't mentioned - was it accidential?
No, it wasn't accidental. There is no reason to return
TODO_rebui
Typo spotted while doing CCmode improvements, as a missed
optimization. It's almost visible from the patch context;
there's not much done in terms of "mode-adjustment" when
replacing (reg:CC CRIS_CC0_REGNUM) with a copy!
This bug affects functions in the newlib printf-formatting
functions (nothing
autoprofiledbootstrap build produces new warnings since inlining decisions
are different from other builds. This patch contains fixes and workarounds
for those warnings.
Tested on x86_64-pc-linux-gnu.
gcc/ChangeLog:
* config/i386/i386-expand.cc (expand_vec_perm_interleave2): Work around
On Thu, May 4, 2023 at 5:49 PM Richard Biener
wrote:
>
> On Thu, May 4, 2023 at 7:37 AM Hongtao Liu via Gcc-patches
> wrote:
> >
> > On Thu, May 4, 2023 at 1:35 PM Hongtao Liu wrote:
> > >
> > > On Thu, Dec 22, 2022 at 4:04 PM Uros Bizjak wrote:
> > > >
> > > > On Thu, Dec 22, 2022 at 5:40 AM H
This issue happens is because the operand1 of scalar move can be
REG_P (operand[1]) in the O0 case, which causes the VSETVL PASS to
not insert the vsetvl instruction correctly, and the compiler crashes.
Consider this following case:
int16_t foo1 (void *base, size_t vl)
{
int16_t maxVal = __ris
Thanks for fix this. It seems that we don't have much testing in O0 (Mostly
testing in optimize > 0).
A couple of comments here:
>> if (avl == NULL_RTX && !optimize)
Chang it into ---> info.has_avl_no_reg ()
>> \ No newline at end of file
Check each test files make sure each file has a newline
From: Juzhe-Zhong
This patch is the prerequiste patch for more RVV auto-vectorization
support.
Since when we enable a very simple binary operations, we will end
up with such following ICE:
during RTL pass: expand
add_run-1.c: In function 'main':
add_run-1.c:28:1: internal compiler error: Segmen
This issue happens is because the operand1 of scalar move can be
REG_P (operand[1]) in the O0 case, which causes the VSETVL PASS to
not insert the vsetvl instruction correctly, and the compiler crashes.
Consider this following case:
int16_t foo1 (void *base, size_t vl)
{
int16_t maxVal = __ris
LGTM. Let's wait for kito's feedback.
Thanks :)
juzhe.zh...@rivai.ai
From: Li Xu
Date: 2023-05-10 12:02
To: gcc-patches
CC: kito.cheng; palmer; juzhe.zhong; Li Xu
Subject: [PATCH V2] RISC-V: Insert vsetivli zero, 0 for vmv.x.s/vfmv.f.s
instructions satisfying REG_P(operand[1]) in -O0.
This is
Hi
Rather than providing a series of patches for _Hashtable I prefer to
submit them one by one. It will maximize the chances to have some of
them in gcc 14.
I'm starting with this simple patch to do some cleanup in the current
implementation to ease compiler optimizations by making some meth
While I was writting a match.pd patch, I can across GCC was being miscompiled
but no testcase was failing. So this adds that testcase.
Committed after testing on x86_64 with
make check-gcc RUNTESTFLAGS="execute.exp=20230509-1.c"
gcc/testsuite/ChangeLog:
* gcc.c-torture/execut
Just migrated to the pointer_mux for the var-tracking, it works well even the
bitsize of tree_base code is different from the rtl_def code. I will prepare
the PATCH if there is no surprise from the X86 bootstrap test.
Thanks Richard for pointing out the pointer_mux, 😉!
Pan
-Original Messa
On Wed, May 10, 2023 at 12:05 AM Eugene Rozenfeld
wrote:
>
> >> free_dominance_info (CDI_DOMINATORS); @@ -1674,7 +1677,7 @@
> >> auto_profile (void)
> >> pop_cfun ();
> >>}
> >>
> >> - return TODO_rebuild_cgraph_edges;
> >> + return 0;
>
> >This change isn't mentioned - was it acci
On Wed, May 10, 2023 at 3:38 AM Eugene Rozenfeld via Gcc-patches
wrote:
>
> autoprofiledbootstrap build produces new warnings since inlining decisions
> are different from other builds. This patch contains fixes and workarounds
> for those warnings.
>
> Tested on x86_64-pc-linux-gnu.
Rather than
On Wed, May 10, 2023 at 3:41 AM Hongtao Liu wrote:
>
> On Thu, May 4, 2023 at 5:49 PM Richard Biener
> wrote:
> >
> > On Thu, May 4, 2023 at 7:37 AM Hongtao Liu via Gcc-patches
> > wrote:
> > >
> > > On Thu, May 4, 2023 at 1:35 PM Hongtao Liu wrote:
> > > >
> > > > On Thu, Dec 22, 2022 at 4:04
On Tue, 9 May 2023, Li, Pan2 wrote:
> Update the memory allocated bytes for both the all 12-bits patch and
> code 8-bits + mode 16-bits.
Just to throw in a comment here - for IL tree/GIMPLE is the more
important part since the whole program will be in tree/GIMPLE while
we only have a single func
The patch doesn't handle:
1. cast64_to_32,
2. memory source with rsize < range.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
PR middle-end/108938
* gimple-ssa-store-merging.cc (is_bswap_or_nop_p): New
function, cut from origin
On Tue, Dec 20, 2022 at 1:23 PM Manolis Tsamis wrote:
>
> When using SWAR (SIMD in a register) techniques a comparison operation within
> such a register can be made by using a combination of shifts, bitwise and and
> multiplication. If code using this scheme is vectorized then there is
> potenti
Hi!
On Wed, 3 May 2023 at 13:47, Richard Biener via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On Wed, 3 May 2023, Thomas Schwinge wrote:
>
> > Hi!
> >
> > This very likely isn't the only instance of such a kind of problem in the
> > GCC testsuite ;-) -- but it's one that I've run into, and
Hi!
The following testcase shows we silently accept (and ignore) attributes without
arguments used as pack expansions. This is because we call
make_pack_expansion and that starts with
if (!arg || arg == error_mark_node)
return arg;
Now, an attribute without arguments like [[noreturn...]] is
Hi!
http://eel.is/c++draft/dcl.attr#grammar-4 says
"In an attribute-list, an ellipsis may appear only if that attribute's
specification permits it."
and doesn't explicitly permit it on any standard attribute.
The https://wg21.link/p1774r8 paper which introduced assume attribute says
"We could ther
> -Original Message-
> From: Christophe Lyon
> Sent: Friday, May 5, 2023 5:49 PM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> Richard Earnshaw ; Richard Sandiford
>
> Cc: Christophe Lyon
> Subject: [PATCH 01/10] arm: [MVE intrinsics] add unary shape
>
> This patch adds the unary
Hi!
The following testcase is miscompiled, because bitwise ccp2 handles
a rotate with a signed type incorrectly.
Seems tree-ssa-ccp.cc has the only callers of wi::[lr]rotate with 3
arguments, all other callers just rotate in the right precision and
I think work correctly. ccp works with widest_in
On Tue, 9 May 2023, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled, because bitwise ccp2 handles
> a rotate with a signed type incorrectly.
> Seems tree-ssa-ccp.cc has the only callers of wi::[lr]rotate with 3
> arguments, all other callers just rotate in the right precision
The small and medium PIC code models generate profiling calls that
always load the address of __fentry__() via the GOT, even if
-mdirect-extern-access is in effect.
This deviates from the behavior with respect to other external
references, and results in a longer opcode that relies on linker
relax
Hi Christophe!
On 2023-05-09T09:32:55+0200, Christophe Lyon wrote:
> On Wed, 3 May 2023 at 13:47, Richard Biener via Gcc-patches
> wrote:
>> On Wed, 3 May 2023, Thomas Schwinge wrote:
>> > "Let each 'lto_init' determine the default 'LTO_OPTIONS', and
>> > 'torture-init' the 'LTO_TORTURE_OPTION
> I think we really need Eric (as one who e.g. introduced the
> DECL_INVARIANT_P apparently for this kind of stuff) to have a look at that
> on the Ada side.
DECL_INVARIANT_P is only set on discriminants with no default value and those
are really invariant in Ada, i.e. do not change once set.
>
From: Juzhe-Zhong
This incorrect codes blocks the scalable RVV auto-vectorization.
Take a look at this target hook implementation of aarch64.
They only have the similiar handling on TARGET_SIMD.
They let movmisalign to handle scalable vector of SVE.
For RVV, we should follow the same implementat
On 5/4/23 15:37, Qing Zhao wrote:
On May 4, 2023, at 9:05 AM, Martin Liška wrote:
On 5/4/23 14:54, Qing Zhao wrote:
On May 4, 2023, at 4:30 AM, Martin Liška wrote:
On 5/3/23 21:10, Qing Zhao via Gcc-patches wrote:
Hi, Jan,
You added the following patch into gcc10:
From 34fbe3f0946f
"Li, Pan2" writes:
> After the bits patch like below.
>
> rtx_def code 16 => 8 bits.
> rtx_def mode 8 => 16 bits.
> tree_base code unchanged.
>
> The structure layout of both the rtx_def and tree_base will be something
> similar as below. As I understand, the lower 8-bits of tree_base will be
>
Hi!
On Tue, May 09, 2023 at 08:55:56AM +, Richard Biener wrote:
> OK.
Thanks.
I came up with a testcase which reproduces all the way to r10-7469.
LTO to avoid early inlining it, so that ccp handles rotates and not
shifts before they are turned into rotates.
Tested on x86_64-linux -m32/-m64,
> > > >
> > > > From my understanding, -fprofile-partial-training is one important
> > > > option for PGO performance.
> > >
> > > I don't think so, speed benefit would be rather small I guess.
> > I saw some articles online to introduce this option for gcc10,
> > https://documentation.suse.com
On Tue, 9 May 2023, Richard Sandiford wrote:
> "Li, Pan2" writes:
> > After the bits patch like below.
> >
> > rtx_def code 16 => 8 bits.
> > rtx_def mode 8 => 16 bits.
> > tree_base code unchanged.
> >
> > The structure layout of both the rtx_def and tree_base will be something
> > similar as b
Hi!
Trivial comment typo...
Committed as obvious to trunk.
2023-05-09 Jakub Jelinek
* mux-utils.h: Fix comment typo, avoides -> avoids.
--- gcc/mux-utils.h.jj 2023-01-02 09:32:37.423068007 +0100
+++ gcc/mux-utils.h 2023-05-09 12:45:29.235288953 +0200
@@ -34,7 +34,7 @@
// and h
Hi,Richards. Would you mind reviewing this patch?
Thanks.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-05-07 23:19
To: juzhe.zhong; gcc-patches
CC: richard.sandiford; rguenther
Subject: Re: [PATCH V4] VECT: Add decrement IV iteration loop control by
variable amount support
On 5/4/23 07:
Sure thing, I will have a try and keep you posted.
Pan
-Original Message-
From: Richard Biener
Sent: Tuesday, May 9, 2023 6:26 PM
To: Richard Sandiford
Cc: Li, Pan2 ; Jeff Law ; Kito Cheng
; juzhe.zh...@rivai.ai; gcc-patches
; palmer ; jakub
Subject: Re: [PATCH] machine_mode type si
From: Juzhe-Zhong
This incorrect codes blocks the scalable RVV auto-vectorization.
Take a look at this target hook implementation of aarch64.
They only have the similiar handling on TARGET_SIMD.
They let movmisalign to handle scalable vector of SVE.
For RVV, we should follow the same implementat
Hi,
This patch implements clang's __has_feature and __has_extension in GCC.
Currently the patch aims to implement all documented features (and some
undocumented ones) following the documentation at
https://clang.llvm.org/docs/LanguageExtensions.html with the following
omissions:
- C++ type traits
Introduce a function that will be used to build intrinsics that use p
predication.
2022-09-08 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-functions.h (class
unspec_mve_function_exact_insn_pred_p): New.
---
gcc/config/arm/arm-mve-builtins-functions.h | 64
This patch adds the binary_maxvminv shape description.
2022-09-08 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-shapes.cc (binary_maxvminv): New.
* config/arm/arm-mve-builtins-shapes.h (binary_maxvminv): New.
---
gcc/config/arm/arm-mve-builtins-shapes.cc | 30
This patch adds the missing expanders for smax/smin for v*hf modes.
2022-09-08 Christophe Lyon
gcc/
* config/arm/vec-common.md (smin3): New.
(smax3): New.
---
gcc/config/arm/vec-common.md | 14 ++
1 file changed, 14 insertions(+)
diff --git a/gcc/config/ar
Factorize vmaxnmaq and vminnmaq so that they use the same pattern.
2022-09-08 Christophe Lyon
gcc/
* config/arm/iterators.md (MVE_VMAXNMA_VMINNMAQ)
(MVE_VMAXNMA_VMINNMAQ_M): New.
(mve_insn): Add vmaxnma, vminnma.
* config/arm/mve.md (mve_vmaxnmaq_f, mve_v
We can call code_for_mve_q_p_f only once this function exists, which
is the case after we factorized vmaxnmavq, vmaxnmvq, vminnmavq and
vminnmvq in a previous patch.
2022-09-08 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-functions.h
(unspec_mve_function_exact_insn
Factorize vmaxvq vminvq vmaxavq vminavq so that they use the same
pattern.
2022-09-08 Christophe Lyon
gcc/
* config/arm/iterators.md (MVE_VMAXVQ_VMINVQ, MVE_VMAXVQ_VMINVQ_P): New.
(mve_insn): Add vmaxav, vmaxv, vminav, vminv.
(supf): Add VMAXAVQ_S, VMAXAVQ_P_S,
Implement vmaxaq and vminaq using the new MVE builtins framework.
2022-09-08 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (vmaxaq, vminaq): New.
* config/arm/arm-mve-builtins-base.def (vmaxaq, vminaq): New.
* config/arm/arm-mve-builtins-base.h (vma
Implement vmaxnmq and vminnmq using the new MVE builtins framework.
2022-09-08 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (vmaxnmq, vminnmq): New.
* config/arm/arm-mve-builtins-base.def (vmaxnmq, vminnmq): New.
* config/arm/arm-mve-builtins-base.
Implement vmaxnmavq vmaxnmvq vminnmavq vminnmvq using the new MVE
builtins framework.
2022-09-08 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (FUNCTION_PRED_P_F): New.
(vmaxnmavq, vmaxnmvq, vminnmavq, vminnmvq): New.
* config/arm/arm-mve-builtins-ba
This patch adds the binary_maxavminav shape description.
2022-09-08 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-shapes.cc (binary_maxavminav): New.
* config/arm/arm-mve-builtins-shapes.h (binary_maxavminav): New.
---
gcc/config/arm/arm-mve-builtins-shapes.cc | 3
Implement vmaxnmaq and vminnmaq using the new MVE builtins framework.
2022-09-08 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (vmaxnmaq, vminnmaq): New.
* config/arm/arm-mve-builtins-base.def (vmaxnmaq, vminnmaq): New.
* config/arm/arm-mve-builtins-
This patch adds the binary_maxamina shape description.
2022-09-08 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-shapes.cc (binary_maxamina): New.
* config/arm/arm-mve-builtins-shapes.h (binary_maxamina): New.
---
gcc/config/arm/arm-mve-builtins-shapes.cc | 40
Factorize vmaxnmq and vminnmq so that they use the same pattern.
2022-09-08 Christophe Lyon
gcc/
* config/arm/iterators.md (MAX_MIN_F): New.
(MVE_FP_M_BINARY): Add VMAXNMQ_M_F, VMINNMQ_M_F.
(mve_insn): Add vmaxnm, vminnm.
(max_min_f_str): New.
*
Factorize vmaxnmavq vmaxnmvq vminnmavq vminnmvq so that they use the
same pattern.
2022-09-08 Christophe Lyon
gcc/
* config/arm/iterators.md (MVE_VMAXNMxV_MINNMxVQ)
(MVE_VMAXNMxV_MINNMxVQ_P): New.
(mve_insn): Add vmaxnmav, vmaxnmv, vminnmav, vminnmv.
* co
Factorize vmaxaq vminaq so that they use the same pattern.
2022-09-08 Christophe Lyon
gcc/
* config/arm/iterators.md (MVE_VMAXAVMINAQ, MVE_VMAXAVMINAQ_M):
New.
(mve_insn): Add vmaxa, vmina.
(supf): Add VMAXAQ_S, VMAXAQ_M_S, VMINAQ_S, VMINAQ_M_S.
Implement vmaxvq, vminvq, vmaxavq, vminavq using the new MVE builtins
framework.
2022-09-08 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (FUNCTION_PRED_P_S_U)
(FUNCTION_PRED_P_S): New.
(vmaxavq, vminavq, vmaxvq, vminvq): New.
* config/arm/a
Hi!
On 2014-11-04T10:31:37-0800, Mike Stump wrote:
> On Nov 4, 2014, at 4:13 AM, Thomas Schwinge wrote:
>> On Wed, 15 Oct 2014 17:46:48 +0200, I wrote:
>>> [...]
>>>
>>> Am I on the right track with the following?
>>
>> Nobody commented, which also means nobody disagreed
>
> :-)
>
>> OK to commi
Hi!
On 2023-05-09T14:36:53+0200, I wrote:
> On 2014-11-04T10:31:37-0800, Mike Stump wrote:
>> On Nov 4, 2014, at 4:13 AM, Thomas Schwinge wrote:
>>> On Wed, 15 Oct 2014 17:46:48 +0200, I wrote:
[...]
Am I on the right track with the following?
>>>
>>> Nobody commented, which also
Hi!
On 2023-05-09T14:39:53+0200, I wrote:
> On 2023-05-09T14:36:53+0200, I wrote:
>> On 2014-11-04T10:31:37-0800, Mike Stump wrote:
>>> On Nov 4, 2014, at 4:13 AM, Thomas Schwinge wrote:
On Wed, 15 Oct 2014 17:46:48 +0200, I wrote:
> [...]
>
> Am I on the right track with the fo
Hi!
On 2014-11-04T10:31:37-0800, Mike Stump wrote:
> I wonder if any variables that you set that need to be cleared out are, that
> seems a defect in the api or conventions we use and it can screw following
> tests with a wrong environment in subtle ways. I could miss accidental bleed
> over
钟居哲 writes:
> Hi, Richards. I would like to give more information about this patch so that
> it will make this patch easier for you to review.
>
> Currently, I saw we have 3 situations that we need to handle in case of loop
> control IV in auto-vectorization:
> 1. Single rgroup loop control (nco
Hi!
On 2023-05-09T14:54:21+0200, I wrote:
> [...] libgomp testsuite is a bit weird [...]: that every '*.exp' file
> begins with a bunch of conditional 'unset lang_[...]' to clean up what
> the previous '*.exp' file left behind. I propose to simplify this as per
> the attached "libgomp testsuite:
Hi!
On 2023-05-09T14:59:53+0200, I wrote:
> On 2023-05-09T14:54:21+0200, I wrote:
>> [...] libgomp testsuite is a bit weird [...]: that every '*.exp' file
>> begins with a bunch of conditional 'unset lang_[...]' to clean up what
>> the previous '*.exp' file left behind. I propose to simplify this
This patch fixes a minor code quality issue I found while testing LRA on
the H8. Specifically we have a peephole which converts a comparison of
a memory location against zero into a load + comparison which is
actually more efficient. This triggers when there are registers
available at the rig
Thanks, Richard.
>> Could you go into more details about this? I imagined that for case 3,
>> there would be a single SELECT_VL that decides how many scalar iterations
>> will be handled by the current vector iteration, then we would "expand"
>> the result (using MIN_EXPRs) to the multi-control c
Hi,
Jeff Law writes:
> On 5/3/23 23:49, guojiufu wrote:
>> Hi,
>>
>> On 2023-05-01 03:00, Jeff Law wrote:
>>> On 3/16/23 21:39, Jiufu Guo wrote:
Hi,
When assigning a parameter to a variable, or assigning a variable to
return value with struct type, and the parameter/return
> -Original Message-
> From: Christophe Lyon
> Sent: Tuesday, May 9, 2023 1:19 PM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> Richard Earnshaw ; Richard Sandiford
>
> Cc: Christophe Lyon
> Subject: [PATCH 06/16] arm: add smax/smin expanders for v*hf
>
> This patch adds the miss
Hi Christophe,
> -Original Message-
> From: Christophe Lyon
> Sent: Tuesday, May 9, 2023 1:19 PM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> Richard Earnshaw ; Richard Sandiford
>
> Cc: Christophe Lyon
> Subject: [PATCH 01/16] arm: [MVE intrinsics] add binary_maxvminv shape
>
> T
I am ok with both changes but I tried to build some test cases, and it
seems the changes are caused by options update, not caused by the
riscv_support_vector_misalignment update? so I would like to see the
testcase should split out into a separated patch.
> +/* Return true if the vector misalignme
On 5/9/23 04:22, Jakub Jelinek wrote:
Hi!
http://eel.is/c++draft/dcl.attr#grammar-4 says
"In an attribute-list, an ellipsis may appear only if that attribute's
specification permits it."
and doesn't explicitly permit it on any standard attribute.
The https://wg21.link/p1774r8 paper which introdu
Oh, checked default_builtin_support_vector_misalignment and I realized
we can just remove riscv_support_vector_misalignment at all...
On Tue, May 9, 2023 at 10:18 PM juzhe.zhong wrote:
>
> riscv_support_vector_misalignment update makes some of the testcase check
> fail. I have checked the those
More details for Case 2:
+ _72 = MIN_EXPR ;
+ _75 = MIN_EXPR ;
+ ...
+ .LEN_STORE (vectp_f.8_51, 128B, _75, { 1, 2, 1, 2, 1, 2, 1, 2 }, 0);
+ vectp_f.8_56 = vectp_f.8_51 + 16;
+ .LEN_STORE (vectp_f.8_56, 128B, _72, { 1, 2, 1, 2, 1, 2, 1, 2 }, 0);
+ ...
+
Yes We can remove it but I still keep it here and add comment for TODO.
Since we may want to support it for VLS modes, like ARM SVE, they have Advanced
SIMD modes (128bit VLS mode):
/* Return true if the vector misalignment factor is supported by the
target. */
static bool
aarch64_builtin_
One more question from me: should we just add -fno-vect-cost-model to
AUTOVEC_TEST_OPTS?
On Tue, May 9, 2023 at 10:29 PM Kito Cheng wrote:
>
> Oh, checked default_builtin_support_vector_misalignment and I realized
> we can just remove riscv_support_vector_misalignment at all...
>
>
> On Tue, May
Hi!
On Tue, 9 May 2023 at 11:00, Thomas Schwinge
wrote:
> Hi Christophe!
>
> On 2023-05-09T09:32:55+0200, Christophe Lyon
> wrote:
> > On Wed, 3 May 2023 at 13:47, Richard Biener via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
> >> On Wed, 3 May 2023, Thomas Schwinge wrote:
> >> > "Let each
No, I don't think so. Some testcases the reason I added -fno-vect-cost-model
here is
because we don't have enough patterns to enable some auto-vectorizations.
I add -fno-vect-cost-model to force enable auto-vectorizations for such cases
for testing.
juzhe.zh...@rivai.ai
From: Kito Cheng
Da
Hi All,
Thanks to Steve Kargl for the fix. It caused finalize_8.f03 to fail because
this testcase checked that finalizable derived types could not be specified
in a submodule. I have replaced the original test with a test of the patch.
Thanks also to Malcolm Cohen for guidance on this.
OK for tr
>From 0b5f469171c340ef61a48a31877d495bb77bd35f Mon Sep 17 00:00:00 2001
From: oluade01
Date: Fri, 14 Apr 2023 10:24:43 +0100
Subject: [PATCH 1/4] Missed opportunity to use [SU]ABD
This adds a recognition pattern for the non-widening
absolute difference (ABD).
gcc/ChangeLog:
* doc/md.tex
Hi All,
This problem caused the gimplifier failure because the reference chain
ending in an inquiry_len still retained a full array reference. This had
already been corrected for deferred character lengths but the fix extends
this to all characters without a length expression and integer expressio
Ping.
On 5/3/23 10:19, Patrick O'Neill wrote:
RISC-V has no support for subword atomic operations; code currently
generates libatomic library calls.
This patch changes the default behavior to inline subword atomic calls
(using the same logic as the existing library call).
Behavior can be speci
>From 0b5f469171c340ef61a48a31877d495bb77bd35f Mon Sep 17 00:00:00 2001
From: oluade01
Date: Fri, 14 Apr 2023 10:24:43 +0100
Subject: [PATCH 1/4] Missed opportunity to use [SU]ABD
This adds a recognition pattern for the non-widening
absolute difference (ABD).
gcc/ChangeLog:
* doc/md.tex
>From afa416dab831795f7e1114da2fb9e94ea3b8c519 Mon Sep 17 00:00:00 2001
From: oluade01
Date: Fri, 14 Apr 2023 15:10:07 +0100
Subject: [PATCH 2/4] AArch64: New RTL for ABD
This patch adds new RTL and tests for sabd and uabd
PR tree-optimization/109156
gcc/ChangeLog:
* config/aarch64/aar
After diagnosing and recovering from unstable satisfaction, it's
possible to evaluate an atom for the first time noisily rather than
quietly. The satisfaction cache tries to handle this situation
gracefully, but apparently not gracefully enough: we inserted an empty
slot in the cache, and left it
When processing a noexcept-spec from a nested class after completion of
the outer class (since a noexcept-spec is a complete-class context), we
pass to noexcept_override_late_checks the outer class type instead of
the nested class type, which leads to bogus errors in the below test.
This patch fix
On Tue, 9 May 2023, Patrick Palka wrote:
> After diagnosing and recovering from unstable satisfaction, it's
> possible to evaluate an atom for the first time noisily rather than
> quietly. The satisfaction cache tries to handle this situation
> gracefully, but apparently not gracefully enough: we
On 5/9/23 04:12, Jakub Jelinek wrote:
Hi!
The following testcase shows we silently accept (and ignore) attributes without
arguments used as pack expansions. This is because we call
make_pack_expansion and that starts with
if (!arg || arg == error_mark_node)
return arg;
Now, an attribute
On 5/9/23 15:48, Kyrylo Tkachov wrote:
-Original Message-
From: Christophe Lyon
Sent: Tuesday, May 9, 2023 1:19 PM
To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
Richard Earnshaw ; Richard Sandiford
Cc: Christophe Lyon
Subject: [PATCH 06/16] arm: add smax/smin expanders for v*hf
On 5/9/23 12:35, Patrick Palka wrote:
After diagnosing and recovering from unstable satisfaction, it's
possible to evaluate an atom for the first time noisily rather than
quietly. The satisfaction cache tries to handle this situation
gracefully, but apparently not gracefully enough: we inserted
Thomas,
On Fri, 5 May 2023 10:59:31 +0200
Thomas Schwinge wrote:
> Worth noting is that with nvptx offloading, there is one execution test case
> that times out ('libgomp.fortran/reverse-offload-5.f90'). This effectively
> stalls progress for almost 5 min:
Short of fixing it for real you could
> -Original Message-
> From: Christophe Lyon
> Sent: Tuesday, May 9, 2023 6:18 PM
> To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org;
> Richard Earnshaw ; Richard Sandiford
>
> Subject: Re: [PATCH 06/16] arm: add smax/smin expanders for v*hf
>
>
>
> On 5/9/23 15:48, Kyrylo Tkachov wrote:
On 5/9/23 19:31, Kyrylo Tkachov wrote:
-Original Message-
From: Christophe Lyon
Sent: Tuesday, May 9, 2023 6:18 PM
To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org;
Richard Earnshaw ; Richard Sandiford
Subject: Re: [PATCH 06/16] arm: add smax/smin expanders for v*hf
On 5/9/23 15:48
> -Original Message-
> From: Christophe Lyon
> Sent: Tuesday, May 9, 2023 6:33 PM
> To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org;
> Richard Earnshaw ; Richard Sandiford
>
> Subject: Re: [PATCH 06/16] arm: add smax/smin expanders for v*hf
>
>
>
> On 5/9/23 19:31, Kyrylo Tkachov wrote:
On 5/9/23 12:35, Patrick Palka wrote:
When processing a noexcept-spec from a nested class after completion of
the outer class (since a noexcept-spec is a complete-class context), we
pass to noexcept_override_late_checks the outer class type instead of
the nested class type, which leads to bogus e
aarch64-sve2-acle-asm.exp tried to prevent --with-cpu/tune
from affecting the results, but it used sve_flags rather than
sve2_flags. This was a silent failure when running the full
testsuite, but was a fatal error when running the harness
individually.
Tested on aarch64-linux-gnu, pushed to trunk
1 - 100 of 110 matches
Mail list logo