Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Thursday, July 4, 2024 12:46 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>> ; Marcus Shawcroft
>> ; ktkac...@gcc.gnu.or
t; ret
>
> .LC0:
> .byte 0
> .byte 1
> .byte 2
> .byte 3
> .byte 20
> .byte 21
> .byte 22
> .byte 23
> .byte 4
> .byte 5
> .byte 6
>
> -Original Message-
> From: Richard Sandiford
> Sent: Thursday, July 4, 2024 12:46 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; ktkac...@gcc.gnu.org
> Subject: Re: [PATCH 1/2]AArch64: make aarch64_
Tamar Christina writes:
> Hi All,
>
> The fix for PR18127 reworked the uxtl to zip optimization.
> In doing so it undid the changes in aarch64_simd_vec_unpack_lo_ and this
> now
> no longer matches aarch64_simd_vec_unpack_hi_. It still works because the
> RTL generated by
> >>>
> >>>
> >>> Am 02.07.24 um 15:48 schrieb Richard Biener:
> >>>> On Tue, Jul 2, 2024 at 3:43 PM Georg-Johann Lay wrote:
> >>>>>
> >>>>> Hi Jeff,
> >>>>>
> >>>>>
.byte 23
.byte 4
.byte 5
.byte 6
.byte 7
.byte 24
.byte 25
.byte 26
.byte 27
and with the patch:
f1:
adrpx0, .LC0
ldr q31, [x0, #:lo12:.LC0]
tbl v0.16b, {v0.16b}, v31.16b
ret
Hi All,
The fix for PR18127 reworked the uxtl to zip optimization.
In doing so it undid the changes in aarch64_simd_vec_unpack_lo_ and this now
no longer matches aarch64_simd_vec_unpack_hi_. It still works because the
RTL generated by aarch64_simd_vec_unpack_lo_ overlaps with the general zero
> On 3 Jul 2024, at 11:59, Kyrylo Tkachov wrote:
>
> Hi all,
>
> The ACLE asks the user to test for __ARM_FEATURE_BF16 before using the
> header but GCC doesn't set this up.
> LLVM does, so this is an inconsistency between the compilers.
>
> This patch enables th
Am 04.07.24 um 11:49 schrieb Richard Biener:
On Thu, Jul 4, 2024 at 11:24 AM Richard Biener
wrote:
On Wed, Jul 3, 2024 at 9:26 PM Georg-Johann Lay wrote:
Am 02.07.24 um 15:48 schrieb Richard Biener:
On Tue, Jul 2, 2024 at 3:43 PM Georg-Johann Lay wrote:
Hi Jeff,
This is a patch
The following implements the group-size three scheme from
vect_permute_store_chain in SLP grouped store permute lowering
and extends it to power-of-two multiples of group size three.
The scheme goes from vectors A, B and C to
{ A[0], B[0], C[0], A[1], B[1], C[1], ... } by first producing
{ A[0],
The following implements the group-size three scheme from
vect_permute_store_chain in SLP grouped store permute lowering
and extends it to power-of-two multiples of group size three.
The scheme goes from vectors A, B and C to
{ A[0], B[0], C[0], A[1], B[1], C[1], ... } by first producing
{ A[0],
Hi All,
The PR was about SVE codegen, the testcase accidentally used neoverse-n1
instead of neoverse-v1 as was the original report.
This updates the tool options.
Regtested on aarch64-none-linux-gnu and no issues.
committed under the obvious rule.
Thanks,
Tamar
gcc/testsuite/ChangeLog:
gcc/ChangeLog:
* config/loongarch/loongarch.cc
(loongarch_split_move): Delete.
(loongarch_hard_regno_mode_ok_uncached): Likewise.
* config/loongarch/loongarch.md
(move_doubleword_fpr): Likewise.
(load_low): Likewise.
(load_high): Likewise.
PR target/115752
gcc/ChangeLog:
* config/loongarch/loongarch.cc
(loongarch_hard_regno_mode_ok_uncached): Replace
UNITS_PER_FPVALUE with UNITS_PER_HWFPVALUE.
* config/loongarch/loongarch.h (UNITS_PER_FPVALUE): Delete.
gcc/testsuite/ChangeLog:
*
On Thu, Jul 4, 2024 at 11:24 AM Richard Biener
wrote:
>
> On Wed, Jul 3, 2024 at 9:26 PM Georg-Johann Lay wrote:
> >
> >
> >
> > Am 02.07.24 um 15:48 schrieb Richard Biener:
> > > On Tue, Jul 2, 2024 at 3:43 PM Georg-Johann Lay wrote:
> > >>
&
end up with
ldm r0!, {r0, r1}
Which of course is unpredictable. So we need to test not only that r0 is dead
but that it isn't written by the load either.
Anyway, thanks for the patch.
R.
>
> Signed-off-by: Siarhei Volkau
> ---
> gcc/config/arm/arm.cc
On Wed, Jul 3, 2024 at 9:26 PM Georg-Johann Lay wrote:
>
>
>
> Am 02.07.24 um 15:48 schrieb Richard Biener:
> > On Tue, Jul 2, 2024 at 3:43 PM Georg-Johann Lay wrote:
> >>
> >> Hi Jeff,
> >>
> >> This is a patch to get correct c
The change is OK, thanks.
> We suffer from an inconsistency in the names of uninstalled gnattools
> executables in cross-compiler configurations. The cause is a recipe we
> have:
>
> ada.all.cross:
> for tool in $(ADA_TOOLS) ; do \
> if [ -f $$tool$(exeext) ] ; \
> then
Hi,
The fix for PR112993 will make KFmode have 128 bit mode precision,
we don't need this workaround to fix up the type precision any
more, and just go with the mode precision. So this patch is to
remove KFmode workaround.
Bootstrapped and regtested on x86_64-redhat-linux,
powerpc64{,le}-linux
Cache the source files as they are read, rather than discarding them at
the end of output_lines (), and move the reading of the source file to
the new function slurp.
This patch does not really change anything other than moving the file
reading out of output_file, but set gcov up for more
,
this special setting has caused some issues like some
unexpected failures mentioned in [1] and also made us have
to introduce some workarounds, such as: the workaround in
build_common_tree_nodes for KFmode 126, the workaround in
range_compatible_p for same mode but different precision
issue.
This patch
for that, this
patch is to make function convert_mode_scalar allow same
precision FP modes conversion if their underlying formats are
ibm_extended_format and ieee_quad_format respectively, just
like the existing special treatment on arm_bfloat_half_format
<-> ieee_half_format. It also factors o
regards,
> Alfie
>
> Sent from Outlook for iOS
> From: Kyrylo Tkachov
> Sent: Wednesday, July 3, 2024 11:23:37 AM
> To: Alfie Richards
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH v1 0/2] Aarch64: addp NEON big-endian fix [PR114890] Hi
> Alfie,
>
Hi Carl,
on 2024/7/4 07:51, Carl Love wrote:
> GCC maintainers:
>
> The patch has been updated to remove the customized vec_init built-in code.
> Specfivically the init identifier, the related generated code for the init
> built-in attribute bit, function altivec_expand_v
Hi,
on 2024/7/4 07:40, Carl Love wrote:
>
> GCC maintainers:
>
> I moved the removal of built-ins __builtin_vsx_xvcvdpsxws and
> __builtin_vsx_xvcvdpuxws from patch 4 to patch patch 2.
>
> I fixed various issues with the ChangeLog wording, spaces and descriptions.
&g
Hi,
on 2024/7/4 07:33, Carl Love wrote:
> GCC maintainers:
>
> Per the comments on patch 2 from version 4, I have moved the removal of
> built-ins __builtin_vsx_xvcvdpsxws and __builtin_vsx_xvcvdpuxws from patch 4
> to this patch.
>
> Please let me know if this patch i
Hi Carl,
on 2024/7/4 01:23, Carl Love wrote:
>
> On 7/3/24 2:36 AM, Kewen.Lin wrote:
>> Hi Carl,
>>
>> on 2024/6/27 01:05, Carl Love wrote:
>>> GCC maintainers:
>>>
>>> The following patch updates the user documentation for the vec_ld,
>&& rs6000_rop_protect
>>>&& info->rop_hash_size != 0
>>
>> ... here, both check info->rop_hash_size isn't zero, I think we can drop
>> these
>> two TARGET_POWER10 (TARGET_POWER8) and rs6000_rop_protect checks? Instead
>> j
scalar stmt computing
> > the result. I originally added SLP_TREE_SCALAR_STMTS to two-operator
> > nodes but this exposes PR115764, so I've split that out.
> >
> > I have a patch use NULL elements for loads from groups with gaps
> > where we get around not doing that by
>> Hmm, now all avx512 tests SIGILL when testing with -m32:
>>
>> Dump of assembler code for function __get_cpuid_count:
>> => 0x08049500 <+0>: kmovd %eax,%k2
>> 0x08049504 <+4>: kmovd %edx,%k1
>> 0x08049508 <+8>: pushf
>> 0x08049509 <+9>: pushf
>> 0x0804950a <+10>:
Ping^5 https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650763.html
On Mon, 2024-05-06 at 12:45 +0800, Xi Ruoyao wrote:
> In GCC 14.1-rc1, there are two new (comparing to GCC 13) failures if
> the build is configured --enable-default-pie. Let's fix them.
>
> Tested on x86_64-linux-gnu. Ok
On Sun, 2024-06-30 at 17:47 -0700, Vineet Gupta wrote:
> - Don't hardcode SI in patterns, try to keep X to avoid potential
> sign extension pitfalls. Implementation wise requires skipping
> :MODE specifier in match_operand which is flagged as missing mode
> warning.
I'm unsure about
-November/637935.html
This patch is using IFN ARG_PARTS and SET_RET_PARTS for parameters
and returns. And expand the IFNs according to the incoming/outgoing
registers.
Again there are a few thing could be enhanced for this patch:
* Multi-registers access
* Parameter access cross call
* Optimize
On Tue, Jul 2, 2024 at 11:24 AM Hongyu Wang wrote:
>
> Hi,
>
> According to APX spec, the pushp/popp pairs should be matched,
> otherwise the PPX hint cannot take effect and cause performance loss.
>
> In the ix86_expand_epilogue, there are several optimizations that may
> cause the epilogue
(call, lhs);
gsi_replace (gsi, call, /* update_eh_info */ true);
}
}
Pan
-Original Message-
From: Jeff Law
Sent: Thursday, July 4, 2024 9:52 AM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; rdapp@gmail.com
Subject: Re: [PATCH v2] RI
gt;> >>
>> >> On Wed, Jul 3, 2024 at 9:25 AM liuhongt wrote:
>> >> >
>> >> > The patch can avoid SIGILL on non-AVX512 machine due to kmovd is
>> >> > generated in dynamic check.
>> >> >
>> >> > Committed a
On 7/3/24 6:48 PM, Li, Pan2 wrote:
Thanks Jeff for comments.
I would expect that QI/HI shouldn't be happening in practice due to the
definition of WORD_REGISTER_OPERATIONS.
Sorry I don't get the point here, I suppose there may be 6 kinds of truncation
for scalar.
uint64_t => uint32_t
On Thu, Jul 4, 2024, 9:12 AM Hongtao Liu wrote:
> On Thu, Jul 4, 2024 at 6:17 AM H.J. Lu wrote:
> >
> >
> > On Wed, Jul 3, 2024, 9:37 PM Richard Biener
> wrote:
> >>
> >> On Wed, Jul 3, 2024 at 9:25 AM liuhongt wrote:
> >> >
> >>
From: "H.J. Lu"
>The above reads like it would be worth splitting branc_prediction_hits
>into branch_prediction_hints_taken and branch_prediction_hints_not_taken
>given not-taken is the default and thus will just increase code size?
>According to Intel® 64 and IA-32 Architectures Optimization
On Thu, Jul 4, 2024 at 6:17 AM H.J. Lu wrote:
>
>
> On Wed, Jul 3, 2024, 9:37 PM Richard Biener
> wrote:
>>
>> On Wed, Jul 3, 2024 at 9:25 AM liuhongt wrote:
>> >
>> > The patch can avoid SIGILL on non-AVX512 machine due to kmovd is
>> &
w
Sent: Wednesday, July 3, 2024 11:14 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; rdapp....@gmail.com
Subject: Re: [PATCH v2] RISC-V: Implement the .SAT_TRUNC for scalar
On 7/2/24 7:16 PM, Li, Pan2 wrote:
> Thanks Jeff for comments.
>
&
Hi!
On Wed, 2024-07-03 at 19:28 +0200, Sébastien Michelland wrote:
> On 2024-07-03 17:59, Jeff Law wrote:
> > On 7/3/24 3:59 AM, Sébastien Michelland wrote:
> > > libgcc's fp-bit.c is quite slow and most modern/developed architectures
> > > have switched to using the
Kewen:
On 6/18/24 20:04, Kewen.Lin wrote:
Hi Carl,
on 2024/6/14 03:40, Carl Love wrote:
GCC maintainers:
The patch has been updated per the feedback from version 3. Please let me know
it the patch is acceptable for mainline.
Thanks.
Carl
GCC maintainers:
The patch has been updated to remove the customized vec_init built-in
code. Specfivically the init identifier, the related generated code for
the init built-in attribute bit, function
altivec_expand_vec_init_builtin and calls to the function.
Please let me know
GCC maintainers:
I moved the removal of built-ins __builtin_vsx_xvcvdpsxws and
__builtin_vsx_xvcvdpuxws from patch 4 to patch patch 2.
I fixed various issues with the ChangeLog wording, spaces and descriptions.
Fixed the comments in file gcc/config/rs6000/vsx.md.
Updated the built
nclude
>
> const int runs = 92;
Sorry, the new include isn't necessary. It's a leftover from a previous
version of the patch.
I removed it locally and if the patch is approved, I'll commit it
without this hunk.
--
Thiago
GCC maintainers:
Per the comments on patch 2 from version 4, I have moved the removal of
built-ins __builtin_vsx_xvcvdpsxws and __builtin_vsx_xvcvdpuxws from patch 4 to
this patch.
Please let me know if this patch is acceptable. Thanks.
Carl
On Wed, Jul 3, 2024 at 4:25 PM Iain Sandoe wrote:
>
>
>
> > On 28 Jun 2024, at 07:03, Uros Bizjak wrote:
> >
> > On Fri, Jun 28, 2024 at 7:29 AM liuhongt wrote:
> >>
> >> Move pass_stv2 and pass_rpad after pre_reload pass_late_combine, also
> >> define target_insn_cost to prevent post_reload
> On 28 Jun 2024, at 07:03, Uros Bizjak wrote:
>
> On Fri, Jun 28, 2024 at 7:29 AM liuhongt wrote:
>>
>> Move pass_stv2 and pass_rpad after pre_reload pass_late_combine, also
>> define target_insn_cost to prevent post_reload pass_late_combine to
>> revert the optimziation did in pass_rpad.
On arm-none-eabi, g++.dg/vect/pr115278.cc fails with:
FAIL: g++.dg/vect/pr115278.cc -std=c++14 (test for excess errors)
Excess errors:
/path/to/gcc.git/gcc/testsuite/g++.dg/vect/pr115278.cc:24:28: error: invalid
conversion from 'volatile unsigned int*' to 'volatile uint32_t*' {aka 'volatile
to be approved. Only these unapproved
patches are posted in the version 5 series.
The goal is to commit the entire series all at once as they are all related.
So I a holding off committing the approved patches.
Thank you for your time and feedback of these patches. The entire patch series
has been
On Wed, Jul 3, 2024, 9:37 PM Richard Biener
wrote:
> On Wed, Jul 3, 2024 at 9:25 AM liuhongt wrote:
> >
> > The patch can avoid SIGILL on non-AVX512 machine due to kmovd is
> > generated in dynamic check.
> >
> > Committed as an obvious fix.
>
> Hmm, n
hand?)
This points to OG14 commit 92c3af3d4f82351c7133b6ee90e213a8a5a485db
"Fortran/OpenMP: Support mapping of DT with allocatable components":
On 2022-03-01T16:34:18+0100, Tobias Burnus wrote:
> this patch adds support for mapping something like
>type t
> type(t2), allocatable :: a, b(:)
> in
Regarding the amocas.q follow-up patch:
I'm having trouble with matching any TImode compare-and-swap patterns.
Here's the RTL I'm trying:
(define_mode_iterator SUPERGPR [SI DI TI])
(define_insn "zacas_atomic_cas_value"
[(set (match_operand:SUPERGPR 0 "r
.
- if (flag_concepts_ts && ppd->type_pack_expansion_p && is_auto (t)
(BTW this seems to be the only actual user of type_pack_expansion_p so we
can in turn remove that field too.)
Oh neat. I can do that as a follow-up, unless y'all think it should be
part of
Address computation (usually add) with symbols that are aligned
to 256 bytes does not require to add the lo8() part as it is zero.
This patch adds a new combine insn that performs a widening add
from QImode plus such a symbol. The case when such an aligned
symbol is added to a reg that's
Am 03.07.24 um 21:39 schrieb Jeff Law:
On 7/3/24 1:26 PM, Georg-Johann Lay wrote:
Am 02.07.24 um 15:48 schrieb Richard Biener:
On Tue, Jul 2, 2024 at 3:43 PM Georg-Johann Lay wrote:
Hi Jeff,
This is a patch to get correct code out of 64-bit
loads from address-space __memx.
The AVR
On 7/3/24 1:26 PM, Georg-Johann Lay wrote:
Am 02.07.24 um 15:48 schrieb Richard Biener:
On Tue, Jul 2, 2024 at 3:43 PM Georg-Johann Lay wrote:
Hi Jeff,
This is a patch to get correct code out of 64-bit
loads from address-space __memx.
The AVR address-spaces may require that move insns
Am 02.07.24 um 15:48 schrieb Richard Biener:
On Tue, Jul 2, 2024 at 3:43 PM Georg-Johann Lay wrote:
Hi Jeff,
This is a patch to get correct code out of 64-bit
loads from address-space __memx.
The AVR address-spaces may require that move insns issue
calls to library support functions
3 Jul 2024 3:10:14 pm Peter Damianov :
Currently, if a warning references a cloned function, the name of the
cloned
function will be emitted in the "In function 'xyz'" part of the
diagnostic,
which users aren't supposed to see. This patch follows the DECL_ORIGIN
link
to ge
On Fri, 2024-06-28 at 17:53 -0700, Vineet Gupta wrote:
> I was also hoping to get __builtin_inf() done but unforutnately it
> requires little more rtl foo/bar to implement a tri-modal return.
Hmm do we really need to care the symbol? The generic __builtin_isinf
does not care the symbol anyway:
x86_override_options_after_change_1): Add opts and opts_set
>>> parms, operate on them, after factoring out of...
>>> (ix86_override_options_after_change): ... this. Restore calls
>>> of ix86_default_align and ix86_recompute_optlev_based_flags.
>>> (ix86_option_over
STMTS to two-operator
> nodes but this exposes PR115764, so I've split that out.
>
> I have a patch use NULL elements for loads from groups with gaps
> where we get around not doing that by having a load permutation.
>
> I'm currently re-bootstrapping and testing this, it passed mu
From: Gianluca Guida
This patch adds support for amocas.{b|h|w|d}. Support for amocas.q
(64/128 bit cas for rv32/64) will be added in a future patch.
Extension: https://github.com/riscv/riscv-zacas
Ratification: https://jira.riscv.org/browse/RVS-680
gcc/ChangeLog:
* common/config
ers in the template arguments exceeds the
> number of levels in the type. This causes the missing levels to be negative.
> This leads to the rejection of valid code and ICEs (like segfault) in the
> release mode. In the debug mode, it is possible to show as an assertion
> failure
>
On 7/3/24 2:36 AM, Kewen.Lin wrote:
Hi Carl,
on 2024/6/27 01:05, Carl Love wrote:
GCC maintainers:
The following patch updates the user documentation for the vec_ld, vec_lde,
vec_st and vec_ste built-ins to make it clearer that there are data alignment
requirements for these built-ins
On 6/27/24 11:25 AM, Tamar Christina wrote:
-Original Message-
From: Jason Merrill
Sent: Tuesday, June 25, 2024 10:24 PM
To: Tamar Christina
Cc: gcc-patches@gcc.gnu.org; nd ; nat...@acm.org
Subject: Re: [PATCH][c++ frontend]: check for missing condition for novector
[PR115623]
On 6/25
On 2024-07-03 17:59, Jeff Law wrote:
On 7/3/24 3:59 AM, Sébastien Michelland wrote:
libgcc's fp-bit.c is quite slow and most modern/developed architectures
have switched to using the soft-fp library. This patch does so for
free-standing/unknown-OS SH3/SH4 builds, using soft-fp's default
][1]();
should not say "converting to S from initializer list would use
explicit constructor" because there's no {}. However, since we
went into the block where we create a {}, we got confused. We
should not have gotten there but we did because array_p was true.
This patch refines the ch
On 7/3/24 11:56 AM, Jakub Jelinek wrote:
On Wed, Jul 03, 2024 at 11:35:26AM -0400, Jason Merrill wrote:
This patch should also remove the integer_zerop diagnostic lower in the
function, which becomes dead code with this change.
So like this?
Passed quick testing, ok if it passes full
> > should be the same either way, so just wondering.
>
> Just that the inline is then redundant.
> But I'll do whatever Jonathan wants (already added #undef of the macro after
> uses).
I have a mild preference (again :-) for what Jakub's patch does. Those
declarations are getting more and more
On 7/3/24 3:59 AM, Sébastien Michelland wrote:
libgcc's fp-bit.c is quite slow and most modern/developed architectures
have switched to using the soft-fp library. This patch does so for
free-standing/unknown-OS SH3/SH4 builds, using soft-fp's default parameters
for the most part, most notably
On Wed, Jul 03, 2024 at 11:35:26AM -0400, Jason Merrill wrote:
> This patch should also remove the integer_zerop diagnostic lower in the
> function, which becomes dead code with this change.
So like this?
Passed quick testing, ok if it passes full bootstrap/regtest?
2024-07-03 Jakub J
On Wed, Jul 03, 2024 at 11:41:58AM -0400, Jason Merrill wrote:
> On 7/3/24 10:37 AM, Jakub Jelinek wrote:
> > +#if __cpp_lib_constexpr_new >= 202406L
> > +# define _GLIBCXX_PLACEMENT_CONSTEXPR constexpr
> > +#else
> > +# define _GLIBCXX_PLACEMENT_CONSTEXPR inline
> > +#endif
>
> I'm a bit curious
On 7/3/24 8:24 AM, Luis Silva wrote:
... to comply with new standards due to stricter analysis in
the latest GCC versions.
gcc/testsuite/ChangeLog:
* gcc.target/arc/pr9001184797.c: (Fix compiler warnings)
I fixed the ChangeLog entry and pushed this to the trunk for you.
I guess we
On 7/3/24 10:37 AM, Jakub Jelinek wrote:
+#if __cpp_lib_constexpr_new >= 202406L
+# define _GLIBCXX_PLACEMENT_CONSTEXPR constexpr
+#else
+# define _GLIBCXX_PLACEMENT_CONSTEXPR inline
+#endif
I'm a bit curious why you want constexpr *or* inline rather than leaving
the inline keyword on the
t; seems to be slightly larger. Maybe it will be faster (or slower) in some
> > cases I didn't test?
> >
> > I think I like the change anyway - any other opinions on whether it's an
> > improvement?
>
> Any thoughts before I push this? Better? Worse? Needs more cowbell?
I think the patch is an improvement. Push it.
On 7/3/24 10:39 AM, Jakub Jelinek wrote:
Hi!
The following patch implements CWG2819 (which wasn't a DR because
it changes behavior of C++26 only).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-07-03 Jakub Jelinek
* constexpr.cc
On Thu, 27 Jun 2024 at 11:52, Jonathan Wakely wrote:
>
> This refactoring to use RAII doesn't seem to make any difference in
> benchmarks, although the generated code for some std::vector operations
> seems to be slightly larger. Maybe it will be faster (or slower) in some
> cases I didn't test?
>
Ping * 2. [Message-ID: <1e003d78-3b2e-4263-830a-7c00a3e9d...@linux.ibm.com>]
Segher, this resolves the issues you mentioned in your review.
Peter
On 6/18/24 5:59 PM, Peter Bergner wrote:
> Updated patch. This passed bootstrap and regtesting on powerpc64le-linux
> with no regr
On 7/2/24 7:16 PM, Li, Pan2 wrote:
Thanks Jeff for comments.
Why are you using Pmode? Pmode is for pointers. This stuff looks like
basic integer ops, so I don't see why Pmode is appropriate.
The incoming operand may be HI/QI/SImode, so we need to prompt the mode.
So there we should take
zero, I think we can drop these
> two TARGET_POWER10 (TARGET_POWER8) and rs6000_rop_protect checks? Instead
> just
> update the inner gcc_assert (now checking DEFAULT_ABI == ABI_ELFv2) by extra
> checkings on TARGET_POWER8 && rs6000_rop_protect?
>
> The other looks good t
On Wed, 3 Jul 2024 at 15:37, Jakub Jelinek wrote:
>
> Hi!
>
> With the PR115754 fix in, constexpr placement new mostly just works,
> so this patch just adds constexpr keyword to the placement new operators
> in , adds FTMs and testsuite coverage.
>
> There is one accepts-i
;
jeffreya...@gmail.com; rdapp@gmail.com
Subject: Re: [PATCH v1] RISC-V: Bugfix vfmv insn honor zvfhmin for FP16 SEW
[PR115763]
LGTM and ok for gcc 14 as well,
btw an idea is that actually could passed via gpr, I mean fpr->gpr and then
vmv.v.x, but it's not block commend for this patch.
Hi!
The following patch implements CWG2819 (which wasn't a DR because
it changes behavior of C++26 only).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-07-03 Jakub Jelinek
* constexpr.cc (cxx_eval_constant_expression): CWG2819 - Allow
cv void
Hi!
With the PR115754 fix in, constexpr placement new mostly just works,
so this patch just adds constexpr keyword to the placement new operators
in , adds FTMs and testsuite coverage.
There is one accepts-invalid though, the
new (p + 1) int[]{2, 3}; // error (in this paper)
case from
LGTM and ok for gcc 14 as well,
btw an idea is that actually could passed via gpr, I mean fpr->gpr and then
vmv.v.x, but it's not block commend for this patch.
钟居哲 於 2024年7月3日 週三 22:18 寫道：
> LGTM。
>
> --
> juzhe.zh...@rivai.ai
>
>
> *From:* pa
... to comply with new standards due to stricter analysis in
the latest GCC versions.
gcc/testsuite/ChangeLog:
* gcc.target/arc/pr9001184797.c: (Fix compiler warnings)
---
gcc/testsuite/ChangeLog | 4
gcc/testsuite/gcc.target/arc/pr9001184797.c | 4 +++-
2 files
try-to-explain-harder seems a little too "cute"
> to me, but I can't think of a better name.
Me either -:)
>
> Various comments inline below... I'm sorry I didn't take a close look
> at the copy history implementation; I'm hoping Richi will dig into that
> part of the patch.
&g
LGTM。
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-07-03 22:17
To: gcc-patches
CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li
Subject: [PATCH v1] RISC-V: Bugfix vfmv insn honor zvfhmin for FP16 SEW
[PR115763]
From: Pan Li
According to the ISA, the zvfhmin sub extension
From: Pan Li
According to the ISA, the zvfhmin sub extension should only contain
convertion insn. Thus, the vfmv insn acts on FP16 should not be
present when only the zvfhmin option is given.
This patch would like to fix it by split the pred_broadcast define_insn
into zvfhmin and zvfh part
Currently, if a warning references a cloned function, the name of the cloned
function will be emitted in the "In function 'xyz'" part of the diagnostic,
which users aren't supposed to see. This patch follows the DECL_ORIGIN link
to get the name of the original function.
gcc/ChangeLog:
On Wed, Jul 3, 2024 at 9:25 AM liuhongt wrote:
>
> The patch can avoid SIGILL on non-AVX512 machine due to kmovd is
> generated in dynamic check.
>
> Committed as an obvious fix.
Hmm, now all avx512 tests SIGILL when testing with -m32:
Dump of assembler code for function __
e-
From: Richard Biener
Sent: Wednesday, July 3, 2024 5:03 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@gmail.com;
tamar.christ...@arm.com; jeffreya...@gmail.com; rdapp....@gmail.com
Subject: Re: [PATCH v1] Vect: Distribute truncation into .SAT_SUB operands
Re: [PATCH v2] Vect: Support IFN SAT_TRUNC for unsigned vector int
On Wed, Jul 3, 2024 at 3:33 AM wrote:
>
> From: Pan Li
>
> This patch would like to support the .SAT_TRUNC for the unsigned
> vector int. Given we have below example code:
>
> Form 1
> #define VEC_
-sizes though (but the patch does not).
Optimal schemes are likely difficult to lay out in VF agnostic form.
I'll note that while the lowering assumes even/odd extract is
generally available for all vector element sizes (which is probably
a good assumption), it doesn't in any way constrain the other
The following implements the group-size three scheme from
vect_permute_store_chain in SLP grouped store permute lowering
and extends it to power-of-two multiples of group size three.
The scheme goes from vectors A, B and C to
{ A[0], B[0], C[0], A[1], B[1], C[1], ... } by first producing
{ A[0],
The following adds handling of gaps by representing them with NULL
entries in SLP_TREE_SCALAR_STMTS for the unpermuted load node.
The SLP discovery changes could be elided if we manually build the
load node instead.
* tree-vect-slp.cc (vect_build_slp_tree_1): Handle NULL stmt.
The following extends the SLP load permutation to single-level
interleaving to handle the case we need multiple levels and adding
a fallback handling when the required permutes do not match
interleaving but would need three vectors to implement (and thus
fail). With the change all single-lane SLP
Re: [PATCH v1] Match: Allow more types truncation for .SAT_TRUNC
On Tue, Jul 2, 2024 at 3:38 AM wrote:
>
> From: Pan Li
>
> The .SAT_TRUNC has the input and output types, aka cvt from
> itype to otype and the sizeof (otype) < sizeof (itype). The
> previous patch only
201 - 300 of 246018 matches
Mail list logo
