On Sat, Aug 20, 2022 at 5:29 PM 钟居哲 wrote:
>
> OK. Thank you. I am gonna try it again and fix this in RISC-V port.
The fix is not in the RISC-V port, the fix needs to happen in
vect_gen_vector_loop_niters (tree-vect-loop-manip.cc).
I described why the code is broken, the second use of const_vf is
OK. Thank you. I am gonna try it again and fix this in RISC-V port.
juzhe.zh...@rivai.ai
From: Andrew Pinski
Date: 2022-08-21 08:18
To: 钟居哲
CC: Andreas Schwab; gcc-patches; kito.cheng; andrew; rguenther
Subject: Re: Re: [PATCH] RISC-V: Add runtime invariant support
On Sat, Aug 20, 2022 at 5:06
On Sat, Aug 20, 2022 at 5:06 PM 钟居哲 wrote:
>
> Hi, it seems that this warning still report if I revert my patch. Am I right?
> Feel free to correct me. Maybe I need to try it again?
The warning will not be still there. The reason is NUM_POLY_INT_COEFFS
defaults to 1 which means vf.is_constant (&
Hi, it seems that this warning still report if I revert my patch. Am I right?
Feel free to correct me. Maybe I need to try it again?
juzhe.zh...@rivai.ai
From: Andrew Pinski
Date: 2022-08-21 07:53
To: Andreas Schwab
CC: juzhe.zhong; gcc-patches; kito.cheng; andrew; Richard Guenther
Subject: R
On Sat, Aug 20, 2022 at 3:34 PM Andreas Schwab wrote:
>
> This breaks bootstrap:
>
> ../../gcc/tree-vect-loop-manip.cc: In function 'void
> vect_gen_vector_loop_niters(loop_vec_info, tree, tree_node**, tree_node**,
> bool)':
> ../../gcc/tree-vect-loop-manip.cc:1981:26: error: 'const_vf' may be u
This breaks bootstrap:
../../gcc/tree-vect-loop-manip.cc: In function 'void
vect_gen_vector_loop_niters(loop_vec_info, tree, tree_node**, tree_node**,
bool)':
../../gcc/tree-vect-loop-manip.cc:1981:26: error: 'const_vf' may be used
uninitialized [-Werror=maybe-uninitialized]
1981 | unsigned
On 8/19/22 15:34, Marek Polacek wrote:
On Thu, Aug 18, 2022 at 08:33:47PM -0400, Jason Merrill wrote:
On 8/18/22 13:19, Marek Polacek wrote:
On Mon, Aug 15, 2022 at 03:54:05PM -0400, Jason Merrill wrote:
On 8/9/22 09:37, Marek Polacek wrote:
+ /* We're looking for *std::move ((T &) &arg), or
Dear all,
the simplification of the TRANSFER intrinsic produces a
redundant representation of the result, one in expr->value
and another in expr->representation.string. This is done
to ensure a safe "round-trip" for nested TRANSFER.
In a subsequent use of this result we either need to make
sure
From: Andrew Pinski
While looking for testcases to quickly test, I Noticed that
check_effective_target_bswap was not enabled for riscv when
ZBB is enabled. This patch checks if ZBB is enabled when
targeting RISCV* for bswap.
OK? Ran the testsuite for riscv32-linux-gnu both with and without ZBB e
From: Andrew Pinski
The problem here is the bswap2 pattern had a check for TARGET_64BIT
but then used the X iterator. Since the X iterator is either SI or DI depending
on the setting TARGET_64BIT, there is no reason for the TARGET_64BIT.
OK? Built and tested on both riscv32-linux-gnu and riscv64
From: Andrew Pinski
The default expansion for bswap16 is two extractions (shift/and)
followed by an insertation (ior) and then a zero extend. This can be improved
with ZBB enabled to just full byteswap followed by a (logical) shift right.
This patch adds a new pattern for this which does that.
O
From: Andrew Pinski
Just some improvements for bswap and ZBB including a testsuite change that will
allow more testing to happen.
Thanks,
Andrew Pinski
Andrew Pinski (3):
Fix PR 106600: __builtin_bswap32 is not hooked up for ZBB for 32bit
Fix PR 106601: __builtin_bswap16 code gen could be
Hi Ian,
Thanks for your input!
I am not familiar with Go runtime internals at all, but the patch below
at least compiles for me. Let me know if this works for you too / if
there is a better way to do this. The untyped uintptr_t seems to be
necessary as otherwise I encountered errors about &sevp e
Le 20/08/2022 à 10:41, Jakub Jelinek via Fortran a écrit :
Hi!
As discussed earlier, all other -static-lib* options are Driver only,
these 2 are Driver in common.opt and Fortran in lang.opt.
The spec files never pass the -static-lib* options down to any compiler
(f951 etc.), so the 2 errors bel
Hi, Lulu,
I think there is a typo in your subject line.
Huacai
On Sat, Aug 20, 2022 at 5:05 PM Lulu Cheng wrote:
>
> The function jump instruction in normal mode is 'bl',
> so the scope of the function jump is +-128MB.
>
> Now we've added support for 'medium' mode, this mode is
> to complete th
The function jump instruction in normal mode is 'bl',
so the scope of the function jump is +-128MB.
Now we've added support for 'medium' mode, this mode is
to complete the function jump through two instructions:
pcalau12i + jirl
So in this mode the function jump range is increased to +-2GB
Pushd to r13-2128.
在 2022/8/20 下午4:39, Lulu Cheng 写道:
v1 -> v2:
- Modify some description information.
- Add options -W[no]extreme-plt, warn about code model extreme not support plt
mode,
and then disable plt.
v2 -> v3:
- When -mcmodel=extreme, default set to -fno-plt mode, if the user forces
Hi!
As discussed earlier, all other -static-lib* options are Driver only,
these 2 are Driver in common.opt and Fortran in lang.opt.
The spec files never pass the -static-lib* options down to any compiler
(f951 etc.), so the 2 errors below are reported only when one
runs ./f951 -static-libgfortran
v1 -> v2:
- Modify some description information.
- Add options -W[no]extreme-plt, warn about code model extreme not support plt
mode,
and then disable plt.
v2 -> v3:
- When -mcmodel=extreme, default set to -fno-plt mode, if the user forces to use
'-mcmodel=extreme -fplt', an error will be reporte
19 matches
Mail list logo
