Vladimir Makarov writes:
> On 1/11/25 1:15 PM, Denis Chertykov wrote:
>> The fix for PR117868.
>>
>> In brief:
>> this is an LRA bug derived from reuse spilling slots after frame
>> pointer spilling.
>> The slot was created for QImode (1 byte) and it was reused after
>> spilling of the
>> frame p
Unlike other access patterns, BIT_FIELD_REFs aren't regarded as
possibly-trapping out of referencing out-of-bounds bits.
So, if decode_field_reference finds a load that could trap, but whose
inner object can't, bail out if it accesses past the inner object's
size.
This may drop some ifcombine o
On 1/17/25 3:21 PM, Jakub Jelinek wrote:
Hi!
This is the third bug discovered today with the
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673945.html
hack but then turned into proper testcases where embed-24.C FAILed
since introduction of optimized #embed support and the others when
op
On Linux/x86_64,
9f009e8865cda01310c52f7ec8bdaa3c557a2745 is the first bad commit
commit 9f009e8865cda01310c52f7ec8bdaa3c557a2745
Author: Vladimir N. Makarov
Date: Fri Jan 17 15:56:29 2025 -0500
[PR118067][LRA]: Check secondary memory mode for the reg class
caused
FAIL: gcc.target/i386/p
Thanks, I will fix it.
> Mark Wielaard 於 2025年1月17日 晚上10:32 寫道：
>
> Hi Monk,
>
>> On Fri, Nov 15, 2024 at 06:53:09PM +0800, Monk Chiang wrote:
>> gcc/ChangeLog:
>>* gcc/config/riscv/riscv.cc
>>(riscv_file_end_indicate_exec_stack): Add .note.gnu.property.
>>* gcc/config/riscv/linux.
On 1/17/25 3:08 PM, Jakub Jelinek wrote:
Hi!
This is the first bug discovered today with the
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673945.html
hack but then turned into proper testcases where embed-21.C FAILed
since introduction of optimized #embed support and the other when
opt
On 1/17/25 1:31 PM, Marek Polacek wrote:
On Fri, Jan 17, 2025 at 08:10:24AM -0500, Jason Merrill wrote:
On 1/16/25 8:04 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
The recent r15-6369 unfortunately caused a bad wrong-code issue.
Here we have
On Fri, Jan 17, 2025 at 3:14 PM Joseph Myers wrote:
>
> On Fri, 17 Jan 2025, Qing Zhao wrote:
>
> > struct fc_bulk {
> > ...
> > struct fs_bulk fs_bulk;
> > struct fc fcs[] __counted_by(fs_bulk.len);
> > };
> >
> > i.e, the “counted_by” field is in the inner structure of the current
> > st
On Fri, 17 Jan 2025, Qing Zhao wrote:
> struct fc_bulk {
> ...
> struct fs_bulk fs_bulk;
> struct fc fcs[] __counted_by(fs_bulk.len);
> };
>
> i.e, the “counted_by” field is in the inner structure of the current
> structure of the FAM.
> With the current syntax, it’s not easy to extend to
On 1/11/25 1:15 PM, Denis Chertykov wrote:
The fix for PR117868.
In brief:
this is an LRA bug derived from reuse spilling slots after frame
pointer spilling.
The slot was created for QImode (1 byte) and it was reused after
spilling of the
frame pointer for TImode register (16 bytes long) and
On Fri, 17 Jan 2025, Jakub Jelinek wrote:
> Bootstrapped on x86_64-linux and i686-linux, regtest ongoing, ok for trunk
> if it passes?
>
> 2025-01-17 Jakub Jelinek
>
> gcc/c/
> * c-decl.cc (names_builtin_p): Return 1 for RID_C23_VA_START and
> RID_VA_ARG.
> gcc/cp/
> * cp-ob
Folks,
we'd appreciate it if someone could take the time to review this fix
for PR116845.
Thanks,
Philipp.
On Tue, 31 Dec 2024 at 10:03, Konstantinos Eleftheriou
wrote:
>
> From: kelefth
>
> `(A * B) + (-C) to (B - C/A) * A` fails to match on ILP32 targets due to
> the upper bits of CST0 bei
On 1/17/25 9:52 AM, Simon Martin wrote:
Hi Jason,
On 16 Jan 2025, at 22:49, Jason Merrill wrote:
On 10/16/24 11:43 AM, Simon Martin wrote:
As you know the patch had to be reverted due to PR117114, that
highlighted a bunch of issues with comparing DECL_VINDEXes: it might
give false positives i
Hi Jerry,
Am 17.01.25 um 22:04 schrieb Jerry Delisle:
Looks Ok by me.
Committed and pushed r15-7009-gca2681d45a4507 .
Thanks,
Harald
Thanks,
Jerry
On Fri, Jan 17, 2025, 12:25 PM Harald Anlauf wrote:
Dear all,
the attached obvious patch extends G formatting to UNSIGNED by reusing
the c
On Fri, Jan 17, 2025 at 8:02 AM Qing Zhao wrote:
> Joseph, Kees and Bill,
>
> I need your input on this.
> > On Jan 17, 2025, at 10:12, Martin Uecker wrote:
> >
> > Am Donnerstag, dem 16.01.2025 um 21:18 + schrieb Qing Zhao:
> >>
> > ..
> >>
> >> Although in the previous discussion, I agreed
Looks Ok by me.
Thanks,
Jerry
On Fri, Jan 17, 2025, 12:25 PM Harald Anlauf wrote:
> Dear all,
>
> the attached obvious patch extends G formatting to UNSIGNED by reusing
> the code for I formatting.
>
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
>
> Thanks,
> Harald
>
>
This is one more patch to solve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118067
with different -mcpu used.
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64le.
commit 9f009e8865cda01310c52f7ec8bdaa3c557a2745
Author: Vladimir N. Makarov
Date: Fri Jan 17 1
Hi!
The Linux kernel uses its own copy of stdarg.h.
Now, before GCC 15, our stdarg.h had
#if defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L
#define va_start(v, ...)__builtin_va_start(v, 0)
#else
#define va_start(v,l) __builtin_va_start(v,l)
#endif
va_start definition but GCC 15 h
Dear all,
the attached obvious patch extends G formatting to UNSIGNED by reusing
the code for I formatting.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 5ba7e37a089257dc40e9f347a835a481121a3f3f Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 17 Jan 2025 21:2
Hi!
This is the third bug discovered today with the
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673945.html
hack but then turned into proper testcases where embed-24.C FAILed
since introduction of optimized #embed support and the others when
optimizing large C++ initializers using RAW_D
Hi!
This is the second bug discovered today with the
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673945.html
hack but then turned into proper testcases where embed-2[23].C FAILed
since introduction of optimized #embed support and the others when
optimizing large C++ initializers using R
Hi!
This is the first bug discovered today with the
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673945.html
hack but then turned into proper testcases where embed-21.C FAILed
since introduction of optimized #embed support and the other when
optimizing large C++ initializers using RAW_DA
Hi!
With the https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673945.html
hack we get slightly different error wording in one of the errors, given that
the test actually does use #embed, I think both wordings are just fine and
we should accept them.
Tested on x86_64-linux, committed to trun
Hi!
I'd like to revert the r15-6448-gd09628742bb17719360ff447a8e604f5c6801bdf
reversion (of course without doing git revert of that because that breaks
ChangeLog generation) soon.
In order to do that and feel comfortable about that, I've performed
an x86_64-linux and i686-linux bootstrap/regtest
From: Alfie Richards
Appologies, forgot to commit my changes before sending.
Alfie Richards (1):
Add warning for non-spec compliant FMV in Aarch64
gcc/config/aarch64/aarch64.cc | 9 +
gcc/config/aarch64/aarch64.opt | 4
gcc/doc/invoke.texi
This patch adds a warning when FMV is used for Aarch64.
The reasoning for this is the ACLE [1] spec for FMV has diverged
significantly from the current implementation and we want to prevent
potential future compatability issues.
There is a patch for an ACLE compliant version of target_version an
This patch adds a warning when FMV is used for Aarch64.
The reasoning for this is the ACLE [1] spec for FMV has diverged
significantly from the current implementation and we want to prevent
potential future compatability issues.
There is a patch for an ACLE compliant version of target_version an
From: Alfie Richards
Hi,
Thank you Richard for catching that!
It's good to know about keeping it around.
Rebased onto master, fixed up a new test, and addressed your comment.
Kind regards,
Alfie
Alfie Richards (1):
Add warning for non-spec compliant FMV in Aarch64
gcc/config/aarch64/aarch
Hi,
This patch backports the individual fix for PR117115 from the upstream
merge in r15-6824 into the releases/gcc-14 branch.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32, and
committed to branch.
Regards,
Iain.
---
PR d/117115
gcc/testsuite/ChangeLog:
* gdc.dg/
Hi,
This patch adds a testcase for a PR that was fixed in upstream, and
merged in r15-6824.
Regression tested on x86_64-linux-gnu, and committed to mainline.
Regards,
Iain.
---
PR d/117115
gcc/testsuite/ChangeLog:
* gdc.dg/pr117115.d: New test.
---
gcc/testsuite/gdc.dg/pr1171
On Fri, Jan 17, 2025 at 08:10:24AM -0500, Jason Merrill wrote:
> On 1/16/25 8:04 PM, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > The recent r15-6369 unfortunately caused a bad wrong-code issue.
> > Here we have
> >
> >TARGET_EXPR
On 1/17/25 4:26 AM, Jakub Jelinek wrote:
Hi!
The following testcase ICEs in import_export_decl.
When cp_finish_decomp handles std::tuple* using structural binding,
it calls copy_linkage to copy various VAR_DECL flags from the structured
binding base to the individual sb variables.
In this case t
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Friday, January 17, 2025 3:10 PM
> To: Richard Sandiford
> Cc: Tamar Christina ; GCC Patches patc...@gcc.gnu.org>; nd ; Richard Earnshaw
> ; ktkac...@gcc.gnu.org
> Subject: Re: [PATCH]AArch64: Drop ILP32 from default elf multilibs after
On Fri, 17 Jan 2025, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> In the linked testcase, we're erroring because the declared return types
> of the functions do not appear to match. This is because when merging
> the deduced return t
Hi, Bill,
Thanks a lot for your testing case.
I studied this testing case and realized that we need to decide
what’s the expected behavior for the following situation:
struct bar;
struct a {
int dummy;
struct bar *array __attribute__((counted_by(count)));
char count;
};
when the siz
writes:
> This patch adds a warning when FMV is used for Aarch64.
>
> The reasoning for this is the ACLE [1] spec for FMV has diverged
> significantly from the current implementation and we want to prevent
> potential future compatability issues.
>
> There is a patch for an ACLE compliant version
Georg-Johann Lay writes:
> Most of the avr built-in functions can be attributed "const".
>
> Ok for trunk?
>
Ok.
Denis.
> Johann
>
> --
>
> AVR: Add "const" attribute to avr built-in functions if possible.
>
> gcc/
> * config/avr/avr-c.cc (DEF_BUILTIN): Add ATTRS argument to macro
>
Joseph, Kees and Bill,
I need your input on this.
> On Jan 17, 2025, at 10:12, Martin Uecker wrote:
>
> Am Donnerstag, dem 16.01.2025 um 21:18 + schrieb Qing Zhao:
>>
> ..
>>
>> Although in the previous discussion, I agreed with Martin that we should use
>> the
>> designator syntax (i.
Kewen:
Sorry for the delay in getting the patch committed. Thanks for all the
help.
Carl
On 11/24/24 5:43 AM, Kewen Lin wrote:
rs6000, Remove redundant built-in __builtin_vsx_xvcvuxwdp
The built-in __builtin_vsx_xvcvuxwdp can be covered with PVIPR
functi
Kewen:
OK, thanks for the approval. Sorry for the delay in getting it committed.
Carl
On 11/24/24 5:43 AM, Kewen Lin wrote:
---
rs6000, remove built-ins __builtin_vsx_vperm
Kewen:
I fixed the space issue and moved the sll, ull and bll together. Sorry
for the delay in getting the patch committed.
Thanks for all the help.
Carl
On 11/24/24 5:43 AM, Kewen Lin wrote:
extern __vector int si[][4];
extern __vector short ss[][4];
exter
Kewen:
Thanks for the approval. Sorry for the delay in getting this
committed. I made the fix requested and retested the patch on the most
recent mainline. I will get this committed. Thanks for all the help.
Carl
On 11/24/24 5:42 AM, Kewen Lin wrote:
rs6000, f
> On 17 Jan 2025, at 15:01, Richard Sandiford wrote:
>
> Tamar Christina writes:
>>> -Original Message-
>>> From: Richard Sandiford
>>> Sent: Friday, January 10, 2025 4:50 PM
>>> To: Akram Ahmad
>>> Cc: ktkac...@nvidia.com; gcc-patches@gcc.gnu.org
>>> Subject: Re: [PATCH v3 1/2] aar
In g:b096a6ebe9d9f9fed4c105f6555f724eb32af95c I'd forgotten
to gate some uses of INS on TARGET_SIMD.
Tested on aarch64-linux-gnu. I'll push around this time on Monday
if there are no comments before then.
Richard
gcc/
PR target/118531
* config/aarch64/aarch64.md (*insv_reg_)
Am Donnerstag, dem 16.01.2025 um 21:18 + schrieb Qing Zhao:
>
..
>
> Although in the previous discussion, I agreed with Martin that we should use
> the
> designator syntax (i.e, counted_by (.n) instead of counted_by (n)) for the
> counted_by attribute for pointer fields, after more considera
> On 17 Jan 2025, at 14:47, Richard Sandiford wrote:
>
> Tamar Christina writes:
>>> -Original Message-
>>> From: Kyrylo Tkachov
>>> Sent: Friday, January 17, 2025 1:22 PM
>>> To: Tamar Christina
>>> Cc: GCC Patches ; nd ; Richard
>>> Earnshaw ; ktkac...@gcc.gnu.org; Richard
>>> Sand
On sparc we end up choosing vector(8) for the
condition but vector(2) int for the value of a COND_EXPR but we
fail to verify their shapes match and thus things go downhill.
This is a missed-optimization on the pattern recognition side
as well as unhandled vector decomposition in vectorizable_cond
Hi Jason,
On 16 Jan 2025, at 22:49, Jason Merrill wrote:
> On 10/16/24 11:43 AM, Simon Martin wrote:
>> As you know the patch had to be reverted due to PR117114, that
>> highlighted a bunch of issues with comparing DECL_VINDEXes: it might
>> give false positives in case of multiple inheritance (t
> > Since the parameter vl of XTheadVector does not support immediate numbers,
> > we need
> > to put it in the register in advance. That generates the initial code
> > correctly.
> >
> > PR 116593
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv-vector-builtins.cc
> > (function_expander::a
Hi Monk,
On Fri, Nov 15, 2024 at 06:53:09PM +0800, Monk Chiang wrote:
> gcc/ChangeLog:
> * gcc/config/riscv/riscv.cc
> (riscv_file_end_indicate_exec_stack): Add .note.gnu.property.
> * gcc/config/riscv/linux.h (TARGET_ASM_FILE_END): Define.
>
> [...]
> diff --git a/gcc/config/ri
> On Thu, 16 Jan 2025, Michal Jires wrote:
>
> > symtab_node::get_dump_name uses node order to identify nodes.
> > Order is no longer unique because of Incremental LTO patches.
> > This patch moves uid from cgraph_node node to symtab_node,
> > so get_dump_name can use uid instead and get back uniq
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Friday, January 10, 2025 4:50 PM
>> To: Akram Ahmad
>> Cc: ktkac...@nvidia.com; gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH v3 1/2] aarch64: Use standard names for saturating
>> arithmetic
>>
>> Akram
From: Alfie Richards
Hi both,
I updated this patch as in other work I found a more natural place
for this warning to be issued.
I also implemented Kyrylo's suggestion to only issue the warning once.
I don't yet have commit access so if this patch is okay would either
of you be okay to commit i
This patch adds a warning when FMV is used for Aarch64.
The reasoning for this is the ACLE [1] spec for FMV has diverged
significantly from the current implementation and we want to prevent
potential future compatability issues.
There is a patch for an ACLE compliant version of target_version an
Tamar Christina writes:
>> -Original Message-
>> From: Kyrylo Tkachov
>> Sent: Friday, January 17, 2025 1:22 PM
>> To: Tamar Christina
>> Cc: GCC Patches ; nd ; Richard
>> Earnshaw ; ktkac...@gcc.gnu.org; Richard
>> Sandiford
>> Subject: Re: [PATCH]AArch64: Drop ILP32 from default elf m
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Friday, January 17, 2025 1:22 PM
> To: Tamar Christina
> Cc: GCC Patches ; nd ; Richard
> Earnshaw ; ktkac...@gcc.gnu.org; Richard
> Sandiford
> Subject: Re: [PATCH]AArch64: Drop ILP32 from default elf multilibs after
> deprecation
>
>
Hi Prathamesh!
On 2025-01-10T04:17:52+, Prathamesh Kulkarni wrote:
>> -Original Message-
>> From: Thomas Schwinge
>> Sent: 07 January 2025 17:45
>> On 2024-12-20T15:37:42+, Prathamesh Kulkarni
>> wrote:
>> > [...] copying libatomic.a over to $(gcc_objdir)$(MULTISUBDIR)/, and
>
> On 17 Jan 2025, at 14:06, Tamar Christina wrote:
>
>> -Original Message-
>> From: Kyrylo Tkachov
>> Sent: Friday, January 17, 2025 1:04 PM
>> To: Tamar Christina
>> Cc: GCC Patches ; nd ; Richard
>> Earnshaw ; ktkac...@gcc.gnu.org; Richard
>> Sandiford
>> Subject: Re: [PATCH]AArch6
On 1/17/25 1:50 AM, Simon Martin wrote:
On 17 Jan 2025, at 0:12, Jason Merrill wrote:
On 1/5/25 11:19 AM, Simon Martin wrote:
We currently reject the following code
=== code here ===
template struct S { friend class non_template; };
class non_template {};
S<0> s;
=== code here ===
While EDG
On 1/16/25 8:04 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
The recent r15-6369 unfortunately caused a bad wrong-code issue.
Here we have
TARGET_EXPR
and call cp_fold_r -> maybe_constant_init with object=D.2996. In
cxx_eval_outermost_cons
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Friday, January 17, 2025 1:04 PM
> To: Tamar Christina
> Cc: GCC Patches ; nd ; Richard
> Earnshaw ; ktkac...@gcc.gnu.org; Richard
> Sandiford
> Subject: Re: [PATCH]AArch64: Drop ILP32 from default elf multilibs after
> deprecation
>
>
> On 17 Jan 2025, at 13:56, Tamar Christina wrote:
>
> Hi All,
>
> Following the deprecation of ILP32 *-elf builds fail now due to -Werror on the
> deprecation warning. This is because on embedded builds ILP32 is part of the
> default multilib.
>
> This patch removed it from the default targ
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, January 10, 2025 4:50 PM
> To: Akram Ahmad
> Cc: ktkac...@nvidia.com; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH v3 1/2] aarch64: Use standard names for saturating
> arithmetic
>
> Akram Ahmad writes:
> > Ah whoops- I di
Hi All,
Following the deprecation of ILP32 *-elf builds fail now due to -Werror on the
deprecation warning. This is because on embedded builds ILP32 is part of the
default multilib.
This patch removed it from the default target as the build would fail anyway.
Cross compiled on aarch64-none-elf
On 1/17/25 5:50 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
In the linked testcase, we're erroring because the declared return types
of the functions do not appear to match. This is because when merging
the deduced return types fo
On 12/20/24 6:17 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk and
maybe release branches?
OK for all.
-- >8 --
This patch removes the (unnecessary) CPP_PRAGMA_EOL case from
cp_parser_cache_defarg, which currently has the result that any pragmas
i
On Fri, Jan 17, 2025 at 10:47:09AM +0100, Jakub Jelinek wrote:
> Hi!
>
> r15-2002 s390: Fully exploit vgm, vgbm, vrepi change added
> some code to print_operand and added gcc_checking_asserts in there.
> But print_operand ideally should have no assertions in it, as most
> of the assumptions can be
On Fri, Jan 17, 2025 at 12:37:49PM +, Sam James wrote:
> So far, testing has gone well on my end (multilib issues fixed too), but
> I suspect it introduced an issue with RPATH:
libtool install into gcc/$(MULTISUBDIR) isn't a good idea.
Jakub
Saurabh Jha writes:
> On 1/16/2025 8:44 AM, Richard Sandiford wrote:
>> Thanks for the update. Mostly LGTM, but some comments below:
>>
>> writes:
>>> diff --git a/gcc/config/aarch64/aarch64-sve2.md
>>> b/gcc/config/aarch64/aarch64-sve2.md
>>> index f8cfe08f4c0..0a1dc314f94 100644
>>> --- a/gc
Prathamesh Kulkarni writes:
>> -Original Message-
>> From: Prathamesh Kulkarni
>> Sent: 10 January 2025 09:48
>> To: Thomas Schwinge
>> Cc: Tobias Burnus ; Joseph Myers
>> ; Xi Ruoyao ; Matthew
>> Malcomson ; gcc-patches@gcc.gnu.org; Tom de
>> Vries
>> Subject: RE: [RFC] PR81358: Enabl
Tamar Christina writes:
>> -Original Message-
>> From: Wilco Dijkstra
>> Sent: Tuesday, January 14, 2025 5:30 PM
>> To: Richard Sandiford
>> Cc: Richard Earnshaw ; ktkac...@nvidia.com; GCC
>> Patches ; sch...@linux-m68k.org
>> Subject: Re: [PATCH] AArch64: Deprecate -mabi=ilp32
>>
>> Hi
See https://gcc.gnu.org/gitwrite.html#authenticated.
Ping
BR,
Jin
ifcombine depends on BRANCH_COST and the testcase relies on ifcombine
to fully optimize the function. But the important parts are optimized
everywhere, so the following delectively XFAILs the less important part.
Tested on aarch64 and x86_64-unknown-linux-gnu, pushed.
PR testsuite/117958
On 1/16/2025 8:44 AM, Richard Sandiford wrote:
Thanks for the update. Mostly LGTM, but some comments below:
writes:
diff --git a/gcc/config/aarch64/aarch64-sve2.md
b/gcc/config/aarch64/aarch64-sve2.md
index f8cfe08f4c0..0a1dc314f94 100644
--- a/gcc/config/aarch64/aarch64-sve2.md
+++ b/gcc
Most of the avr built-in functions can be attributed "const".
Ok for trunk?
Johann
--
AVR: Add "const" attribute to avr built-in functions if possible.
gcc/
* config/avr/avr-c.cc (DEF_BUILTIN): Add ATTRS argument to macro
definition.
* config/avr/avr.cc: Same.
> In RVV 1.0, the instruction "vsetvli zero,zero,*" indicates that the
> available vector length (avl) does not change. However, in XTheadVector,
> this same instruction signifies that the avl should take the maximum value.
> Consequently, when fusing vsetvl instructions, the optimization labeled
>> +# GCC testsuite that uses the `dg.exp' driver.
>> +
>> +# Test the front-end for C++.
>> +# We don't need to test back-end code-gen in RV32 system for C++
>> +# Because it is already tested in C.
>> +# Exit immediately if this isn't a RISC-V target.
>> +if ![istarget riscv*-*-*] then {
>> + re
> Since the parameter vl of XTheadVector does not support immediate numbers, we
> need
> to put it in the register in advance. That generates the initial code
> correctly.
>
> PR 116593
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-vector-builtins.cc
> (function_expander::add_input_ope
> -Original Message-
> From: Wilco Dijkstra
> Sent: Tuesday, January 14, 2025 5:30 PM
> To: Richard Sandiford
> Cc: Richard Earnshaw ; ktkac...@nvidia.com; GCC
> Patches ; sch...@linux-m68k.org
> Subject: Re: [PATCH] AArch64: Deprecate -mabi=ilp32
>
> Hi Richard,
>
> >> + if (TARGET_IL
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672098.html.
On Fri, Dec 20, 2024 at 10:17:43PM +1100, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk and
> maybe release branches?
>
> -- >8 --
>
> This patch removes the (unnecessary) CPP
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
In the linked testcase, we're erroring because the declared return types
of the functions do not appear to match. This is because when merging
the deduced return types for 'foo' in 'auto-5_b.C', we overwrote the
return typ
чт, 16 янв. 2025 г. в 21:19, Georg-Johann Lay :
>
> This patch uses the INT_N interface to define __int24.
>
> Ok for trunk?
Ok.
Please apply.
Denis.
OpenMP's adjust_args clause to 'declare variant' can request to
convert a pointer to a device pointer in the call ('need_device_ptr').
The arguments are stored by their position in the argument list,
but if hidden arguments get added - like C++'s 'this' pointer,
the list if off by one. This patch
In RVV 1.0, the instruction "vsetvlizero,zero,*" indicates that the
available vector length (avl) does not change. However, in XTheadVector,
this same instruction signifies that the avl should take the maximum value.
Consequently, when fusing vsetvl instructions, the optimization labeled
"VSETV
On Fri, 17 Jan 2025, Jakub Jelinek wrote:
> Hi!
>
> The last case of this optimization assumes that if 2 integral types
> have same precision and TYPE_UNSIGNED, then they are uselessly convertible.
> While that is very likely the case for GIMPLE, it is not the case for
> GENERIC, so the following
Hi!
r15-2002 s390: Fully exploit vgm, vgbm, vrepi change added
some code to print_operand and added gcc_checking_asserts in there.
But print_operand ideally should have no assertions in it, as most
of the assumptions can be easily violated by people using it in
inline asm.
This issue in particular
On Fri, Jan 17, 2025 at 9:50 AM Hongyu Wang wrote:
>
> Uros Bizjak 于2025年1月17日周五 15:05写道：
>
> > Is there a reason to have operand 0 with "nonimmediate_operand"
> > predicate? If you have to generate a register temporary and then
> > unconditionally copy it to the output, it is better to use
> > "
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/xtheadvector/pr114194.c: Adjust correctly.
* gcc.target/riscv/rvv/xtheadvector/prefix.c: Likewise.
* gcc.target/riscv/rvv/xtheadvector/vlb-vsb.c: Likewise.
* gcc.target/riscv/rvv/xtheadvector/vlbu-vsb.c: Likewise.
Hi!
The last case of this optimization assumes that if 2 integral types
have same precision and TYPE_UNSIGNED, then they are uselessly convertible.
While that is very likely the case for GIMPLE, it is not the case for
GENERIC, so the following patch adds there a convert so that the
optimization pr
Hi!
The following testcase ICEs in import_export_decl.
When cp_finish_decomp handles std::tuple* using structural binding,
it calls copy_linkage to copy various VAR_DECL flags from the structured
binding base to the individual sb variables.
In this case the base variable is in anonymous union, so
Changes from V1:
* Raise the minimal revision to r2.
MIPS16e2 ASE is a superset of MIPS16e ASE, which is again a superset
of MIPS16 ASE. Later, all of them are forbidden in Release 6.
Make -mmips16e2 imply -mips16 as the ASE requires, so users won't
be surprised even if they expect it to. Meanwhi
Uros Bizjak 于2025年1月17日周五 15:05写道：
> Is there a reason to have operand 0 with "nonimmediate_operand"
> predicate? If you have to generate a register temporary and then
> unconditionally copy it to the output, it is better to use
> "register_operand" predicate and leave middle end to do the copy f
LLVM folks noticed that GCC was shrink wrapping the call to
vector::push_back.
So I thought it was a good idea to commit a testcase to make sure GCC does not
regress
in this area unknowning.
Note the shrink wrapping started with r15-1619-g3b9b8d6cfdf593.
Note this enables the testcase for x86_64
94 matches
Mail list logo
