Nowhere near the top of my list, but a quick looksie Sunday led to an
easy to fix backend bug. It's not a regression, but given its the H8
backend I think we've safely got a degree of freedom here.
The H8 has a constraint "U" which allowed both a subset of MEMs and
REGs, so it wasn't marked
On Mon, 27 Jan 2025, Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14?
>
> -- >8 --
>
> This case was incorrectly failing in C++23 mode even after P2492R2
> because the perfect forwarding simplification mechanism assumed bound
> arguments are copy-constructibl
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14?
-- >8 --
This case was incorrectly failing in C++23 mode even after P2492R2
because the perfect forwarding simplification mechanism assumed bound
arguments are copy-constructible which is no longer necessarily true
after that paper.
Hello all,
The attached patch is part 1 of my effort to fix these X and T edit
descriptor issues. This one cleans up some really ugly output.
Before the patch with the test case provided by the reporter:
PI.^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ 3.1415926535897931
REAL(PI)
On 1/26/25 05:33, pan2...@intel.com wrote:
> From: Pan Li
>
> After we add the frm register to the global_regs, we may not need to
> define_insn that volatile to emit the frm restore insns. The
> cooperatively-managed global register will help to handle this, instead
> of emit the volatile define
Hi!
The following testcases ICE with RAW_DATA_CSTs (so the first one since
introduction of #embed C++ optimizations and the latter since optimization
of large sequences of comma separated literals).
I've missed the fact that implicit_conversion can embed the exact expression
passed to it into stuf
Hi!
The following testcase is miscompiled at -Os on x86_64-linux.
The problem is during make_compound_operation of
(ashiftrt:SI (ashift:SI (mult:SI (reg:SI 107 [ a_5 ])
(const_int 3 [0x3]))
(const_int 31 [0x1f]))
(const_int 31 [0x1f]))
where it incorrectly returns
(mult:SI
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
-- >8 --
We've had a wrong-code problem since r14-4140, due to which we
forget to initialize a variable.
In consteval39.C, we evaluate
struct QQQ q;
<>>
(const char *) "" ) >;
into
struct QQQ q;
<;
a
Hi!
This is basically Marek's PR114479 r14-9759 __is_array fix applied to
__is_bounded_array as well. Similarly to that trait, when not using
the builtin it returned false for zero sized arrays but when using
the builtin it returns true.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In r15-2761 I changed unify to always strip IMPLICIT_CONV_EXPR from PARM.
In this testcase that leads to comparing nullptr to (int*)0, and failing
because they aren't the same. Let's only strip conversions if we're
actually going to try to
On 1/27/25 4:17 PM, Patrick Palka wrote:
On Mon, 27 Jan 2025, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/14?
OK.
+&& (cxx_dialect < cxx23 || !deduction_guide_p (NODE))) \
N.B. I decided to check cxx_dialect here since deduction
Hi,
On Mon, Jan 20, 2025 at 11:59:16AM +0100, Mark Wielaard wrote:
> On Sun, Jan 19, 2025 at 05:14:20PM +0100, Mark Wielaard wrote:
> > On Tue, Dec 17, 2024 at 04:40:10PM +0900, Gerald Pfeifer wrote:
> > > On Mon, 2 Dec 2024, Mark Wielaard wrote:
> > > > Adjust the DCO text to match the broader co
On Sat, 25 Jan 2025, Jakub Jelinek wrote:
> The following patch uses build_qualified_type with TYPE_UNQUALIFIED instead,
> which will be in the common case the same as TYPE_MAIN_VARIANT if the
> checks are satisfied for it, but if not, will look up different unqualified
> type or even create it if
The issue is same as PR118103 and fixed by commit 55d288d4ff53
("RISC-V: Make FRM as global register [PR118103]").
Essentially FRM save/restore were getting eliminated because FRM reg
semantics were not being modelled correctly.
In this case it showed up as SPEC2017 527.cam4 runtime aborts in
gli
On Mon, 27 Jan 2025, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk/14?
>
> -- >8 --
>
> We recently started using the lang_decl_fn::context field to track
> inheritedness of a deduction guide (for C++23 inherited CTAD). This
> new overlo
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/14?
-- >8 --
We recently started using the lang_decl_fn::context field to track
inheritedness of a deduction guide (for C++23 inherited CTAD). This
new overloading of the field accidentally made DECL_FRIEND_CONTEXT
re
On Sat, 2025-01-25 at 23:31 -0800, Andi Kleen wrote:
> From: Andi Kleen
>
> This is the hot function in input.cc
>
> The vectorizer can vectorize it now, but in a generic cpu O2 x86
> build it isn't.
> Add a automatic target clone to handle it for x86 and build
> that function with O3.
>
> The
On Sat, 2025-01-25 at 23:30 -0800, Andi Kleen wrote:
> From: Andi Kleen
>
> While the input line cache size now tunable it's better if the
> compiler
> auto tunes it. Otherwise large files needing random file access will
> still have to search many lines to find the right lines.
>
> Add support
On Sat, 2025-01-25 at 23:30 -0800, Andi Kleen wrote:
> From: Andi Kleen
>
> For larger files the file_cache line index will be spread out to make
> the index fit into the fixed buffer, so any access to the non latest
> line
> will need some skipping of lines.
>
> Most accesses for line are near
Am 27.01.25 um 01:41 schrieb Jerry D:
On 1/26/25 2:07 PM, Harald Anlauf wrote:
Dear all,
in the checking of imported interfaces we need to use the local names
of procedures that are renamed-on-use, as the original name becomes
inaccessible. Similarly, we should not compare interfaces of
non-bi
On Sat, 2025-01-25 at 23:30 -0800, Andi Kleen wrote:
> From: Andi Kleen
>
> With the new cache maintenance algorithm we don't need the
> maximum number of lines anymore. Remove all the code for that.
>
> gcc/ChangeLog:
>
> PR preprocessor/118168
> * input.cc (total_lines_num): Remov
On Sat, 2025-01-25 at 23:30 -0800, Andi Kleen wrote:
> From: Andi Kleen
>
> The input context file_cache maintains an array of anchors
> to speed up accessing lines before the previous line.
> The array has a fixed upper size and the algorithm relies
> on the linemap reporting the maximum number
Hi Jason,
On 27 Jan 2025, at 20:53, Jason Merrill wrote:
> On 1/27/25 2:34 PM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 27 Jan 2025, at 15:23, Jason Merrill wrote:
>>
>>> On 1/27/25 8:14 AM, Simon Martin wrote:
Hi Jason,
On 24 Jan 2025, at 16:51, Jason Merrill wrote:
> On
On 1/27/25 12:48 PM, Vineet Gupta wrote:
On 1/26/25 05:29, Jeff Law wrote:
On 1/24/25 3:12 PM, Vineet Gupta wrote:
RV-Vector FP-INT insns use the rounding mode in FRM register which if
explicitly set for V insn needs, is saved/restored (although from the
psABI CC Spec, it is not clear if i
On 1/27/25 2:34 PM, Simon Martin wrote:
Hi Jason,
On 27 Jan 2025, at 15:23, Jason Merrill wrote:
On 1/27/25 8:14 AM, Simon Martin wrote:
Hi Jason,
On 24 Jan 2025, at 16:51, Jason Merrill wrote:
On 1/24/25 6:19 AM, Simon Martin wrote:
Hi Jason,
On 23 Jan 2025, at 22:56, Jason Merrill wrot
On 1/26/25 05:29, Jeff Law wrote:
>
> On 1/24/25 3:12 PM, Vineet Gupta wrote:
>> RV-Vector FP-INT insns use the rounding mode in FRM register which if
>> explicitly set for V insn needs, is saved/restored (although from the
>> psABI CC Spec, it is not clear if it actually a caller-saved or
>> cal
On 1/27/25 1:26 PM, Patrick Palka wrote:
On Wed, 1 Jan 2025, A J Ryan Solutions Ltd wrote:
Hi and happy new year, this patch is to fix a compiler seg-fault as encountered
in the following example:
Hi, thanks for the patch! Your fix makes sense to me, and I believe it
also fixes the testcase
On Sat, 2025-01-25 at 23:30 -0800, Andi Kleen wrote:
> From: Andi Kleen
>
> The input machinery to read the source code independent of the lexer
> has a range of hard coded maximum array sizes that can impact
> performance.
> Make them tunable.
>
> input.cc is part of libcommon so it cannot dire
Hi Jason,
On 27 Jan 2025, at 15:23, Jason Merrill wrote:
> On 1/27/25 8:14 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 24 Jan 2025, at 16:51, Jason Merrill wrote:
>>
>>> On 1/24/25 6:19 AM, Simon Martin wrote:
Hi Jason,
On 23 Jan 2025, at 22:56, Jason Merrill wrote:
> On
On Wed, 1 Jan 2025, A J Ryan Solutions Ltd wrote:
> Hi and happy new year, this patch is to fix a compiler seg-fault as
> encountered in the following example:
Hi, thanks for the patch! Your fix makes sense to me, and I believe it
also fixes the testcases from PR102626 and at least some of its
Richard Earnshaw writes:
> Older versions of the Arm architecture lack support for __sync
> operations directly in hardware and require calls into appropriate
> operating-system hooks. But such hooks obviously don't exist in a
> freestanding environment.
>
> Consquently, it is incorrect to assum
Am 27.01.25 um 16:19 schrieb Richard Sandiford:
Georg-Johann Lay writes:
Am 24.01.25 um 08:18 schrieb Richard Biener:
On Thu, Jan 23, 2025 at 4:53 PM Georg-Johann Lay wrote:
Am 23.01.25 um 14:58 schrieb Richard Biener:
On Thu, Jan 23, 2025 at 2:23 PM Georg-Johann Lay wrote:
Hi, this is
On 1/16/25 3:15 PM, John David Anglin wrote:
Tested on hppa64-hp-hpux11.11 and hppa-unknown-linux-gnu.
Okay for trunk?
OK.
Dave
---
c++: Use mapped reads and writes when munmap and msync are available
Module support is broken when MAPPED_READING and MAPPED_WRITING
are defined to 0. This c
On Sat, 2025-01-25 at 23:31 -0800, Andi Kleen wrote:
> From: Andi Kleen
Thanks for writing the test case!
Some nitpicks...
>
> gcc/ChangeLog:
>
> * input.cc (check_line): New.
> (test_replacement): New function to test line caching.
> (input_cc_tests): Call test_replacement
On Mon, 2025-01-27 at 11:25 -0500, David Malcolm wrote:
> On Sat, 2025-01-25 at 23:31 -0800, Andi Kleen wrote:
> > From: Andi Kleen
>
> Thanks for writing the test case!
>
> Some nitpicks...
>
>
> >
> > gcc/ChangeLog:
> >
> > * input.cc (check_line): New.
> > (test_replacement): New
On 1/27/25 10:41 AM, Simon Martin wrote:
Hi Jason,
On 17 Jan 2025, at 23:33, Jason Merrill wrote:
On 1/17/25 9:52 AM, Simon Martin wrote:
Hi Jason,
On 16 Jan 2025, at 22:49, Jason Merrill wrote:
On 10/16/24 11:43 AM, Simon Martin wrote:
As you know the patch had to be reverted due to PR11
Hi Jason,
On 17 Jan 2025, at 23:33, Jason Merrill wrote:
> On 1/17/25 9:52 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 16 Jan 2025, at 22:49, Jason Merrill wrote:
>>
>>> On 10/16/24 11:43 AM, Simon Martin wrote:
As you know the patch had to be reverted due to PR117114, that
highlighte
Hi,
Zhendong Su and Michal Jireš found out that our gimple DSE pass can,
under fairly specific conditions, remove a noreturn call which then
leaves behind a "normal" BB with no successor edges which following
passes do not expect. This patch simply tells the pass to leave such
calls alone even wh
On 1/21/25 10:52 AM, Jakub Jelinek wrote:
Hi!
On top of the
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662507.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662750.html
patches (where the first one implements CWG2867 for block scope static
or thread_local structured
On 2025-01-27 14:37, Christophe Lyon wrote:
On Mon, 27 Jan 2025 at 13:30, Torbjorn SVENSSON
wrote:
Hi Christophe,
On 2025-01-27 13:07, Christophe Lyon wrote:
Hi Torbjorn,
On Fri, 24 Jan 2025 at 18:45, Torbjorn SVENSSON
wrote:
Another ping... :)
Kind regards,
Torbjörn
On 2024-12-18 1
On Sat, 12 Oct 2024, Nathaniel Shead wrote:
> This version rewords all "ignored exposures" language.
>
> I haven't fixed up the issue with DECL_TEMPLATE_INSTANTIATIONS for this
> patch. I'll try to get to that as a separate patch if I find the time,
> but it's not 100% needed here I don't think.
Georg-Johann Lay writes:
> Am 24.01.25 um 08:18 schrieb Richard Biener:
>> On Thu, Jan 23, 2025 at 4:53 PM Georg-Johann Lay wrote:
>>>
>>> Am 23.01.25 um 14:58 schrieb Richard Biener:
On Thu, Jan 23, 2025 at 2:23 PM Georg-Johann Lay wrote:
>
> Hi, this is Ping #2 for a patch from 20
Hello,
On Thu, 23 Jan 2025, Richard Biener wrote:
> When we get a zero distance vector we still have to check for the
> situation of a common inner loop with zero distance. But we can
> still allow a zero distance for the loop we distribute
> (gcc.dg/tree-ssa/ldist-33.c is such a case). This is
The checking code didn't take into account debug uses.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/118653
* tree-vect-loop.cc (vectorizable_live_operation): Also allow
out-of-loop debug uses.
* gcc.dg/vect/pr118653.c: New test
The following fixes part of the issue that niter analysis uses UB
of stmts that might not execute due to inner infinite loops (the
testcase in the PR) or due to calls terminating the program or
the function. This patch addresses inner infinite loops by copying
parts of the analysis loop invariant
> From: Richard Biener
> Sent: Monday, January 27, 2025 5:09 PM
>
> On Mon, Jan 27, 2025 at 8:30 AM Haochen Jiang
> wrote:
> >
> > Hi all,
> >
> > AVX10 has been published for one and half year and we have got many
> > feedbacks on that, one of the feedback is on whether the alias option
> > -ma
On 1/26/25 2:25 PM, Jakub Jelinek wrote:
On Sat, Jan 25, 2025 at 10:53:50AM -0500, Jason Merrill wrote:
On 1/25/25 4:12 AM, Jakub Jelinek wrote:
On Fri, Jan 24, 2025 at 07:07:15PM -0500, Jason Merrill wrote:
Hypothetically, but those cases are just either error or DECL_EXTERNAL. In
the error c
Richard Biener writes:
> On Mon, 27 Jan 2025, Jakub Jelinek wrote:
>
>> On Mon, Jan 27, 2025 at 11:09:38AM +0100, Richard Biener wrote:
>> >PR rtl-optimization/118662
>> >* combine.cc (try_combine): When re-materializing a load
>> >from an extended reg by a lowpart subreg make sure we'
Spencer Abson writes:
> Enable a target with FEAT_FP16 to emit the half-precision variants
> of FCMP/FCMPE.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64.md: Update cbranch, cstore, fcmp
> and fcmpe to use the GPF_F16 iterator for floating-point
> modes.
>
> gcc/testsuite/Chang
On 1/27/25 8:14 AM, Simon Martin wrote:
Hi Jason,
On 24 Jan 2025, at 16:51, Jason Merrill wrote:
On 1/24/25 6:19 AM, Simon Martin wrote:
Hi Jason,
On 23 Jan 2025, at 22:56, Jason Merrill wrote:
On 1/23/25 12:06 PM, Simon Martin wrote:
Hi Marek,
On 23 Jan 2025, at 16:45, Marek Polacek wro
Older versions of the Arm architecture lack support for __sync
operations directly in hardware and require calls into appropriate
operating-system hooks. But such hooks obviously don't exist in a
freestanding environment.
Consquently, it is incorrect to assume during configure that such
functions
On 1/26/25 12:24 PM, Jakub Jelinek wrote:
On Sun, Jan 26, 2025 at 08:35:29AM -0700, Jeff Law wrote:
On 1/23/25 8:49 AM, Stefan Schulze Frielinghaus wrote:
On Sat, Jan 18, 2025 at 09:36:14AM -0700, Jeff Law wrote:
[...]
Do we detect conflicts between a hard register constraint and another
co
On Mon, 27 Jan 2025 at 13:30, Torbjorn SVENSSON
wrote:
>
> Hi Christophe,
>
> On 2025-01-27 13:07, Christophe Lyon wrote:
> > Hi Torbjorn,
> >
> > On Fri, 24 Jan 2025 at 18:45, Torbjorn SVENSSON
> > wrote:
> >>
> >> Another ping... :)
> >>
> >> Kind regards,
> >> Torbjörn
> >>
> >> On 2024-12-18
On Sat, Jan 25, 2025 at 4:37 AM Alexandre Oliva wrote:
>
> On Jan 24, 2025, Richard Biener wrote:
>
> > Hmm. I think when an original ref could trap that should be the
> > insertion point (or the original ref should post-dominate the insertion
> > point).
>
> I suppose we could do that, but...
On Mon, Jan 27, 2025 at 1:28 PM Lewis Hyatt wrote:
>
> Hello-
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115913#c10
>
> This tweak to optc-save-gen.awk weakens the check performed by
> cl_optimization_compare() to avoid checking asserts that have been there
> since this function was first ad
Hi Jason,
On 24 Jan 2025, at 16:51, Jason Merrill wrote:
> On 1/24/25 6:19 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 23 Jan 2025, at 22:56, Jason Merrill wrote:
>>
>>> On 1/23/25 12:06 PM, Simon Martin wrote:
Hi Marek,
On 23 Jan 2025, at 16:45, Marek Polacek wrote:
> O
On Mon, Jan 27, 2025 at 02:02:14PM +0100, Ilya Leoshkevich wrote:
> Thank you for the review!
> I have fixed the style and committed this.
>
> Would it be okay to backport this to gcc-13 and gcc-14?
> Bootstrap and regtest pass on x86_64-redhat-linux.
Ok.
Jakub
On Fri, 2025-01-24 at 17:25 +0100, Jakub Jelinek wrote:
> On Thu, Jan 09, 2025 at 01:15:30AM +0100, Ilya Leoshkevich wrote:
> > Bootstrapped and regtested on x86_64-redhat-linux. Ok for master?
> >
> >
> >
> > The FakeStack flag is not zeroed out when can_store_by_pieces()
> > returns false. O
On Mon, 27 Jan 2025 at 10:55, Andreas Schwab wrote:
>
> RISC-V only gained support for bfloat16_t after gcc 14. Passes
> libstdc++/check_abi on {x86_64,aarch64,ppc64le,riscv64,s390x}-suse-linux.
OK, thanks.
>
> PR libstdc++/118563
> * testsuite/util/testsuite_abi.cc (check_versi
The following fixes an issue in the RTL combiner where we correctly
combine two vector sign-extends with a vector load
Trying 7, 9 -> 10:
7: r106:V4QI=[r119:DI]
REG_DEAD r119:DI
9: r108:V4HI=sign_extend(vec_select(r106:V4QI#0,parallel))
10: r109:V4SI=sign_extend(vec_select(r108:V4
Hi Christophe,
On 2025-01-27 13:07, Christophe Lyon wrote:
Hi Torbjorn,
On Fri, 24 Jan 2025 at 18:45, Torbjorn SVENSSON
wrote:
Another ping... :)
Kind regards,
Torbjörn
On 2024-12-18 18:35, Torbjorn SVENSSON wrote:
Gentle ping :)
Kind regards,
Torbjörn
On 2024-11-14 17:16, Torbjorn SVEN
Hello-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115913#c10
This tweak to optc-save-gen.awk weakens the check performed by
cl_optimization_compare() to avoid checking asserts that have been there
since this function was first added in r11-1141. Is it OK for 15 please? I
think it would be appro
Hi Torbjorn,
On Fri, 24 Jan 2025 at 18:45, Torbjorn SVENSSON
wrote:
>
> Another ping... :)
>
> Kind regards,
> Torbjörn
>
> On 2024-12-18 18:35, Torbjorn SVENSSON wrote:
> > Gentle ping :)
> >
> > Kind regards,
> > Torbjörn
> >
> > On 2024-11-14 17:16, Torbjorn SVENSSON wrote:
> >>
> >>
> >> On 2
From: Pan Li
This patch would like to fix the wroing code generation for the scalar
signed SAT_TRUNC. The input can be QI/HI/SI/DI while the alu like sub
can only work on Xmode. Unfortunately we don't have sub/add for
non-Xmode like QImode in scalar, thus we need to sign extend to Xmode
to ensu
From: Pan Li
This patch would like to fix the wroing code generation for the scalar
signed SAT_ADD. The input can be QI/HI/SI/DI while the alu like sub
can only work on Xmode. Unfortunately we don't have sub/add for
non-Xmode like QImode in scalar, thus we need to sign extend to Xmode
to ensure
From: Pan Li
This patch would like to fix the wroing code generation for the scalar
signed SAT_SUB. The input can be QI/HI/SI/DI while the alu like sub
can only work on Xmode. Unfortunately we don't have sub/add for
non-Xmode like QImode in scalar, thus we need to sign extend to Xmode
to ensure
From: Pan Li
This patch would like to refactor the helper function of the SAT_*
scalar. The helper function will convert the define_pattern ops
to the xmode reg for the underlying code-gen. This patch add
new parameter for ZERO_EXTEND or SIGN_EXTEND if the input is const_int
or the mode is non-
RISC-V only gained support for bfloat16_t after gcc 14. Passes
libstdc++/check_abi on {x86_64,aarch64,ppc64le,riscv64,s390x}-suse-linux.
PR libstdc++/118563
* testsuite/util/testsuite_abi.cc (check_version): Add
CXXABI_1.3.16.
* config/abi/pre/gnu.ver (CXXABI_1.3.1
On Mon, 27 Jan 2025, Jakub Jelinek wrote:
> On Mon, Jan 27, 2025 at 11:09:38AM +0100, Richard Biener wrote:
> > PR rtl-optimization/118662
> > * combine.cc (try_combine): When re-materializing a load
> > from an extended reg by a lowpart subreg make sure we're
> > dealing with sing
On Mon, Jan 27, 2025 at 11:32:17AM +0100, Richard Biener wrote:
> When RTL expansion of an out-of-bound access of a register falls
> back to a BIT_FIELD_REF we have to ensure that's valid. The
> following avoids negative offsets by expanding through a stack
> temporary.
>
> Bootstrap and regtest
When RTL expansion of an out-of-bound access of a register falls
back to a BIT_FIELD_REF we have to ensure that's valid. The
following avoids negative offsets by expanding through a stack
temporary.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
OK if that succeeds?
Thanks,
Richard.
On Mon, Jan 27, 2025 at 11:09:38AM +0100, Richard Biener wrote:
> PR rtl-optimization/118662
> * combine.cc (try_combine): When re-materializing a load
> from an extended reg by a lowpart subreg make sure we're
> dealing with single-component modes.
>
> * gcc.dg/tortu
Hi,
in both tests we expect a VEC_SHL_INSERT expression but we now add the
initial value at the end. Just remove that scan check.
Will commit as obvious after the CI run.
Regards
Robin
---
gcc/testsuite/gcc.target/riscv/rvv/autovec/reduc/reduc-8.c | 1 -
gcc/testsuite/gcc.target/riscv/rvv/a
Hi,
the test fails with _zvfh because we vectorize more. Just adjust the
test expectations. I regtested this a while ago on rv64gcv_zvl512b.
Will commit as obvious if the CI is happy.
Regards
Robin
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_64-
The following fixes an issue in the RTL combiner where we correctly
combine two vector sign-exxtends with a vector load
Trying 7, 9 -> 10:
7: r106:V4QI=[r119:DI]
REG_DEAD r119:DI
9: r108:V4HI=sign_extend(vec_select(r106:V4QI#0,parallel))
10: r109:V4SI=sign_extend(vec_select(r108:V
Hi All,
Pushed as an 'obvious' one-liner(less additional comments) in r15-7224
Fortran: ICE in gfc_conv_expr_present w. defined assignment [PR118640]
2025-01-27 Paul Thomas
gcc/fortran
PR fortran/118640
* resolve.cc (generate_component_assignments): Make sure that
the rhs temporary does not
Enable a target with FEAT_FP16 to emit the half-precision variants
of FCMP/FCMPE.
gcc/ChangeLog:
* config/aarch64/aarch64.md: Update cbranch, cstore, fcmp
and fcmpe to use the GPF_F16 iterator for floating-point
modes.
gcc/testsuite/ChangeLog:
* gcc.target/aarch6
This patch allows the AArch64 back end to emit the half-precision variants of
FCMP and FCMPE, given the target supports FEAT_FP16. Previously, such
comparisons
would be unnecessarily promoted to single-precision.
The latest documentation of these instructions can be found here:
https://developer.
On Mon, Jan 27, 2025 at 8:30 AM Haochen Jiang wrote:
>
> Hi all,
>
> AVX10 has been published for one and half year and we have got many feedbacks
> on that, one of the feedback is on whether the alias option -mavx10.x should
> point to 256 or 512.
>
> If you also pay attention to LLVM community,
79 matches
Mail list logo
