Hi, Richard.
>> Yes, I think VEC_EXTRACT is suitable for this.
Thanks for suggestion.
Actually I was trying to use VEC_EXTRACT yesterday but it ICE since GCC failed
to create LCSSA PHI for VEC_EXTRACT.
For example, like ARM SVE:
https://godbolt.org/z/rfbb4rfKv
vect dump IR:
;; Created LCSSA
> -Original Message-
> From: Michael Matz
> Sent: Wednesday, August 9, 2023 9:54 PM
> To: Zhang, Annita
> Cc: Florian Weimer ; Hongtao Liu
> ; Beulich, Jan ; Jiang, Haochen
> ; gcc-patches@gcc.gnu.org; ubiz...@gmail.com;
> Liu, Hongtao ; Wang, Phoebe
> ; x86-64-abi ;
> llvm-dev ;
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This prevents Clang from warning about the use of the non-standard
__complex__ keyword.
libstdc++-v3/ChangeLog:
* include/std/complex: Add diagnostic pragma for clang.
---
libstdc++-v3/include/std/complex | 9 +
1 file changed, 9
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Some constexpr functions were inadvertently relying on relaxed constexpr
rules from later standards.
libstdc++-v3/ChangeLog:
* include/bits/chrono.h (duration_cast): Do not use braces
around statements for C++11 constexpr rules.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/list.tcc (list::sort(Cmp)): Fix -Wsign-compare
warning for loop condition.
---
libstdc++-v3/include/bits/list.tcc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/shared_ptr_atomic.h (atomic): Change class-head
to struct.
* include/bits/stl_tree.h (_Rb_tree_merge_helper): Change
class-head to struct in friend declaration.
*
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The standard says that the implicit copy assignment operator is
deprecated for classes that have a user-provided copy constructor, and
vice versa.
libstdc++-v3/ChangeLog:
* include/bits/new_allocator.h (__new_allocator): Define copy
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/alloc_traits.h (allocate): Add [[maybe_unused]]
attribute.
* include/bits/regex_executor.tcc: Remove name of unused
parameter.
* include/bits/shared_ptr_atomic.h
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/format: Fix some warnings.
(__format::__write(Ctx&, basic_string_view)): Remove
unused function template.
---
libstdc++-v3/include/std/format | 28 +---
1 file
On Wed, 9 Aug 2023, ??? wrote:
> Hi, Richard.
>
> >> I'm a bit behind of email, but why isn't BIT_FIELD_REF enough for
> >> the case that the patch is handling? It seems that:
>
> >> .EXTRACT_LAST (len, vec)
>
> >> is equivalent to:
>
> >> vec[len - 1]
>
> >> I think eventually there'll
Hi, Richard.
>> I'm a bit behind of email, but why isn't BIT_FIELD_REF enough for
>> the case that the patch is handling? It seems that:
>> .EXTRACT_LAST (len, vec)
>> is equivalent to:
>> vec[len - 1]
>> I think eventually there'll be the temptation to lower/fold it like that.
Current
On Wed, 2023-08-09 at 19:46 +0800, Jiajie Chen wrote:
> LoongArch32 only provides basic ll/sc instructions for atomic
> operations. Mark am* atomic instructions as 64-bit only.
I'd prefer using a different symbol, say TARGET_LOONGARCH_AM here. Then
it would be easier to adjust the code if we
On Wed, 2023-08-09 at 19:46 +0800, Jiajie Chen wrote:
> + builtin_define ("_ABILP32=3");
> + builtin_define ("_LOONGARCH_SIM=_ABILP32");
Let's remove them. These MIPS-style definitions are deprecated:
https://github.com/loongson/LoongArch-Documentation/pull/28.
Unfortunately for LP64
Hello,
On Wed, 9 Aug 2023, Zhang, Annita via Gcc-patches wrote:
> > The question is whether you want to mandate the 16-bit floating point
> > extensions. You might get better adoption if you stay compatible with
> > shipping
> > CPUs. Furthermore, the 256-bit tuning apparently benefits
On Wed, 9 Aug 2023, Richard Biener via Gcc-patches wrote:
> The following teaches the non-loop reduction vectorization code to
> handle non-associatable reductions. Using the existing FOLD_LEFT_PLUS
> internal functions might be possible but I'd have to convince myself
> that +0.0 + x[0] is a
Committed, thanks Robin.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Robin Dapp via Gcc-patches
Sent: Wednesday, August 9, 2023 8:34 PM
To: Juzhe-Zhong ; gcc-patches@gcc.gnu.org
Cc: rdapp@gmail.com; kito.ch...@gmail.com; kito.ch...@sifive.com;
jeffreya...@gmail.com
"juzhe.zh...@rivai.ai" writes:
> Hi, Richi.
>
>>> that should be
>
>>> || (!LOOP_VINFO_FULLY_MASKED_P (loop_vinfo)
>>> && !LOOP_VINFO_FULLY_WITH_LENGTH_P (loop_vinfo))
>
>>> I think. It seems to imply that SLP isn't supported with
>>> masking/lengthing.
>
> Oh, yes. At first glance, the
On Tue, Aug 1, 2023 at 11:01 AM Joseph Myers wrote:
>
> On Mon, 31 Jul 2023, Lewis Hyatt via Gcc-patches wrote:
>
> > I added some additional testcases from the PR for x86. The other targets
> > that support `#pragma GCC target' (aarch64, arm, nios2, powerpc, s390)
> > already had tests verifying
On 08/08/2023 20:39, Carlos O'Donell via Gcc-patches wrote:
On 8/8/23 13:46, David Edelsohn wrote:
I believe that upstream projects for components that are imported
into GCC should be responsible for their security policy, including
libgo, gofrontend, libsanitizer (other than local patches),
On Mon, 31 Jul 2023, Maciej W. Rozycki wrote:
> > > That's a good suggestion! Thanks, let me try to apply myself workflow :)
> > I'm thinking that as part of the CI POC being done by RISE that the base AMI
> > image ought to be gcc-13 based and that we should configure the toolchains
> > we
> >
The following teaches the non-loop reduction vectorization code to
handle non-associatable reductions. Using the existing FOLD_LEFT_PLUS
internal functions might be possible but I'd have to convince myself
that +0.0 + x[0] is a safe extra operation in ever rounding mode
(I also have no way to
> On Aug 9, 2023, at 2:32 AM, Alexander Monakov wrote:
>
>
> On Tue, 8 Aug 2023, Jeff Law wrote:
>
>> If the compiler can identify a CRC and collapse it down to a table or clmul,
>> that's a major win and such code does exist in the real world. That was the
>> whole point behind the Fedora
Hi, Richi.
>> Note the expanders are documented
>> as to receive 'mask' operands, not 'len' ones (and we'd miss BIAS).
Oh. Yes. This patch is reusing current EXTRACT_LAST and generate loop len
instead of loop mask.
It seems this patch missed 'BIAS'. If we need 'BIAS', we may need
OK, thanks.
Regards
Robin
On Wed, 9 Aug 2023, juzhe.zh...@rivai.ai wrote:
> Hi, Richi.
>
> >> that should be
>
> >> || (!LOOP_VINFO_FULLY_MASKED_P (loop_vinfo)
> >> && !LOOP_VINFO_FULLY_WITH_LENGTH_P (loop_vinfo))
>
> >> I think. It seems to imply that SLP isn't supported with
> >> masking/lengthing.
>
> Oh,
This patch fix ICE: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110950
0x1cf8939 expand_const_vector
../../../riscv-gcc/gcc/config/riscv/riscv-v.cc:1587
PR target/110950
gcc/ChangeLog:
* config/riscv/riscv-v.cc (expand_const_vector): Add NPATTERNS = 1
stepped vector
On Wed, Aug 9, 2023 at 12:23 PM Robin Dapp wrote:
>
> > We seem to be looking at promotions of the call argument, lhs_type
> > is the same as the type of the call LHS. But the comment mentions .POPCOUNT
> > and the following code also handles others, so maybe handling should be
> > moved. Also
LoongArch32 only provides basic ll/sc instructions for atomic
operations. Mark am* atomic instructions as 64-bit only.
gcc/ChangeLog:
* config/loongarch.sync.md: Guard am* atomic insns by
TARGET_64BIT.
---
gcc/config/loongarch/sync.md | 10 +-
1 file changed, 5
In LoongArch, signed DF->DI conversion can be done if -mfpu=64 and
-march=loongarch32.
gcc/ChangeLog:
* config/loongarch/loongarch.md (fix_trunc*2): Use ANYFI instead
of GPR because it depends on fpu width instead of target bits.
---
gcc/config/loongarch/loongarch.md | 8
LoongArch32 does not include LDX/STD instructions, and cannot lower
(plus (reg) (reg)) pattern. Forbid ADDRESS_REG_REG and do not emit
ldx/stx.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_valid_index_p): Check
ADDRESS_REG_REG pattern and fail in loongarch32.
The correct ilp32 macro name is __loongarch_ilp32.
libitm/ChangeLog:
* config/loongarch/asm.h: Fix ilp32 detection.
---
libitm/config/loongarch/asm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libitm/config/loongarch/asm.h b/libitm/config/loongarch/asm.h
index
The compiler emits a warning if the current target (-march=loongarch32)
mismatches with abi(-march=lp64d). Adding: Add -march=loongarch64
explicitly fixes the tests.
gcc/testsuite/ChangeLog:
* g++.target/loongarch/bytepick.C: Add -march=loongarch64
*
The current SF/DF -> unsigned DI expand rules require iordi3 insn which
is not available in loongarch32.
gcc/ChangeLog:
* config/loongarch/loongarch.md (fixuns_truncdfdi2): Add
TARGET_64BIT to condition.
(fixuns_truncsfdi2): Add TARGET_64BIT to condition.
---
When rhs equals to 0x7fff, adding 1 to rhs overflows SI, generating
invalid const_int.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_emit_int_compare):
Call trunc_int_mode to ensure valid rhs.
---
gcc/config/loongarch/loongarch.cc | 1 +
1 file changed, 1
Add TARGET_64BIT check for loongarch64-only handling of SI division. It
shall not promote SI to DI before division in loongarch32 target.
gcc/ChangeLog:
* config/loongarch/loongarch.md: Add TARGET_64BIT check for
loongarch64-only handling of SI division.
---
loongarch_move_integer does not support splitting 64-bit integer into
two 32-bit ones. Thus, define_split is removed from movdi_32bit and
TARGET_64BIT is added to the split condition of movdi_64bit to avoid
using it for loongarch32.
gcc/ChangeLog:
* config/loongarch/loongarch.md
According to latest loongarch procedure call standard, sizeof(long
double) == 128 in ilp32 data model regardless of target bitness.
gcc/ChangeLog:
* config/loongarch/loongarch.h: Set LONG_DOUBLE_TYPE_SIZE to 128
regardless of target bitness.
---
gcc/config/loongarch/loongarch.h
Introduce loongarch32 target and ilp32 abi variants. The ilp32d abi
variant is selected as the default abi of loongarch32 target.
Currently, ilp32 abi can only be used for loongarch32, but in the
future, it might be possible to use ilp32 abi for loongarch64.
contrib/ChangeLog:
*
The operand order of movgr2frh.w was wrong. The correct order should be
`movgr2frh.w fd, rj`.
gcc/ChangeLog:
* config/loongarch/loongarch.md (movgr2frh): Correct
movgr2frh.w operand order.
---
gcc/config/loongarch/loongarch.md | 2 +-
1 file changed, 1 insertion(+), 1
Bring back 64-bit move splitting for loongarch32. The code was removed
in commit 16fc26d4e7a (`LoongArch: Support split symbol.`) for unknown
reason.
gcc/ChangeLog:
* config/loongarch/loongarch.md: Handle move splitting for
64-bit operands.
---
gcc/config/loongarch/loongarch.md
When loongarch_arch_target is called, la_target has not been
initialized, thus the macro LARCH_ACTUAL_ARCH always equals to zero.
This commit fixes by expanding the macro and reading the latest value.
It permits -march=loongarch64 when the default target is loongarch32 and
vice versa.
The patch series add loongarch32 and ilp32 abi support to gcc. One can
build libgcc, libatomic and glibc etc and generate a complete
loongarch32-unknown-linux-gnu-toolchain with minimal patches at:
- binutils: https://github.com/jiegec/binutils-gdb/tree/loongarch32
- glibc:
Richard Ball writes:
> ACLE has added intrinsics to bridge between SVE and Neon.
>
> The NEON_SVE Bridge adds intrinsics that allow conversions between NEON and
> SVE vectors.
>
> This patch adds support to GCC for the following 3 intrinsics:
> svset_neonq, svget_neonq and svdup_neonq
>
>
Hi, Richi.
>> that should be
>> || (!LOOP_VINFO_FULLY_MASKED_P (loop_vinfo)
>> && !LOOP_VINFO_FULLY_WITH_LENGTH_P (loop_vinfo))
>> I think. It seems to imply that SLP isn't supported with
>> masking/lengthing.
Oh, yes. At first glance, the original code is quite suspicious and your
Committed to trunk as 'obvious' in
r14-3098-gb8ec3c952324f866f191883473922e250be81341
13-branch to follow in a few days.
Paul
The insert location argument isn't actually used but we compute
that ourselves. There's a single spot, namely when asking
for the loop mask via vect_get_loop_mask that the passed argument
is used but that looks like an oversight. The following fixes that
and adjusts vectorizable_live_operation
On Wed, 9 Aug 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> Hi, this patch is adding loop len control on extract_last autovectorization.
>
> Consider this following case:
>
> #include
>
> #define EXTRACT_LAST(TYPE)\
> TYPE __attribute__ ((noinline,
Realize we have a bug in VSETVL PASS which is triggered by strided_load_run-1.c
in RV32 system.
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/strided_load_run-1.c
execution test
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/strided_load_run-1.c
execution test
FAIL:
On Fri, 2023-08-04 at 09:16 -0400, Vladimir Makarov wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> The following patch fixes a problem found by LRA port for avr target.
> The problem description is in the commit message.
>
> The patch
> We seem to be looking at promotions of the call argument, lhs_type
> is the same as the type of the call LHS. But the comment mentions .POPCOUNT
> and the following code also handles others, so maybe handling should be
> moved. Also when we look to vectorize popcount (x) instead of
> -Original Message-
> From: Florian Weimer
> Sent: Wednesday, August 9, 2023 5:16 PM
> To: Hongtao Liu
> Cc: Beulich, Jan ; Jiang, Haochen
> ; gcc-patches@gcc.gnu.org; ubiz...@gmail.com;
> Liu, Hongtao ; Zhang, Annita
> ; Wang, Phoebe ; x86-
> 64-abi ; llvm-dev ;
> Craig Topper ;
On Wed, Aug 9, 2023 at 5:15 PM Florian Weimer wrote:
>
> * Hongtao Liu:
>
> > On Wed, Aug 9, 2023 at 3:17 PM Jan Beulich wrote:
> >> Aiui these ABI levels were intended to be incremental, i.e. higher versions
> >> would include everything earlier ones cover. Without such a guarantee, how
> >>
On Mon, Aug 7, 2023 at 1:20 PM Richard Biener
wrote:
> > Please also note the RFC patch [1] that relaxes clears for V2SFmode
> > with -fno-trapping-math. The patched compiler will then emit the same
> > code as clang does for -O2. Which raises another question - should gcc
> > default to
* Hongtao Liu:
> On Wed, Aug 9, 2023 at 3:17 PM Jan Beulich wrote:
>> Aiui these ABI levels were intended to be incremental, i.e. higher versions
>> would include everything earlier ones cover. Without such a guarantee, how
>> would you propose compatibility checks to be implemented in a way
Hi,
on 2023/7/20 12:35, jeevitha via Gcc-patches wrote:
> Hi All,
>
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>
> When the user specifies PTImode as an attribute, it breaks. Created
> a tree node to handle PTImode types. PTImode attribute helps in
Hi Carl,
on 2023/8/8 01:50, Carl Love wrote:
>
> GCC maintainers:
>
> Ver 3: Updated description to make it clear the patch fixes the
> confusion on the availability of the builtins. Fixed the dg-require-
> effective-target on the test cases and the dg-options. Change the test
> case so the
On Wed, Aug 9, 2023 at 4:14 PM Florian Weimer wrote:
>
> * Richard Biener via Gcc-patches:
>
> > I don’t think we can realistically change the ABI. If we could
> > passing them in two 256bit registers would be possible as well.
> >
> > Note I fully expect intel to turn around and implement 512
* Richard Biener via Gcc-patches:
> I don’t think we can realistically change the ABI. If we could
> passing them in two 256bit registers would be possible as well.
>
> Note I fully expect intel to turn around and implement 512 bits on a
> 256 but data path on the E cores in 5 years. And it
On 09.08.2023 09:38, Hongtao Liu wrote:
> On Wed, Aug 9, 2023 at 3:17 PM Jan Beulich wrote:
>>
>> On 09.08.2023 04:14, Hongtao Liu wrote:
>>> On Wed, Aug 9, 2023 at 9:21 AM Hongtao Liu wrote:
On Wed, Aug 9, 2023 at 3:55 AM Joseph Myers
wrote:
>
> Do you have any comments
On Wed, Aug 9, 2023 at 3:17 PM Jan Beulich wrote:
>
> On 09.08.2023 04:14, Hongtao Liu wrote:
> > On Wed, Aug 9, 2023 at 9:21 AM Hongtao Liu wrote:
> >>
> >> On Wed, Aug 9, 2023 at 3:55 AM Joseph Myers
> >> wrote:
> >>>
> >>> Do you have any comments on the interaction of AVX10 with the
> >>>
On 09.08.2023 04:14, Hongtao Liu wrote:
> On Wed, Aug 9, 2023 at 9:21 AM Hongtao Liu wrote:
>>
>> On Wed, Aug 9, 2023 at 3:55 AM Joseph Myers wrote:
>>>
>>> Do you have any comments on the interaction of AVX10 with the
>>> micro-architecture levels defined in the ABI (and supported with
>>>
This minor fix is preapproved in [1].
Committed to trunk.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626758.html
gcc/ChangeLog:
* common/config/i386/cpuinfo.h (get_available_features):
Rename local variable subleaf_level to max_subleaf_level.
---
On Wed, Aug 9, 2023 at 8:38 AM Uros Bizjak wrote:
>
> On Wed, Aug 9, 2023 at 8:37 AM Liu, Hongtao wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Uros Bizjak
> > > Sent: Wednesday, August 9, 2023 2:33 PM
> > > To: Liu, Hongtao
> > > Cc: gcc-patches@gcc.gnu.org
> > > Subject:
On Wed, Aug 9, 2023 at 8:37 AM Liu, Hongtao wrote:
>
>
>
> > -Original Message-
> > From: Uros Bizjak
> > Sent: Wednesday, August 9, 2023 2:33 PM
> > To: Liu, Hongtao
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH V2] [X86] Workaround possible CPUID bug in Sandy
> > Bridge.
> >
> -Original Message-
> From: Uros Bizjak
> Sent: Wednesday, August 9, 2023 2:33 PM
> To: Liu, Hongtao
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH V2] [X86] Workaround possible CPUID bug in Sandy
> Bridge.
>
> On Wed, Aug 9, 2023 at 3:48 AM liuhongt wrote:
> >
> > > Please
From: Ju-Zhe Zhong
Hi, this patch is adding loop len control on extract_last autovectorization.
Consider this following case:
#include
#define EXTRACT_LAST(TYPE) \
TYPE __attribute__ ((noinline, noclone)) \
test_##TYPE (TYPE *x, int n, TYPE value) \
{
On Wed, Aug 9, 2023 at 3:48 AM liuhongt wrote:
>
> > Please rather do it in a more self-descriptive way, as proposed in the
> > attached patch. You won't need a comment then.
> >
>
> Adjusted in V2 patch.
>
> Don't access leaf 7 subleaf 1 unless subleaf 0 says it is
> supported via EAX.
>
> Intel
On Tue, 8 Aug 2023, Jeff Law wrote:
> If the compiler can identify a CRC and collapse it down to a table or clmul,
> that's a major win and such code does exist in the real world. That was the
> whole point behind the Fedora experiment -- to determine if these things are
> showing up in the
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, August 8, 2023 8:45 PM
> To: Jiang, Haochen
> Cc: Jakub Jelinek ; gcc-patches@gcc.gnu.org;
> ubiz...@gmail.com; Liu, Hongtao
> Subject: Re: Intel AVX10.1 Compiler Design and Support
>
> On Tue, Aug 8, 2023 at 10:15 AM Jiang,
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, August 9, 2023 1:38 PM
> To: Phoebe Wang
> Cc: Hongtao Liu ; Joseph Myers
> ; Jiang, Haochen ; gcc-
> patc...@gcc.gnu.org; ubiz...@gmail.com; Liu, Hongtao
> ; Zhang, Annita ; Wang,
> Phoebe ; x86-64-abi
From: Tsukasa OI
This built-in does not imply the 'Xgnuzihintpausestate' extension.
It does not change architectural state (because all HINTs are prohibited
from doing that).
gcc/ChangeLog:
* doc/extend.texi: Fix the description of __builtin_riscv_pause.
---
gcc/doc/extend.texi | 6
From: Tsukasa OI
The "pause" RISC-V hint instruction requires the 'Zihintpause' extension
(in the assembler). However, GCC emits "pause" unconditionally, making
an assembler error while compiling code with __builtin_riscv_pause while
the 'Zihintpause' extension disabled.
However, the "pause"
Hello,
I found that a built-in function "__builtin_riscv_pause" is not usable
unless we enable the 'Zihintpause' extension explicitly (still, this
built-in exists EVEN IF the 'Zihintpause' extension is disabled).
Contents of a.c:
> void sample(void)
> {
> __builtin_riscv_pause();
> }
From: Tsukasa OI
Since this extension does not exist, this commit prunes this from
the defined extension version table.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc(riscv_ext_version_table):
Remove 'Zve32d' from the version list.
---
101 - 174 of 174 matches
Mail list logo
