I compare the codegen with aarch64:
https://godbolt.org/z/xTxPGcYMj
asm of aarch64:
f:
add x5, x1, 7
mov x2, 0
cntbx4
ptrue p7.b, all
adrpx3, .LC0
add x3, x3, :lo12:.LC0
index z30.b, #0, #8
ld1rd z29.d, p7/z
The gimplifier can elide initialized constant automatic variables
to static storage in which case TARGET_EXPR gimplification needs
to avoid emitting a CLOBBER for them since their lifetime is no
longer limited. Failing to do so causes spurious dangling-pointer
diagnostics on the added testcase for
The following improves solution_set_expand to require one less
iteration over the bitmap and avoid changing the bitmap we iterate
over. Plus we handle adjacent subvars in the ID space (the common case)
and use bitmap_set_range. This cuts a bit less than 10% off the PTA
time from the testcase in t
Richard Sandiford writes:
>> diff --git a/gcc/gensupport.h b/gcc/gensupport.h
>> index
>> a1edfbd71908b6244b40f801c6c01074de56777e..7925e22ed418767576567cad583bddf83c0846b1
>> 100644
>> --- a/gcc/gensupport.h
>> +++ b/gcc/gensupport.h
>> @@ -20,6 +20,7 @@ along with GCC; see the file COPYING3.
Hi, Richard and Richi.
Recently, we have some tries on our downstream RVV LLVM.
We change "get_vector_length" (same IR like GCC "select_vl") into "umin", turns
out LLVM SCEV analysis succeed.
The unroll PASS works in LLVM.
I think Richard's suggestion is very reasonable.
I didn't have the time
On Tue, Jun 6, 2023 at 12:49 PM Andrew Pinski wrote:
>
> On Mon, Jun 5, 2023 at 9:34 PM liuhongt via Gcc-patches
> wrote:
> >
> > r14-1145 fold the intrinsics into gimple ABS_EXPR which has UB for
> > TYPE_MIN, but PABSB will store unsigned result into dst. The patch
> > uses ABSU_EXPR + VCE inst
> I think this is a better patch and will always be correct and still
> get folded at the gimple level (correctly):
> diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> index d4ff56ee8dd..02bf5ba93a5 100644
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -18561,8
r14-1145 fold the intrinsics into gimple ABS_EXPR which has UB for
TYPE_MIN, but PABSB will store unsigned result into dst. The patch
uses ABSU_EXPR + VCE instead of ABS_EXPR.
Also don't fold _mm_abs_{pi8,pi16,pi32} w/o TARGET_64BIT since 64-bit
vector absm2 is guarded with TARGET_MMX_WITH_SSE.
g
You are right, this is also a remnant of the old function design
that I completely missed.Here is the follow-up patch for that.
Thanks for pointing it out.
Costas
On Tue, 6 Jun 2023 at 04:12, Jeff Law wrote:
>
>
> On 6/5/23 08:37, Costas Argyris via Gcc-patches wrote:
> > writeargv can be
Hi all,
We've received requests to optimise the attached intrinsics testcase.
We currently generate:
foo_1:
uaddlp v0.4s, v0.8h
uaddlv d31, v0.4s
fmovx0, d31
ret
foo_2:
uaddlp v0.4s, v0.8h
addvs31, v0.4s
fmovw0, s31
ret
Hi all,
Now that we've got the annotations we can get rid of explicit
!BYTES_BIG_ENDIAN and BYTES_BIG_ENDIAN patterns for the narrowing shift
instructions.
This allows us to clean up the expanders as well.
Bootstrapped and tested on aarch64-none-linux-gnu and aarch64_be-none-elf.
Pushing to tru
Hi Carl,
on 2023/5/3 23:30, Carl Love via Gcc-patches wrote:
> GCC maintainers:
>
> The following patch cleans up the definition for the
> __builtin_altivec_vcmpnet. The current implementation implies that the
> builtin is only supported on Power 9 since it is defined under the
> Power 9 stanza.
On Tue, Jun 6, 2023 at 6:33 AM liuhongt via Gcc-patches
wrote:
>
> r14-1145 fold the intrinsics into gimple ABS_EXPR which has UB for
> TYPE_MIN, but PABSB will store unsigned result into dst. The patch
> uses ABSU_EXPR + VCE instead of ABS_EXPR.
>
> Also don't fold _mm_abs_{pi8,pi16,pi32} w/o TAR
On Tue, Jun 6, 2023 at 6:33 AM liuhongt via Gcc-patches
wrote:
>
> r14-1145 fold the intrinsics into gimple ABS_EXPR which has UB for
> TYPE_MIN, but PABSB will store unsigned result into dst. The patch
> uses ABSU_EXPR + VCE instead of ABS_EXPR.
>
> Also don't fold _mm_abs_{pi8,pi16,pi32} w/o TAR
Hi,
As PR109932 shows, builtins __builtin_{un,}pack_vector_int128
should be guarded under vsx rather than power7, as their
corresponding bif patterns have the conditions TARGET_VSX
and VECTOR_MEM_ALTIVEC_OR_VSX_P (V1TImode). This patch is to
move __builtin_{un,}pack_vector_int128 to stanza vsx to
Hi,
As PR110011 shows, when encoding 128 bits fp constant into
toc, we adopts REAL_VALUE_TO_TARGET_LONG_DOUBLE which is
to find the first float mode with LONG_DOUBLE_TYPE_SIZE
bits of precision, it would be TFmode here. But the 128
bits fp constant can be with mode IFmode or KFmode, which
doesn't
Hi Haochen,
on 2023/5/30 14:32, HAO CHEN GUI wrote:
> Hi,
> By checking the object files of SPECint, I found that two kinds of
> compare/move can't be combined to "mr." pattern as there is no register
> link between them. The patch adds two peephole2 patterns for them.
>
Thanks for improving t
> > + if (TYPE_PRECISION (unprom_diff.type) != TYPE_PRECISION (abs_type)
> > + && TYPE_UNSIGNED (unprom_diff.type)
> > + && TYPE_UNSIGNED (abs_type))
>
> The last line is now redundant, since TYPE_UNSIGNED was checked above.
Done.
> > + // Failed to find a widen operation so we check
Hi all,
Having converted the patterns for the URSRA,SRSRA instructions to standard RTL
codes we can also
easily convert the non-accumulating forms URSHR,SRSHR.
This patch does that, reusing the various helpers and predicates from that
patch in a straightforward way.
This allows GCC to perform th
The eh_frame value is only used by linear_search_fdes, not the binary
search directly in find_fde_tail, so the bug is not immediately
apparent with most programs.
Fixes commit e724b0480bfa5ec04f39be8c7290330b495c59de ("libgcc:
Special-case BFD ld unwind table encodings in find_fde_tail").
[I'd ap
From: oluade01
This adds a recognition pattern for the non-widening
absolute difference (ABD).
gcc/ChangeLog:
* doc/md.texi (sabd, uabd): Document them.
* internal-fn.def (ABD): Use new optab.
* optabs.def (sabd_optab, uabd_optab): New optabs,
* tree-vect-pattern
From: Juzhe-Zhong
This patch add combine optimization for following case:
__attribute__ ((noipa)) void
vwmaccsu (int16_t *__restrict dst, int8_t *__restrict a, uint8_t *__restrict b,
int n)
{
for (int i = 0; i < n; i++)
dst[i] += (int16_t) a[i] * (int16_t) b[i];
}
Before this pat
Hi all,
The aarch64_addpdi pattern is redundant as the reduc_plus_scal_ pattern
can already generate
the required form of the ADDP instruction, and is mostly folded to GIMPLE early
on so can benefit from more optimisations.
Though it turns out that we were missing the folding for the unsigned va
I suppose that it is possible to check assembly.
Following is part of diff before and after my patch:
29,32c29,32
< sd $6,0($2)
< sd $7,8($2)
< sd $8,16($2)
< sd $9,24($2)
---
> sd $5,0($2)
> sd $6,8($2)
> sd $7,16($2)
>
Jovan Dmitrovic 于2023年6月6日周二 18:29写道：
>
> I suppose that it is possible to check assembly.
>
Great.
> Following is part of diff before and after my patch:
>
> 29,32c29,32
> < sd $6,0($2)
> < sd $7,8($2)
> < sd $8,16($2)
> < sd $9,24($2)
> ---
> >
Hi Juzhe,
just one/two really minor nits.
> +rtx ops[] = {operands[0], operands[1], operands[2], operands[3]};
> +riscv_vector::emit_vlmax_ternary_insn (code_for_pred_widen_mul_plus
> (, mode),
> +riscv_vector::RVV_WIDEN_TERNOP, ops);
Here and in
Hi, Robin.
>> Here and in the following similar cases you could just use operands
>>instead of creating a new rtx array.
Ok. Thanks for catching this.
>> Similar example as before would be nice or just "this helps combine
>> match ...". Apart from that I just wondered where/how these unpredica
On Wed, 22 Mar 2023 at 12:14, Jonathan Wakely wrote:
>
>
> On Mon, 20 Mar 2023 at 22:30, Jonathan Wakely via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> On 20/03/23 22:27 +, Jonathan Wakely wrote:
>> >On 06/03/23 20:52 +0100, Jannik Glückert wrote:
>> >>we were previously only using send
On Wed, 22 Mar 2023 at 12:18, Jonathan Wakely wrote:
> On Wed, 22 Mar 2023 at 12:14, Jonathan Wakely wrote:
>
>>
>>
>> On Mon, 20 Mar 2023 at 22:30, Jonathan Wakely via Libstdc++ <
>> libstd...@gcc.gnu.org> wrote:
>>
>>> On 20/03/23 22:27 +, Jonathan Wakely wrote:
>>> >On 06/03/23 20:52 +0100
On Wed, 22 Mar 2023 at 12:20, Jonathan Wakely wrote:
> On Wed, 22 Mar 2023 at 12:18, Jonathan Wakely wrote:
>
>> On Wed, 22 Mar 2023 at 12:14, Jonathan Wakely wrote:
>>
>>>
>>>
>>> On Mon, 20 Mar 2023 at 22:30, Jonathan Wakely via Libstdc++ <
>>> libstd...@gcc.gnu.org> wrote:
>>>
On 20/03/23
Tested x86_64-linux. Pushed to trunk. This is worth backporting.
-- >8 --
libstdc++-v3/ChangeLog:
* src/filesystem/ops-common.h (do_copy_file) [O_CLOEXEC]: Set
close-on-exec flag on file descriptors.
---
libstdc++-v3/src/filesystem/ops-common.h | 13 +++--
1 file changed
> These enhance patterns are generated in complicate combining situations.
Yes, that's clear. One strategy is to look through combine's output and
see which combination results make sense for a particular backend.
I was wondering where the unspec-less patterns originate (when we
expand everything
On Tue, Jun 6, 2023 at 5:11 PM Uros Bizjak wrote:
>
> On Tue, Jun 6, 2023 at 6:33 AM liuhongt via Gcc-patches
> wrote:
> >
> > r14-1145 fold the intrinsics into gimple ABS_EXPR which has UB for
> > TYPE_MIN, but PABSB will store unsigned result into dst. The patch
> > uses ABSU_EXPR + VCE instead
On Fri, 2 Jun 2023 at 17:52, Jonathan Wakely wrote:
> On Fri, 2 Jun 2023 at 16:45, Joseph Faulls wrote:
>
>> It is not required that codecvt facet be
>> supported by
>>
>> the locale, nor is it added as part of the default locale. This can lead
>> to
>>
>> dangerous behaviour when static_cast.
>>
>> I didn't mean to say that splitters should be used, just that I had similary
>>"ugly" patterns with splitters and there will be more in the future.
I think some "ugly" patterns can not be avoid for now and I don't think we need
to waste too much on it currently.
You can take a look at ARM SVE.
From: Juzhe-Zhong
Fix according to comments from Robin of V1 patch.
This patch add combine optimization for following case:
__attribute__ ((noipa)) void
vwmaccsu (int16_t *__restrict dst, int8_t *__restrict a, uint8_t *__restrict b,
int n)
{
for (int i = 0; i < n; i++)
dst[i] +=
From: Juzhe-Zhong
This patch enables basic VLA SLP auto-vectorization.
Consider this following case:
void
f (uint8_t *restrict a, uint8_t *restrict b)
{
for (int i = 0; i < 100; ++i)
{
a[i * 8 + 0] = b[i * 8 + 7] + 1;
a[i * 8 + 1] = b[i * 8 + 7] + 2;
a[i * 8 + 2] = b[i * 8
Tested x86_64-linux. Pushed to trunk. Backport needed for gcc-13 too.
-- >8 --
For 32-bit targets using -pedantic (or using Clang) makes the expression
_M_elems[0] ambiguous. The overloaded operator[] that we want to call
has a size_t parameter, but 0 is type ptrdiff_t for many ILP32 targets,
so
From: Juzhe-Zhong
gcc/ChangeLog:
* config/riscv/autovec.md (select_vl): New pattern.
* config/riscv/riscv-protos.h (gen_no_side_effects_vsetvl_rtx): export
global.
* config/riscv/riscv-v.cc (force_vector_length_operand): Ditto.
gcc/testsuite/ChangeLog:
* gcc.ta
From: Juzhe-Zhong
Fix according to comments from Robin of V1 patch.
This patch add combine optimization for following case:
__attribute__ ((noipa)) void
vwmaccsu (int16_t *__restrict dst, int8_t *__restrict a, uint8_t *__restrict b,
int n)
{
for (int i = 0; i < n; i++)
dst[i] +=
From: Benjamin Priour
This patch enchances -Wanalyzer-out-of-bounds that is no longer paired
with a -Wanalyzer-use-of-uninitialized-value on out-of-bounds-read.
This also fixes PR analyzer/109437.
Before there could always be at most one OOB-read warning per frame because
-Wanalyzer-use-of-unini
Oh。 Sorry my mistake. Forget about this patch since SELECT_VL is not merged
into middle-end yet.
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2023-06-06 19:46
To: gcc-patches
CC: kito.cheng; palmer; rdapp.gcc; jeffreyalaw; Juzhe-Zhong
Subject: [PATCH] RISC-V: Enable SELECT_VL for RVV
From: Ju
> +rtx ops[] = {operands[0], operands[1], operands[2], operands[3]};
> +riscv_vector::emit_vlmax_ternary_insn (code_for_pred_widen_mul_plus
> (, mode),
> +riscv_vector::RVV_WIDEN_TERNOP, ops);
ops is still there ;) No need for another revision thou
Hi,
Thanks for the review, just some quick responses before I make the changes:
> >int operand_number; /* Operand index in the big array. */
> >int output_format; /* INSN_OUTPUT_FORMAT_*. */
> > + bool compact_syntax_p;
> >struct operand_data operand[MAX_
From: Juzhe-Zhong
Fix according to comments from Robin of V1 patch.
This patch add combine optimization for following case:
__attribute__ ((noipa)) void
vwmaccsu (int16_t *__restrict dst, int8_t *__restrict a, uint8_t *__restrict b,
int n)
{
for (int i = 0; i < n; i++)
dst[i] +=
Thanks for catching this.
I still send V4 patch :)
since I want to make kito && Jeff see the latest version.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-06-06 19:58
To: juzhe.zhong; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; palmer; palmer; jeffreyalaw; pan2.li
Subject: Re: [PATC
pushed to trunk, will backport later
tested on x86_64-pc-linux-gnu
--- >8
Signed-off-by: Matthias Kretz
libstdc++-v3/ChangeLog:
* include/experimental/bits/simd.h (__bit_cast): Use
__gnu__::__vector_size__ instead of gnu::vector_size.
---
libstdc++-v3/include/exp
OK for master and backports?
Tested on x86_64-pc-linux-gnu
- >8 -
The call to the base implementation sometimes didn't find a matching
signature because the _Abi parameter of _SimdImpl* was "wrong" after
conversion. It has to call into ::_SimdImpl instead of the
current ABI tag's _SimdIm
This is the first part of a fix for the failure of the new simd test on non-
VSX POWER targets. There are more casts to unavailable vectors of 64-bit
element types to be rewritten.
OK for master and backports?
Tested on x86_64-pc-linux-gnu and powerpc64le-linux-gnu
-- >8 ---
Signed-off
From: Pan Li
This patch would like to refactor the ZVFHMIN implementation by
separated iterator and pattern. Thus, we can tell the sub extension
between the ZVFHMIN and ZVFH.
Please note the ZVFH will cover the ZVFHMIN instructions. This patch
add one test for this.
Signed-off-by: Pan Li
gcc/
My apologies for the delay. I was on vacation.
On 5/26/23 18:17, Martin Jambor wrote:
Hello,
On Mon, May 22 2023, Aldy Hernandez wrote:
I've adjusted the patch with some minor cleanups that came up when I
implemented the rest of the IPA revamp.
Rested. OK?
On Wed, May 17, 2023 at 4:31 PM A
Tamar Christina writes:
>> >int operand_number; /* Operand index in the big array. */
>> >int output_format; /* INSN_OUTPUT_FORMAT_*. */
>> > + bool compact_syntax_p;
>> >struct operand_data operand[MAX_MAX_OPERANDS]; };
>> >
>> > @@ -700,12 +702,57 @@ proc
Oluwatamilore Adebayo writes:
> From: oluade01
>
> This adds a recognition pattern for the non-widening
> absolute difference (ABD).
>
> gcc/ChangeLog:
>
> * doc/md.texi (sabd, uabd): Document them.
> * internal-fn.def (ABD): Use new optab.
> * optabs.def (sabd_optab, uabd_optab
On Tue, 6 Jun 2023 at 13:26, Matthias Kretz via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> OK for master and backports?
>
OK for trunk and branches
> Tested on x86_64-pc-linux-gnu
>
> - >8 -
>
> The call to the base implementation sometimes didn't find a matching
> signature because t
On Tue, 6 Jun 2023 at 13:34, Matthias Kretz via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> This is the first part of a fix for the failure of the new simd test on
> non-
> VSX POWER targets. There are more casts to unavailable vectors of 64-bit
> element types to be rewritten.
>
> OK for master a
Hi,
This patch adds four IEEE functions from the Fortran 2018 standard:
IEEE_MIN_NUM, IEEE_MAX_NUM, IEEE_MIN_NUM_MAG, and IEEE_MAX_NUM_MAG.
Bootstrapped and regtested on x86_64-pc-linux-gnu, both 32 and 64-bit. OK to
commit?
FX
0001-Fortran-add-Fortran-2018-IEEE_-MIN-MAX-functions.patch
Des
Hi,
This patch merges the D front-end with upstream dmd 316b89f1e3, and
standard library with phobos 8e8aaae50.
Updates the D language version to v2.100.2 in the GCC 12 release branch.
Phobos changes:
- Fix instantiating std.container.array.Array!T where T is a
shared class.
- Fix
This makes the code more readable, more digestible, more maintainable,
more extensible. That kind of thing. It does that by pulling things
apart a bit, but also making what stays together more cohesive lumps.
The original function was a bunch of loops and early-outs, and then
quite a bit of stuf
2023-06-06 Segher Boessenkool
* config/rs6000/genfusion.pl: Delete some dead code.
---
gcc/config/rs6000/genfusion.pl | 3 ---
1 file changed, 3 deletions(-)
diff --git a/gcc/config/rs6000/genfusion.pl b/gcc/config/rs6000/genfusion.pl
index 2851bb7..82e8f86 100755
--- a/gcc/config/rs
+(define_mode_iterator V_ZVFHMIN_SF [
+ (VNx1SF "TARGET_VECTOR_ELEN_FP_32 && (TARGET_ZVFH || TARGET_ZVFHMIN) &&
TARGET_MIN_VLEN < 128")
+ (VNx2SF "TARGET_VECTOR_ELEN_FP_32 && (TARGET_ZVFH || TARGET_ZVFHMIN)")
+ (VNx4SF "TARGET_VECTOR_ELEN_FP_32 && (TARGET_ZVFH || TARGET_ZVFHMIN)")
+ (VNx8SF "T
Last part to resolve test failure introduced with PR109822.
OK for master and backports (gcc-11 doesn't have __builtin_shufflevector,
though)?
Tested on x86_64-pc-linux-gnu and powerpc64le-linux-gnu
- >8 -
Fix SFINAE on __is_intrinsic_type for 64-bit element types on non-VSX
POWER targ
IMO, TARGET_ZVFH || TARGET_ZVFHMIN may be a little readable compares to FP_16,
or some context I missed.
Anyway as we discussed offline, will refine this part and add zvfh part in V2.
Pan
From: 钟居哲
Sent: Tuesday, June 6, 2023 10:07 PM
To: Li, Pan2 ; gcc-patches
Cc: kito.cheng ; Li, Pan2 ; Wang
From: oluade01
This adds a recognition pattern for the non-widening
absolute difference (ABD).
gcc/ChangeLog:
* doc/md.texi (sabd, uabd): Document them.
* internal-fn.def (ABD): Use new optab.
* optabs.def (sabd_optab, uabd_optab): New optabs,
* tree-vect-pattern
On Tue, Jun 6, 2023 at 1:42 PM Hongtao Liu wrote:
>
> On Tue, Jun 6, 2023 at 5:11 PM Uros Bizjak wrote:
> >
> > On Tue, Jun 6, 2023 at 6:33 AM liuhongt via Gcc-patches
> > wrote:
> > >
> > > r14-1145 fold the intrinsics into gimple ABS_EXPR which has UB for
> > > TYPE_MIN, but PABSB will store u
LGTM, we would like to improve that on the combine pass, but it could
be improved later.
On Tue, Jun 6, 2023 at 8:04 PM wrote:
>
> From: Juzhe-Zhong
>
> Fix according to comments from Robin of V1 patch.
>
> This patch add combine optimization for following case:
> __attribute__ ((noipa)) void
>
Hi all,
This adds OpenMP 5.1's 'present' modifier to the to/from/map clauses
and 'defaultmap(present)'.
I have now committed that patch as
r14-1579-g4ede915d5dde935a16df2c6640aee5ab22348d30,
or as attached.
Or rather: I have done so after revising the patch for the issues I noted
before;
whil
On 6/5/23 17:26, Patrick Palka wrote:
Here when substituting the injected class name A during regeneration of
the lambda, we find ourselves in lookup_template_class for A with
V=_ZTAXtl3BarEE (i.e. the template parameter object for Foo{}). The
call to coerce_template_parms within then undesirabl
Hi Thomas,
this patch implements the OpenACC 2.7 change requiring the host_data construct
to have at least one use_device clause.
This patch started out with a simple check during gimplify (much smaller patch),
but turned out that front-ends removed use_device clauses when they have error,
and the
Hi Thomas,
this patch implements the OpenACC 2.7 addition of default(none|present) support
for data constructs.
Apart from adjusting the front-ends for allowed clauses masks (for acc data),
mostly implemented in gimplify.
Tested on powerpc64le-linux/nvptx, x86_64-linux/amdgcn tests in progress (e
> It would be good to mark all of these functions with __attribute__((noipa)),
> since I think interprocedural optimisations might otherwise defeat the
> runtime test in abd_run_1.c (in the sense that we might end up folding
> things at compile time and not testing the vector versions of the functi
Hi Uros,
This revision implements your suggestions/refinements. (i) Avoid the
UNSPEC_CMC by using the canonical RTL idiom for *x86_cmc, (ii) Use
peephole2s to convert x86_stc and *x86_cmc into alternate forms on
TARGET_SLOW_STC CPUs (pentium4), when a suitable QImode register is
available, (iii) P
From: oluade01
This patch adds new RTL and tests for sabd and uabd
PR tree-optimization/109156
gcc/ChangeLog:
* config/aarch64/aarch64-simd-builtins.def (sabd, uabd):
Change the mode to 3.
* config/aarch64/aarch64-simd.md (aarch64_abd):
Rename to abd3.
*
Committed, thanks Kito.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Kito Cheng via Gcc-patches
Sent: Tuesday, June 6, 2023 10:45 PM
To: juzhe.zh...@rivai.ai
Cc: gcc-patches@gcc.gnu.org; pal...@rivosinc.com; rdapp@gmail.com;
jeffreya...@gmail.com
Subject: Re: [PATCH V4] RI
On Tue, 2023-06-06 at 13:48 +0200, priour...@gmail.com wrote:
> From: Benjamin Priour
Hi Benjamin, thanks for this patch.
Overall it look great.
You didn't say what testing you did on the patch. Typically when
preparing a patch for the mailing list we do a bootstrap build of gcc
with the patch
On Thu, 1 Jun 2023 at 16:59, Jonathan Wakely via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Tested x86_64-linux. I'd appreciate a second set of eyeballs on this
> before I push it.
>
Pushed to trunk now.
>
> -- >8 --
>
> This ensures that anything that depends on AC_REQUIRE is hoisted out of
From: Pan Li
This patch would like to refactor the requirement of both the ZVFH
and ZVFHMIN. The related define_insn and iterator will take the
requirement based on the ZVFHMIN and ZVFH.
Please note the ZVFH will cover the ZVFHMIN instructions. This patch
add one test for this.
Signed-off-by: P
Andrew: Does the GCN change look okay to you?
This patch permits to use GCN devices with 'omp requires unified_address' which
in principle works already, except that the requirement handling did disable it.
(It also updates libgomp.texi for this change and likewise for an older
likewise nvptx c
Update the PATCH V2 as below.
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620787.html
Pan
From: Li, Pan2
Sent: Tuesday, June 6, 2023 10:34 PM
To: 钟居哲 ; gcc-patches
Cc: kito.cheng ; Wang, Yanzhang
Subject: RE: [PATCH v1] RISC-V: Refactor ZVFHMIN to separated iterator and
pattern
IMO,
On Tue, Jun 06, 2023 at 03:19:18PM +0200, FX via Fortran wrote:
> Hi,
>
> This patch adds four IEEE functions from the Fortran 2018
> standard: IEEE_MIN_NUM, IEEE_MAX_NUM, IEEE_MIN_NUM_MAG,
> and IEEE_MAX_NUM_MAG.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, both 32
> and 64-bit. OK to
On Tue, Jun 06, 2023 at 08:43:36AM -0700, Steve Kargl via Fortran wrote:
> On Tue, Jun 06, 2023 at 03:19:18PM +0200, FX via Fortran wrote:
> > Hi,
> >
> > This patch adds four IEEE functions from the Fortran 2018
> > standard: IEEE_MIN_NUM, IEEE_MAX_NUM, IEEE_MIN_NUM_MAG,
> > and IEEE_MAX_NUM_MAG.
On Tue, 6 Jun 2023 at 15:14, Matthias Kretz via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Last part to resolve test failure introduced with PR109822.
>
> OK for master and backports (gcc-11 doesn't have __builtin_shufflevector,
> though)?
>
Yep, OK.
>
> Tested on x86_64-pc-linux-gnu and powe
Thanks for reviewing Segher. Will work on backports as well :).
Jeevitha
Tested x86_64-linux and powerpc64le-linux. Pushed to trunk.
-- >8 --
This redefines std::numeric_limits<__float128> so that it works with
non-GCC compilers. The previous definition didn't work with Clang, due
to it not supporting __builtin_high_valq, __builtin_nanq, and
__builtin_nansq. It also d
Tested x86_64-linux and powerpc64le-linux. Pushed to trunk.
-- >8 --
Add the recently added CXXABI_1.3.15 version. Also remove two "frozen"
versions from the latestp list, as no more symbols should be added to
those now.
libstdc++-v3/ChangeLog:
* testsuite/util/testsuite_abi.cc (check_v
On 06/06/2023 16:33, Tobias Burnus wrote:
Andrew: Does the GCN change look okay to you?
This patch permits to use GCN devices with 'omp requires
unified_address' which
in principle works already, except that the requirement handling did
disable it.
(It also updates libgomp.texi for this chan
On 06/06/2023 13:49, Richard Sandiford via Gcc-patches wrote:
Tamar Christina writes:
int operand_number; /* Operand index in the big array. */
int output_format; /* INSN_OUTPUT_FORMAT_*. */
+ bool compact_syntax_p;
struct operand_data operand[MAX_MAX_OPERANDS];
Oluwatamilore Adebayo writes:
>> It would be good to mark all of these functions with __attribute__((noipa)),
>> since I think interprocedural optimisations might otherwise defeat the
>> runtime test in abd_run_1.c (in the sense that we might end up folding
>> things at compile time and not testin
gcc/ChangeLog:
* rtl.h (function_invariant_p): Change return type from int to bool.
* reload1.cc (function_invariant_p): Change return type from
int to bool and adjust function body accordingly.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Uros.
diff --git a/gcc/re
On Tue, Jun 6, 2023 at 5:14 PM Roger Sayle wrote:
>
>
> Hi Uros,
> This revision implements your suggestions/refinements. (i) Avoid the
> UNSPEC_CMC by using the canonical RTL idiom for *x86_cmc, (ii) Use
> peephole2s to convert x86_stc and *x86_cmc into alternate forms on
> TARGET_SLOW_STC CPUs (
Hi,
(It took me a while to get back to this.)
This is a new and improved version of the patch at
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602932.html
It addresses the comment from Joseph that FE_INVALID should really be tested in
the case of both quiet and signaling NaNs, which is
On Tue, Jun 06, 2023 at 08:51:54AM -0700, Steve Kargl via Fortran wrote:
>
> Scratch 2. Another scan shows that you moduled the Fortran
s/you moduled/you added to
> module where interface are built. This will automatically
s/interface/interfaces
> catch and report the items in 2.
Complete
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
In the second testcase of PR110122, during regeneration of the generic
lambda with V=Bar{}, substitution followed by coerce_template_parms for
A's template argument naturally yields a copy of V in terms of Ba
Hi FX,
On 6/6/23 15:19, FX via Gcc-patches wrote:
Hi,
This patch adds four IEEE functions from the Fortran 2018 standard:
IEEE_MIN_NUM, IEEE_MAX_NUM, IEEE_MIN_NUM_MAG, and IEEE_MAX_NUM_MAG.
Bootstrapped and regtested on x86_64-pc-linux-gnu, both 32 and 64-bit. OK to
commit?
FX
it would b
On Thu, Jun 01, 2023 at 05:27:56PM +0100, Andre Vieira (lists) via Gcc-patches
wrote:
> --- a/gcc/internal-fn.h
> +++ b/gcc/internal-fn.h
> @@ -20,6 +20,10 @@ along with GCC; see the file COPYING3. If not see
> #ifndef GCC_INTERNAL_FN_H
> #define GCC_INTERNAL_FN_H
>
> +#include "insn-codes.h"
Hi,
> I cannot see if there is proper support for kind=17 in your patch;
> at least the libgfortran/ieee/ieee_arithmetic.F90 part does not
> seem to have any related code.
Can real(kind=17) ever be an IEEE mode? If so, something seriously wrong
happened, because the IEEE modules have no kind=17
Hi,
This is a repost of the patch at
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600887.html
which never really got green light, but I stopped pushing because stage 1 was
closing and I was out of time.
It depends on a middle-end patch adding a type-generic __builtin_iseqsig(),
whi
Hi Steve,
I am not subscribed to the list (too little time, sadly), please keep me in CC
of your responses.
> 1. You added fmin, fmax, and friends. Are these used
>internally by gfortran in support of the IEEE_*
>functions or are these exposed to the user?
The math builtins are added
Kewen, GCC maintainers:
Version 2, I have addressed the various comments from Kewen. I had
issues with adding an additional overloaded version of
scalar_insert_exp with vector arguments. The overload infrastructure
didn't work with a mix of scalar and vector arguments. I did rename
the __builti
On Mon, 2023-06-05 at 16:45 +0800, Kewen.Lin wrote:
> Hi Carl,
>
> on 2023/5/2 23:52, Carl Love via Gcc-patches wrote:
> > GCC maintainers:
> >
> > The following patch adds three buitins for inserting and extracting
> > the
> > exponent and significand for an IEEE 128-bit floating point
> > value
Hi,
This patch series adds initial support for ISO C++'s [P1689R5][], a
format for describing C++ module requirements and provisions based on
the source code. This is required because compiling C++ with modules is
not embarrassingly parallel and need to be ordered to ensure that
`import some_modul
1 - 100 of 168 matches
Mail list logo
