On Tue, Jul 30, 2024 at 09:28:46AM +0800, Hongtao Liu wrote:
> On Tue, Jul 30, 2024 at 9:27 AM Hongtao Liu wrote:
> >
> > On Fri, Jul 26, 2024 at 4:55 PM Haochen Jiang
> > wrote:
> > >
> > > Hi all,
> > >
> > > I added related O0 testcase in this patch.
> > >
> > > Ok for trunk and backport to G
Committed, thanks Robin.
Pan
-Original Message-
From: Robin Dapp
Sent: Tuesday, July 30, 2024 2:28 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com; Robin
Dapp
Subject: Re: [PATCH v1] RISC-V: Take Xmode instead of Pmode fo
OK.
--
Regards
Robin
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, July 29, 2024 9:43 PM
> To: Richard Biener
> Cc: Prathamesh Kulkarni ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: Support streaming of poly_int for offloading when it's
> degree <= accel's NUM_POLY_INT_COEFFS
>
> External em
On Tue, Jul 23, 2024 at 5:52 PM Takayuki 'January June' Suwa
wrote:
>
> According to the implemented pipeline model, this cost can be assumed to be
> 1 clock cycle.
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.cc (xtensa_insn_cost):
> Add a case statement for TYPE_FARITH.
Regtest
On Tue, Jul 23, 2024 at 5:52 PM Takayuki 'January June' Suwa
wrote:
>
> We would like to implement the following to store a single-precision FP
> constant in a hardware FP register:
>
> - Load the bit-exact integer image of the pooled single-precision FP
>constant into an address (integer) reg
On Fri, Jul 19, 2024 at 1:35 PM Takayuki 'January June' Suwa
wrote:
>
> It is not wrong but also not optimal to specify that sibcalls require
> register A0 in RTX generation pass, by misleading DFA into thinking it
> is being used in function body.
> It would be better to specify it in pro_and_epi
From: Pan Li
The Pmode is designed for pointer, thus leverage the Xmode instead
for the expanding of the ussub.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_expand_ussub): Promote to Xmode
instead of Pmode.
Signed-off-by: Pan Li
---
gcc/config/riscv/riscv.cc | 24 ++
On 2024-07-29 12:16, Jonathan Wakely wrote:
On Mon, 29 Jul 2024 at 10:45, Jonathan Wakely wrote:
On Mon, 29 Jul 2024 at 09:42, Ehrnsperger, Markus
wrote:
Hi,
I'm attaching two files:
1.: to_chars10.h:
This is intended to be included in libstdc++ / gcc to achieve performance
improvemen
Richard Biener 于2024年7月26日周五 19:45写道：
>
> On Fri, Jul 26, 2024 at 10:50 AM Hongyu Wang wrote:
> >
> > Hi,
> >
> > When introducing munroll-only-small-loops, the option was marked as
> > Target Save and added to -O2 default which makes attribute(optimize)
> > resets target option and causing error
LGTM, thanks :)
On Tue, Jul 30, 2024 at 10:53 AM Patrick O'Neill wrote:
>
> This patch removes the zabha configure check since it's not a breaking change
> and updates the existing zaamo/zalrsc comment.
>
> gcc/ChangeLog:
>
> * common/config/riscv/riscv-common.cc
> (riscv_subset
Thanks Richard S for comments, updated in v2.
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658637.html
Pan
-Original Message-
From: Richard Sandiford
Sent: Tuesday, July 30, 2024 12:09 AM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@gmail.com;
ric
From: Pan Li
For some target like target=amdgcn-amdhsa, we need to take care of
vector bool types prior to general vector mode types. Or we may have
the asm check failure as below.
gcc.target/gcn/cond_smax_1.c scan-assembler-times \\tv_cmp_gt_i32\\tvcc,
s[0-9]+, v[0-9]+ 80
gcc.target/gcn/cond
(insn 98 94 387 2 (parallel [
(set (reg:TI 337 [ _32 ])
(ashift:TI (reg:TI 329)
(reg:QI 521)))
(clobber (reg:CC 17 flags))
]) "test.c":11:13 953 {ashlti3_doubleword}
is reloaded into
(insn 98 452 387 2 (parallel [
(se
This patch removes the zabha configure check since it's not a breaking change
and updates the existing zaamo/zalrsc comment.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::to_string): Remove zabha configure check
handling and clarify zaamo/zal
on 2024/7/29 23:47, Peter Bergner wrote:
> On 7/29/24 5:21 AM, Kewen.Lin wrote:
>> on 2024/7/27 06:37, Carl Love wrote:
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.target/powerpc/vec-shift-double-runnable-int128.c
>>> @@ -0,0 +1,358 @@
>>> +/* { dg-do run { target power10_hw } } */
>>> +/* { dg-
On Tue, Jul 30, 2024 at 9:27 AM Hongtao Liu wrote:
>
> On Fri, Jul 26, 2024 at 4:55 PM Haochen Jiang wrote:
> >
> > Hi all,
> >
> > I added related O0 testcase in this patch.
> >
> > Ok for trunk and backport to GCC 14 and GCC 13?
> Ok.
I mean for trunk, and it needs jakub's approval to backport
On Fri, Jul 26, 2024 at 4:55 PM Haochen Jiang wrote:
>
> Hi all,
>
> I added related O0 testcase in this patch.
>
> Ok for trunk and backport to GCC 14 and GCC 13?
Ok.
>
> Thx,
> Haochen
>
> ---
>
> Changes in v2: Add testcases.
>
> ---
>
> Under -O0, with the "newly" introduced intrins, the varia
On Jul 29, 2024, Alexandre Oliva wrote:
> - auto status = f1.wait_for(wait_time);
> + auto status __attribute__ (__unused__) = f1.wait_for(wait_time);
Sorry, it looks like I posted the patch before refreshing it. Make it:
+ auto status __attribute__ ((__unused__)) = f1.wait_for(wait_time)
On Sun, Jul 14, 2024 at 4:05 AM Takayuki 'January June' Suwa
wrote:
>
> They were once mistakenly removed with
> "xtensa: Remove old broken tweak for leaf function", but caused unwanted
> register spills.
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.h (LEAF_REGISTERS, LEAF_REG_REMAP):
>
On Sun, Jul 14, 2024 at 4:05 AM Takayuki 'January June' Suwa
wrote:
>
> [U]FLOAT.S machine instruction in Xtensa ISA, which converts an integer to
> a hardware single-precision FP register, has the ability to divide the
> result by power of two (0 to 15th).
>
> Similarly, [U]TRUNC.S instruction, w
On Sun, Jul 14, 2024 at 4:05 AM Takayuki 'January June' Suwa
wrote:
>
> No functional changes.
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.cc
> (gen_int_relational, gen_float_relational): Replace tempvar-based
> value-swapping codes with std::swap.
> * config/xten
When we get to test_pr91486_wait_until(), we're about 10s past the
float_steady_clock epoch. This is enough for the 1s delta for the
timeout to come out slightly lower when the futex-less wait_until
converts the deadline from float_steady_clock to __clock_t. So we may
wake up a little too early
Jason Merrill writes:
> I don't know what all-caps BUILTIN_SOURCE_LOCATION refers to specifically (it
> doesn't match CP_BUILT_IN_SOURCE_LOCATION, for instance); let's just refer to
> source_location.
ACK - will reword.
> On 7/29/24 8:20 AM, Arsen Arsenović wrote:
>> This fixes the value of cur
Jason Merrill writes:
> On 7/29/24 8:18 AM, Arsen Arsenović wrote:
>> When register_local_var_uses iterates a BIND_EXPRs BIND_EXPR_VARS, it
>> fails to account for the fact that FUNCTION_DECLs might be present, and
>> later passes it to DECL_HAS_VALUE_EXPR_P. This leads to a tree check
>> failur
On 7/29/24 4:18 PM, Marek Polacek wrote:
On Tue, Jul 23, 2024 at 05:18:52PM -0400, Jason Merrill wrote:
On 7/17/24 5:33 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
Hmm, I thought I had replied to this already.
-- >8 --
Unfortunately, my r15-1946 fix
Minor oversight in the ext-dce bits. If the shift count is a constant
vector, then we shouldn't be extracting values with [U]INTVAL. We
guarded that test with CONSTANT_P, when it should have been CONSTANT_INT_P.
Shows up on gcn, but I wouldn't be terribly surprised if it could be
triggered
From: Gianluca Guida
This patch adds support for amocas.{b|h|w|d}. Support for amocas.q
(64/128 bit cas for rv32/64) will be added in a future patch.
Extension: https://github.com/riscv/riscv-zacas
Ratification: https://jira.riscv.org/browse/RVS-680
gcc/ChangeLog:
* config/riscv/arch-c
On 7/29/24 2:13 PM, Richard Sandiford wrote:
Sorry for the slow reply!
Slow?!? I think I sent that Thu/Fri last week. Nothing to be sorry
about at all in my mind!
No, I agree it looks like a bug. Seems like:
if (outermode == innermostmode
&& known_eq (byte, 0U)
On Mon, 29 Jul 2024, Jakub Jelinek wrote:
> On Fri, Jul 26, 2024 at 06:00:12PM -0400, Patrick Palka wrote:
> > On Fri, 26 Jul 2024, Jakub Jelinek wrote:
> >
> > > On Fri, Jul 26, 2024 at 04:42:36PM -0400, Patrick Palka wrote:
> > > > > // P2963R3 - Ordering of constraints involving fold expressio
PR ipa/111613
* gcc.c-torture/pr111613.c: Rename to..
* gcc.c-torture/execute/pr111613.c: ...this.
---
Pushed as obvious. It wasn't being used at all in the old location.
gcc/testsuite/gcc.c-torture/{ => execute}/pr111613.c | 0
1 file changed, 0 insertions(+), 0 deletions
Hi,
And this is the corresponding change libstdc++.
Thank you,
--
Giuseppe D'Angelo
From c81392a11834b9ccbe476c280915c9a4fbf64d6d Mon Sep 17 00:00:00 2001
From: Giuseppe D'Angelo
Date: Mon, 29 Jul 2024 19:23:54 +0200
Subject: [PATCH 2/2] libstdc++: add std::is_virtual_base_of
Added by P2985R
Thanks for doing this.
Jennifer Schmitz writes:
> [...]
> diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/div_s32.c
> b/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/div_s32.c
> index c49ca1aa524..6500b64c41b 100644
> --- a/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/div_s32.c
> +++
Hi,
The attached patch is a stab at adding the necessary compiler builtin to
support std::is_virtual_base_of (P2985R0, approved for C++26). The name
of the builtin matches the one just merged into clang:
https://github.com/llvm/llvm-project/issues/98310
The next patch will add the libstdc++
Sorry for the slow review.
Pengxuan Zheng writes:
> This patch improves the Advanced SIMD popcount expansion by using SVE if
> available.
>
> For example, GCC currently generates the following code sequence for V2DI:
> cnt v31.16b, v31.16b
> uaddlp v31.8h, v31.16b
> uaddlp v31.4s, v31
On 30/01/24 17:00 -0500, Lennox Ho wrote:
std::filesystem::hard_link_count() always returns 1 on
mingw-w64ucrt-11.0.1-r3 on Windows 10 19045
hard_link_count() queries _wstat64() on MinGW-w64
The MSFT documentation claims _wstat64() will always return 1 *non*-NTFS volumes
https://learn.microsoft.
On Tue, Jul 23, 2024 at 05:18:52PM -0400, Jason Merrill wrote:
> On 7/17/24 5:33 PM, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> Hmm, I thought I had replied to this already.
>
> > -- >8 --
> > Unfortunately, my r15-1946 fix broke the attached testcas
Sorry for the slow reply!
Jeff Law writes:
> We don't really have a good place for discussions anymore other than
> gcc-patches, but this really isn't a patch.. Oh well.
>
>
> I'm debugging a failure of ext-dce on a big endian target (m68k) and I
> can't help but think it's actually exposed a
On 7/29/24 8:18 AM, Arsen Arsenović wrote:
This is a partial fix for PR115906. Per [expr.await] 2s3, "An
await-expression shall not appear in a default argument
([dcl.fct.default])". This patch introduces the diagnostic in that
case, and in the case of a co_yield (as co_yield is defined in term
On 7/29/24 8:18 AM, Arsen Arsenović wrote:
When register_local_var_uses iterates a BIND_EXPRs BIND_EXPR_VARS, it
fails to account for the fact that FUNCTION_DECLs might be present, and
later passes it to DECL_HAS_VALUE_EXPR_P. This leads to a tree check
failure in DECL_HAS_VALUE_EXPR_P:
tree
Am 29.07.2024 um 19:58 schrieb Eli Zaretskii:
From: Ian Lance Taylor
Date: Mon, 29 Jul 2024 09:46:46 -0700
Cc: Eli Zaretskii , gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
On Fri, Mar 15, 2024 at 1:41 PM Björn Schäpers wrote:
Am 10.01.2024 um 13:34 schrieb Eli Zaretskii:
Date: Tue, 9 Jan 2024
I don't know what all-caps BUILTIN_SOURCE_LOCATION refers to
specifically (it doesn't match CP_BUILT_IN_SOURCE_LOCATION, for
instance); let's just refer to source_location.
On 7/29/24 8:20 AM, Arsen Arsenović wrote:
This fixes the value of current_function in compiler generated coroutine
code.
On 7/29/24 11:38 AM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk and perhaps 14.3? It should only make a differenc
for C++20 code where lambdas are permitted as template arguments.
OK for both.
-- >8 --
Here we're rejecting the generic
The problem is code like:
MEM [(c_char * {ref-all})&arr2]
where arr2 is the value expr '*arr2$13$linkptr'
(i.e. indirect ref + decl name).
Insidepass_omp_target_link::execute, there is a call to
gimple_regimplify_operands but the value expression is not
expanded.There are two problems: ADD
On Fri, 2024-03-15 at 13:02 +, Jonathan Wakely wrote:
> OK for trunk?
LGTM, thanks
Dave
>
> -- >8 --
>
> The hyphen can be misunderstood to mean "emitted to -" i.e. stdout.
> Refer to both forms by name, rather than using "the former" for one
> and
> referring to the other by name.
>
> gc
gcc/
* config/xtensa/xtensa.cc (xtensa_option_override_after_change):
New function.
(TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE): Define as
xtensa_option_override_after_change.
(xtensa_option_override): Call
xtensa_option_override_after_change.
---
gcc/con
On 7/29/24 07:42, Will Hawkins wrote:
> If the user provides a kind value that is more than 5 bits, the
> BTF_KIND_INFO macro would emit incorrect values for info (by clobbering
> values of the kind flag).
>
> Tested on x86_64-redhat-linux.
OK, thanks.
>
> include/ChangeLog:
>
> * btf.
From: Andi Kleen
This is a new attempt to fix PR116080. The previous try was reverted
because it just broke a bunch of tests, hiding the problem.
- musttail behaves differently than tailcall at -O0. Some of the test
run at -O0, so add separate effective target tests for musttail.
- New effective
Tested x86_64-linux.
-- >8 --
This implements the proposed resolution of LWG 4124, so that
low-resolution chrono::zoned_time objects can be formatted. The
formatter for zoned_time needs to account for get_local_time
returning local_time> not local_time.
libstdc++-v3/ChangeLog:
* include
My first attempt to fix this was an overly complex kluge, but there was
a nice simple solution staring me in the face. I'm pretty happy with
this now.
Tested x86_64-linux.
-- >8 --
When formatting a chrono::zoned_time with an empty chrono-specs, we were
only formatting its _M_time member, but th
> From: Ian Lance Taylor
> Date: Mon, 29 Jul 2024 09:46:46 -0700
> Cc: Eli Zaretskii , gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
>
> On Fri, Mar 15, 2024 at 1:41 PM Björn Schäpers wrote:
> >
> > Am 10.01.2024 um 13:34 schrieb Eli Zaretskii:
> > >> Date: Tue, 9 Jan 2024 21:02:44 +0100
> > >> Cc:
I'm going to revert the patch for now. There are two problems:
- The new tests don't have a unique name so the caching confuses
the results.
- To test with -O2 we need explicit musttail checks because tail call doesn't
run with -O0 w/o musttail.
On Fri, Mar 15, 2024 at 1:41 PM Björn Schäpers wrote:
>
> Am 10.01.2024 um 13:34 schrieb Eli Zaretskii:
> >> Date: Tue, 9 Jan 2024 21:02:44 +0100
> >> Cc: i...@google.com, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> >> From: Björn Schäpers
> >>
> >> Am 07.01.2024 um 18:03 schrieb Eli Zaretskii:
>
Richard Biener writes:
> On Mon, 29 Jul 2024, Jakub Jelinek wrote:
>> And, for the GET_MODE_INNER, I also meant it for Aarch64/RISC-V VL vectors,
>> I think those should be considered as true by the hook, not false
>> because maybe_ne.
>
> I don't think relevant modes will have size/precision mism
PR middle-end/115277
* gcc.c-torture/compile/pr115277.c: Rename to...
* gcc.c-torture/execute/pr115277.c: ...this.
---
ACKed on IRC by honza. Pushed.
gcc/testsuite/gcc.c-torture/{compile => execute}/pr115277.c | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename gc
Richard Biener writes:
> On Mon, 29 Jul 2024, Prathamesh Kulkarni wrote:
>
>> Hi Richard,
>> Thanks for your suggestions on RFC email, the attached patch adds support
>> for streaming of poly_int when it's degree <= accel's NUM_POLY_INT_COEFFS.
>> The patch changes streaming of poly_int as follow
On Mon, 29 Jul 2024 at 17:02, Thomas Schwinge wrote:
>
> Hi Jonathan!
>
> On 2024-07-22T17:28:38+0100, Jonathan Wakely wrote:
> > This adds a new dg-final action to compare two files after a test has
> > run, [...]
>
> Nice!
>
> > --- a/libstdc++-v3/testsuite/lib/libstdc++.exp
> > +++ b/libstdc++
pan2...@intel.com writes:
> From: Pan Li
>
> For some target like target=amdgcn-amdhsa, we need to take care of
> vector bool types prior to general vector mode types. Or we may have
> the asm check failure as below.
>
> gcc.target/gcn/cond_smax_1.c scan-assembler-times \\tv_cmp_gt_i32\\tvcc,
>
> ..., that means that a number of the new test cases are UNSUPPORTED, for
> example, x86_64 GNU/Linux:
>
> +UNSUPPORTED: c-c++-common/musttail1.c -Wc++-compat
> +UNSUPPORTED: c-c++-common/musttail12.c -Wc++-compat
> +PASS: c-c++-common/musttail13.c -Wc++-compat (test for errors
Hi Jonathan!
On 2024-07-22T17:28:38+0100, Jonathan Wakely wrote:
> This adds a new dg-final action to compare two files after a test has
> run, [...]
Nice!
> --- a/libstdc++-v3/testsuite/lib/libstdc++.exp
> +++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
> +# Compare output file written by test
On 7/29/24 5:21 AM, Kewen.Lin wrote:
> on 2024/7/27 06:37, Carl Love wrote:
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/powerpc/vec-shift-double-runnable-int128.c
>> @@ -0,0 +1,358 @@
>> +/* { dg-do run { target power10_hw } } */
>> +/* { dg-do link { target { ! power10_hw } } } */
>> +/* {
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk and perhaps 14.3? It should only make a differenc
for C++20 code where lambdas are permitted as template arguments.
-- >8 --
Here we're rejecting the generic lambda inside the default template
argument ultimately beca
The 2nd ping for the following patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657150.html
thanks.
Qing
> On Jul 22, 2024, at 09:01, Qing Zhao wrote:
>
> Hi, Richard,
>
> Could you please take a look at the patch and let me know any comment you
> have (especially on the middle-en
Hi Richard,
> > Sorry, I'm not sure if I understand. Are you suggesting something like
> > this?
> >
> > if (idom(default bb) == cond bb)
> > {
> > if (exists a path from default bb to final bb)
> > {
> > idom(final bb) = cond bb;
> > }
> > else
> > {
> > idom(final bb) = swit
Kewen:
On 7/29/24 3:21 AM, Kewen.Lin wrote:
index 0d3e0a24e11..75d95ccfb47 100644
--- a/gcc/config/rs6000/vector.md
+++ b/gcc/config/rs6000/vector.md
@@ -26,7 +26,8 @@
;; Vector int modes
(define_mode_iterator VEC_I [V16QI V8HI V4SI V2DI])
-;; Vector int modes for comparison, shift and rota
The old name was misleading.
While at it, also rename some temporary variables that are used with
this function, for consistency.
Link:
https://inbox.sourceware.org/gcc-patches/9fffd80-dca-2c7e-14b-6c9b509a7...@redhat.com/T/#m2f661c67c8f7b2c405c8c7fc3152dd85dc729120
Cc: Gabriel Ravier
Cc: Marti
On Mon, Jul 29, 2024 at 11:20 AM Jeff Law wrote:
>
>
>
> On 7/29/24 6:18 AM, Raphael Zinsly wrote:
> > On Fri, Jul 26, 2024 at 6:48 PM Jeff Law wrote:
> >>
> >>
> >>
> >> On 7/24/24 12:00 PM, Raphael Moreira Zinsly wrote:
> >>> Adds basic support to vector stack-clash protection using a loop to d
If the user provides a kind value that is more than 5 bits, the
BTF_KIND_INFO macro would emit incorrect values for info (by clobbering
values of the kind flag).
Tested on x86_64-redhat-linux.
include/ChangeLog:
* btf.h (BTF_TYPE_INFO): Protect against user providing invalid
ki
On Linux/x86_64,
29b1587e7d34667a1fd63071c1e4f5475cd71026 is the first bad commit
commit 29b1587e7d34667a1fd63071c1e4f5475cd71026
Author: Tobias Burnus
Date: Mon Jul 29 11:46:57 2024 +0200
OpenMP/Fortran: Fix handling of 'declare target' with 'link' clause
[PR115559]
caused
FAIL: gfortr
On 7/29/24 6:18 AM, Raphael Zinsly wrote:
On Fri, Jul 26, 2024 at 6:48 PM Jeff Law wrote:
On 7/24/24 12:00 PM, Raphael Moreira Zinsly wrote:
Adds basic support to vector stack-clash protection using a loop to do
the probing and stack adjustments.
gcc/ChangeLog:
* config/riscv/ris
On 7/29/24 06:12, Tobias Burnus wrote:
I recently stumbled over omp_get_default_device returning -1 (=
omp_initial_device)
vs. returning omp_get_num_devices(). Thus, it makes sense to document
this properly.
I also updated some wording and made a tiny step to documenting the
missing functions
Dear Richard,
I revised the patch according to your comments and also implemented the
transform for unsigned division; more comments inline below.
The new patch was bootstrapped and tested again.
Looking forward to your feedback.
Thanks,
Jennifer
0001-SVE-intrinsics-Add-strength-reduction-for-d
On 17 Jul 2024, at 09:29, Richard Sandiford wrote:
>
> External email: Use caution opening links or attachments
>
>
> Jennifer Schmitz writes:
>> This patch series is part of an ongoing effort to replace the SVE intrinsic
>> svdiv
>> by lower-strength instructions for division by constant. To
> > This API is intended to provide the capability to query minimal common
> > available extensions on the system.
> >
> > Proposal in riscv-c-api-doc:
> > https://github.com/riscv-non-isa/riscv-c-api-doc/pull/74
>
> That's not merged, but I'm not sure what the rules are on stability for
> the C
On Fri, Jul 26, 2024 at 06:00:12PM -0400, Patrick Palka wrote:
> On Fri, 26 Jul 2024, Jakub Jelinek wrote:
>
> > On Fri, Jul 26, 2024 at 04:42:36PM -0400, Patrick Palka wrote:
> > > > // P2963R3 - Ordering of constraints involving fold expressions
> > > > // { dg-do compile { target c++20 } }
> >
LGTM, although I said no binutils check for zacas and zabha, but B is
a different situation since GCC will add that if zba, zbb and zbs are
all present.
On Thu, Jul 25, 2024 at 7:51 AM Edwin Lu wrote:
>
> Binutils 2.42 and before don't recognize the B extension in the march
> strings even thoug
On Mon, 29 Jul 2024, Jakub Jelinek wrote:
> On Mon, Jul 29, 2024 at 02:52:24PM +0200, Richard Biener wrote:
> > > mode = GET_MODE_INNER (mode);
> > > ?
> >
> > I specifically wanted to avoid this (at least for the purpose of the
> > hook).
> >
> > > I mean say XCmode has similar problems as XF
On Mon, Jul 29, 2024 at 02:59:58PM +0200, Jakub Jelinek wrote:
> On Mon, Jul 29, 2024 at 02:52:24PM +0200, Richard Biener wrote:
> > > mode = GET_MODE_INNER (mode);
> > > ?
> >
> > I specifically wanted to avoid this (at least for the purpose of the
> > hook).
> >
> > > I mean say XCmode has si
Am 10.07.24 um 01:17 schrieb Jeff Law:
On 7/9/24 4:03 AM, Georg-Johann Lay wrote:
Hi Jeff,
This patch adds peephole2s and insns to make better use of
instructions that set condition code (SREG) as a byproduct.
Of course with cc0 all this was *much* simpler... so here we go;
adding CCNmode and
On Mon, 29 Jul 2024, Richard Biener wrote:
> The following implements the hook, excluding x87 modes.
Jakub correctly pointed out complex modes, so I've adjusted the hook to
the following which might be easier to parse (and handles decimal
FP modes as returning true). Re-testing in progress.
/*
On Mon, Jul 29, 2024 at 02:52:24PM +0200, Richard Biener wrote:
> > mode = GET_MODE_INNER (mode);
> > ?
>
> I specifically wanted to avoid this (at least for the purpose of the
> hook).
>
> > I mean say XCmode has similar problems as XFmode, or
> > V4SFmode as SFmode if i?86 -mno-sse.
> > Thoug
On Mon, 29 Jul 2024, Jakub Jelinek wrote:
> On Mon, Jul 29, 2024 at 02:14:40PM +0200, Richard Biener wrote:
> > The following adds a target hook to specify whether regs of MODE can be
> > used to transfer bits. The hook is supposed to be used for value-numbering
> > to decide whether a value load
Thomas Schwinge writes:
> Hi!
>
> On 2024-02-10T17:26:01+, Andrew Burgess wrote:
>> --- a/libiberty/argv.c
>> +++ b/libiberty/argv.c
>
>> @@ -439,17 +442,8 @@ expandargv (int *argcp, char ***argvp)
>> }
>>/* Add a NUL terminator. */
>>buffer[len] = '\0';
>> - /* If
Richard Sandiford writes:
> A somewhat similar situation can happen for SVE with subregs like:
>
> (subreg:V4SI (reg:VNx8SI R) 16)
>
> IMO, what ought to happen here is that the RA should spill
> the inner register to memory and load the V4SI back from there.
> (Or vice versa, for an lvalue.) O
Jeff Law writes:
> On 7/26/24 2:42 PM, Robin Dapp wrote:
>> Hi,
>>
>> when the source mode is potentially larger than one vector (e.g. an
>> LMUL2 mode for VLEN=128) we don't know which vector the subreg actually
>> refers to. For zvl128b and LMUL=2 the subreg in (subreg:V2DI (reg:V4DI))
>> coul
On Mon, Jul 29, 2024 at 02:14:40PM +0200, Richard Biener wrote:
> The following adds a target hook to specify whether regs of MODE can be
> used to transfer bits. The hook is supposed to be used for value-numbering
> to decide whether a value loaded in such mode can be punned to another
> mode ins
> OK.
Thanks Richard, will wait the confirmation from Thomas in case I missed some
more failed cases.
Pan
-Original Message-
From: Richard Biener
Sent: Monday, July 29, 2024 4:44 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@gmail.com;
tamar.christ...
This fixes the value of current_function in compiler generated coroutine
code.
PR c++/110855 - std::source_location doesn't work with C++20 coroutine
gcc/cp/ChangeLog:
PR c++/110855
* cp-gimplify.cc (fold_builtin_source_location): Use the name of
the DECL_RAMP_FN of the c
This is a partial fix for PR115906. Per [expr.await] 2s3, "An
await-expression shall not appear in a default argument
([dcl.fct.default])". This patch introduces the diagnostic in that
case, and in the case of a co_yield (as co_yield is defined in terms of
co_await, so prerequisites of co_await h
When register_local_var_uses iterates a BIND_EXPRs BIND_EXPR_VARS, it
fails to account for the fact that FUNCTION_DECLs might be present, and
later passes it to DECL_HAS_VALUE_EXPR_P. This leads to a tree check
failure in DECL_HAS_VALUE_EXPR_P:
tree check: expected var_decl or parm_decl or resu
> OK
Committed, thanks Richard.
Pan
-Original Message-
From: Richard Biener
Sent: Monday, July 29, 2024 5:03 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@gmail.com;
tamar.christ...@arm.com; jeffreya...@gmail.com; rdapp@gmail.com
Subject: Re: [PATC
On Fri, Jul 26, 2024 at 6:48 PM Jeff Law wrote:
>
>
>
> On 7/24/24 12:00 PM, Raphael Moreira Zinsly wrote:
> > Adds basic support to vector stack-clash protection using a loop to do
> > the probing and stack adjustments.
> >
> > gcc/ChangeLog:
> > * config/riscv/riscv.cc
> > (riscv_all
The following addresses another case where x87 FP loads mangle the
bit representation and thus are not suitable for a representative
in other types. VN was value-numbering a later integer load of 'x'
as the same as a former float load of 'x'.
We can use the new TARGET_MODE_CAN_TRANSFER_BITS hook
The following implements the hook, excluding x87 modes.
* i386.cc (TARGET_MODE_CAN_TRANSFER_BITS): Define.
(ix86_mode_can_transfer_bits): New function.
---
gcc/config/i386/i386.cc | 11 +++
1 file changed, 11 insertions(+)
diff --git a/gcc/config/i386/i386.cc b/gcc/config
The following adds a target hook to specify whether regs of MODE can be
used to transfer bits. The hook is supposed to be used for value-numbering
to decide whether a value loaded in such mode can be punned to another
mode instead of re-loading the value in the other mode and for SRA to
decide whe
Claudio Bantaloukas writes:
> Unlike most system registers, fpmr can be heavily written to in code that
> exercises the fp8 functionality. That is because every fp8 instrinsic call
> can potentially change the value of fpmr.
> Rather than just use a an unspec, we treat the fpmr system register lik
I recently stumbled over omp_get_default_device returning -1 (=
omp_initial_device)
vs. returning omp_get_num_devices(). Thus, it makes sense to document this
properly.
I also updated some wording and made a tiny step to documenting the missing
functions
by adding a title to the commented @menu
On 15/03/24 13:02 +, Jonathan Wakely wrote:
OK for trunk?
Ping
-- >8 --
The hyphen can be misunderstood to mean "emitted to -" i.e. stdout.
Refer to both forms by name, rather than using "the former" for one and
referring to the other by name.
gcc/ChangeLog:
* doc/invoke.texi (
Hello,
the SH backend in GCC is currently in rather poor shape and could need some
overhaul and for that matter, I'm looking for an experienced GCC developer
who might be willing to fix some bugs in the backend for money.
I have started similar efforts in the past for the avr, m68k and vax backen
On Mon, 29 Jul 2024, Prathamesh Kulkarni wrote:
> Hi Richard,
> Thanks for your suggestions on RFC email, the attached patch adds support for
> streaming of poly_int when it's degree <= accel's NUM_POLY_INT_COEFFS.
> The patch changes streaming of poly_int as follows:
>
> Streaming out poly_int:
1 - 100 of 141 matches
Mail list logo
