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
>>> glibc
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
> >>> m
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
* 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 will
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 bi
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 fo
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 generating
* 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
Cor
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 -fno-tra
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
> >> wou
> -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 ; Josep
> 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 popcount((T)
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 wa
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: gcc.target/riscv/rvv/
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, noclone)
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 an
Committed to trunk as 'obvious' in
r14-3098-gb8ec3c952324f866f191883473922e250be81341
13-branch to follow in a few days.
Paul
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
c
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
>
> gcc/Chan
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: https://github.com/jieg
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.
gcc/ChangeL
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 |
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 deletion(-)
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:
* config-l
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 |
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 (movdi_32
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.
---
gcc/config/loongarch/
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 insertio
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.
---
gcc/config/l
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
* g++.target/loongarch/pr106828.
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 39
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.
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 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 insertions
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 w
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 su
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, y
OK, thanks.
Regards
Robin
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
LEN_EXTRACT_LAST
> 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 e
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 test
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
> >
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), zli
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
"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
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
Subjec
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 s
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 current
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 A
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 have
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 B
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
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 ch
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 (atomic_
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/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.
* include
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 a/libstdc++-v
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 --
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 i
> -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 ; Craig
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
I took a look at my calendar and decided to backport right away.
r13-7703-ged049e5d5f36cc0f4318cd93bb6b33ed6f6f2ba7
BTW It is a regression :-)
Paul
On Wed, 9 Aug 2023 at 12:10, Paul Richard Thomas
wrote:
>
> Committed to trunk as 'obvious' in
> r14-3098-gb8ec3c952324f866f191883473922e250be8134
Here is my new version, see inline response to your comments.
New cover letter:
This patch enables the use of mixed-types for simd clones for AArch64,
adds aarch64 as a target_vect_simd_clones and corrects the way the
simdlen is chosen for non-specified simdlen clauses according to the
'Vecto
Kewen:
On Wed, 2023-08-09 at 16:47 +0800, Kewen.Lin wrote:
> > Patch has been tested on Power 8 LE/BE, Power 9 LE/BE and Power 10
> > LE
> > with no regressions.
>
> Okay for trunk with two nits below fixed, thanks!
Thanks for all the help with the patch. Fixed the nits below, compiled
and re
GCC maintainers:
The following patch adds four built-ins for the decimal floating point
(DFP) quantize instructions on rs6000. The built-ins are for 64-bit
and 128-bit DFP operands.
The patch also adds a test case for the new builtins.
The Patch has been tested on Power 10LE and Power 9 LE/BE
verify
Hi, Martin,
Thanks for raising this issue.
Although this is an old FAM related issue that does not relate to my current
patch
(and might need to be resolved in a separate patch). I think that it’s
necessary to have
more discussion on this old issue and resolve it.
The first thing that I’d l
If `A` has a range of `[0,0][100,INF]` and the comparison
of `A < 50`. This should be optimized to `A <= 0` (which then
will be optimized to just `A == 0`).
This patch implement this via a new function which sees if
the constant of a comparison is in the middle of 2 range pairs
and change the const
Hello,
On Wed, 9 Aug 2023, Qing Zhao wrote:
> Although this is an old FAM related issue that does not relate to my current
> patch
> (and might need to be resolved in a separate patch). I think that it’s
> necessary to have
> more discussion on this old issue and resolve it.
>
> The first t
On 8/7/23 08:33, Manolis Tsamis wrote:
This is a new RTL pass that tries to optimize memory offset calculations
by moving them from add immediate instructions to the memory loads/stores.
For example it can transform this:
addi t4,sp,16
add t2,a6,t4
shl t3,t2,1
ld a2,0(t3)
a
On 8/9/23 07:51, Alexander Monakov wrote:
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
Hi,
The previous version of this patch tries to solve two problems
at the same time. For better clarity, I'll separate them and
only deal with the "nested" FMA in this version. I plan to
propose another patch in avoiding bad shaped FMA (deferring FMA).
Other changes:
1. Added new testcases for
"Andre Vieira (lists)" writes:
> Here is my new version, see inline response to your comments.
>
> New cover letter:
>
> This patch enables the use of mixed-types for simd clones for AArch64,
> adds aarch64 as a target_vect_simd_clones and corrects the way the
> simdlen is chosen for non-specifi
On 8/9/23 04:51, Juzhe-Zhong wrote:
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
e
On 09/08/2023 17:55, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
On 08/08/2023 11:51, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
- "unsupported return type %qT for % functions",
+
On Wed, Aug 09, 2023 at 05:55:28PM +0100, Richard Sandiford wrote:
> Jakub: do you remember what the reason was? I don't mind dropping
> "function", but it feels weird to drop the quotes around "simd".
> Seems like, if we do that, there'll one day be a patch to add
> them back. :)
Because in Open
Jakub Jelinek writes:
> On Wed, Aug 09, 2023 at 05:55:28PM +0100, Richard Sandiford wrote:
>> Jakub: do you remember what the reason was? I don't mind dropping
>> "function", but it feels weird to drop the quotes around "simd".
>> Seems like, if we do that, there'll one day be a patch to add
>> t
On 2023-08-08 10:30, Siddhesh Poyarekar wrote:
Do you have a suggestion for the language to address libgcc,
libstdc++, etc. and libiberty, libbacktrace, etc.?
I'll work on this a bit and share a draft.
Hi David,
Here's what I came up with for different parts of GCC, including the
runtime li
On Wed, Aug 09, 2023 at 06:27:20PM +0100, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > On Wed, Aug 09, 2023 at 05:55:28PM +0100, Richard Sandiford wrote:
> >> Jakub: do you remember what the reason was? I don't mind dropping
> >> "function", but it feels weird to drop the quotes around "s
Hi Jin Ma,
On 5/16/23 00:06, jinma via Gcc-patches wrote:
On 5/15/23 07:16, Jin Ma wrote:
Do we also need to check Z[FDH]INX too?
Otherwise it looks pretty good. We just need to wait for everything to
freeze and finalization on the assembler interface.
jeff
Yes, you are right, we also need
Hi!
The following patch series introduces support for C23 bit-precise integer
types. In short, they are similar to other integral types in many ways,
just aren't subject for integral promotions if smaller than int and they can
have even much wider precisions than ordinary integer types.
This ser
Hi!
Small optimization to avoid testing modifier multiple times.
2023-08-09 Jakub Jelinek
PR c/102989
* expr.cc (expand_expr_real_1) : Add an early return for
EXPAND_WRITE or EXPAND_MEMORY modifiers to avoid testing it multiple
times.
--- gcc/expr.cc.jj 2
Hi!
With _BitInt(575) or any other _BitInt(513) or larger constants we can
run into this assertion. MAX_BITSIZE_MODE_ANY_INT is just a value from
which WIDE_INT_MAX_PRECISION is derived.
2023-08-09 Jakub Jelinek
PR c/102989
* lto-streamer-in.cc (lto_input_tree_1): Assert TYPE
Hi!
I've ran into ICE on gcc.dg/torture/bitint-42.c with -O1 or -Os
when enabling expensive tests, and unfortunately I can't reproduce without
_BitInt. The IL before phiopt3 has:
[local count: 203190070]:
# .MEM_428 = VDEF <.MEM_367>
bitint.159 = VIEW_CONVERT_EXPR(*.LC3);
goto ; [100.00%
Hi!
The following patch introduces the middle-end part of the _BitInt
support, a new BITINT_TYPE, handling it where needed, except the lowering
pass and sanitizer support.
2023-08-09 Jakub Jelinek
PR c/102989
* tree.def (BITINT_TYPE): New type.
* tree.h (TREE_CHECK6, T
On Wed, Aug 9, 2023 at 1:33 PM Siddhesh Poyarekar
wrote:
> On 2023-08-08 10:30, Siddhesh Poyarekar wrote:
> >> Do you have a suggestion for the language to address libgcc,
> >> libstdc++, etc. and libiberty, libbacktrace, etc.?
> >
> > I'll work on this a bit and share a draft.
>
> Hi David,
>
>
Hi!
The following patch enables _BitInt support on x86-64, the only
target which has _BitInt specified in psABI.
2023-08-09 Jakub Jelinek
PR c/102989
* config/i386/i386.cc (classify_argument): Handle BITINT_TYPE.
(ix86_bitint_type_info): New function.
(TARGET_C
Hi!
The following patch introduces some -fsanitize=undefined support for _BitInt,
but some of the diagnostics is limited by lack of proper support in the
library.
I've filed https://github.com/llvm/llvm-project/issues/64100 to request
proper support, for now some of the diagnostics might have less
Hi!
This patch adds the library helpers for multiplication, division + modulo
and casts from and to floating point (both binary and decimal).
As described in the intro, the first step is try to reduce further the
passed in precision by skipping over most significant limbs with just zeros
or sign b
Hi!
This patch adds the C FE support, c-family support, small libcpp change
so that 123wb and 42uwb suffixes are handled plus glimits.h change
to define BITINT_MAXWIDTH macro.
The previous patches really do nothing without this, which enables
all the support.
2023-08-09 Jakub Jelinek
On Wed, Aug 9, 2023 at 11:17 AM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> I've ran into ICE on gcc.dg/torture/bitint-42.c with -O1 or -Os
> when enabling expensive tests, and unfortunately I can't reproduce without
> _BitInt. The IL before phiopt3 has:
>[local count: 203190070]:
> #
Ping.
On 6/30/23 2:26 PM, Pat Haugen via Gcc-patches wrote:
Updated from prior version to address latest review comment (simplify
umod3).
Disable generation of scalar modulo instructions.
It was recently discovered that the scalar modulo instructions can suffer
noticeable performance issues fo
On Mon, Aug 07, 2023 at 04:33:13PM +, Qing Zhao wrote:
> What’s the testing case for the one that failed?
> If it’s
>
> __builtin_dynamic_object_size(p->array, 0/2) without the allocation
> information in the routine,
> then with the current algorithm, gcc cannot deduce the size for the wh
This adds a simple match pattern for this case.
I noticed it a couple of different places.
One while I was looking at code generation of a parser and
also while I was looking at locations where bitwise_inverted_equal_p
should be used more.
Committed as approved after bootstrapped and tested on x86
Thank you for your help in getting dg-require-python-h working! I can
confirm that the FAILs are related to differences between the --cflags
affecting the gimple seen by the analyzer. For this reason, I have
changed it to --includes for now. To be sure, I tested on Python 3.8 as
well and it works a
On 7/12/23 14:59, Jivan Hakobyan via Gcc-patches wrote:
Accessing local arrays element turned into load form (fp + (index << C1)) +
C2 address.
In the case when access is in the loop we got loop invariant computation.
For some reason, moving out that part cannot be done in
loop-invariant passes
On 5/29/23 06:46, Jeff Law wrote:
On 5/29/23 05:01, Jin Ma wrote:
Reference:
https://github.com/gcc-mirror/gcc/commit/d0bc0cb66bcb0e6a5a5a31a9e900e8ccc98e34e5
RISC-V should also be implemented to handle no_insn patterns for
pipelining.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_
On 8/9/23 00:09, Tsukasa OI via Gcc-patches wrote:
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.
Tha
On Wed, Aug 09, 2023 at 11:27:48AM -0700, Andrew Pinski wrote:
> Maybe it is better to punt for VOPS after the call to
> single_non_singleton_phi_for_edges since none of functions called
> afterwards support VOPs.
> That is something like:
> diff --git a/gcc/tree-ssa-phiopt.cc b/gcc/tree-ssa-phiopt
On 8/9/23 00:11, Tsukasa OI via Gcc-patches wrote:
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 samp
1 - 100 of 169 matches
Mail list logo
