> > 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
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
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
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
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
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
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
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
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
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
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 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 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
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 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
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 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 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 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:
> + /* 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
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:
> + /* 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"
>
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 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
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 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 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, 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 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 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 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
Hi!
I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647445.html
PR111284 P2 patch.
Thanks.
Jakub
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
> 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
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
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
>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
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
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
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)
>
>
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, 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
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 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
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 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 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:
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
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
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
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 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
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
@@ -
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 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
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,
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
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
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
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
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
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,
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
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
64 matches
Mail list logo
