The following amends the cpymem documentation to mention that exact
overlap needs to be handled gracefully, also noting that the target
runtime is expected to behave the same way.
OK?
Thanks,
Richard.
PR middle-end/32667
* md.texi (cpymem): Document that exact overlap of source
On Thu, Nov 23, 2023 at 08:00:49AM +, Richard Biener wrote:
> The following amends the cpymem documentation to mention that exact
> overlap needs to be handled gracefully, also noting that the target
> runtime is expected to behave the same way.
>
> OK?
>
> Thanks,
> Richard.
>
> PR mi
在 2023/11/19 上午2:25, Xi Ruoyao 写道:
On Fri, 2023-11-17 at 10:21 +0800, chenglulu wrote:
Pushed to r14-5545.
在 2023/11/16 下午4:44, Jiahao Xu 写道:
Based on SPEC2017 performance evaluation results, it's better to make them equal
to the cost of unaligned store/load so as to avoid odd alignment peel
> -Original Message-
> From: Sebastian Huber
> Sent: Wednesday, November 22, 2023 10:24 PM
> To: Christophe Lyon
> Cc: Jakub Jelinek ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH v2] gcov: Fix integer types in gen_counter_update()
>
> On 22.11.23 15:22, Christophe Lyon wrote:
> > On Tu
在 2023/11/23 下午3:31, chenglulu 写道:
在 2023/11/23 下午3:11, Xi Ruoyao 写道:
On Thu, 2023-11-23 at 14:35 +0800, chenglulu wrote:
Hi,
I don’t quite understand this part. Is it because define_insn
would be
duplicated with the above implementation,
so define_insn_and_split is used?
Yes, but if
On Thu, 23 Nov 2023, Jakub Jelinek wrote:
> On Thu, Nov 23, 2023 at 08:00:49AM +, Richard Biener wrote:
> > The following amends the cpymem documentation to mention that exact
> > overlap needs to be handled gracefully, also noting that the target
> > runtime is expected to behave the same way
On Sunday, 19 November 2023 22:53:37 CET Jan Hubicka wrote:
> Sadly it is really hard to work out this
> from IPA passes, since we basically care whether the iterator points to
> the same place as the end pointer, which are both passed by reference.
> This is inter-procedural value numbering that i
On Wed, 22 Nov 2023, Jakub Jelinek wrote:
> On Wed, Nov 22, 2023 at 01:21:12PM +0100, Jakub Jelinek wrote:
> > So, pedantically perhaps just assuming TRY_CATCH_EXPR where second argument
> > is not STATEMENT_LIST to be the CATCH_EXPR/EH_FILTER_EXPR case could work
> > for C++, but there are other
On 2023-11-23 14:34 Andrew Pinski wrote:
>
>On Wed, Nov 22, 2023 at 10:07 PM Feng Wang wrote:
>>
>> This patch add another condition for gimple-cond optimization. Refer to
>> the following test case.
>> int foo1 (int data, int res)
>> {
>> res = data & 0xf;
>> res |=
On 23.11.23 09:11, Jiang, Haochen wrote:
-Original Message-
From: Sebastian Huber
Sent: Wednesday, November 22, 2023 10:24 PM
To: Christophe Lyon
Cc: Jakub Jelinek;gcc-patches@gcc.gnu.org
Subject: Re: [PATCH v2] gcov: Fix integer types in gen_counter_update()
On 22.11.23 15:22, Christoph
I tested it and it was fine. I never knew this could be used like this.
Thank you!
在 2023/11/20 上午8:47, Xi Ruoyao 写道:
No functional change, just a cleanup.
gcc/ChangeLog:
* config/loongarch/loongarch.md (lrint_allow_inexact): Remove.
(2): Check if
== UNSPEC_FTINT inst
On Thu, Nov 23, 2023 at 4:02 AM Kewen.Lin wrote:
>
> on 2023/11/22 18:25, Richard Biener wrote:
> > On Wed, Nov 22, 2023 at 10:31 AM Kewen.Lin wrote:
> >>
> >> on 2023/11/17 20:55, Alexander Monakov wrote:
> >>>
> >>> On Fri, 17 Nov 2023, Kewen.Lin wrote:
> > I don't think you can run cleanup
On Thu, Nov 23, 2023 at 08:13:47AM +, Richard Biener wrote:
> On Thu, 23 Nov 2023, Jakub Jelinek wrote:
>
> > On Thu, Nov 23, 2023 at 08:00:49AM +, Richard Biener wrote:
> > > The following amends the cpymem documentation to mention that exact
> > > overlap needs to be handled gracefully,
On Wed, Nov 22, 2023 at 04:53:48PM -0500, Jason Merrill wrote:
> I agree it's weird to get two of the same error, but maybe instead of
> duplicating the error, we could look up data only if size succeeded, and
> then error once if either failed?
Here is what I've committed after another bootstrap/
LGTM.
Thanks.
在 2023/11/20 上午8:47, Xi Ruoyao 写道:
Remove unnecessary UNSPECs and make the [x]vrotr[i] instructions useful
with GNU vectors and auto vectorization.
gcc/ChangeLog:
* config/loongarch/lsx.md (bitimm): Move to ...
(UNSPEC_LSX_VROTR): Remove.
(lsx_vrotr_): Re
On Thu, 2023-11-23 at 15:31 +0800, chenglulu wrote:
> I modified this code to use define_expand:
>
> (define_expand "fix_trunc2"
> [(set (match_operand: 0 "register_operand" "=f")
> (fix: (match_operand:FVEC 1 "register_operand" "f")))]
> ""
> {
> em
On Thu, 2023-11-23 at 16:23 +0800, chenglulu wrote:
> I tested it and it was fine. I never knew this could be used like
> this.
I remember when I wrote r13-3920 I tried this but failed. Maybe
something has been improved in machine description parser, or perhaps I
just did some stupid thing that t
Hi Iain,
On Mon, 6 Nov 2023 at 11:58, Richard Sandiford
wrote:
>
> Iain Sandoe writes:
> > Hi Richard,
> >
> >> On 5 Nov 2023, at 12:11, Richard Sandiford
> >> wrote:
> >>
> >> Iain Sandoe writes:
> >
> On 26 Oct 2023, at 21:00, Iain Sandoe wrote:
> >>>
> > On 26 Oct 2023, at 20:49,
On Thu, 2023-11-23 at 16:13 +0800, chenglulu wrote:
> The fix_truncv4sfv4si2 template is indeed called when debugging with
> gdb.
>
> So I think we can use define_expand here.
The problem is cases where we want to combine an rint call with float-
to-int conversion:
float x[4];
int y[4];
void te
Le 22/11/2023 à 21:36, Harald Anlauf a écrit :
Hi Mikael!
On 11/22/23 10:36, Mikael Morin wrote:
(...)
diff --git a/gcc/fortran/error.cc b/gcc/fortran/error.cc
index 2ac51e95e4d..be715b50469 100644
--- a/gcc/fortran/error.cc
+++ b/gcc/fortran/error.cc
@@ -980,7 +980,11 @@ char const*
notify_
on 2023/11/23 16:20, Richard Biener wrote:
> On Thu, Nov 23, 2023 at 4:02 AM Kewen.Lin wrote:
>>
>> on 2023/11/22 18:25, Richard Biener wrote:
>>> On Wed, Nov 22, 2023 at 10:31 AM Kewen.Lin wrote:
on 2023/11/17 20:55, Alexander Monakov wrote:
>
> On Fri, 17 Nov 2023, Kewen.Lin w
Hi Christophe.
> On 23 Nov 2023, at 09:02, Christophe Lyon wrote:
>
> Hi Iain,
>
> On Mon, 6 Nov 2023 at 11:58, Richard Sandiford
> wrote:
>>
>> Iain Sandoe writes:
>>> Hi Richard,
>>>
On 5 Nov 2023, at 12:11, Richard Sandiford
wrote:
Iain Sandoe writes:
>>>
>>
在 2023/11/23 下午5:02, Xi Ruoyao 写道:
On Thu, 2023-11-23 at 16:13 +0800, chenglulu wrote:
The fix_truncv4sfv4si2 template is indeed called when debugging with
gdb.
So I think we can use define_expand here.
The problem is cases where we want to combine an rint call with float-
to-int conversion:
在 2023/11/23 下午4:58, Xi Ruoyao 写道:
On Thu, 2023-11-23 at 16:23 +0800, chenglulu wrote:
I tested it and it was fine. I never knew this could be used like
this.
I remember when I wrote r13-3920 I tried this but failed. Maybe
something has been improved in machine description parser, or perhaps
On Thu, 23 Nov 2023 at 10:09, Iain Sandoe wrote:
>
> Hi Christophe.
>
> > On 23 Nov 2023, at 09:02, Christophe Lyon
> > wrote:
> >
> > Hi Iain,
> >
> > On Mon, 6 Nov 2023 at 11:58, Richard Sandiford
> > wrote:
> >>
> >> Iain Sandoe writes:
> >>> Hi Richard,
> >>>
> On 5 Nov 2023, at 12:11
> [CCing Ian as libgcc maintainer]
>
> On Wed, 1 Nov 2023 10:14:37 +
> "Zhu, Lipeng" wrote:
>
> > > >
> > > > Hi Lipeng,
> > > >
> > > > >>> Sure, as your comments, in the patch V6, I added 3 test cases
> > > > >>> with OpenMP to test different cases in concurrency respectively:
> > > > >>>
Hello,
Le 22/11/2023 à 22:02, Harald Anlauf a écrit :
Dear all,
testcases assumed_rank_8.f90 and assumed_rank_10.f90 are invalid:
NULL() is passed without MOLD to an assumed-rank dummy argument.
This is detected by NAG, but not yet by gfortran (see pr104819).
gfortran even ignores the MOLD arg
Hi!
As the following testcase shows, there are some bugs in the
-fnon-call-exceptions bit-field load lowering. In particular, there
is a case where we want to emit a load early in the initialization
(before m_init_gsi) and because that load might throw exception, need
to split block after the loa
Tested on a cross to armv8l-unknown-linux-gnueabihf where the failing
testcase is restored, and on aarch64-linux-gnu where no change is seen
on the aarch64.exp suite. Also tested on arm64 Darwin for aarch64.exp
and aarch64-darwin.exp.
OK for trunk, or some alternative would be better?
Iain
--- 8
Hi!
As the following testcase shows, we ICE when trying to emit ADDR_EXPR of
a bitint variable which doesn't have mode width.
The problem is in the EXTEND_BITINT stuff which makes sure we treat the
padding bits on memory reads from user bitint vars as undefined.
When expanding ADDR_EXPR on such va
On Thu, Nov 23, 2023 at 10:43 AM Jakub Jelinek wrote:
>
> Hi!
>
> As the following testcase shows, there are some bugs in the
> -fnon-call-exceptions bit-field load lowering. In particular, there
> is a case where we want to emit a load early in the initialization
> (before m_init_gsi) and becaus
On Thu, Nov 23, 2023 at 12:09:05AM +, Joseph Myers wrote:
> OK with tests added for unsigned _BitInt(1). Specifically, unsigned
> _BitInt(1) is a bit of a degenerate case for stdc_bit_ceil (always
> returning 1 after evaluating the argument's side effects); I think the
> code that builds of
On Thu, 2023-11-23 at 17:12 +0800, chenglulu wrote:
>
> 在 2023/11/23 下午5:02, Xi Ruoyao 写道:
> > On Thu, 2023-11-23 at 16:13 +0800, chenglulu wrote:
> > > The fix_truncv4sfv4si2 template is indeed called when debugging with
> > > gdb.
> > >
> > > So I think we can use define_expand here.
> > The pr
This patch is NFC patch to refine unreasonable codes I notice.
Tested on zvl128b/zvl256b/zvl512b/zvl1024b no regression.
Committed.
gcc/ChangeLog:
* config/riscv/riscv-v.cc (emit_vlmax_gather_insn): Refine codes.
(emit_vlmax_masked_gather_mu_insn): Ditto.
(modulo_sel_ind
Jakub noted in the PR that this test fails for -std=c++98.
Tested x86_64-linux.
OK for trunk?
-- >8 --
The _M_realloc_insert member does not have the trivial relocation
optimization for C++98, which seems to be why the _M_end_of_storage
member does not get optimized away. Make this test unsuppo
Hello, Richi,
Thanks for the extensive review!
On Nov 22, 2023, Richard Biener wrote:
> On Mon, Nov 20, 2023 at 1:40 PM Alexandre Oliva wrote:
>>
>> On Oct 26, 2023, Alexandre Oliva wrote:
>>
>> >> This is a refreshed and improved version of the version posted back in
>> >> June. https://g
On Thu, Nov 23, 2023 at 11:01:08AM +0100, Richard Biener wrote:
> > --- gcc/gimple-lower-bitint.cc.jj 2023-11-14 10:52:16.0 +0100
> > +++ gcc/gimple-lower-bitint.cc 2023-11-22 14:34:17.327140002 +0100
> > @@ -1687,7 +1687,22 @@ bitint_large_huge::handle_load (gimple *
> >
On Thu, Nov 23, 2023 at 10:54:56AM +, Jonathan Wakely wrote:
> Jakub noted in the PR that this test fails for -std=c++98.
>
> Tested x86_64-linux.
>
> OK for trunk?
>
> -- >8 --
>
> The _M_realloc_insert member does not have the trivial relocation
> optimization for C++98, which seems to be
* Tatsuyuki Ishi:
> I've considered gating this behind a GAS feature test, but it seems
> nontrivial especially for restricting the variants available at runtime.
> Since TLS descriptors is not selected by default, I've decided to leave it
> ungated.
>
> In other news, I have made some progress on
This patch fixes following FAILs in zvl1024b of both RV32/RV64:
FAIL: gcc.c-torture/execute/990128-1.c -O2 execution test
FAIL: gcc.c-torture/execute/990128-1.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none execution test
FAIL: gcc.c-torture/execute/990128-1.c -O2 -flto -fuse-link
> On Nov 23, 2023, at 19:57, Florian Weimer wrote:
>
> * Tatsuyuki Ishi:
>
>> I've considered gating this behind a GAS feature test, but it seems
>> nontrivial especially for restricting the variants available at runtime.
>> Since TLS descriptors is not selected by default, I've decided to leave
Hi Richard,
For the test-case mentioned in PR111702, compiling with -O2
-frounding-math -fstack-protector-all results in following ICE during
cse2 pass:
test.c: In function 'foo':
test.c:119:1: internal compiler error: in insert_regs, at cse.cc:1120
119 | }
| ^
0xb7ebb0 insert_regs
* Tatsuyuki Ishi:
> There is, please see [1]. The vector register file handling is missing right
> now as I’m not sure if we have agreed upon a calling convention for RVV.
> [1]:
> https://inbox.sourceware.org/libc-alpha/20230914084033.222120-1-ishitatsuy...@gmail.com/
Thank you, I have raised
On Wed, 15 Nov 2023 at 20:44, Prathamesh Kulkarni
wrote:
>
> On Wed, 8 Nov 2023 at 21:57, Prathamesh Kulkarni
> wrote:
> >
> > On Thu, 26 Oct 2023 at 09:43, Prathamesh Kulkarni
> > wrote:
> > >
> > > On Thu, 26 Oct 2023 at 04:09, Richard Sandiford
> > > wrote:
> > > >
> > > > Prathamesh Kulkarn
On Thu, Nov 23, 2023 at 11:05 AM Jakub Jelinek wrote:
>
> Hi!
>
> As the following testcase shows, we ICE when trying to emit ADDR_EXPR of
> a bitint variable which doesn't have mode width.
> The problem is in the EXTEND_BITINT stuff which makes sure we treat the
> padding bits on memory reads fro
On Thu, Nov 23, 2023 at 11:56:33AM +0100, Jakub Jelinek wrote:
> Now, regarding m_init_gsi, I think I'll need to play around, maybe
> I should have in the end insert after and update behavior rather than
> insert after, and that could be achieved by adding
> m_init_gsi = m_gsi;
>
I was just about to post a similar-ish patch that fixes pr65518.c
but you were faster ;)
Therefore LGTM. You can add PR/target 112670.
Regards
Robin
Oh. You mean this patch also fixes FLTO failed case ?
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-11-23 19:55
To: Juzhe-Zhong; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; jeffreyalaw
Subject: Re: [PATCH] RISC-V: Disable AVL propagation of vrgather instruction
I was just about to po
> Oh. You mean this patch also fixes FLTO failed case ?
Yes, it's the same issue. There we have a fixed vl (known via LTO)
that is being propagated "into" gathers and we end up missing
gather elements.
Regards
Robin
This patch fixes following FAILs in zvl1024b of both RV32/RV64:
FAIL: gcc.c-torture/execute/990128-1.c -O2 execution test
FAIL: gcc.c-torture/execute/990128-1.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none execution test
FAIL: gcc.c-torture/execute/990128-1.c -O2 -flto -fuse-li
Thanks Robin.
I have sent V2:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637921.html
with adding PR/target 112670
Could you commit it for me ?
I am sorry that make you doing redundant work.
I didn't realize they are same issue :)
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023
On Thu, 2023-11-23 at 18:12 +0800, Xi Ruoyao wrote:
> On Thu, 2023-11-23 at 17:12 +0800, chenglulu wrote:
> >
> > 在 2023/11/23 下午5:02, Xi Ruoyao 写道:
> > > On Thu, 2023-11-23 at 16:13 +0800, chenglulu wrote:
> > > > The fix_truncv4sfv4si2 template is indeed called when debugging with
> > > > gdb.
>
Add wrapper for vec_extract since my following patch will need to call it.
gcc/ChangeLog:
* config/riscv/riscv-protos.h (emit_vec_extract): New function.
* config/riscv/riscv-v.cc (emit_vec_extract): Ditto.
* config/riscv/riscv.cc (riscv_legitimize_move): Refine codes.
---
LGTM.
Thanks!
在 2023/11/20 上午8:47, Xi Ruoyao 写道:
Removes unnecessary UNSPECs and make the muh instructions useful with
GNU vectors or auto vectorization.
gcc/ChangeLog:
* config/loongarch/simd.md (muh): New code attribute mapping
any_extend to smul_highpart or umul_highpart.
On Thu, Nov 23, 2023 at 11:56 AM Alexandre Oliva wrote:
>
> Hello, Richi,
>
> Thanks for the extensive review!
>
> On Nov 22, 2023, Richard Biener wrote:
>
> > On Mon, Nov 20, 2023 at 1:40 PM Alexandre Oliva wrote:
> >>
> >> On Oct 26, 2023, Alexandre Oliva wrote:
> >>
> >> >> This is a refresh
On Thu, Nov 23, 2023 at 12:55 PM Jakub Jelinek wrote:
>
> On Thu, Nov 23, 2023 at 11:56:33AM +0100, Jakub Jelinek wrote:
> > Now, regarding m_init_gsi, I think I'll need to play around, maybe
> > I should have in the end insert after and update behavior rather than
> > insert after, and that could
On Thu, 2023-11-23 at 17:14 +0800, chenglulu wrote:
> When I look at this code and compare it to our scalar implementation, it
> seems
>
> that our scalar implementation still lacks an "lround".
Should be "lroundeven". We don't have an instruction for lround :(.
I tried this but it does not wo
Bootstrapped and regtested on x86_64-pc-linux-gnu. I don't have write
access.
-- >8 --
Otherwise attempting to get the originating module declaration ICEs
because the DECL_CHAIN of an instantiated friend template is no longer
its context.
PR c++/104234
PR c++/112580
gcc/cp/Chang
When working on fixing bugs of zvl1024b. I notice a special VLA SLP case
can be better optimized.
v = vec_perm (op1, op2, { nunits - 1, nunits, nunits + 1, ... })
Before this patch, we are using genriec approach (vrgather):
vid
vadd.vx
vrgather
vmsgeu
vrgather
With this patch, we use vec_extrac
On Thu, 2023-11-16 15:26:14 +, Christophe Lyon
wrote:
> diff --git a/gcc/config/arm/arm-mve-builtins-functions.h
> b/gcc/config/arm/arm-mve-builtins-functions.h
> index eba1f071af0..6d234a2dd7c 100644
> --- a/gcc/config/arm/arm-mve-builtins-functions.h
> +++ b/gcc/config/arm/arm-mve-builtins
Sorry, I just noticed I hadn't actually filled in the changelog. It
should say "Clear DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P."
On Thu, Nov 23, 2023 at 11:54 PM Nathaniel Shead
wrote:
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu. I don't have write
> access.
>
> -- >8 --
>
> Otherwise atte
gcc/ChangeLog:
PR tree-optimization/112678
* tree-profile.cc (tree_profiling): Do not use atomic operations
for -fprofile-update=single.
---
gcc/tree-profile.cc | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/gcc/tree-profile.cc b/gcc/tree-prof
On Thu, Nov 23, 2023 at 01:10:02PM +0100, Richard Biener wrote:
> Looks a bit better. As for constructing a gsi_end_p () iterator for a
> basic-block
> I'd simply add a new gsi_end_{bb,seq} ({basic_block,gimple_seq}).
Ok, here it is (just used gsi_end without _seq suffix for gimple_seq &
because
On Fri, Oct 27, 2023 at 3:51 AM Jiufu Guo wrote:
>
> Hi,
>
> Compare with previous version:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632399.html
> This verion supports TI/VEC mode of the access.
>
> There are a few PRs (meta-bug PR101926) on various targets.
> The root causes of th
On Wed, Nov 22, 2023 at 3:39 PM Jose E. Marchesi
wrote:
>
> The function __hardcfr_check_fail in hardcfr.c is internal and static
> inline. It receives many arguments, which require more than five
> registers to be passed in bpf-none-unknown targets. BPF is limited to
> that number of registers
I stumbled over this trivial omission which blocks some testcases.
I am not sure whether I have solved the is-same-expr most elegantly,
but I did loosely follow the duplicated-entry check for 'map'. As that's
a restriction to the user, we don't have to catch all and I hope the code
catches the mo
On Thu, Nov 23, 2023 at 2:47 PM Sebastian Huber
wrote:
>
> gcc/ChangeLog:
> PR tree-optimization/112678
>
> * tree-profile.cc (tree_profiling): Do not use atomic operations
> for -fprofile-update=single.
> ---
> gcc/tree-profile.cc | 8 +---
> 1 file changed, 5 inserti
On Thu, Nov 23, 2023 at 2:56 PM Jakub Jelinek wrote:
>
> On Thu, Nov 23, 2023 at 01:10:02PM +0100, Richard Biener wrote:
> > Looks a bit better. As for constructing a gsi_end_p () iterator for a
> > basic-block
> > I'd simply add a new gsi_end_{bb,seq} ({basic_block,gimple_seq}).
>
> Ok, here it
On 23.11.23 15:19, Richard Biener wrote:
On Thu, Nov 23, 2023 at 2:47 PM Sebastian Huber
wrote:
gcc/ChangeLog:
PR tree-optimization/112678
* tree-profile.cc (tree_profiling): Do not use atomic operations
for -fprofile-update=single.
---
gcc/tree-profile.cc | 8 +++
On Thu, Nov 23, 2023 at 03:21:41PM +0100, Tobias Burnus wrote:
> I stumbled over this trivial omission which blocks some testcases.
>
> I am not sure whether I have solved the is-same-expr most elegantly,
> but I did loosely follow the duplicated-entry check for 'map'. As that's
> a restriction to
On 11/15/23 14:12, Juergen Christ wrote:
> When using GNU vector extensions, an access outside of the vector size
> caused an ICE on s390. Fix this by aligning with the vec_extract
> builtin, i.e., computing constant index modulo number of lanes.
>
> Fixes testcase gcc.target/s390/pr89233.c.
>
>
On 11/15/23 14:15, Juergen Christ wrote:
> Issue two loads when using GPRs instead of one load-multiple.
>
> Bootstrapped and tested on s390. OK for mainline?
>
> gcc/ChangeLog:
>
> * config/s390/s390.md: Split TImode loads.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/s390/int12
在 2023/11/23 下午8:24, Xi Ruoyao 写道:
On Thu, 2023-11-23 at 17:14 +0800, chenglulu wrote:
When I look at this code and compare it to our scalar implementation, it
seems
that our scalar implementation still lacks an "lround".
Should be "lroundeven". We don't have an instruction for lround :(.
On 11/15/23 14:15, Juergen Christ wrote:
> Implement flags output for inline assemblies. Only use one output constraint
> that captures the whole condition code. No breakout into different condition
> codes is allowed. Also, only one condition code variable is allowed.
>
> Add further logic to
LGTM (and harmless enough) but I'd rather wait for a second look or a
maintainer's OK as we're past stage 1 and it's not a real bugfix.
(On top, it's Thanksgiving so not many people will even notice).
On a related note, this should probably be a middle-end optimization
but before a variable-index
> On Sunday, 19 November 2023 22:53:37 CET Jan Hubicka wrote:
> > Sadly it is really hard to work out this
> > from IPA passes, since we basically care whether the iterator points to
> > the same place as the end pointer, which are both passed by reference.
> > This is inter-procedural value number
> On Wed, Nov 22, 2023 at 3:39 PM Jose E. Marchesi
> wrote:
>>
>> The function __hardcfr_check_fail in hardcfr.c is internal and static
>> inline. It receives many arguments, which require more than five
>> registers to be passed in bpf-none-unknown targets. BPF is limited to
>> that number of
[Changes from V1:
- Use always_inline only in BPF target.]
The function __hardcfr_check_fail in hardcfr.c is internal and static
inline. It receives many arguments, which require more than five
registers to be passed in bpf-none-unknown targets. BPF is limited to
that number of registers to pass
On Mon, Nov 20, 2023 at 5:33 PM Uros Bizjak wrote:
>
> With the above two options, use a temporary register regno (as returned
> from split_stack_prologue_scratch_regno) as an indirect call scratch
> register to hold __morestack function address. On 64-bit targets, two
> temporary registers are a
Hi Jakub,
On 23.11.23 15:32, Jakub Jelinek wrote:
On Thu, Nov 23, 2023 at 03:21:41PM +0100, Tobias Burnus wrote:
I stumbled over this trivial omission which blocks some testcases.
I am not sure whether I have solved the is-same-expr most elegantly,
Answer: I didn't - as expected.
+ if (DECL_U
gen_parityhi2_cmp instruction clobbers its input operand, so use
a temporary register in the call to gen_parityhi2_cmp.
PR target/112672
gcc/ChangeLog:
* config/i386/i386.md (parityhi2):
Use temporary register in the call to gen_parityhi2_cmp.
gcc/testsuite/ChangeLog:
* gcc.tar
On Thu, Nov 23, 2023 at 04:21:50PM +0100, Tobias Burnus wrote:
> @@ -21663,7 +21666,25 @@ c_parser_omp_depobj (c_parser *parser)
> clause = error_mark_node;
> }
>else if (!strcmp ("destroy", p))
> - kind = OMP_CLAUSE_DEPEND_LAST;
> + {
> + matching_parens c_par
> > On Sunday, 19 November 2023 22:53:37 CET Jan Hubicka wrote:
> > > Sadly it is really hard to work out this
> > > from IPA passes, since we basically care whether the iterator points to
> > > the same place as the end pointer, which are both passed by reference.
> > > This is inter-procedural va
Hi,
so if I understand it right, it should be safe to simply replace memmove
by memcpy. I wonder if we can get rid of the count != 0 check at least
for glibc systems. In general push_back now need inline-insns-auto to
be 33 to be inlined at -O2
jh@ryzen4:/tmp> cat ~/tt.C
#include
typedef unsig
> Am 23.11.2023 um 16:17 schrieb Jose E. Marchesi :
>
> [Changes from V1:
> - Use always_inline only in BPF target.]
>
> The function __hardcfr_check_fail in hardcfr.c is internal and static
> inline. It receives many arguments, which require more than five
> registers to be passed in bpf-no
My recent commit 0c2037d9d93a8f768cb11698ff794278246bb31f added a
switch statement lacking a default clause, leading to warnings or
errors when building with --enable-werror-always.
Fix by adding an empty default.
Committed as obvious.
2023-11-23 Christophe Lyon
gcc/
* config
Hi!
On Thu, 23 Nov 2023 at 14:29, Jan-Benedict Glaw wrote:
>
> On Thu, 2023-11-16 15:26:14 +, Christophe Lyon
> wrote:
> > diff --git a/gcc/config/arm/arm-mve-builtins-functions.h
> > b/gcc/config/arm/arm-mve-builtins-functions.h
> > index eba1f071af0..6d234a2dd7c 100644
> > --- a/gcc/conf
Hi Jakub,
On 23.11.23 16:32, Jakub Jelinek wrote:
On Thu, Nov 23, 2023 at 04:21:50PM +0100, Tobias Burnus wrote:
@@ -21663,7 +21666,25 @@ c_parser_omp_depobj (c_parser *parser)
+ else if (depobj != error_mark_node
+ && !operand_equal_p (destobj, depobj,
+
Hi Iain,
Thanks for dealing with this :-)
On Thu, 23 Nov 2023 at 10:58, Iain Sandoe wrote:
>
> Tested on a cross to armv8l-unknown-linux-gnueabihf where the failing
> testcase is restored, and on aarch64-linux-gnu where no change is seen
> on the aarch64.exp suite. Also tested on arm64 Darwin f
On Wed, 22 Nov 2023, Richard Earnshaw (lists) wrote:
> > Use non-capturing parentheses for the subexpressions used with
> > `scan-assembler-times', to avoid a quirk with double-counting.
> >
> > gcc/testsuite/
> > * gcc.target/aarch64/ccmp_1.c: Use non-capturing parentheses
> > with
On Thu, 23 Nov 2023 at 15:34, Jan Hubicka wrote:
>
> > > On Sunday, 19 November 2023 22:53:37 CET Jan Hubicka wrote:
> > > > Sadly it is really hard to work out this
> > > > from IPA passes, since we basically care whether the iterator points to
> > > > the same place as the end pointer, which are
On Thu, 23 Nov 2023 at 15:44, Jan Hubicka wrote:
>
> Hi,
> so if I understand it right, it should be safe to simply replace memmove
> by memcpy. I wonder if we can get rid of the count != 0 check at least
> for glibc systems.
I don't think we can do that. It's still undefined with glibc, and
gli
On Tue, 21 Nov 2023 at 18:11, Marc Glisse wrote:
>
> On Tue, 21 Nov 2023, Jonathan Wakely wrote:
>
> > CC Marc Glisse who added the relocation support. He might recall why
> > we use memmove when all uses are for newly-allocated storage, which
> > cannot overlap the existing storage.
>
> Going bac
>> Am 23.11.2023 um 16:17 schrieb Jose E. Marchesi :
>>
>> [Changes from V1:
>> - Use always_inline only in BPF target.]
>>
>> The function __hardcfr_check_fail in hardcfr.c is internal and static
>> inline. It receives many arguments, which require more than five
>> registers to be passed in
Hi
> On 23 Nov 2023, at 16:11, Christophe Lyon wrote:
>
> Hi Iain,
>
> Thanks for dealing with this :-)
>
> On Thu, 23 Nov 2023 at 10:58, Iain Sandoe wrote:
>>
>> Tested on a cross to armv8l-unknown-linux-gnueabihf where the failing
>> testcase is restored, and on aarch64-linux-gnu where no
On 11/12/23 07:00, Nathaniel Shead wrote:
I think the error message is still a little bit unclear but I couldn't
come up with something clearer that was similarly concise and matching
the existing style.
(Also I noticed that the linked PR was assigned to Nathan but there
hadn't been activity for
Hi,
This is a v2, original patch is here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637606.html
This addresses review feedback and:
- Fixes a bug in the previous version in
function_info::finalize_new_accesses; we should now correctly handle
the case where properties.refs ()
On 11/13/23 01:09, Nathaniel Shead wrote:
I happened to be browsing the standard a bit later and noticed that we
incorrectly reject the example given below.
Bootstrapped on x86_64-pc-linux-gnu; regtesting ongoing but modules.exp
completed with no errors.
-- >8 --
A typedef doesn't create a new
On Mon, Nov 13, 2023 at 09:06:09PM -0500, Jason Merrill wrote:
> On 11/6/23 17:34, Marek Polacek wrote:
> > On Fri, Nov 03, 2023 at 01:51:07PM -0400, Jason Merrill wrote:
> > > On 11/2/23 11:28, Marek Polacek wrote:
> > > > On Sat, Oct 14, 2023 at 12:56:11AM -0400, Jason Merrill wrote:
> > > > > On
On Thu, Nov 23, 2023 at 04:59:16PM +0100, Tobias Burnus wrote:
> > There is also OEP_LEXICOGRAPHIC which could be used in addition to that.
> > The question is if we want to consider say
> > #pragma depobj (a[++i]) destroy (a[++i])
> > as same or different (similarly a[foo ()] in both cases).
>
>
1 - 100 of 180 matches
Mail list logo
