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
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 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
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
Hi all,
commit 517c9487f8fdc4e4e90252a9365e5823259dc783
Author: Alejandro Colomar
Date: Thu May 22 01:15:36 2025 +0200
c: Add _Countof operator [PR117025]
broke gcc build on RHEL 9 when building texi files:
gcc/doc/extend.texi:6: node `C Extensions' lacks menu item for
`_Countof' despite
On Tue, May 27, 2025 at 3:39 PM Joseph Myers wrote:
>
> 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
On 5/27/25 2:36 AM, Alfie Richards wrote:
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 feedbac
Documentation for `__cmpsf2` and similar functions currently indicate a
return type of `int`. This is not correct however; the `libgcc`
functions return `CMPtype`, the size of which is determined by the
`libgcc_cmp_return` mode.
Update documentation to use `CMPtype` and indicate that this is
targe
Add support of double trap extension [1], enabling GCC
to recognize the following extensions at compile time.
New extensions:
- ssdbltrp
- smdbltrp
[1]
https://github.com/riscv/riscv-double-trap/releases/download/v1.0/riscv-double-trap.pdf
gcc/ChangeLog:
* config/riscv/riscv-ext.def
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
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.
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
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 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 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 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
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 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 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 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 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
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 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-
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
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
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
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: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 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
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/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
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
Thanks everyone — I just applied the series (including the requested)
changes to trunk.
We'll also send the committed series (v4) to the list for archival.
Philipp.
On Tue, 20 May 2025 at 14:31, Richard Sandiford
wrote:
>
> Konstantinos Eleftheriou writes:
> > This patch uses `lowpart_subreg`
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 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
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
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
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
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
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.
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 replaces if (slp) with if (1) and if (!slp) with if (0).
gcc/ChangeLog:
* tree-vect-stmts.cc (vectorizable_load): Make non-SLP paths
unreachable.
---
gcc/tree-vect-stmts.cc | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/gcc/
On Wed, 21 May 2025, Icen Zeyada wrote:
> Generalize existing scalar gimple_fold rules to apply the same
> bitwise comparison simplifications to vector types. Previously, an
> expression like
>
> (x < y) && (x > y)
>
> would fold to `false` if x and y are scalars, but eq
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
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
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
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?
--
Regards
Robin
During the base register initialization, when we are eliminating the load
instruction, we were calling `emit_move_insn` on registers of the same
size but of different mode in some cases, causing an ICE.
We update the base register initialization to use `lowpart_subreg`
instead of zero-extending th
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
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
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
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
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 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
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 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:
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
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
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
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,
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
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
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
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 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
> 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
>
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 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
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 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
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 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: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: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 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, 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
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 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
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 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
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 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, 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
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 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
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
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 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
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
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
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
1 - 100 of 110 matches
Mail list logo
