On 3/3/25 2:59 AM, Liao Shihua wrote:
The pass ext-dce is only activated at O2 and above. Using O2 instead of O1
in testsuites when using -fdump-ext_dce.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/core_list_init.c: Using -O2 instead of -O1.
* gcc.target/riscv/pr111384.c: Ditt
On Wed, Mar 5, 2025 at 3:23 PM Haochen Jiang wrote:
>
> Hi all,
>
> For bf8 -> pf16 convert, when dst is 256 bit, the mask should be
> 16 bit since 16*16=256, not the 8 bit in the current intrin. In
> 512 bit intrin, the mask bit is also halved. This patch will fix
> both of them.
>
> Ok for trunk
On Wed, 05 Mar 2025 12:17:24 +0100, "Robin Dapp" wrote:
> Hi Jin,
>
> > I apologize for the delayed response. I spent quite a bit of time trying to
> > reproduce
> > the case, and given the passage of time, it wasn't easy to refine the
> > testing.
> > Fortunately, you can see the results here.
* Patrick Palka [2025-03-05 11:15:06]:
> On Tue, 4 Mar 2025, Patrick Palka wrote:
>
> > On Sun, 2 Mar 2025, Da Xie wrote:
> >
> > > Add check for constrained auto type specifier in function declaration or
> > > function type declaration with trailing return type. Issue error if such
> > > usage
From: Pan Li
The changes to vsetvl pass since 14 result in the asm check failure,
update the asm check to meet the newest behavior.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/partial/mult
As is done for other releases.
---
Pushed.
htdocs/gcc-8/porting_to.html | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/htdocs/gcc-8/porting_to.html b/htdocs/gcc-8/porting_to.html
index d24ea347..1d16a29e 100644
--- a/htdocs/gcc-8/porting_to.html
+++ b/htdocs/gcc-8/porti
---
Pushed.
htdocs/gcc-4.8/porting_to.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/gcc-4.8/porting_to.html b/htdocs/gcc-4.8/porting_to.html
index 9ed0d06b..c7e188ef 100644
--- a/htdocs/gcc-4.8/porting_to.html
+++ b/htdocs/gcc-4.8/porting_to.html
@@ -231,7 +231,7
Suggested by Andrew Pinski. I think it makes sense to have it in here even
if perhaps a bit verbose, because we really try to tell bug reporters to
read the page properly.
---
This takes into account Gerald's comments, hopefully faithfully.
Gerald, let me know if I misinterpreted anything or need
On Sat, 2025-02-08 at 10:33 +0100, Matthias Klose wrote:
> When configuring GCC with --program-suffix=-$(BASE_VERSION) to allow
> installation multiple GCC versions in parallel, the executable of the
> driver (gcc-$(BASE_VERSION)) gets recorded in the libgccjit.so.0
> library. Assuming, that you
Gerald Pfeifer writes:
> On Wed, 12 Feb 2025, Sam James wrote:
>> Suggested by Andrew Pinski. I think it makes sense to have it in here
>> even if perhaps a bit verbose, because we really try to tell bug
>> reporters to read the page properly.
>
> Makes sense.
>
>> This could also be a table.
>
On 3/5/25 4:00 PM, Marek Polacek wrote:
On Wed, Mar 05, 2025 at 03:31:59PM -0500, Jason Merrill wrote:
On 3/5/25 12:09 PM, Marek Polacek wrote:
On Tue, Mar 04, 2025 at 05:34:10PM -0500, Jason Merrill wrote:
On 2/11/25 6:24 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu
Implement LWG 3912, approved in Varna, June 2023.
libstdc++-v3/ChangeLog:
* include/std/ranges (enumerate_view::_Iterator::operator-):
Add noexcept, as per LWG 3912.
* testsuite/std/ranges/adaptors/enumerate/1.cc: Check iterator
difference is noexcept.
---
Tested
The new test functions I added in r15-7765-g3866ca796d5281 are causing
those tests to FAIL on Solaris and arm-thumb due to the linker
complaining about undefined functions. The new test functions are not
called, so it shouldn't matter that they call undefined member
functions, but it does.
Move t
Hi Jakub,
On Tue, Feb 11, 2025 at 07:04:31PM +0100, Jakub Jelinek wrote:
> The following testcase IMO in violation of the P2552R3 paper doesn't
> pedwarn on alignas applying to dependent types or alignas with dependent
> argument.
>
> tsubst was just ignoring TYPE_ATTRIBUTES.
>
> The following p
fortran added a new -Wexternal-argument-mismatch option, but the
lang.opt.urls file wasn't regenerated.
Fixes: 21ca9153ebe5 ("C prototypes for external arguments; add warning for
mismatch.")
gcc/fortran/ChangeLog:
* lang.opt.urls: Regenerated.
---
gcc/fortran/lang.opt.urls | 3 +++
1 f
On 3/5/25 6:58 AM, Simon Martin wrote:
Hi Jason,
On Tue Mar 4, 2025 at 11:47 PM CET, Jason Merrill wrote:
On 2/14/25 12:08 PM, Simon Martin wrote:
We have been miscompiling the following valid code since GCC8, and
r8-3497-g281e6c1d8f1b4c
=== cut here ===
struct span {
span (const int (&__
On 3/5/25 10:13 AM, Patrick Palka wrote:
On Tue, 4 Mar 2025, Jason Merrill wrote:
On 3/4/25 2:49 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14?
-- >8 --
In the three-parameter version of satisfy_declaration_constraints, when
't' is
On Wed, Mar 05, 2025 at 03:31:59PM -0500, Jason Merrill wrote:
> On 3/5/25 12:09 PM, Marek Polacek wrote:
> > On Tue, Mar 04, 2025 at 05:34:10PM -0500, Jason Merrill wrote:
> > > On 2/11/25 6:24 PM, Marek Polacek wrote:
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > > >
>
On Wed, 5 Mar 2025 at 11:06, Tomasz Kamiński wrote:
>
> Fix regression introduced by r14-8710-g65b4cba9d6a9ff
>
> PR libstdc++/119121
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/ranges_util.h (__detail::__pair_like_convertible_from):
> Use `_Tp` in `is_reference_v` check
On 3/5/25 12:09 PM, Marek Polacek wrote:
On Tue, Mar 04, 2025 at 05:34:10PM -0500, Jason Merrill wrote:
On 2/11/25 6:24 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we ICE since r11-7740 because we no longer say that (long)&a
(where a is a
On 3/5/25 10:39 AM, Simon Martin wrote:
Hi Jason,
On Wed Mar 5, 2025 at 12:03 AM CET, Jason Merrill wrote:
On 2/18/25 5:12 AM, Simon Martin wrote:
We've been rejecting this valid code since r8-4571:
=== cut here ===
void foo (float);
int main () {
constexpr float x = 0;
(void) [&] ()
On 3/5/25 10:50 AM, Marek Polacek wrote:
On Tue, Mar 04, 2025 at 04:41:05PM -0500, Jason Merrill wrote:
On 3/4/25 3:26 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This PR complains that we issue a -Wnonnull even in a decltype.
Since we can't u
Hi Andre,
Jerry already OK'ed your patch, but:
Am 05.03.25 um 15:34 schrieb Andre Vehreschild:
This fixes the PR, but not really the problem, because when say a
obj(i)%arr(2:5) => obj(i)%arr(1:4) is done we run into the same issue. I don't
have a solution for that error. It might be needed to
Ping.
On 2/12/25 19:00, Jørgen Kvalsvik wrote:
Ping.
On 1/31/25 10:35, Jørgen Kvalsvik wrote:
Record basic blocks that make up a conditional expression with
-fcondition-coverage and report when using the gcov -w/--verbose flag.
This makes the report more accurate when basic blocks are included
Ping.
On 2/21/25 19:15, Jørgen Kvalsvik wrote:
Ping
On 2/12/25 16:30, Jørgen Kvalsvik wrote:
I have applied fixes for everything in the last review, plus some GNU
style fixes that I had missed previously. We have tested and used a
build with this applied for 3-4 months now and haven't run into
On 3/5/25 6:34 AM, Andre Vehreschild wrote:
Hi all,
attached patch fixes a gimplification error when a pointer remapping on derived
type's components with deferred arrays is made. The issue boiled down to the
dependency analysis being to loose. It saw a dependency as soon as both sides
of the =>
On 3/3/25 2:59 AM, Liao Shihua wrote:
The pass ext-dce is only activated at O2 and above. Using O2 instead of O1
in testsuites when using -fdump-ext_dce.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/core_list_init.c: Using -O2 instead of -O1.
* gcc.target/riscv/pr111384.c: Ditt
Thanks for the patch and sorry for the slow review.
Eikansh Gupta writes:
> Many of the constants which are generated using 3 `mov` instruction can be
> generated using `mov` plus `sub` instruction. The patch uses following method
> to add the mentioned functionality. If a constant `val` can not
This is a backport of Richard's fix for PR118320 to GCC 14 (squashed
together with my follow-up tweak of the dump message). Pushed to
releases/gcc-14 after testing on aarch64-linux-gnu.
Thanks,
Alex
-- >8 --
As Andrew says in the bugzilla comments, this PR is about a case where
we tried to fuse
On 17/01/25 00:01 +0800, yxj-github-437 wrote:
I notice std::timespec and std::timespec_get are used in preprocessor
condition _GLIBCXX_HAVE_TIMESPEC_GET. So in module std, it should be
the same.
libstdc++-v3:
* src/c++23/std-clib.cc.in: move std::timespec in preprocessor
conditi
> -Original Message-
> From: Jakub Jelinek
> Sent: Wednesday, March 5, 2025 10:58
> To: Robert Dubner
> Cc: Richard Biener ; James K. Lowden
> ; gcc-patches@gcc.gnu.org
> Subject: Re: The COBOL front end, version 3, now in 14 easy pieces
>
> On Wed, Mar 05, 2025 at 09:47:45AM -0600, R
On Tue, Mar 04, 2025 at 05:34:10PM -0500, Jason Merrill wrote:
> On 2/11/25 6:24 PM, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > Here we ICE since r11-7740 because we no longer say that (long)&a
> > (where a is a global var) is non_con
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Because coroutines insert a call to the resumer between the initialization
of the return value and the actual return to the caller, we need to
duplicate the work of gimplify_return_expr for the !aggregate_value_p case.
PR c++/117364
On 04/03/2025 11:01, Christophe Lyon wrote:
> Commit r9-4307-g89d7557202d25a forgot to accept a fixed PIC register
> when extending the assert in require_pic_register.
>
> arm_pic_register can be set explicitly by the user
> (e.g. -mpic-register=r9) or implicitly as the default value with
> -fpic/
> -Original Message-
> From: Jakub Jelinek
> Sent: Wednesday, March 5, 2025 10:58
> To: Robert Dubner
> Cc: Richard Biener ; James K. Lowden
> ; gcc-patches@gcc.gnu.org
> Subject: Re: The COBOL front end, version 3, now in 14 easy pieces
>
> On Wed, Mar 05, 2025 at 09:47:45AM -0600, R
On 20/02/2025 14:09, Hannes Braun wrote:
> vld1q_s8_x3, vld1q_s16_x3, vld1q_s8_x4 and vld1q_s16_x4 were expecting
> pointers to unsigned integers. These parameters should be pointers to
> signed integers.
>
> gcc/ChangeLog:
>
> * config/arm/arm_neon.h (vld1q_s8_x3): Use int8_t instead of
>
On Tue, 4 Mar 2025, Patrick Palka wrote:
> On Sun, 2 Mar 2025, Da Xie wrote:
>
> > Add check for constrained auto type specifier in function declaration or
> > function type declaration with trailing return type. Issue error if such
> > usage is detected.
> >
> > Test file renamed, and added a n
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, March 5, 2025 10:50
> To: Robert Dubner
> Cc: Jakub Jelinek ; James K. Lowden
> ; gcc-patches@gcc.gnu.org
> Subject: Re: The COBOL front end, version 3, now in 14 easy pieces
>
> On Wed, Mar 5, 2025 at 4:47 PM Robert Dubner
On Wed, 5 Mar 2025, Patrick Palka wrote:
> On Thu, 24 Oct 2024, Jonathan Wakely wrote:
>
> > On Wed, 9 Oct 2024 at 14:02, Patrick Palka wrote:
> > >
> > > On Mon, 7 Oct 2024, Patrick Palka wrote:
> > >
> > > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk only?
> > > > This doesn't
On Wed, Mar 05, 2025 at 09:47:45AM -0600, Robert Dubner wrote:
> > -Original Message-
> > From: Jakub Jelinek
> > Sent: Wednesday, March 5, 2025 08:35
> > To: Richard Biener
> > Cc: James K. Lowden ; gcc-patches@gcc.gnu.org
> > Subject: Re: The COBOL front end, version 3, now in 14 easy p
There's a sanity check in gen_type_die_with_usage that trips
unnecessarily for a case where the relevant DIE has already been
generated successfully in other ways. The following keys the
existing TREE_ASM_WRITTEN check on the correct object, honoring
this and does nothing instead of ICEing for the
On Thu, 24 Oct 2024, Jonathan Wakely wrote:
> On Wed, 9 Oct 2024 at 14:02, Patrick Palka wrote:
> >
> > On Mon, 7 Oct 2024, Patrick Palka wrote:
> >
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk only?
> > > This doesn't seem worth backporting since there should be no
> > > beha
On Tue, Mar 04, 2025 at 04:41:05PM -0500, Jason Merrill wrote:
> On 3/4/25 3:26 PM, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > This PR complains that we issue a -Wnonnull even in a decltype.
> > Since we can't use cp_unevaluated_opera
> -Original Message-
> From: Jakub Jelinek
> Sent: Wednesday, March 5, 2025 08:35
> To: Richard Biener
> Cc: James K. Lowden ; gcc-patches@gcc.gnu.org
> Subject: Re: The COBOL front end, version 3, now in 14 easy pieces
>
> On Wed, Mar 05, 2025 at 12:46:48PM +0100, Richard Biener wrote:
On Wed, Mar 5, 2025 at 4:47 PM Robert Dubner wrote:
>
> > -Original Message-
> > From: Jakub Jelinek
> > Sent: Wednesday, March 5, 2025 08:35
> > To: Richard Biener
> > Cc: James K. Lowden ; gcc-patches@gcc.gnu.org
> > Subject: Re: The COBOL front end, version 3, now in 14 easy pieces
>
On Fri, 14 Feb 2025 at 05:12, Patrick Palka wrote:
>
> On Thu, 13 Feb 2025, Jonathan Wakely wrote:
>
> > On Tue, 11 Feb 2025 at 05:59, Patrick Palka wrote:
> > >
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> > >
> > > -- >8 --
> > >
> > > libstdc++-v3/ChangeLog:
> > >
> > >
On 2/18/25 11:12 AM, Keith Packard wrote:
We can avoid the setpsw instructions when len is a known constant.
When len is zero, the insn result is zero. When len is non-zero,
the scmpu instructions will set the flags correctly.
Were you able to actually trigger cases where operands[3] is a
CON
Hi Jason,
On Wed Mar 5, 2025 at 12:03 AM CET, Jason Merrill wrote:
> On 2/18/25 5:12 AM, Simon Martin wrote:
>> We've been rejecting this valid code since r8-4571:
>>
>> === cut here ===
>> void foo (float);
>> int main () {
>>constexpr float x = 0;
>>(void) [&] () {
>> foo (x);
>>
On Wed, 5 Mar 2025 at 15:37, Patrick Palkawrote:
>
> On Mon, 17 Feb 2025, Patrick Palka wrote:
>
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> > -- >8 --
> >
> > - Use __builtin_unreachable to suppress a false-positive "control
> > reaches end of non-void function" warning
On Mon, 17 Feb 2025, Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> -- >8 --
>
> - Use __builtin_unreachable to suppress a false-positive "control
> reaches end of non-void function" warning in the recursive lambda
> (which the existing tests failed to
On 3/5/25 7:39 AM, Robin Dapp wrote:
Hi,
when merging two vsetvls that both only demand "SEW >= ..." we
use their maximum SEW and keep the LMUL. That may lead to invalid
vector configurations like
e64, mf4.
As we make sure that the SEW requirements overlap we can use the SEW
and LMUL of th
Hi all,
The PARALLEL created in aarch64_evpc_dup is used to hold the lane number.
It is not appropriate for it to have a vector mode.
Other such uses use VOIDmode.
Do this here as well.
This avoids the risk of generic code treating the PARALLEL as trapping when it
has floating-point mode.
Bootstr
On Wed, 5 Mar 2025 at 13:44, Giuseppe D'Angelo wrote:
>
> Hi,
>
> I'm attaching a very small cleanup for constexpr std::stable_sort, using
> `if consteval` instead of `__is_constant_evaluated` within a C++26 feature.
OK for trunk, thanks.
You can drop the Signed-off-by from the commit message now
On Tue, 4 Mar 2025, Jason Merrill wrote:
> On 3/4/25 2:49 PM, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > for trunk/14?
> >
> > -- >8 --
> >
> > In the three-parameter version of satisfy_declaration_constraints, when
> > 't' isn't the most ge
Hi,
when merging two vsetvls that both only demand "SEW >= ..." we
use their maximum SEW and keep the LMUL. That may lead to invalid
vector configurations like
e64, mf4.
As we make sure that the SEW requirements overlap we can use the SEW
and LMUL of the configuration with the larger SEW.
Ma J
Hi all,
attached patch fixes a gimplification error when a pointer remapping on derived
type's components with deferred arrays is made. The issue boiled down to the
dependency analysis being to loose. It saw a dependency as soon as both sides
of the => had a derived type, independent of the actual
Hi,
I'm attaching a very small cleanup for constexpr std::stable_sort, using
`if consteval` instead of `__is_constant_evaluated` within a C++26 feature.
Thanks,
--
Giuseppe D'Angelo
From d81ed6c0e5eb8b4bce831217bafdf71c183b1ffa Mon Sep 17 00:00:00 2001
From: Giuseppe D'Angelo
Date: Wed, 5 Mar
On Wed, Mar 05, 2025 at 12:46:48PM +0100, Richard Biener wrote:
> and the installed compiler behaves as intended. I can trick -m32 to "work"
> by using the generic gcc diriver:
>
> > ./install/gcc-cobol/usr/local/bin/gcc -x cobol t.cob -m32 -c
>
> but I think this is a less important issue.
Agr
On Tue, Mar 4, 2025 at 7:18 PM James K. Lowden wrote:
>
> On Tue, 4 Mar 2025 00:08:16 +0100
> Jakub Jelinek wrote:
>
> > On Mon, Mar 03, 2025 at 05:21:38PM -0500, James K. Lowden wrote:
> > > However IMO, the incantation:
> > >
> > > make install DESTDIR=/foo
> > >
> > > is invalid. The comp
On Wed, Feb 26, 2025 at 10:29:59AM -0500, Jason Merrill wrote:
> On 2/21/25 6:05 AM, Nathaniel Shead wrote:
> > After seeing PR c++/118964 I'm coming back around to this [1] patch
> > series, since it appears that this can cause errors on otherwise valid
> > code by instantiations coming into modul
Ping for this. Or should this cleanup wait till GCC16?
On Wed, Feb 12, 2025 at 12:49:03AM +1100, Nathaniel Shead wrote:
> On Mon, Jan 27, 2025 at 10:20:05AM -0500, Patrick Palka wrote:
> > [snip]
> >
> > > @@ -18486,6 +18562,12 @@ dependent_operand_p (tree t)
> > > {
> > >while (TREE_CODE (t
Ping for this; was there any changes that you wanted me to make here?
On Sat, Feb 08, 2025 at 11:32:28PM +1100, Nathaniel Shead wrote:
> On Fri, Feb 07, 2025 at 11:11:21AM -0500, Jason Merrill wrote:
> > On 2/7/25 9:28 AM, Nathaniel Shead wrote:
> > > On Fri, Feb 07, 2025 at 08:14:23AM -0500, Jaso
Ping for this fix for a P1 issue.
On Sun, Feb 09, 2025 at 10:38:24PM +1100, Nathaniel Shead wrote:
> On Sun, Feb 09, 2025 at 01:16:00AM +1100, Nathaniel Shead wrote:
> > Tested on x86_64-pc-linux-gnu, OK for trunk if full bootstrap + regtest
> > passes?
> >
> > -- >8 --
> >
> > There are two iss
GCC must imply C extension from Zca extension when it's
possible. It's necessary for achieving compatibility
between different march strings which in fact may be
the same.
E.g., if rv32ic multilib configuration is presented in
GCC, then GCC will not choose this configuration for
linking if -march=
On Wed, Mar 5, 2025 at 12:46 PM Richard Biener
wrote:
>
> On Wed, Mar 5, 2025 at 11:43 AM Richard Biener
> wrote:
> >
> > On Tue, Mar 4, 2025 at 7:18 PM James K. Lowden
> > wrote:
> > >
> > > On Tue, 4 Mar 2025 00:08:16 +0100
> > > Jakub Jelinek wrote:
> > >
> > > > On Mon, Mar 03, 2025 at 05:
The header file arm_neon.h provides the Advanced SIMD intrinsics that
are available on armv7 or later A & R profile cores. However, they
are not compatible with M-profile and we also need to ensure that the
FP instructions are enabled (with -mfloat-abi=softfp/hard). That
leads to some complicated
Hi Jason,
On Tue Mar 4, 2025 at 11:47 PM CET, Jason Merrill wrote:
> On 2/14/25 12:08 PM, Simon Martin wrote:
>> We have been miscompiling the following valid code since GCC8, and
>> r8-3497-g281e6c1d8f1b4c
>>
>> === cut here ===
>> struct span {
>>span (const int (&__first)[1]) : _M_ptr (__f
On Tue, 4 Mar 2025, Richard Sandiford wrote:
> Richard Biener writes:
> > When vectorizing a shift of u16 data by an amount that's known to
> > be less than 16 we currently fail to emit a vector u16 shift. The
> > first reason is that the promotion of the shift amount is hoisted
> > only by PRE
On Wed, Mar 5, 2025 at 11:43 AM Richard Biener
wrote:
>
> On Tue, Mar 4, 2025 at 7:18 PM James K. Lowden
> wrote:
> >
> > On Tue, 4 Mar 2025 00:08:16 +0100
> > Jakub Jelinek wrote:
> >
> > > On Mon, Mar 03, 2025 at 05:21:38PM -0500, James K. Lowden wrote:
> > > > However IMO, the incantation:
>
Hi Jin,
I apologize for the delayed response. I spent quite a bit of time trying to
reproduce
the case, and given the passage of time, it wasn't easy to refine the testing.
Fortunately, you can see the results here.
https://godbolt.org/z/Mc8veW7oT
Using GCC version 14.2.0 should allow you to
Fix regression introduced by r14-8710-g65b4cba9d6a9ff
PR libstdc++/119121
libstdc++-v3/ChangeLog:
* include/bits/ranges_util.h (__detail::__pair_like_convertible_from):
Use `_Tp` in `is_reference_v` check
* testsuite/std/ranges/subrange/tuple_like.cc: New tests fo
Tamar Christina writes:
>> > diff --git a/gcc/config/aarch64/aarch64-sve.md
>> > b/gcc/config/aarch64/aarch64-
>> sve.md
>> > index
>> e975286a01904bec0b283b7ba4afde6f0fd60bf1..6c0be3c1a51449274720175b
>> 5e6e7d7535928de6 100644
>> > --- a/gcc/config/aarch64/aarch64-sve.md
>> > +++ b/gcc/config/a
Jakub Jelinek writes:
> Hi!
>
> The following testcase is miscompiled during evrp.
> Before vrp, we have (from ccp):
> # RANGE [irange] long long unsigned int [0, +INF] MASK 0xc000
> VALUE 0x2d
> _3 = _2 + 18446744073708503085;
> ...
> # RANGE [irange] long long unsigned int [0
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, March 3, 2025 11:53 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; ktkac...@gcc.gnu.org
> Subject: Re: [1/3 PATCH]AArch64: add support for partial modes to last
> extractions [PR118464]
>
>
> On 5 Mar 2025, at 11:14, Richard Biener wrote:
>
> On Tue, Mar 4, 2025 at 10:01 PM Richard Sandiford
> wrote:
>>
>> Kyrylo Tkachov writes:
>>> Hi all,
>>>
>>> In this testcase late-combine was failing to merge:
>>> dup v31.4s, v31.s[3]
>>> fmla v30.4s, v31.4s, v29.4s
>>> into the lane-wis
On Tue, Mar 4, 2025 at 10:01 PM Richard Sandiford
wrote:
>
> Kyrylo Tkachov writes:
> > Hi all,
> >
> > In this testcase late-combine was failing to merge:
> > dup v31.4s, v31.s[3]
> > fmla v30.4s, v31.4s, v29.4s
> > into the lane-wise fmla form.
> > This is because late-combine checks may_trap_p
Pushed to the trunk.
commit 2653d988e92bc9d70a3ac674d1b819610858e00a
Author: Tomasz Kamiński
Date: Wed Mar 5 10:33:23 2025 +0100
MAINTAINERS: Add myself to write after approval
ChangeLog:
* MAINTAINERS: Add myself.
diff --git a/MAINTAINERS b/MAINTAINERS
index 193c
On Tue, 4 Mar 2025, Ian Lance Taylor wrote:
> On Tue, Mar 4, 2025 at 2:12 AM Richard Biener wrote:
>
> > As PR119098 shows the gccgo driver uses the install path compiled
> > into the shared libgo and thus updating that but not the driver
> > will cause the driver to fail to find other tools lik
We found one more issue with the patch in our internal compile cluster. When
using "-fdirectives-only", linemarkers do not always start at the beginning of
a line.
This version of the patch (last submission
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675450.html) fixes this
by skipp
Hi Harald,
thanks for the review. Committed as gcc-15-7826-g705ae582d51.
The fix for pr107143 may be something similar. I am having a harder time getting
a testcase correct, then fixing the gimplification fault (that's fixed, but the
test is fouling me).
Thanks again,
Andre
On Tue, 4 Ma
80 matches
Mail list logo
