I think I found the bug that caused the test failure, and will send v3
later.
BRs
Jerry
Jerry Zhang Jian 於 2025年5月25日 週日 下午11:05寫道：
> Add support of double trap extension [1], enabling GCC
> to recognize the following extensions at compile time.
>
> New extensions:
> - ssdbltrp
> - smdb
This patch add the RISC-V Shlcofideleg extension. It supports delegating
LCOFI interrupts(the count-overflow interrupts) to VS-mode.[1]
[1] https://riscv.github.io/riscv-isa-manual/snapshot/privileged
gcc/ChangeLog:
* config/riscv/riscv-ext.def: New extension defs.
* config/riscv
On Tue, May 27, 2025 at 3:06 AM liuhongt wrote:
>
> > > It's https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119181
> >
> > Please mention that in the changelog. Also ...
>
> Changed.
>
> > Please put this condition in the set of conds we test in the else branch of
> > ...
> >
> > > > /*
Sounds good. I've added the changes you suggested (diff is linked below). I'll
send an updated patch after your review.
https://github.com/gcc-mirror/gcc/compare/97e8cd9...pkeir:gcc:4f699d8
From: Jonathan Wakely
Sent: 23 May 2025 8:11 PM
To: Paul Keir
Cc
On Tue, May 27, 2025 at 10:53 AM Jonathan Wakely
wrote:
> On Mon, 26 May 2025 at 08:49, Tomasz Kaminski wrote:
> >
> >
> >
> > On Sat, May 24, 2025 at 1:29 PM Luc Grosheintz
> wrote:
> >>
> >> The array that stores the dynamic extents used to be default
> >> initialized. The standard requires v
The P8700 is a high-performance processor from MIPS by extending RISCV with
the MIPS custom instruction and the following changes are added to enable the
conditional move support from mips.
No regression found for "runtest --tool gcc
--target_board='riscv-sim/-mabi=lp64d/-mcmodel=medlow/-mtune=m
This patch adds fdiml to libgcc/config/avr/libf7
AVR: target/120442 - Support f7_fdim / fdiml in LibF7.
PR target/120442
Add Support for fdiml.
libgcc/config/avr/libf7/
* libf7-common.mk (LIBF_C_PARTS, m_ddd): Add fdim.
* libf7.h (f7_fdim): New proto.
* li
On Mon, May 26, 2025 at 12:17:44PM +0200, Juergen Christ wrote:
> Since floating point and vector registers overlap on s390, more
> efficient code can be generated to extract FPRs from VRs.
> Additionally, for double vectors, more efficient code can be generated
> to load specific lanes.
>
> Boots
The P8700 is a high-performance processor from MIPS by extending RISCV with
the MIPS custom instruction and the following changes are added to enable the
conditional move support from mips
No regressions are found for "runtest --tool gcc
--target_board='riscv-sim/-mabi=lp64d/-mcmodel=medlow/-mtu
On Wed, May 21, 2025 at 6:05 PM MCC CS wrote:
>
> Dear Richard,
>
> Thank you so much for your reply. I submitted the patch for the third case to
> LLVM before I've received your reply, and they said the same thing,
> that it would probably be used outside of loops as well and it would inflict
> a
On Tue, 20 May 2025, Jakub Jelinek wrote:
> Hi!
>
> The following patch fixes
> FAIL: gcc.dg/dfp/bitint-1.c (test for excess errors)
> FAIL: gcc.dg/dfp/bitint-2.c (test for excess errors)
> FAIL: gcc.dg/dfp/bitint-3.c (test for excess errors)
> FAIL: gcc.dg/dfp/bitint-4.c (test for excess errors)
On Tue, 27 May 2025 at 07:51, Luc Grosheintz wrote:
>
> While reading the compiler output of
>
> make check-target-libstdc++-v3
>
> for buggy code, e.g. cmp_equal(1.0, 1.0), the error message
> was very short, and I saw no hint that neither of the two
> template arguments weren't integers. Ess
From: Jonathan Wakely
This patch implements C++26 std::polymorphic as specified in P3019 with
amendment to move assignment from LWG 4251.
The implementation always allocate stored object on the heap. The manager
function (_M_manager) is similary keep with the object (polymorphic::_Obj),
which re
On Wed, 21 May 2025, Icen Zeyada wrote:
> Merge simple_comparison patterns under a single vec_cond_expr for bit_and,
> bit_ior, and bit_xor in the simplify pass.
>
> Ensure that when both operands of a bit_and, bit_or, or bit_xor are
> simple_comparison
> results, they reside within the same vec
With -maix32 (the default) we only have 16-bit wchar_t so these tests
fail. The debug.cc one is because we use -fwide-exec-charset=UTF-32BE
which tries to encode each wide character as four bytes in a 2-byte
wchar_t. The format.cc one is because the clown face character can't be
encoded in a single
On Tue, 27 May 2025 at 13:26, Tomasz Kaminski wrote:
>
>
>
> On Fri, May 23, 2025 at 7:00 PM Jonathan Wakely wrote:
>>
>> Since r16-154-gc91eb5a5c13f14 std::addressof is no less efficient than
>> std::__addressof, so change some uses of the latter to the former.
>>
>> We can't change them all, be
On 5/24/25 11:06 PM, Alexandre Oliva wrote:
In the added C++ testcase, a stack slot at a negative sp offset is
used to hold a value across a call.
There are a couple of causes that directly lead to this outcome:
- the -fstack-clash-protection and -fnon-call-exception options, that
cause arm_f
On Tue, May 27, 2025 at 2:38 PM Jonathan Wakely wrote:
> With -maix32 (the default) we only have 16-bit wchar_t so these tests
> fail. The debug.cc one is because we use -fwide-exec-charset=UTF-32BE
> which tries to encode each wide character as four bytes in a 2-byte
> wchar_t. The format.cc one
On Tue, May 27, 2025 at 2:40 PM Martin Jambor wrote:
>
> Hi,
>
> On Wed, May 21 2025, Eric Botcazou wrote:
> > Hi,
> >
> > IPA-SRA generally works fine in the presence of reverse Scalar_Storage_Order
> > by propagating the relevant flag onto the newly generated MEM_REFs. However
> > we have been
On Tue, May 27, 2025 at 2:44 PM Robin Dapp wrote:
>
> > This mangles in the non-SLP path removal, can you please separate that
> > out?
>
> So should patch 1/2 do more than it does, i.e. fully remove the non-slp
> paths rather than just if (0) them?
There should be a separate 2/3 that does this,
On Tue, May 27, 2025 at 2:44 PM Robin Dapp wrote:
> This mangles in the non-SLP path removal, can you please separate that
> out?
So should patch 1/2 do more than it does, i.e. fully remove the non-slp
paths rather than just if (0) them?
There should be a separate 2/3 that does this, aka rem
On 5/27/25 12:27 AM, Robin Dapp wrote:
Apart from that it LGTM, thanks for digging deeper here.
Just wanted to echo this. I've had a low priority todo to review vaaddu
and friends after seeing them get used in some hand coded versions of
various routines in x264. Even if you're not tackl
That would be appreciated (but is of course a larger task - I was fine with
the partial thing you did).
Ok. Then to move things forward I'll do a 2/3 for this one first. Once we're
through the review cycle for the series I can work on the non-slp removal for
the full function.
--
Regards
R
On Tue, May 27, 2025 at 2:53 PM Robin Dapp wrote:
>
> > On Tue, May 27, 2025 at 2:44 PM Robin Dapp wrote:
> >>
> >> > This mangles in the non-SLP path removal, can you please separate that
> >> > out?
> >>
> >> So should patch 1/2 do more than it does, i.e. fully remove the non-slp
> >> paths rat
libstdc++-v3/ChangeLog:
* include/Makefile.in: Regenerate.
---
Pushed to trunk.
libstdc++-v3/include/Makefile.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/include/Makefile.in b/libstdc++-v3/include/Makefile.in
index a6e602327b6e..0ef8564f2385 10064
On 5/22/25 9:26 PM, Yangyu Chen wrote:
On 23 May 2025, at 04:02, Jeff Law wrote:
On 5/22/25 9:05 AM, Alfie Richards wrote:
Hi Jeff,
I sent this patch with my implementation a while ago:
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681043.html
There hasn't been any feedback on th
> On 27 May 2025, at 20:59, Jeff Law wrote:
> So if it's OK with you I'd like to temporarily shift focus over to Alfie's
> patch to get that moved forward, then come back to the RISC-V specific stuff?
>
Sure.
Thanks,
Yangyu Chen
> Jeff
>
On Mon, May 26, 2025 at 4:27 PM Jason Merrill wrote:
>
> Tested x86_64-pc-linux-gnu, OK for trunk?
LGTM.
Richard.
> Iain, will you verify that one of your coroutine testcases breaks without this
> fix? I don't think lambda or anonymous union uses of DECL_VALUE_EXPR can
> break
> in the same w
Hi all,
Sorry for the noise ,looks like patch was truncated and will be sending a
new email with proper patch for the same.
Thank you and again my apologies for the noise.
~U
On Tue, May 27, 2025 at 3:41 PM Umesh Kalappa
wrote:
> The P8700 is a high-performance processor from MIPS by extending
gcc/ChangeLog:
* doc/extend.texi (Common Variable Attributes): Fix typo in
description of nonstring.
---
Pushed as obvious.
gcc/doc/extend.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 442fce653a40..989df
On Tue, May 27, 2025 at 5:02 AM Andrew Pinski wrote:
>
> This was noticed in the review of copy propagation for aggregates
> patch, instead of checking for a NULL or a non-ssa name of vuse,
> we should instead check if it the vuse is a default name and stop
> then.
>
> Bootstrapped and tested on x
On Tue, May 27, 2025 at 5:02 AM Andrew Pinski wrote:
>
> As part of the review of copy prop for aggregates, it was
> mentioned there should be some statistics added, and I noticed
> the memcpy->memset was missing the statistics too. So this adds
> that.
OK.
> gcc/ChangeLog:
>
> * tree-ss
On Tue, May 20, 2025 at 11:35 AM Robin Dapp wrote:
>
> This patch enables strided loads for VMAT_STRIDED_SLP. Instead of
> building vectors from scalars or other vectors we can use strided loads
> directly when applicable.
>
> The current implementation limits strided loads to cases where we can
This patch renames `bitmap_bit_in_range_p` to `bitmap_any_bit_in_range_p`
to better reflect its purpose.
gcc/ChangeLog:
* sbitmap.cc (bitmap_bit_in_range_p): Renamed the function.
(bitmap_any_bit_in_range_p): New function name.
(bitmap_bit_in_range_p_checking): Renamed the
This patch uses `lowpart_subreg` for the base register initialization,
instead of zero-extending it. We had tried this solution before, but
we were leaving undefined bytes in the upper part of the register.
This shouldn't be happening as we are supposed to write the whole
register when the load is
This patch adds the `bitmap_all_bits_in_range_p` function in sbitmap,
which checks if all the bits in a range are set.
Helper function `bitmap_bit_in_range_p` has also been added, in order
to be used by `bitmap_all_bits_in_range_p` and `bitmap_any_bit_in_range_p`.
When the function's `any_inverted
f7_exp's exponent was limited to |a| < 512, but exponents to to
1024 * ln2 = 709 may occur.
Applied as obvious.
Johann
--
AVR: target/120441 - Fix f7_exp for |x| ≥ 512.
f7_exp limited exponents to 512, but 1023 * ln2 ≈ 709,
hence 1024 is a correct limit.
libgcc/config/avr/libf7/
PR t
Hi,
in check_builtin_call we eventually perform a division by zero when no
vector modes are present. This patch just avoids the division in that
case.
Regtested on rv64gcv_zvl512b. I guess this is obvious enough that it can be
pushed after the CI approves.
Regards
Robin
PR target/1
Hi Jeff,
On 22/05/2025 21:02, Jeff Law wrote:
On 5/22/25 9:05 AM, Alfie Richards wrote:
Hi Jeff,
I sent this patch with my implementation a while ago:
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681043.html
There hasn't been any feedback on that patch yet.
These patches are still
LGTM
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2025-05-27 16:31
To: gcc-patches
CC: kito.ch...@gmail.com; juzhe.zh...@rivai.ai; jeffreya...@gmail.com;
pan2...@intel.com; rdapp@gmail.com
Subject: [PATCH] RISC-V: Avoid division by zero in check_builtin_call
[PR120436].
Hi,
in check_bu
On Mon, 26 May 2025 at 08:49, Tomasz Kaminski wrote:
>
>
>
> On Sat, May 24, 2025 at 1:29 PM Luc Grosheintz
> wrote:
>>
>> The array that stores the dynamic extents used to be default
>> initialized. The standard requires value intialization. This
>> commit fixes the bug and adds a test.
>>
>> l
On Tue, 27 May 2025 at 13:46, Tomasz Kaminski wrote:
>
>
>
> On Tue, May 27, 2025 at 2:38 PM Jonathan Wakely wrote:
>>
>> With -maix32 (the default) we only have 16-bit wchar_t so these tests
>> fail. The debug.cc one is because we use -fwide-exec-charset=UTF-32BE
>> which tries to encode each wi
On 5/27/25 14:34, Jonathan Wakely wrote:
On Tue, 27 May 2025 at 07:51, Luc Grosheintz wrote:
While reading the compiler output of
make check-target-libstdc++-v3
for buggy code, e.g. cmp_equal(1.0, 1.0), the error message
was very short, and I saw no hint that neither of the two
templ
Ping.
thanks.
Qing
> On May 13, 2025, at 17:03, Qing Zhao wrote:
>
> For example:
> struct PP {
> size_t count2;
> char other1;
> char *array2 __attribute__ ((counted_by (count2)));
> int other2;
> } *pp;
>
> specifies that the "array2" is an array that is pointed by the
> pointer field,
Ping.
thanks.
Qing
> On May 7, 2025, at 12:59, Qing Zhao wrote:
>
> Hi,
>
> This is the 2nd version of the patch for:
>
> Evaluate the object size by the size of the pointee type when the type
> is a structure with flexible array member which is annotated with
> counted_by.
>
> Per the fo
A few arm effective-targets call check_effective_target_arm32 even
though they would force an -march=XXX flag which support Arm and/or
Thumb-2, thus making the arm32 check useless. This has an impact when
the toolchain is configured with a default -march or -mcpu which
supports Thumb-1 only: in su
Since, I believe now we're through the larger questions about
how to implement layouts. If reviewing all three over and over
is too painful, it might now make sense to split the patch into
separate patches, one per layout.
On 5/26/25 16:04, Luc Grosheintz wrote:
This follows up on:
https://gcc.g
On Mon, May 26, 2025 at 9:15 PM Luc Grosheintz
wrote:
>
>
> On 5/26/25 18:17, Tomasz Kaminski wrote:
> > On Mon, May 26, 2025 at 4:15 PM Luc Grosheintz >
> > wrote:
> >
> >> Implements the parts of layout_left that don't depend on any of the
> >> other layouts.
> >>
> >> libstdc++-v3/ChangeLog:
The PR shows that when using std::clamp from the C++ standard library
and there is surrounding code using exceptions then phiprop can fail
to simplify the code so phiopt can turn the clamping into efficient
min/max operations.
The validation code is needlessly complicated, steming from the
time we
On Tue, May 27, 2025 at 4:32 PM Luc Grosheintz
wrote:
> Since, I believe now we're through the larger questions about
> how to implement layouts. If reviewing all three over and over
> is too painful, it might now make sense to split the patch into
> separate patches, one per layout.
>
I think we
Hi all,
I've reverted the recent format changes, as three reviewers indicated they
caused more harm than good.
Are there any functional problems I need to address?
Thanks,
Yuao
0001-fortran-add-constant-input-support-for-trig-function.patch
Description: 0001-fortran-add-constant-input-support
On Fri, May 23, 2025 at 7:00 PM Jonathan Wakely wrote:
> Since r16-154-gc91eb5a5c13f14 std::addressof is no less efficient than
> std::__addressof, so change some uses of the latter to the former.
>
> We can't change them all, because some uses need to compile as C++98
> which only has std::__add
Hello Nicolas,
Continuing discussion from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
but on the mailing list.
After more testing, we've observed a regression on one simple test:
8<8<8<8<8<8<
with Ada.Text_IO; use Ada.Text_IO;
with Interfaces.C.Extensions;
with GN
This needs to be added to r16-775-g18df4a10bc9694 if/when that is
backported to GCC-15.
Tested on powerpc64le-linux, x86_64-darwin, pushed to trunk as
trivial/obvious, thanks
Iain
--- 8< ---
These were typoed to TRUTH_AND_EXPR (and then that got copied).
gcc/cp/ChangeLog:
* coroutines.c
On 5/27/25 11:24 AM, Harald Anlauf wrote:
Dear all,
the attached patch fixes a variety of small issues with parsing of
inquiry references of substrings. The testcase exercises variations
of the examples in the PR and ensures that these are successfully
simplified.
Don't try it with other compi
Hi Jerry!
On 5/27/25 21:02, Jerry D wrote:
On 5/20/25 12:35 PM, Jerry D wrote:
On 5/20/25 12:01 PM, Harald Anlauf wrote:
Hi Jerry!
Am 20.05.25 um 05:23 schrieb Jerry D:
On 5/19/25 1:50 PM, Harald Anlauf wrote:
Hi Jerry,
so contrary to what the name of patch claims (pr120049-final.diff),
it
On 5/27/25 12:39 PM, Harald Anlauf wrote:
Hi Jerry!
On 5/27/25 21:02, Jerry D wrote:
On 5/20/25 12:35 PM, Jerry D wrote:
On 5/20/25 12:01 PM, Harald Anlauf wrote:
Hi Jerry!
Am 20.05.25 um 05:23 schrieb Jerry D:
On 5/19/25 1:50 PM, Harald Anlauf wrote:
Hi Jerry,
so contrary to what the nam
Hi Jerry!
On 5/27/25 21:36, Jerry D wrote:
On 5/27/25 11:24 AM, Harald Anlauf wrote:
Dear all,
the attached patch fixes a variety of small issues with parsing of
inquiry references of substrings. The testcase exercises variations
of the examples in the PR and ensures that these are successful
Hi!
On 2025-05-23T17:01:31+0200, Richard Biener wrote:
> Am 23.05.2025 um 16:49 schrieb Thomas Schwinge :
>> This fell out of me looking into PR119835. This doesn't resolve the
>> underlying
>> issue, but instead of failing GIMPLE semantics verification just by chance in
>> the 'GIMPLE pass: n
The first patch makes SLP paths unreachable and the second one removes those
entirely. The third patch does the actual strided-load work.
Bootstrapped and regtested on x86 and aarch64.
Regtested on rv64gcv_zvl512b.
Robin Dapp (3):
vect: Make non-SLP paths unreachable in strided slp/elementwis
Yuao Ma wrote:
PR113152
If you run your patch through
./contrib/gcc-changelog/git_email.py
0001-fortran-add-constant-input-support-for-trig-function.patch
you will notice that the PR is not recognized. The format as mentioned before is "PR
component/number". Namely:
"PR fortran/113
On Tue, 20 May 2025, Jakub Jelinek wrote:
> Tested on x86_64-linux, i686-linux and s390x-linux with
> make check-gcc dfp.exp
> ok for trunk?
OK.
--
Joseph S. Myers
josmy...@redhat.com
On Tue, 27 May 2025, David Malcolm wrote:
> On Fri, 2025-05-23 at 16:58 -0400, Jason Merrill wrote:
> > On 4/14/25 9:57 AM, Jason Merrill wrote:
> > > On 1/9/25 10:00 PM, Jason Merrill wrote:
> > > > Tested x86_64-pc-linux-gnu. Is the diagnostic.h change OK for
> > > > trunk?
> > >
> > > Ping?
>
On 5/27/25 4:47 PM, Jason Merrill wrote:
On 5/27/25 1:33 PM, David Malcolm wrote:
On Fri, 2025-05-23 at 16:58 -0400, Jason Merrill wrote:
On 4/14/25 9:57 AM, Jason Merrill wrote:
On 1/9/25 10:00 PM, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. Is the diagnostic.h change OK for
trunk?
P
On Wed, May 28, 2025 at 12:24:54AM -0400, Jason Merrill wrote:
> On 11/27/24 11:17 AM, Jason Merrill wrote:
> > On 11/27/24 1:43 AM, Nathaniel Shead wrote:
> > > On Wed, Nov 27, 2024 at 12:03:23AM -0500, Jason Merrill wrote:
> > > > Tested x86_64-pc-linux-gnu.
> > > >
> > > > Does this approach ma
This is a small patch to address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92386 updated thanks to Andrew's
feedback.
This patch implements "-Wshadow=used," which throws a warning for shadowed
variables only if the shadowed variable was previously used in the same scope
where it is being shadow
On 11/27/24 11:17 AM, Jason Merrill wrote:
On 11/27/24 1:43 AM, Nathaniel Shead wrote:
On Wed, Nov 27, 2024 at 12:03:23AM -0500, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu.
Does this approach make sense to you? Any other ideas?
-- 8< --
We weren't representing 'using namespace' at all
On Tue, May 27, 2025 at 7:08 PM Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/15?
>
> The 'volatile' issue from that PR Will be fixed in a separate patch as
> operator[] isn't the only operation that's affected.
>
> -- >8 --
>
> The const lvalue operator[] over
Hi,
On Wed, May 21 2025, Eric Botcazou wrote:
> Hi,
>
> IPA-SRA generally works fine in the presence of reverse Scalar_Storage_Order
> by propagating the relevant flag onto the newly generated MEM_REFs. However
> we have been recently faced with a specific Ada pattern that it doesn't
> handle
On Fri, 2025-05-23 at 16:58 -0400, Jason Merrill wrote:
> On 4/14/25 9:57 AM, Jason Merrill wrote:
> > On 1/9/25 10:00 PM, Jason Merrill wrote:
> > > Tested x86_64-pc-linux-gnu. Is the diagnostic.h change OK for
> > > trunk?
> >
> > Ping?
>
> Ping.
Sorry for the delay in responding; comments be
Hi,
this code to track what locations were used when reading auto-fdo profile
seems dead since the initial commit. Removed thus.
Comitted as obvious.
Honza
gcc/ChangeLog:
* auto-profile.cc (function_instance::mark_annotated): Remove.
(function_instance::total_annotated_count): Re
Thanks, I've committed these patches, with additional commit message
changes to reference PR117025 in the standard way for GCC so that Bugzilla
picks up the commits automatically.
--
Joseph S. Myers
josmy...@redhat.com
On Tue, May 27, 2025 at 08:22:28PM +, Joseph Myers wrote:
> Thanks, I've committed these patches, with additional commit message
> changes to reference PR117025 in the standard way for GCC so that Bugzilla
> picks up the commits automatically.
--- a/gcc/c/c-parser.cc
On Fri, 23 May 2025, Trevor Gross wrote:
> +Comparison functions return a CMPtype which is a signed integer of
> +target-depdent size. Typically CMPtype will be word-sized, but other
> backends
> +may override this with the TARGET_LIBGCC_CMP_RETURN_MODE hook. Of note,
> +AArch64 uses an single-
After my last commit, I always rerun make check-fortran.
Now I see a bunch of fails. I reverted my patch locally and did a
rebuild and I still see these. Heralds patch still in there.
No failures after reverting this:
commit r16-914-g787a8dec1acedf5561c8ee43bed0b3653fca150d
Author: Harald Anl
On 5/27/25 1:33 PM, David Malcolm wrote:
On Fri, 2025-05-23 at 16:58 -0400, Jason Merrill wrote:
On 4/14/25 9:57 AM, Jason Merrill wrote:
On 1/9/25 10:00 PM, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. Is the diagnostic.h change OK for
trunk?
Ping?
Ping.
Sorry for the delay in resp
On Tue, 2025-05-27 at 17:21 -0400, Patrick Palka wrote:
>
> On Tue, 27 May 2025, Patrick Palka wrote:
>
> > On Tue, 27 May 2025, David Malcolm wrote:
> >
> > > On Fri, 2025-05-23 at 16:58 -0400, Jason Merrill wrote:
> > > > On 4/14/25 9:57 AM, Jason Merrill wrote:
> > > > > On 1/9/25 10:00 PM, J
From: Pan Li
Some existing avg_floor test need updated due to change to
leverage vaadd.vv directly.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vls/avg-1.c: Update asm check
to vaadd.
* gcc.target/riscv/rvv/autovec/vls/avg-2.c: Ditto.
* gcc.target/ris
From: Pan Li
The signed avg_floor totally match the sematics of fixed point
rvv insn vaadd, within round down. Thus, leverage it directly
to implement the avf_floor.
The spec of RVV is somehow not that clear about the difference
between the float point and fixed point for the rounding that
disc
From: Pan Li
The spec of RVV is somehow not that clear about the difference
between the float point and fixed point for the rounding that
discard least-significant information.
For float point which is not two's complement, the "discard
least-significant information" indicates truncation round.
From: Pan Li
Add asm and run testcase for avg_floor vaadd implementation.
The below test suites are passed for this patch series.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/avg.h: New test.
* gcc.target/riscv/rvv/autovec/avg_dat
Hi Jakub, Joseph,
On Tue, May 27, 2025 at 10:28:23PM +0200, Jakub Jelinek wrote:
> On Tue, May 27, 2025 at 08:22:28PM +, Joseph Myers wrote:
> > Thanks, I've committed these patches, with additional commit message
> > changes to reference PR117025 in the standard way for GCC so that Bugzilla
On the 13 branch and older, C++ >= 20 tests need an explicit dg-options
directive specifying the -std flag, otherwise they won't run by default.
PR libstdc++/112490
libstdc++-v3/ChangeLog:
* testsuite/24_iterators/const_iterator/112490.cc: Add
dg-options directive.
---
l
> On 26 May 2025, at 2:47 pm, Kugan Vivekanandarajah
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> > On 26 May 2025, at 2:25 pm, Andrew Pinski wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Tue, May 20, 2025 at 3:09 AM
Jerry, all,
that was entirely my fault - attempting a last-minute cleanup
that reordered code, trying to use a refactoring. I've put
on my brown bag and pushed a corrections as obvious as:
r16-921-g74a2281ae18c6d.
See attached.
Caveat: this was tested on top of r16-915, as I cannot compile
an
On 5/27/25 2:19 PM, Harald Anlauf wrote:
Jerry, all,
that was entirely my fault - attempting a last-minute cleanup
that reordered code, trying to use a refactoring. I've put
on my brown bag and pushed a corrections as obvious as:
r16-921-g74a2281ae18c6d.
See attached.
Caveat: this was tested
On Tue, May 27, 2025 at 11:15:14PM +0200, Alejandro Colomar wrote:
> Oopsy! Sorry! Please fix, yep, it's a pasto. :)
Committed as obvious to trunk:
2025-05-27 Jakub Jelinek
PR c/117025
* c-parser.cc (c_parser_sizeof_or_countof_expression): Use
C2Y rather than C23 in
On Tue, 27 May 2025, Patrick Palka wrote:
> On Tue, 27 May 2025, David Malcolm wrote:
>
> > On Fri, 2025-05-23 at 16:58 -0400, Jason Merrill wrote:
> > > On 4/14/25 9:57 AM, Jason Merrill wrote:
> > > > On 1/9/25 10:00 PM, Jason Merrill wrote:
> > > > > Tested x86_64-pc-linux-gnu. Is the diagno
On Tue, May 27, 2025 at 02:25:14PM +0200, Richard Biener wrote:
> Isn't soft-fp imported from glibc?
Most of it, yes.
Though, the _BitInt specific stuff in there (whether
binary float <-> _BitInt or decimal float <-> _BitInt) is not owned
by glibc, it is an implementation detail of GCC, put into t
libstdc++-v3/ChangeLog:
* testsuite/17_intro/names.cc [_AIX] (n): Undefine.
* testsuite/experimental/names.cc [_AIX] (ptr): Undefine.
---
Tested x86_64-linux and powerpc-aix.
Pushed to trunk.
libstdc++-v3/testsuite/17_intro/names.cc | 2 ++
libstdc++-v3/testsuite/experimenta
Dear all,
the attached patch fixes a variety of small issues with parsing of
inquiry references of substrings. The testcase exercises variations
of the examples in the PR and ensures that these are successfully
simplified.
Don't try it with other compilers... ;-)
Regtested on x86_64-pc-linux-g
Hi, Kees,
> On May 19, 2025, at 14:23, Kees Cook wrote:
>
> On Fri, May 16, 2025 at 01:34:14PM +, Qing Zhao wrote:
>> Adding -fdiagnotics-details into GCC to provide more hints to the
>> end users on how the warnings come from, in order to help the user
>> to locate the exact location in s
On 5/20/25 12:35 PM, Jerry D wrote:
On 5/20/25 12:01 PM, Harald Anlauf wrote:
Hi Jerry!
Am 20.05.25 um 05:23 schrieb Jerry D:
On 5/19/25 1:50 PM, Harald Anlauf wrote:
Hi Jerry,
so contrary to what the name of patch claims (pr120049-final.diff),
it fixes only the case of direct use of iso_c_b
> Couldn't we keep the RTL in order for other optimizations? I'm not really
> expecting any but at least we'd still have the opportunity. Or does that
> interfere with the tests?
I see, let me have a try in v2.
Pan
-Original Message-
From: Robin Dapp
Sent: Tuesday, May 27, 2025 2:2
This removes the non-SLP paths that were made unreachable in the
previous patch.
gcc/ChangeLog:
* tree-vect-stmts.cc (vectorizable_load): Remove non-SLP paths.
---
gcc/tree-vect-stmts.cc | 49 --
1 file changed, 18 insertions(+), 31 deletions(-)
d
From: Robin Dapp
This patch enables strided loads for VMAT_STRIDED_SLP. Instead of
building vectors from scalars or other vectors we can use strided loads
directly when applicable.
The current implementation limits strided loads to cases where we can
load entire groups and not subsets of them.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/15?
The 'volatile' issue from that PR Will be fixed in a separate patch as
operator[] isn't the only operation that's affected.
-- >8 --
The const lvalue operator[] overload wasn't properly forwarding the key
type to the generic overload
On Tue, May 27, 2025 at 02:17:46PM +, Yuao Ma wrote:
>
> I've reverted the recent format changes, as three reviewers indicated they
> caused more harm than good.
>
Thank you.
> Are there any functional problems I need to address?
I did not see any additional functional issues. Patch is
OK
Some tests have 'dg-do link' but currently require 'tls' which is a
compile-only check.
In some configurations of arm-none-eabi, the 'tls' effective-target
can be successful although these tests fail to link with
undefined reference to `__aeabi_read_tp'
This patch as a new tls_link effective targ
Am 25.04.25 um 16:37 schrieb Vladimir Makarov:
On 4/19/25 3:29 PM, Denis Chertykov wrote:
Bugfix for PR118591
[...]
It is difficult for me to understand AVR code but I think the reason for
the bug is in something else. And the fix should be different.
Hi Vladimir,
let me try to explain t
1 - 100 of 110 matches
Mail list logo
