Scratch the previous one, the "slightly different version" I had before
it was not entirely broken due to unnecessary, suboptimal and incorrect
use of ctz. Here I have yet another implementation of that loop that
should perform better and even work correctly ;-)
This one has so far regstrapped o
On 12/8/23 16:15, Marek Polacek wrote:
On Fri, Dec 08, 2023 at 12:09:18PM -0500, Jason Merrill wrote:
On 12/5/23 15:31, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This test shows that we cannot clear *walk_subtrees in
cp_fold_immediate_r when we'
According to RVV ISA, we can allow vwadd.wv v2, v2, v3 overlap.
Before this patch:
nop
vsetivlizero,4,e8,m4,tu,ma
vle16.v v8,0(a0)
vmv8r.v v0,v8
vwsub.wvv0,v8,v12
nop
addia4,a0,100
vle16.v v8,0(a4)
vmv8r.v
Comply with dubious doc warning that after an @xref there must be a
comma or a period, not a close parentheses.
Build-testing on x86_64-linux-gnu now. Ok to install?
for gcc/ChangeLog
* doc/invoke.texi (multiflags): Add period after @xref to
silence warning.
---
gcc/doc/inv
The recently-added logic for -finline-stringops=memset introduced an
assumption that doesn't necessarily hold, namely, that
can_store_by_pieces of a larger size implies can_store_by_pieces by
smaller sizes. Checks for all sizes the by-multiple-pieces machinery
might use before committing to an e
On aarch64 -milp32, and presumably on other such targets, ptr can be
in a different mode than ptr_mode in the testcase. Cope with it.
Regstrapped on x86_64-linux-gnu, also tested the new test on
aarch64-elf. Ok to install?
for gcc/ChangeLog
PR target/112804
* builtins.cc (t
smallest_int_mode_for_size may abort when the requested mode is not
available. Call int_mode_for_size instead, that signals the
unsatisfiable request in a more graceful way.
Regstrapped on x86_64-linux-gnu. Ok to install?
for gcc/ChangeLog
PR middle-end/112784
* expr.cc (em
On Nov 22, 2023, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, OK for trunk?
FYI, Linaro's regression tester let me know that my patch reversal, that
expected this patch to go in instead, caused two "regressions".
https://linaro.atlassian.net/browse/GNU-1067
--
Alexandre Oliva, happy hack
On Dec 7, 2023, Alexandre Oliva wrote:
> Thanks for raising the issue. Maybe there should be at least a comment
> there, and perhaps some asserts to check that pointer and reference
> types don't make to indirect_parms.
Document why attribute access doesn't need the same treatment as fn
spec,
FAIL: gcc.target/riscv/rvv/autovec/builtin/strcmp-run.c execution test
FAIL: gcc.target/riscv/rvv/autovec/builtin/strcmp-run.c execution test
FAIL: gcc.target/riscv/rvv/autovec/builtin/strcmp-run.c execution test
FAIL: gcc.target/riscv/rvv/autovec/builtin/strcmp-run.c execution test
FAIL: gcc.targe
Although cgit is more efficient than gitweb it still is not great
for bots to go through it.
---
htdocs/robots.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/htdocs/robots.txt b/htdocs/robots.txt
index c650057b..b9fc830d 100644
--- a/htdocs/robots.txt
+++ b/htdocs/robots.txt
@@ -6,6 +6,7
Clean up scan dump failures on linux rv64 vector targets Juzhe mentioned
could be ignored for now. This will help reduce noise and make it more obvious
if a bug or regression is introduced. The failures that are still reported
are either execution failures or failures that are also present on armv
On Tue, 2023-11-21 at 23:43 +, Joseph Myers wrote:
> On Tue, 21 Nov 2023, Tobias Burnus wrote:
>
> > On 21.11.23 14:57, David Malcolm wrote:
> > > On Tue, 2023-11-21 at 02:09 +0100, Hans-Peter Nilsson wrote:
> > > > Sorry for barging in though I did try finding the relevant
> > > > discussion,
On Fri, Dec 08, 2023 at 12:09:18PM -0500, Jason Merrill wrote:
> On 12/5/23 15:31, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > This test shows that we cannot clear *walk_subtrees in
> > cp_fold_immediate_r when we're in_immediate_conte
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-6349-g0bef72539e585d.
gcc/analyzer/ChangeLog:
* sm-taint.cc (taint_state_machine::alt_get_inherited_state): Fix
handling of TRUNC_MOD_EXPR.
gcc/testsuite/ChangeLog:
* c-c++-common/analyze
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-6348-g08262e78209ed4.
gcc/analyzer/ChangeLog:
* region-model.cc (contains_uninit_p): Only check for
svalues that the infoleak warning can handle.
gcc/testsuite/ChangeLog:
* gcc.dg/plugin/
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112875
The patch was successfully tested and bootstrapped on x86-64 and ppc64le.
commit 48cb51827c9eb991b92014a3f59d31eb237ce03f
Author: Vladimir N. Makarov
Date: Fri Dec 8 15:37:42 2023 -0500
[PR112875][LRA]: Fix an
On 12/5/23 12:17, Marek Polacek wrote:
On Tue, Dec 05, 2023 at 06:00:31PM +0100, Jakub Jelinek wrote:
On Tue, Dec 05, 2023 at 09:45:32AM -0500, Marek Polacek wrote:
When working on the previous patch I put [[]] [[]] asm (""); into a
testcase, but was surprised it wasn't parsed.
By wasn't pars
On 12/8/23 12:53, Jakub Jelinek wrote:
On Fri, Dec 08, 2023 at 12:06:01PM -0500, Jason Merrill wrote:
@@ -2,7 +21116,7 @@ cp_parser_elaborated_type_specifier (cp_
}
else if (is_declaration && cp_parser_declares_only_class_p (parser))
cplus_decl_attributes (&type, att
On 12/8/23 12:35, Jakub Jelinek wrote:
On Fri, Dec 08, 2023 at 11:51:19AM -0500, Jason Merrill wrote:
Do we want to do the same for TARGET_EXPR, since those are handled like
SAVE_EXPR in mostly_copy_tree_r?
In mostly_copy_tree_r yes, but I don't see cp_fold doing anything for
TARGET_EXPRs (lik
On 12/6/23 02:33, waffl3x wrote:
Here is the next version, it feels very close to finished. As before, I
haven't ran a bootstrap or the full testsuite yet but I did run the
explicit-obj tests which completed as expected.
There's a few test cases that still need to be written but more tests
can a
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
This one was fixed by r12-7714-g47da5198766256.
PR c++/88848
gcc/testsuite/ChangeLog:
* g++.dg/inherit/multiple2.C: New test.
---
gcc/testsuite/g++.dg/inherit/multiple2.C | 35
1 file changed, 35 i
Excerpts from Yang Yujie's message of Dezember 8, 2023 11:09 am:
> libphobos/ChangeLog:
>
> * m4/druntime/cpu.m4: Support loongarch* targets.
> * libdruntime/Makefile.am: Same.
> * libdruntime/Makefile.in: Regenerate.
> * configure: Regenerate.
> ---
> libphobos/configure
On Fri, Dec 08, 2023 at 12:06:01PM -0500, Jason Merrill wrote:
> > @@ -2,7 +21116,7 @@ cp_parser_elaborated_type_specifier (cp_
> > }
> > else if (is_declaration && cp_parser_declares_only_class_p (parser))
> > cplus_decl_attributes (&type, attributes, (int)
> > ATTR_FLAG_TYPE_
On 12/7/23 03:39, Jakub Jelinek wrote:
On Thu, Dec 07, 2023 at 09:36:22AM +0100, Jakub Jelinek wrote:
So, one way to fix the LRA issue would be just to use
lra_insn_recog_data_len = index * 3U / 2;
if (lra_insn_recog_data_len <= index)
lra_insn_recog_data_len = index + 1;
basically
On Fri, Dec 08, 2023 at 11:51:19AM -0500, Jason Merrill wrote:
> Do we want to do the same for TARGET_EXPR, since those are handled like
> SAVE_EXPR in mostly_copy_tree_r?
In mostly_copy_tree_r yes, but I don't see cp_fold doing anything for
TARGET_EXPRs (like it does for SAVE_EXPRs), so I think T
On 12/5/23 15:31, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This test shows that we cannot clear *walk_subtrees in
cp_fold_immediate_r when we're in_immediate_context, because that,
as the comment says, affects cp_fold_r as well. Here we had an
e
On 12/6/23 09:10, Jakub Jelinek wrote:
On Tue, Dec 05, 2023 at 11:01:20AM -0500, Jason Merrill wrote:
And there is another thing I wonder about: with -Wno-attributes= we are
supposed to ignore the attributes altogether, but we are actually still
warning about them when we emit these generic warn
On 12/7/23 04:28, Jakub Jelinek wrote:
Hi!
The following testcase is miscompiled because two ubsan instrumentations
run into each other.
The first one is the shift instrumentation. Before the C++ FE calls
it, it wraps the 2 shift arguments with cp_save_expr, so that side-effects
in them aren't
On 08.12.23 15:09, Thomas Schwinge wrote:
On 22/11/2023 17:07, Tobias Burnus wrote:
Let's start with the patch itself:
--- a/libgomp/target.c
+++ b/libgomp/target.c
...
+static struct gomp_device_descr *
+get_device_for_page_locked (void)
+{
+ gomp_debug (0, "%s\n",
+ __FUNCTION__);
This fixes a regression caused by my previous VM fixes.
Fix regression causing ICE for structs with VLAs [PR 112488]
A previous patch the fixed several ICEs related to size expressions
of VM types (PR c/70418, ...) caused a regression for structs where
a DECL_EXPR is not generated anymore alth
On Fri, 8 Dec 2023, Jakub Jelinek wrote:
> On Fri, Dec 08, 2023 at 06:43:19PM +0300, Alexander Monakov wrote:
> > On Fri, 8 Dec 2023, Jakub Jelinek wrote:
> > > In your version, did the new function go just to libgcc.a or to
> > > libgcc_s.so.1?
> >
> > It participates in libgcc_s link, but it
early-ra's likely_operand_match_p didn't handle relaxed and special
memory constraints, which meant that the pass wasn't able to match
LD1RQ instructions to their constraints, and so backed out of
trying to allocate. This patch fixes that by switching the sense
of the match: does the rtx seem appr
Ah, I forgot to attach the current v2 that also enables strncmp.
It was additionally tested with -minline-strncmp on rv64gcv.
Regards
Robin
Subject: [PATCH v2] RISC-V: Add vectorized strcmp and strncmp.
This patch adds vectorized strcmp and strncmp implementations and
tests. Similar to strlen,
Sorry, Ezra, but I've taken the decision to back out all 4 of the patch
series' related to this. I think the problems that the CI has shown up
need to be addressed first, and the fixes don't seem to be entirely trivial.
R.
On 07/12/2023 16:44, Richard Earnshaw wrote:
Pushed, thanks.
R.
On
On Fri, Dec 08, 2023 at 06:43:19PM +0300, Alexander Monakov wrote:
> On Fri, 8 Dec 2023, Jakub Jelinek wrote:
> > In your version, did the new function go just to libgcc.a or to
> > libgcc_s.so.1?
>
> It participates in libgcc_s link, but it's not listed in the version script,
> so it's not export
So is it OK for trunk as is in v6 with the generic changes added in GCC-15?
Manos.
Στις Πέμ 7 Δεκ 2023, 16:10 ο χρήστης Richard Biener <
richard.guent...@gmail.com> έγραψε:
> On Thu, Dec 7, 2023 at 1:20 PM Richard Sandiford
> wrote:
> >
> > Richard Biener writes:
> > > On Wed, Dec 6, 2023 at 7
On Fri, 8 Dec 2023, Jakub Jelinek wrote:
> Does VALGRIND_MAKE_MEM_UNDEFINED macro ever change onarches once implemented
> there?
It seems Valgrind folks take binary compatibility seriously, so that sounds
unlikely.
> Wouldn't this be better done by emitting the sequence inline?
> Even if it is
* Jakub Jelinek:
> On Sat, Dec 02, 2023 at 01:43:22PM +0100, Florian Weimer wrote:
>> Some targets do not provide a prototype for fork, and compilation now
>> fails with an implicit-function-declaration error.
>>
>> libgcc/
>>
>> * libgcov-interface.c (__gcov_fork):
>
> Description missing
> > Hi,
> >
> > this is a patch that I submitted two months ago as an RFC. I added some
> > polish
> > since.
> >
> > It is a new lightweight pass that removes redundant PHI functions and as a
> > bonus does basic copy propagation. With Jan Hubička we measured that it is
> > able
> > to remove
> -Original Message-
> From: Richard Biener
> Sent: Friday, December 8, 2023 2:00 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: RE: [PATCH 9/21]middle-end: implement vectorizable_early_exit for
> codegen of exit code
>
> On Fri, 8 Dec 2023,
The 11/13/2023 11:47, Victor Do Nascimento wrote:
> +/* LRCPC atomic support encoded in ID_AA64ISAR1_EL1.Atomic,
> + bits[23:20]. The expected value is 0b0011. Check that. */
> +#define HAS_LRCPC3() ({ \
> + unsigned long val;
The 11/29/2023 15:15, Richard Earnshaw wrote:
> On 13/11/2023 11:37, Victor Do Nascimento wrote:
> > +/* LSE128 atomic support encoded in ID_AA64ISAR0_EL1.Atomic,
> > + bits[23:20]. The expected value is 0b0011. Check that. */
> > +#define HAS_LSE128() ({
On Fri, Dec 08, 2023 at 03:28:59PM +0100, Tobias Burnus wrote:
> This patch fixes the issue:
>
> int a[100];
> p = &a[0];
>
> #pragma omp target map(a)
> p[0] = p[99] = 3;
>
> where 'p' is predetermined firstprivate, i.e. it is firstprivatized
> but its address gets updated to the devi
This patch fixes the issue:
int a[100];
p = &a[0];
#pragma omp target map(a)
p[0] = p[99] = 3;
where 'p' is predetermined firstprivate, i.e. it is firstprivatized
but its address gets updated to the device address of 'a' as there is
associated storage for the value of 'p', i.e. its po
Hi!
On 2023-12-07T13:43:17+, Andrew Stubbs wrote:
> @Thomas, there are questions for you below
It's been a while that I've been working on this; I'll try to produce
some coherent answers now.
> On 22/11/2023 17:07, Tobias Burnus wrote:
>> Let's start with the patch itself:
>>> --- a/lib
On Sat, Dec 02, 2023 at 01:43:22PM +0100, Florian Weimer wrote:
> Some targets do not provide a prototype for fork, and compilation now
> fails with an implicit-function-declaration error.
>
> libgcc/
>
> * libgcov-interface.c (__gcov_fork):
Description missing (Use __builtin_fork instead
On Fri, Dec 08, 2023 at 04:49:49PM +0300, Alexander Monakov wrote:
> I would like to propose Valgrind integration previously sent as RFC for trunk.
>
> Arsen and Sam, since you commented on the RFC I wonder if you can have
> a look at the proposed configure and documentation changes and let me
> k
On Fri, 8 Dec 2023, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Friday, December 8, 2023 10:28 AM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> > Subject: RE: [PATCH 9/21]middle-end: implement vectorizable_early
From: Daniil Frolov
PR 66487 is asking to provide sanitizer-like detection for C++ object
lifetime violations that are worked around with -fno-lifetime-dse or
-flifetime-dse=1 in Firefox, LLVM (PR 106943), OpenJade (PR 69534).
The discussion in the PR was centered around extending MSan, but MSan
I would like to propose Valgrind integration previously sent as RFC for trunk.
Arsen and Sam, since you commented on the RFC I wonder if you can have
a look at the proposed configure and documentation changes and let me
know if they look fine for you? For reference, gccinstall.info will say:
‘--e
On Tue, Nov 28, 2023 at 12:28:05PM +0100, Tobias Burnus wrote:
> I stumbled over this omission when looking at Sandra's patch. It turned out
> that this is
> a new OpenMP 5.2 feature - probably added to simplify/unify the syntax. I
> guess the reason
> that release/acquire wasn't added before is
> -Original Message-
> From: Richard Biener
> Sent: Friday, December 8, 2023 10:28 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: RE: [PATCH 9/21]middle-end: implement vectorizable_early_exit for
> codegen of exit code
>
> On Fri, 8 Dec 2023
Similar to strlen, this now seems safe to push. Will do so
later.
I tested on rv64gcv_zvl128b with -minline-strlen and didn't see
regressions.
Regards
Robin
After Juzhe's vsetvl fix earlier this week this seems safe to push.
Going to do so later.
I tested on rv64gcv_zvl128b with -minline-strlen and didn't see
regressions apart from zbb-strlen-disabled-2.c which will always
fail with -minline-strlen because it expects -mno-inline-strlen.
Regards
Robi
On Fri, Dec 08, 2023 at 12:18:50PM +, Costas Argyris wrote:
> Does the simple XDELETEVEC patch need any more work?
Well, it needs to be actually tested and posted and committed.
I can take care of it in my next bootstraps.
Jakub
On Mon, Nov 20, 2023 at 11:42:02AM +0100, Tobias Burnus wrote:
> 2023-11-19 Tobias Burnus
> Chung-Lin Tang
>
> gcc/ChangeLog:
>
> * builtin-types.def (BT_FN_VOID_PTRMODE):
> (BT_FN_PTRMODE_PTRMODE_INT_PTR): Add.
> * gimplify.cc (gimplify_bind_expr): Diagnose missin
It was updated incorrectly in
commit dbbfb52b0e9c66ee9d05b8fd17c4f44655e48463
Author: Szabolcs Nagy
CommitDate: 2023-12-08 11:29:06 +
libgcc: aarch64: Configure check for __getauxval
so regenerate it.
libgcc/ChangeLog:
* config.in: Regenerate.
---
libgcc/config.in |
Does the simple XDELETEVEC patch need any more work?
I think it just fixes a leak for the JIT case where driver::finalize is
called.
On Thu, 7 Dec 2023 at 16:04, Jakub Jelinek wrote:
> On Thu, Dec 07, 2023 at 04:01:11PM +, Costas Argyris wrote:
> > Thanks for all the explanations.
> >
> > I
On Thu, 2023-12-07 at 20:09 -0500, Antoni Boucher wrote:
> Can I merge this on master even though we're not in phase 1 anymore?
Yes, assuming it passes the regression testsuite.
>
> On Thu, 2023-12-07 at 20:07 -0500, David Malcolm wrote:
> > On Thu, 2023-12-07 at 17:32 -0500, Antoni Boucher wrot
On Wed, Nov 08, 2023 at 05:58:10PM +0100, Tobias Burnus wrote:
> --- a/gcc/builtins.cc
> +++ b/gcc/builtins.cc
> @@ -11739,6 +11739,7 @@ builtin_fnspec (tree callee)
> return ".cO ";
>/* Realloc serves both as allocation point and deallocation point. */
>case BUILT_IN_REALLOC
On Fri, Oct 20, 2023 at 06:49:58PM +0200, Tobias Burnus wrote:
> + if (!processing_template_decl)
> + finish_omp_allocate (true, OMP_CLAUSE_LOCATION (nl), var);
The above should be called even if processing_template_decl, see below.
And pass DECL_ATTRIBUTES (var) to it (also see below).
Hi Harald,
> here's another fix for the CONTIGUOUS attribute: NULL() should
> derive its characteristics from its MOLD argument; otherwise it is
> "determined by the entity with which the reference is associated".
> (F2018:16.9.144).
Looking good to me, but leave 48 hours for someone else to obje
Szabolcs Nagy writes:
> The call ABI for SME (Scalable Matrix Extension) requires a number of
> helper routines which are added to libgcc so they are tied to the
> compiler version instead of the libc version. See
> https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#sme-support-r
The call ABI for SME (Scalable Matrix Extension) requires a number of
helper routines which are added to libgcc so they are tied to the
compiler version instead of the libc version. See
https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#sme-support-routines
The routines are in sh
On Tue, Oct 31, 2023 at 07:59:25AM +, Richard Biener wrote:
> On Wed, 18 Oct 2023, Andre Vieira (lists) wrote:
>
> > This patch moves the call to TARGET_SIMD_CLONE_ADJUST until after the
> > arguments and return types have been transformed into vector types. It also
> > constructs the adjumen
The following avoids spurious uninit diagnostics for SSA name
copies which mostly appear when the source is marked as abnormal
which prevents copy propagation.
To prevent regressions I remove the bail out for anonymous SSA
names in the PHI arg place from warn_uninitialized_phi leaving
that to warn
On Fri, 8 Dec 2023, Tamar Christina wrote:
> > --param vect-partial-vector-usage=2 would, no?
> >
> I.. didn't even know it went to 2!
>
> > > In principal I suppose I could mask the individual stmts, that should
> > > handle the
> > future case when
> > > This is relaxed to supposed non-fix le
Dear all,
here's another fix for the CONTIGUOUS attribute: NULL() should
derive its characteristics from its MOLD argument; otherwise it is
"determined by the entity with which the reference is associated".
(F2018:16.9.144).
The testcase is cross-checked with Intel.
NAG rejects cases where MOLD i
On Fri, Aug 18, 2023 at 11:18:19AM +0800, Zhu, Lipeng wrote:
> From: Lipeng Zhu
>
> This patch try to introduce the rwlock and split the read/write to
> unit_root tree and unit_cache with rwlock instead of the mutex to
> increase CPU efficiency. In the get_gfc_unit function, the percentage
> to s
libphobos/ChangeLog:
* m4/druntime/cpu.m4: Support loongarch* targets.
* libdruntime/Makefile.am: Same.
* libdruntime/Makefile.in: Regenerate.
* configure: Regenerate.
---
libphobos/configure | 21 ++-
libphobos/libdruntime/Makefile.am | 3 +
lib
libphobos/ChangeLog:
* libdruntime/config/loongarch/switchcontext.S: New file.
---
.../config/loongarch/switchcontext.S | 133 ++
1 file changed, 133 insertions(+)
create mode 100644 libphobos/libdruntime/config/loongarch/switchcontext.S
diff --git a/libphobos/l
This patchset is based on Zixing Liu's initial support patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631260.html
Updates
v1 -> v2: Rebased onto the dmd/druntime upstream state.
v2 -> v3: Dropped unnecessary changes.
Regtested on loongarch64-linux-gnu with the following result:
On LoongArch, the regitsters $r4 - $r7 (EH_RETURN_DATA_REGNO) will be saved
and restored in the function prologue and epilogue if the given function calls
__builtin_eh_return. This causes the return value to be overwritten on normal
return paths and breaks a rare case of libgcc's _Unwind_RaiseExce
Sorry, this is the wrong patch. I will post it again.
On Fri, Dec 08, 2023 at 05:57:12PM +0800, Yang Yujie wrote:
> Updates:
> v1 -> v2: Add a test case.
> v2 -> v3: Fix code format.
> v3 -> v4: Fix code format. Avoid unwanted optimization in the test.
>
> On Fri, Dec 08, 2023 at 05:54:46PM +08
Updates:
v1 -> v2: Add a test case.
v2 -> v3: Fix code format.
v3 -> v4: Fix code format. Avoid unwanted optimization in the test.
On Fri, Dec 08, 2023 at 05:54:46PM +0800, Yang Yujie wrote:
> On LoongArch, the regitsters $r4 - $r7 (EH_RETURN_DATA_REGNO) will be saved
> and restored in the functi
On LoongArch, the regitsters $r4 - $r7 (EH_RETURN_DATA_REGNO) will be saved
and restored in the function prologue and epilogue if the given function calls
__builtin_eh_return. This causes the return value to be overwritten on normal
return paths and breaks a rare case of libgcc's _Unwind_RaiseExce
Hi Ajit,
on 2023/12/8 16:01, Ajit Agarwal wrote:
> Hello Kewen:
>
> On 07/12/23 4:31 pm, Ajit Agarwal wrote:
>> Hello Kewen:
>>
>> On 06/12/23 7:52 am, Kewen.Lin wrote:
>>> on 2023/12/6 02:01, Ajit Agarwal wrote:
Hello Kewen:
On 05/12/23 7:13 pm, Ajit Agarwal wrote:
> Hell
Hi Alexandre!
On 2023-12-07T14:52:19-0300, Alexandre Oliva wrote:
> On Dec 7, 2023, Thomas Schwinge wrote:
>> during IPA pass: emutls
>> [...]/source-gcc/gcc/testsuite/c-c++-common/strub-unsupported-3.c:18:1:
>> internal compiler error: in verify_curr_properties, at passes.cc:2198
>
>
Marc Poulhiès writes:
> Should I revert r14-6272 that has the same issue of disabling the
> modified tests on non-x86?
I've reverted the r14-6272.
Marc
On Thu, Nov 16, 2023 at 11:49 AM liuhongt wrote:
>
> Update in V2:
> 1) Add some comments before the pattern.
> 2) Remove ? from view_convert.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk?
>
> When I'm working on PR112443, I notice there's some misoptimizations:
> a
Thomas Schwinge writes:
> Hi Marc!
>
> On 2023-11-06T11:59:18+0100, Marc Poulhiès wrote:
>> These 3 tests fails parsing the 'vect' dump when not using -mavx. Make
>> the dependency explicit.
>
> But that means that the tests are now enabled *only* for
> effective-target 'avx_runtime', so, for
Hi Marc!
On 2023-11-06T11:59:18+0100, Marc Poulhiès wrote:
> These 3 tests fails parsing the 'vect' dump when not using -mavx. Make
> the dependency explicit.
But that means that the tests are now enabled *only* for
effective-target 'avx_runtime', so, for example, on GCN I see:
-PASS: gcc.d
Jakub Jelinek writes:
> This looks wrong, then it won't be tested at all on non-x86 targets.
Right, I'll look for a better fix.
Should I revert r14-6272 that has the same issue of disabling the
modified tests on non-x86?
Marc
> --param vect-partial-vector-usage=2 would, no?
>
I.. didn't even know it went to 2!
> > In principal I suppose I could mask the individual stmts, that should
> > handle the
> future case when
> > This is relaxed to supposed non-fix length buffers?
>
> Well, it looks wrong - either put in an a
Pushed to r14-6317.
在 2023/11/29 上午11:18, Jiahao Xu 写道:
loongarch_expand_vec_cond_mask_expr generates 'subreg's of 'subreg's, which are
not supported
in gcc, it causes an ICE:
ice.c:55:1: error: unrecognizable insn:
55 | }
| ^
(insn 63 62 64 8 (set (reg:V4DI 278)
(subreg:V4
Pushed to r14-6316.
在 2023/11/29 上午11:16, Jiahao Xu 写道:
For [x]vshuf instructions, if the index value in the selector exceeds 63, it
triggers
undefined behavior on LA464, but not on LA664. To ensure compatibility of these
two
tests on both LA464 and LA664, we have modified both tests to ensure
Pushed to r14-6311...r14-6315.
在 2023/12/6 下午3:04, Jiahao Xu 写道:
LoongArch V1.1 adds support for approximate instructions, which are utilized
along with additional
Newton-Raphson steps implement single precision floating-point division, square
root and reciprocal
square root operations for bet
Jakub Jelinek writes:
> On Thu, Dec 07, 2023 at 05:25:39PM +0100, Marc Poulhiès wrote:
>> The 'target_clones' attribute depends on the ifunc support.
>>
>> gcc/testsuite/ChangeLog:
>> * gcc.target/i386/pr105554.c: Add dg-require ifunc.
>> ---
>> Tested on x86_64-linux and x86_64-elf.
>>
>>
Committed, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Friday, December 8, 2023 4:03 PM
To: Li, Pan2 ; gcc-patches
Cc: Li, Pan2 ; Wang, Yanzhang ;
kito.cheng
Subject: Re: [PATCH v1] RISC-V: Fix ICE for incorrect mode attr in
V_F2DI_CONVERT_BRIDGE
LGTM.
__
The following removes the second GIMPLE function dump after
remove_ssa_form which used to rewrite the IL with the coalescing
result but doesn't do so since a long time now.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-outof-ssa.cc (rewrite_out_of_ssa): Dump GIMPLE o
Pushed to r14-6308.
在 2023/11/17 下午5:00, Jiahao Xu 写道:
This patch adds support for xorsign pattern to scalar fp and vector. With the
new expands, uniformly using vector bitwise logical operations to handle
xorsign.
On LoongArch64, floating-point registers and vector registers share the same
r
LGTM.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-12-08 16:00
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Fix ICE for incorrect mode attr in
V_F2DI_CONVERT_BRIDGE
From: Pan Li
The mode attr V_F2DI_CONVERT_BRIDGE converts the floating-po
On Fri, 8 Dec 2023, Jakub Jelinek wrote:
> Hi!
>
> Before bitint lowering, the IL has:
> b.0_1 = b;
> _2 = -b.0_1;
> _3 = (unsigned _BitInt(512)) _2;
> a.1_4 = a;
> a.2_5 = (unsigned _BitInt(512)) a.1_4;
> _6 = _3 * a.2_5;
> on the first function. Now, gimple_lower_bitint has an opti
Hello Kewen:
On 07/12/23 4:31 pm, Ajit Agarwal wrote:
> Hello Kewen:
>
> On 06/12/23 7:52 am, Kewen.Lin wrote:
>> on 2023/12/6 02:01, Ajit Agarwal wrote:
>>> Hello Kewen:
>>>
>>>
>>> On 05/12/23 7:13 pm, Ajit Agarwal wrote:
Hello Kewen:
On 04/12/23 7:31 am, Kewen.Lin wrote:
> H
On Fri, 8 Dec 2023, Jakub Jelinek wrote:
> Hi!
>
> For casts from integers to floating point,
> simplify_float_conversion_using_ranges uses SCALAR_INT_TYPE_MODE
> and queries optabs on the optimization it wants to make.
>
> That doesn't really work for large/huge BITINT_TYPE, those have BLKmode
From: Pan Li
The mode attr V_F2DI_CONVERT_BRIDGE converts the floating-point mode
to the widden floating-point by design. But we take (RVVM1HF "RVVM2SI") by
mistake.
This patch would like to fix it by replacing the
(RVVM1HF "RVVM2SI") to (RVVM1HF "RVVM2SF") as design.
gcc/ChangeLog:
*
97 matches
Mail list logo
