From: Pan Li
This patch would like to allow the RVV intrinsic when function is
attributed as target("arch=+v") and build with rv64gc. For example:
vint32m1_t
__attribute__((target("arch=+v")))
test_1 (vint32m1_t a, vint32m1_t b, size_t vl)
{
return __riscv_vadd_vv_i32m1 (a, b, vl);
}
build w
On Mon, 25 Mar 2024, Chenghui Pan wrote:
> Current document of Tree SSA passes contains many parts that is not
> updated for many years.
>
> This patch removes some info that is outdated and not existed in
> current GCC codebase, and fixes some wrong code location descriptions
> based on current
gcc/ChangeLog:
* config.gcc (aarch64-*-rtems*): Add target makefile fragment
t-aarch64-rtems.
* config/aarch64/t-aarch64-rtems: New file.
---
gcc/config.gcc | 1 +
gcc/config/aarch64/t-aarch64-rtems | 41 ++
2 files changed,
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
I'm not 100% sure I've covered all places where this needs to be handled
but so far this passes all the testcases I have.
-- >8 --
This patch fixes a number of issues with the handling of temploid friend
declarations.
The primary
This patch adds the smin/smax RTL mode for the
min/max.fmt instructions.
Also, since the min/max.fmt instrucions applies to the
IEEE 754-2008 "minNum" and "maxNum" operations, this
patch also provides the new "fmin3" and
"fmax3" modes.
gcc/ChangeLog:
* config/mips/i6400.md (i6400_fpu_min
Current document of Tree SSA passes contains many parts that is not
updated for many years.
This patch removes some info that is outdated and not existed in
current GCC codebase, and fixes some wrong code location descriptions
based on current codebase status and ChangeLogs.
Changes since v1: Add
On Mon, 25 Mar 2024, Chenghui Pan wrote:
> Current document of Tree SSA passes contains many parts that is not
> updated for many years.
>
> This patch removes some info that is outdated and not existed in
> current GCC codebase, and fixes some wrong code location descriptions
> based on current
Hi,
On 3/22/24 21:14, Max Filippov wrote:
libgcc/
* unwind-arm-common.inc (__gnu_personality_sigframe_fdpic): Cast
last argument of _Unwind_VRS_Set to void *.
---
libgcc/unwind-arm-common.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libgcc/unwind-arm
Due to the Linux kernel exposing the lrcpc3 architectural feature as
"lrcpc3", this patch corrects the relevant FEATURE_STRING entry in the
"rcpc3" AARCH64_OPT_FMV_EXTENSION macro, such that the feature can be
correctly detected when doing native compilation on rcpc3-enabled
targets.
Regtested on
Hi Victor,
> -Original Message-
> From: Victor Do Nascimento
> Sent: Monday, March 25, 2024 10:59 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Sandiford
> ; Richard Earnshaw
> ; Victor Do Nascimento
>
> Subject: [PATCH] aarch64: Align lrcpc3 FEAT_STRING with /proc/cpui
Add support for the gfx1036 RDNA2 APU integrated graphics devices. The ROCm
documentation warns that these may not be supported, but it seems to work
at least partially.
x86 host bootstrap/regtest running, target-libgomp testing for the
offload produces results comparable to those of gfx1030. Th
Hi!
I've committed the following patch to add the new CWG papers (and filed
corresponding bugzilla bugs).
diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html
index 65030980..bfef2114 100644
--- a/htdocs/projects/cxx-status.html
+++ b/htdocs/projects/cxx-status.html
@@ -
On 3/21/24 10:28 PM, Jason Merrill wrote:
On 3/21/24 16:48, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
This started to break
$ cat test.cc
struct S1 { S1(); };
struct S2 {
S2() {}
S1 a[1] {};
};
$ g++ -fsyntax-only test.cc
test.cc: In c
LGTM, thanks :)
On Mon, Mar 25, 2024 at 3:42 PM wrote:
>
> From: Pan Li
>
> This patch would like to allow the RVV intrinsic when function is
> attributed as target("arch=+v") and build with rv64gc. For example:
>
> vint32m1_t
> __attribute__((target("arch=+v")))
> test_1 (vint32m1_t a, vint32m
On Mon, Mar 25, 2024 at 12:36:46PM +0100, Stephan Bergmann wrote:
> On 3/21/24 10:28 PM, Jason Merrill wrote:
> > On 3/21/24 16:48, Marek Polacek wrote:
> > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > OK.
>
> This started to break
>
> > $ cat test.cc
> > struct S1 { S1
Committed, thanks kito.
Pan
-Original Message-
From: Kito Cheng
Sent: Monday, March 25, 2024 8:04 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; Wang, Yanzhang
Subject: Re: [PATCH v1] RISC-V: Allow RVV intrinsic when function
target("arch=+v")
LGTM, thanks :)
O
Tested aarch64-linux. Puhed to trunk.
-- >8 --
This was a copy & paste error.
libstdc++-v3/ChangeLog:
* testsuite/std/text_encoding/requirements.cc: #undef the
correct macro.
---
libstdc++-v3/testsuite/std/text_encoding/requirements.cc | 2 +-
1 file changed, 1 insertion(+), 1
On 3/25/24 13:07, Jakub Jelinek wrote:
On Mon, Mar 25, 2024 at 12:36:46PM +0100, Stephan Bergmann wrote:
This started to break
$ cat test.cc
struct S1 { S1(); };
struct S2 {
S2() {}
S1 a[1] {};
};
$ g++ -fsyntax-only test.cc
test.cc: In constructor ‘S2::S2()’:
test.cc:3:10: error:
On Tue, Mar 12, 2024 at 07:57:59PM +0800, liuhongt wrote:
> if alignb > ASAN_RED_ZONE_SIZE and offset[0] is not multiple of
> alignb. (base_align_bias - base_offset) may not aligned to alignb, and
> caused segement fault.
>
> Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
> Ok for trunk an
On 21/03/2024 10:41, Thomas Schwinge wrote:
Hi!
OK to push the attached
"GCN: Enable effective-target 'vect_hw_misalign'"? (Or is that not what
you'd expect to see for GCN? I haven't checked the actual back end
code...)
OK.
Andrew.
On 21/03/2024 10:41, Thomas Schwinge wrote:
Hi!
OK to push the attached "GCN: Enable effective-target 'vect_long_mult'"?
(Or is that not what you'd expect to see for GCN? I haven't checked the
actual back end code...)
OK.
Andrew
Hi,
After the backport off PR target/112787 a failure was reported against
x86_64, this would be fixed by backporting:
* tree-optimization/91838 - fix FAIL of g++.dg/opt/pr91838.C
(d1c072a1c3411a6fe29900750b38210af8451eeb)
* tree-optimization/110838 - less aggressively fold out-of-bound shifts
On Mon, 25 Mar 2024, Andre Vieira (lists) wrote:
> Hi,
>
> After the backport off PR target/112787 a failure was reported against x86_64,
> this would be fixed by backporting:
> * tree-optimization/91838 - fix FAIL of g++.dg/opt/pr91838.C
> (d1c072a1c3411a6fe29900750b38210af8451eeb)
> * tree-opti
Richard Biener wrote:
I'll follow up with the libgomp testing test summary for archival
purposes. I still see linker errors for testcases using -g
(the ld: ^[[0;31merror: ^[[0mincompatible mach:
/tmp/ccr0oDpD.mkoffload.dbg.o^M kind)
Hmm, odd – can you try compile with -save-temp and look at th
On Mon, 25 Mar 2024, Tobias Burnus wrote:
> Richard Biener wrote:
> > I'll follow up with the libgomp testing test summary for archival
> > purposes. I still see linker errors for testcases using -g
> > (the ld: ^[[0;31merror: ^[[0mincompatible mach:
> > /tmp/ccr0oDpD.mkoffload.dbg.o^M kind)
>
>
On 25/03/2024 11:27, Richard Biener wrote:
Add support for the gfx1036 RDNA2 APU integrated graphics devices. The ROCm
documentation warns that these may not be supported, but it seems to work
at least partially.
x86 host bootstrap/regtest running, target-libgomp testing for the
offload produce
Ping!
Rgds,
Yvan
From: Torbjorn SVENSSON - foss
Sent: Friday, March 15, 2024 11:32 AM
To: David Malcolm; Alexandre Oliva
Cc: gcc-patches@gcc.gnu.org; Yvan ROUX - foss
Subject: [PING^3] Re: [PATCH] analyzer: deal with -fshort-enums
Ping!
Kind regards,
Torb
>From b34312d82b236601c348382d30e625558f37d40c Mon Sep 17 00:00:00 2001
From: centurion
Date: Mon, 25 Mar 2024 01:57:21 +0400
Subject: [PATCH] c++: fix alias CTAD [PR114377]
PR c++/114377
gcc/cp/ChangeLog:
PR c++/114377
* pt.cc (find_template_parameter_info::found): Use TREE_TYP
On Mon, 25 Mar 2024, Richard Biener wrote:
> Add support for the gfx1036 RDNA2 APU integrated graphics devices. The ROCm
> documentation warns that these may not be supported, but it seems to work
> at least partially.
>
> x86 host bootstrap/regtest running, target-libgomp testing for the
> offl
Wow, thank you all, you guys!
在 2024年3月14日星期四，Jonathan Wakely 写道：
> On Fri, 16 Feb 2024 at 15:15, Jonathan Wakely wrote:
> >
> > On Fri, 16 Feb 2024 at 14:10, Jakub Jelinek wrote:
> > >
> > > On Fri, Feb 16, 2024 at 01:51:54PM +, Jonathan Wakely wrote:
> > > > Ah, although __atomic_compare_e
> So where do we stand with this? Juzhe asked it to be rebased, but I
> don't see a rebased version in my inbox and I don't see anything that
> looks like this on the trunk.
I missed this one and figured as we're pretty late in the cycle it can
wait until GCC 15. Therefore let's call it "deferre
On Fri, Mar 22, 2024 at 1:15 PM Max Filippov wrote:
>
> libgcc/
> * unwind-arm-common.inc (__gnu_personality_sigframe_fdpic): Cast
> last argument of _Unwind_VRS_Set to void *.
> ---
> libgcc/unwind-arm-common.inc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Build-test
Hi!
I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647445.html
PR111284 P2 patch.
Thanks.
Jakub
On 3/22/24 17:30, Marek Polacek wrote:
On Thu, Mar 21, 2024 at 05:27:37PM -0400, Jason Merrill wrote:
On 3/21/24 17:01, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Patrick noticed that my r14-9339-gdc6c3bfb59baab patch is wrong;
we're dealing with
On 3/22/24 05:11, Jakub Jelinek wrote:
Hi!
I've noticed that the c-c++-common/gomp/depobj-3.c test FAILs on i686-linux:
PASS: c-c++-common/gomp/depobj-3.c -std=c++17 at line 17 (test for warnings,
line 15)
FAIL: c-c++-common/gomp/depobj-3.c -std=c++17 at line 39 (test for warnings,
line 37
On Mon, 2024-03-18 at 20:54 -0600, Jeff Law wrote:
> > +/* Costs to use when optimizing for xiangshan nanhu. */
> > +static const struct riscv_tune_param xiangshan_nanhu_tune_info = {
> > + {COSTS_N_INSNS (3), COSTS_N_INSNS (3)}, /* fp_add */
> > + {COSTS_N_INSNS (3), COSTS_N_INSNS (3)}, /* fp
On Mon, Mar 25, 2024 at 01:39:39PM +0100, Stephan Bergmann wrote:
> On 3/25/24 13:07, Jakub Jelinek wrote:
> > On Mon, Mar 25, 2024 at 12:36:46PM +0100, Stephan Bergmann wrote:
> > > This started to break
> > >
> > > > $ cat test.cc
> > > > struct S1 { S1(); };
> > > > struct S2 {
> > > > S2(
On 3/25/24 1:48 PM, Xi Ruoyao wrote:
On Mon, 2024-03-18 at 20:54 -0600, Jeff Law wrote:
+/* Costs to use when optimizing for xiangshan nanhu. */
+static const struct riscv_tune_param xiangshan_nanhu_tune_info = {
+ {COSTS_N_INSNS (3), COSTS_N_INSNS (3)}, /* fp_add */
+ {COSTS_N_INSNS
On Mon, 25 Mar 2024 12:59:14 PDT (-0700), Jeff Law wrote:
On 3/25/24 1:48 PM, Xi Ruoyao wrote:
On Mon, 2024-03-18 at 20:54 -0600, Jeff Law wrote:
+/* Costs to use when optimizing for xiangshan nanhu. */
+static const struct riscv_tune_param xiangshan_nanhu_tune_info = {
+ {COSTS_N_INSNS (3)
On 3/25/24 2:13 PM, Palmer Dabbelt wrote:
On Mon, 25 Mar 2024 12:59:14 PDT (-0700), Jeff Law wrote:
On 3/25/24 1:48 PM, Xi Ruoyao wrote:
On Mon, 2024-03-18 at 20:54 -0600, Jeff Law wrote:
+/* Costs to use when optimizing for xiangshan nanhu. */
+static const struct riscv_tune_param xiang
On Mon, 25 Mar 2024 13:27:34 PDT (-0700), Jeff Law wrote:
On 3/25/24 2:13 PM, Palmer Dabbelt wrote:
On Mon, 25 Mar 2024 12:59:14 PDT (-0700), Jeff Law wrote:
On 3/25/24 1:48 PM, Xi Ruoyao wrote:
On Mon, 2024-03-18 at 20:54 -0600, Jeff Law wrote:
+/* Costs to use when optimizing for xiangs
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
https://translationproject.org/latest/gcc/de.po
(This file, 'gcc-14.1-b20240218.de.po',
On Wed, 20 Mar 2024, Qing Zhao wrote:
> + /* This attribute only applies to a C99 flexible array member type. */
> + else if (! c_flexible_array_member_type_p (TREE_TYPE (decl)))
> +{
> + error_at (DECL_SOURCE_LOCATION (decl),
> + "%qE attribute is not allowed for a non"
>
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
-- >8 --
The below testcases use a lambda-expr as a template argument and they
all trip over the below added tsubst_lambda_expr sanity check ultimately
because current_template_parms is empty, which causes push_templa
On Wed, 20 Mar 2024, Qing Zhao wrote:
> + /* get the TYPE of the counted_by field. */
Start comments with an uppercase letter.
> + The type of the first argument of this function is a POINTER type
> + to the orignal flexible array type.
s/orignal/original/
> + If HANDLE_COUNTED_BY
On 3/25/24 2:31 PM, Palmer Dabbelt wrote:
On Mon, 25 Mar 2024 13:27:34 PDT (-0700), Jeff Law wrote:
I'd doubt it's worth the complexity. Picking some reasonable value gets
you the vast majority of the benefit. Something like
COSTS_N_INSNS(6) is enough to get CSE to trigger. So what's le
On Wed, 20 Mar 2024, Qing Zhao wrote:
> + the size of the element can be retrived from the result type of the call,
> + which is the pointer to the array type. */
Again, start a sentence with an uppercase letter.
> + /* if not for dynamic object size, return. */
> + /* result type is a
On Mon, 25 Mar 2024, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> for trunk?
>
> -- >8 --
>
> The below testcases use a lambda-expr as a template argument and they
> all trip over the below added tsubst_lambda_expr sanity check ultimately
> becaus
On Mon, 25 Mar 2024 13:49:18 PDT (-0700), jeffreya...@gmail.com wrote:
On 3/25/24 2:31 PM, Palmer Dabbelt wrote:
On Mon, 25 Mar 2024 13:27:34 PDT (-0700), Jeff Law wrote:
I'd doubt it's worth the complexity. Picking some reasonable value gets
you the vast majority of the benefit. Somethi
On 3/25/24 2:57 PM, Palmer Dabbelt wrote:
On Mon, 25 Mar 2024 13:49:18 PDT (-0700), jeffreya...@gmail.com wrote:
On 3/25/24 2:31 PM, Palmer Dabbelt wrote:
On Mon, 25 Mar 2024 13:27:34 PDT (-0700), Jeff Law wrote:
I'd doubt it's worth the complexity. Picking some reasonable value
gets
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
can_init_array_with_p is wrongly saying that the init for 's' here:
struct S {
int *list = arr;
int arr[];
};
struct A {
A() {}
S s[2]{};
};
is invalid. But as process_init_constructor_array says, for
On 3/25/24 17:59, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
can_init_array_with_p is wrongly saying that the init for 's' here:
struct S {
int *list = arr;
int arr[];
};
struct A {
A() {}
S s[2]{};
};
is i
On Mon, Mar 25, 2024 at 03:40:10PM -0400, Jason Merrill wrote:
> On 3/22/24 17:30, Marek Polacek wrote:
> > On Thu, Mar 21, 2024 at 05:27:37PM -0400, Jason Merrill wrote:
> > > On 3/21/24 17:01, Marek Polacek wrote:
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > > >
> > >
On Sat, Mar 23, 2024 at 4:32 AM Дилян Палаузов
wrote:
>
> Can the build experts say what needs to be changed? The dependencies I added
> are missing in the build configuration (@if gcc-bootstrap).
>
> I cannot say if libbacktrace should or should not be a bootstrap=true module.
I don't count as
On Sun, Mar 24, 2024 at 8:46 PM Chenghui Pan wrote:
>
> Current document of Tree SSA passes contains many parts that is not
> updated for many years.
>
> This patch removes some info that is outdated and not existed in
> current GCC codebase, and fixes some wrong code location descriptions
> based
I think it's harmless to let this patch in GCC-14.
So LGTM from my side to land this path in GCC-14..
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-03-26 01:07
To: Jeff Law; 钟居哲; gcc-patches; palmer; kito.cheng
CC: rdapp.gcc
Subject: Re: [PATCH] RISC-V: Add initial cost handling for segment
Seems right. I will reference them.
Also I think maybe some documents for the passes are still missing and
we can add them
in the future...
On 2024/3/26 08:11, Andrew Pinski wrote:
On Sun, Mar 24, 2024 at 8:46 PM Chenghui Pan wrote:
Current document of Tree SSA passes contains many parts t
Current document of Tree SSA passes contains many parts that is not
updated for many years.
This patch removes some info that is outdated and not existed in
current GCC codebase, and fixes some wrong code location descriptions
based on current codebase status and ChangeLogs.
Changes since v1:
* v
Jie Mei 于2024年3月25日周一 17:46写道：
>
> This patch adds the smin/smax RTL mode for the
> min/max.fmt instructions.
>
> Also, since the min/max.fmt instrucions applies to the
> IEEE 754-2008 "minNum" and "maxNum" operations, this
> patch also provides the new "fmin3" and
> "fmax3" modes.
>
> gcc/ChangeL
Hi all,
There has been a bit of discussio on which way to go on this.
I took a look today and this trivial patch gives the behavior concluded
on Fortran Discourse. See the bugzilla for all the relevant information.
Regresion tested on x86-64.
I will do the appropriate changelog.
OK for trun
On Mon, Mar 25, 2024 at 8:51 PM Jakub Jelinek wrote:
>
> On Tue, Mar 12, 2024 at 07:57:59PM +0800, liuhongt wrote:
> > if alignb > ASAN_RED_ZONE_SIZE and offset[0] is not multiple of
> > alignb. (base_align_bias - base_offset) may not aligned to alignb, and
> > caused segement fault.
> >
> > Boots
On Tue, Mar 26, 2024 at 11:26 AM Hongtao Liu wrote:
>
> On Mon, Mar 25, 2024 at 8:51 PM Jakub Jelinek wrote:
> >
> > On Tue, Mar 12, 2024 at 07:57:59PM +0800, liuhongt wrote:
> > > if alignb > ASAN_RED_ZONE_SIZE and offset[0] is not multiple of
> > > alignb. (base_align_bias - base_offset) may no
Ping!
please review.
Thanks & Regards
Jeevitha
On 26/02/24 11:13 am, jeevitha wrote:
> Hi All,
>
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>
> PR110040 exposes an issue concerning moves from vector registers to GPRs.
> There are two moves, one for upper 6
> > So, try to add some other variable with larger size and smaller alignment
> > to the frame (and make sure it isn't optimized away).
> >
> > alignb above is the alignment of the first partition's var, if
> > align_frame_offset really needs to depend on the var alignment, it probably
> > should b
64 matches
Mail list logo
