On Mon, Apr 29, 2024 at 5:58 AM Kito Cheng wrote:
>
> OK for trunk, and my understanding is that flag isn't really used in
> code gen yet, so it's not necessary to port to GCC 14 branch?
Pushed to master.
Since the riscv_zi_subext masks of the affected extensions are applied
to higher bits of ri
Hi!
The following patch implements the P0609R3 paper; we build the
VAR_DECLs for the structured binding identifiers early, so all we need
IMHO is just to parse the attributed identifier list and pass the attributes
to the VAR_DECL creation.
The paper mentions maybe_unused and gnu::nonstring attri
Hi,
this removes the last parameter of choose_multiplier, which is unused, adds
another assertion and more details to the description and various comments.
Likewise to the closely related invert_mod2n, except for the last parameter.
Tested on x86-64/Linux, OK for the mainline?
2024-04-29 Eric
On Apr 28, 2024, "Kewen.Lin" wrote:
> OK, from this perspective IMHO it seems more clear to adopt xfail
> with effective target long_double_64bit?
That's effective target is quite broken, alas. I doubt it's used
anywhere: it calls an undefined proc, and its memcmp call seems to have
the size cu
From: Pan Li
When we build with isl, there will be a ICE for graphite in both
the c/c++ and fortran. The legitimize move cannot take care of
below rtl.
(set (subreg:DI (reg:TI 237) 8) (subreg:DI (const_poly_int:TI [4, 2]) 8))
Then we will have ice similar to below:
internal compiler error: in
Thanks Kito, sent v2 for addressing comments.
Pan
-Original Message-
From: Kito Cheng
Sent: Monday, April 29, 2024 2:37 PM
To: juzhe.zh...@rivai.ai
Cc: Li, Pan2 ; gcc-patches
Subject: Re: [PATCH v1] RISC-V: Fix ICE for legitimize move on subreg
const_poly_move
> diff --git a/gcc/conf
Hi Pan:
LGTM.
Hi Jakub:
Is this OK for GCC 14 branch? it's fix ICE on valid code, thanks :)
On Mon, Apr 29, 2024 at 3:40 PM wrote:
>
> From: Pan Li
>
> When we build with isl, there will be a ICE for graphite in both
> the c/c++ and fortran. The legitimize move cannot take care of
> below rt
On Mon, Apr 29, 2024 at 03:47:05PM +0800, Kito Cheng wrote:
> Hi Jakub:
>
> Is this OK for GCC 14 branch? it's fix ICE on valid code, thanks :)
Ok.
Jakub
From: Pan Li
Update in v3:
* Rebase upstream for conflict.
Update in v2:
* Fix one failure for x86 bootstrap.
Original log:
This patch would like to add the middle-end presentation for the
saturation add. Aka set the result of add to the max when overflow.
It will take the pattern similar as
This patch updates the Solaris baselines for the GLIBCXX_3.4.32 version
added in GCC 13.2.
Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32 and 64-bit
each) on the gcc-13 branch and (together with the GLIBCXX_3.4.33 update)
on both gcc-14 branch and trunk.
Ok for all of gcc-13 and gcc-
This patch updates the Solaris baselines for the GLIBCXX_3.4.33 version
added in GCC 14.0.
Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32 and 64-bit
each), together with the GLIBCXX_3.4.32 update, on both gcc-14 branch
and trunk.
Ok for and gcc-14 branch and trunk?
Rainer
-
From: Yang Yujie
On LoongArch, the regitsters $r4 - $r7 (EH_RETURN_DATA_REGNO) will be saved
and restored in the function prologue and epilogue if the given function calls
__builtin_eh_return. This causes the return value to be overwritten on normal
return paths and breaks a rare case of libgcc'
From: Yang Yujie
On LoongArch, the regitsters $r4 - $r7 (EH_RETURN_DATA_REGNO) will be saved
and restored in the function prologue and epilogue if the given function calls
__builtin_eh_return. This causes the return value to be overwritten on normal
return paths and breaks a rare case of libgcc'
On Mon, Apr 29, 2024 at 10:02:56AM +0200, Rainer Orth wrote:
> This patch updates the Solaris baselines for the GLIBCXX_3.4.32 version
> added in GCC 13.2.
>
> Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32 and 64-bit
> each) on the gcc-13 branch and (together with the GLIBCXX_3.4.33
On Mon, Apr 29, 2024 at 10:07:42AM +0200, Rainer Orth wrote:
> This patch updates the Solaris baselines for the GLIBCXX_3.4.33 version
> added in GCC 14.0.
>
> Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32 and 64-bit
> each), together with the GLIBCXX_3.4.32 update, on both gcc-14 br
Committed to trunk, thanks Kito.
Backported to releases/gcc-14, thanks Jakub.
Pan
-Original Message-
From: Jakub Jelinek
Sent: Monday, April 29, 2024 3:53 PM
To: Kito Cheng
Cc: Li, Pan2 ; Jeff Law ;
gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai
Subject: Re: [PATCH v2] RISC-V: Fix ICE
Hello,
Le 28/04/2024 à 23:37, Paul Richard Thomas a écrit :
Hi All,
Could this be looked at quickly? The timing of this regression is more
than a little embarrassing on the eve of the 14.1 release. The testcase
and the comment in gfc_trans_class_init_assign explain what this problem
is all a
on 2024/4/29 14:28, Alexandre Oliva wrote:
> On Apr 28, 2024, "Kewen.Lin" wrote:
>
>> Nit: Maybe add a prefix "testsuite: ".
>
> ACK
>
>>>
>>> From: Kewen Lin
>
>> Thanks, you can just drop this. :)
>
> I've turned it into Co-Authored-By, since you insist.
>
> But unfortunately with the pa
on 2024/4/29 15:20, Alexandre Oliva wrote:
> On Apr 28, 2024, "Kewen.Lin" wrote:
>
>> OK, from this perspective IMHO it seems more clear to adopt xfail
>> with effective target long_double_64bit?
>
> That's effective target is quite broken, alas. I doubt it's used
> anywhere: it calls an undefi
On Mon, 22 Apr 2024 at 22:43, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk? More tests
> are needed but I figured I'd submit this now for possible consideration into
> GCC 14 since we're getting close to release.. All changes are confined to
> C++26.
OK for
On Fri, Apr 26, 2024 at 09:16:40PM -0400, Jason Merrill wrote:
> On 4/19/24 09:29, Nathaniel Shead wrote:
> > On Fri, Apr 19, 2024 at 12:14:06PM +1000, Nathaniel Shead wrote:
> > > On Wed, Apr 17, 2024 at 02:02:21PM -0400, Patrick Palka wrote:
> > > > On Mon, 15 Apr 2024, Nathaniel Shead wrote:
> >
On Sun, Apr 28, 2024 at 10:37:06PM +0100, Paul Richard Thomas wrote:
> Could this be looked at quickly? The timing of this regression is more than
> a little embarrassing on the eve of the 14.1 release. The testcase and the
> comment in gfc_trans_class_init_assign explain what this problem is all
>
Hi Mikael,
Thank you for the review and, in particular, the corrections in the fortran
ChangeLog. Unfortunately, both of us missed the systematically wrong PR
number. The commit was made to 15-branch with the wrong number throughout,
which I will correct tomorrow. This, however, has made a bit mor
Hi, Juzhe.
Thanks for reminding.
I did regression again and committed.
Regard,
Demin
From: juzhe.zh...@rivai.ai
Sent: 2024年4月29日 13:10
To: Demin Han ; gcc-patches
Cc: kito.cheng ; pan2.li ; jeffreyalaw
; Robin Dapp
Subject: Re: [PATCH v2] RISC-V: Refine the condition for add additional vars
According to documentation, '^' should only have an effect during reload.
However ira-costs.cc treats it in the same way as '?' during early costing.
As a result using '^' can accidentally disable valid alternatives and cause
significant regressions (see PR114741). Avoid this by ignoring '^' duri
Thanks Christophe!
I've added your patch as part of a documentation pull-request I'm adding
to our dev repo: https://github.com/Rust-GCC/gccrs/pull/2966
It'll be upstreamed with the next batch of commits we send, as soon as
trunk reopens fully for 15.1.
Best,
Arthur
On 4/4/24 18:27, Chris
On Fri, Apr 26, 2024 at 11:10:12PM +, Christophe Lyon wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/mve/pr114801.c
> @@ -0,0 +1,36 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target arm_v8_1m_mve_ok } */
> +/* { dg-add-options arm_v8_1m_mve } */
> +/* { dg-final { c
On Mon, 29 Apr 2024 at 15:24, Arthur Cohen wrote:
>
> Thanks Christophe!
>
> I've added your patch as part of a documentation pull-request I'm adding
> to our dev repo: https://github.com/Rust-GCC/gccrs/pull/2966
>
> It'll be upstreamed with the next batch of commits we send, as soon as
> trunk re
On Mon, 29 Apr 2024 at 15:29, Jakub Jelinek wrote:
>
> On Fri, Apr 26, 2024 at 11:10:12PM +, Christophe Lyon wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/arm/mve/pr114801.c
> > @@ -0,0 +1,36 @@
> > +/* { dg-do compile } */
> > +/* { dg-require-effective-target arm_v8_1m_mve_ok }
On Thu, 25 Apr 2024, Jakub Jelinek wrote:
> Hi!
>
> glibc 2.34 and later doesn't have separate libpthread (libpthread.so.0 is a
> dummy shared library with just some symbol versions for compatibility, but
> all the pthread_* APIs are in libc.so.6).
I suspect this has caused link failures in the
The Fortran standard does not specify what the result of the MAX
and MIN intrinsics are if one of the arguments is a NaN. So it
should be ok to tranform reduction for IFN_COND_MIN with vectorized
COND_MIN and REDUC_MIN.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk and bac
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
14 (I guess after 14.1 is released)?
-- >8 --
We need to look through TEMPLATE_DECL like make_friend_class does when
adding to CLASSTYPE_BEFRIENDING_CLASSES.
Otherwise in the below testcase we won't add _Hashtable to
CLASSTYP
Lightly tested on x86_64-pc-linux-gnu so far, does this look OK for
trunk/14.1 after bootstrap+regtest finishes?
-- >8 --
We're missing a dependence check for the second operand in the
sizeof / sizeof handling.
PR c++/114888
gcc/cp/ChangeLog:
* typeck.cc (cp_build_binary_op) :
On Mon, Apr 29, 2024 at 10:28:19AM -0400, Patrick Palka wrote:
> Lightly tested on x86_64-pc-linux-gnu so far, does this look OK for
> trunk/14.1 after bootstrap+regtest finishes?
LGTM.
> -- >8 --
>
> We're missing a dependence check for the second operand in the
> sizeof / sizeof handling.
>
On Mon, Apr 29, 2024 at 01:44:24PM +, Joseph Myers wrote:
> > glibc 2.34 and later doesn't have separate libpthread (libpthread.so.0 is a
> > dummy shared library with just some symbol versions for compatibility, but
> > all the pthread_* APIs are in libc.so.6).
>
> I suspect this has caused l
This optimisation does not honour signed zeros, so should not be
enabled except with -fno-signed-zeros.
Cherry-pick of 7dd3b2b09cbeb6712ec680a0445cb0ad41070423.
Applies cleanly on releases/gcc-12. Regression-tested, only new
failure is in gcc/testsuite/c-c++-common/hwasan/large-aligned-1.c
which
This optimisation does not honour signed zeros, so should not be
enabled except with -fno-signed-zeros.
Cherry-pick of 7dd3b2b09cbeb6712ec680a0445cb0ad41070423.
Applies cleanly on releases/gcc-13, regression-tested with no new
failures.
OK for backport to GCC 13? If so, please commit for me as I
On 4/29/24 1:14 AM, Eric Botcazou wrote:
Hi,
this removes the last parameter of choose_multiplier, which is unused, adds
another assertion and more details to the description and various comments.
Likewise to the closely related invert_mod2n, except for the last parameter.
Tested on x86-64/L
On 3/22/24 11:45 PM, Li, Pan2 wrote:
Thanks Jeff for comments.
As Richi noted using validate_subreg here isn't great. Does it work to
factor out this code from extract_low_bits
if (!int_mode_for_mode (src_mode).exists (&src_int_mode)
|| !int_mode_for_mode (mode).exists (&int_mod
On 4/26/24 11:25 PM, Andrew Pinski wrote:
This is a small cleanup of loop_versioning where m_nloops
is only used in the constructor so we can remove the whole
field.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* gimple-loop-versioning.cc (loop_versioning): Remove m_n
On Mon, Apr 29, 2024 at 6:47 AM liuhongt wrote:
>
> The Fortran standard does not specify what the result of the MAX
> and MIN intrinsics are if one of the arguments is a NaN. So it
> should be ok to tranform reduction for IFN_COND_MIN with vectorized
> COND_MIN and REDUC_MIN.
The commit subject
> OK. Consider waiting to commit though as we want to make it easy to
> cherry pick patches over to the release branch if needed.
Sure. There are a couple more changes on top of it, but all can wait a bit.
--
Eric Botcazou
Hi,
for integral modes, the expansion of MULT_HIGHPART_EXPR requires the presence
of an {s,u}mul_highpart optab whereas, for vector modes, widening expansion is
supported. This adds a widening expansion for integral modes too, which is in
fact already implemented in expmed_mult_highpart_optab.
This libgo patch changes runtime/runtime.h to use the C99
header file rather than defining a bool type and true/false constants
itself. C99 was a long time ago and in case this file is always
compiled by the newly built GCC. This should fix GCC PR 114875.
Bootstrapped on x86_64-pc-linux-gnu. Co
On Mon, 29 Apr 2024, Jakub Jelinek wrote:
> On Mon, Apr 29, 2024 at 01:44:24PM +, Joseph Myers wrote:
> > > glibc 2.34 and later doesn't have separate libpthread (libpthread.so.0 is
> > > a
> > > dummy shared library with just some symbol versions for compatibility, but
> > > all the pthread_
Dear all,
the attached patch fixes issues with assignments of unlimited polymorphic
entities that were found with the help of valgrind or asan, see PR. Looking
further into it, it turns out that allocation sizes as well as array spans
could be set incorrectly, leading to wrong results or heap cor
This libgo patch, by Rainer Orth, dumps register values on Solaris on
a crash. This fixes GC PR 106813. Bootstrapped and ran Go testsuite
on x86_64-pc-linux-gnu. Committed to mainline.
Ian
a05efc8bf5ed329ea7d9b1740c326bdc6b04e37a
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
in
On Thu, 25 Apr 2024, Jakub Jelinek wrote:
> Hi!
>
> While the C23 standard isn't officially release yet,
> in 2011 we've changed __STDC_VERSION__ value for C11 already
> in the month in which the new __STDC_VERSION__ value has been
> finalized, so we want to change this now or wait
> until we imp
On 4/29/24 07:52, Marek Polacek wrote:
On Mon, Apr 29, 2024 at 10:28:19AM -0400, Patrick Palka wrote:
Lightly tested on x86_64-pc-linux-gnu so far, does this look OK for
trunk/14.1 after bootstrap+regtest finishes?
LGTM.
Yes, OK.
-- >8 --
We're missing a dependence check for the second op
On 4/29/24 06:50, Patrick Palka wrote:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
14 (I guess after 14.1 is released)?
OK for both.
-- >8 --
We need to look through TEMPLATE_DECL like make_friend_class does when
adding to CLASSTYPE_BEFRIENDING_CLASSES.
Otherwise
On 4/29/24 02:34, Nathaniel Shead wrote:
On Fri, Apr 26, 2024 at 09:16:40PM -0400, Jason Merrill wrote:
On 4/19/24 09:29, Nathaniel Shead wrote:
On Fri, Apr 19, 2024 at 12:14:06PM +1000, Nathaniel Shead wrote:
On Wed, Apr 17, 2024 at 02:02:21PM -0400, Patrick Palka wrote:
On Mon, 15 Apr 2024,
This patch solves another ICE-after-error problem in the C family
front-ends. Upon a conflicting type redeclaration, the ambiguous
type is poisoned with an error_mark_node to indicate to the middle-end
that the type is suspect, but care has to be taken by the front-end to
avoid passing these malf
On Apr 29, 2024, "Kewen.Lin" wrote:
> Thanks for catching this and sorry
> that I didn't check it before suggesting it, I think we can aggressively
> drop this effective target instead to avoid any possible confusion.
The 128-bit ones, unfortunately, follow the same pattern but are
probably used
On Apr 22, 2024, Richard Biener wrote:
>> Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu. Also tested with
>> gcc-13 on ppc64-vx7r2 and ppc-vx7r2. Ok to install?
> That makes sense. OK
>> for gcc/testsuite/ChangeLog
>>
>> * lib/target-supports.exp (check_vect_support_and_set_flags):
On 4/29/24 00:11, Jakub Jelinek wrote:
Hi!
The following patch implements the P0609R3 paper; we build the
VAR_DECLs for the structured binding identifiers early, so all we need
IMHO is just to parse the attributed identifier list and pass the attributes
to the VAR_DECL creation.
The paper menti
> So how about this. I'll ack this for the trunk, but not for gcc-14 (at
> this time). We can revisit for gcc-14 after it's been on the trunk a
> bit. Realistically that likely means gcc-14.2 at the end of the summer
> rather than gcc-14.1 which is due in roughly a week.
Thanks Jeff, I will
Pushed to r12-10403.
在 2024/4/29 下午4:09, Lulu Cheng 写道:
From: Yang Yujie
On LoongArch, the regitsters $r4 - $r7 (EH_RETURN_DATA_REGNO) will be saved
and restored in the function prologue and epilogue if the given function calls
__builtin_eh_return. This causes the return value to be overwritt
Pushed to r13-8661.
在 2024/4/29 下午4:09, Lulu Cheng 写道:
From: Yang Yujie
On LoongArch, the regitsters $r4 - $r7 (EH_RETURN_DATA_REGNO) will be saved
and restored in the function prologue and epilogue if the given function calls
__builtin_eh_return. This causes the return value to be overwritte
I get a diff when running "autoreconf" in this directory. I think that
the current state is erroneous: it appears to have been generated using
aclocal -I ../config -I ..
even though configure.ac and Makefile.am list the include flag in the
reverse order:
aclocal -I .. -I ../config
Runni
Add an "AC_CONFIG_MACRO_DIRS" call in configure.ac, with the same
directories as specified in "ACLOCAL_AMFLAGS", in Makefile.in.
This makes it possible to re-generate aclocal.m4 using "autoreconf".
---
fixincludes/configure| 1 +
fixincludes/configure.ac | 1 +
2 files changed, 2 insertions(+
Hi Harald,
This patch is verging on 'obvious', . once one sees it :-)
Yes, it's good for mainline and all active branches, when available.
Thanks
Paul
PS The fall-out pr114874 is so peculiar that I am dropping everything to
find the source.
On Mon, 29 Apr 2024 at 19:39, Harald Anlauf wr
61 matches
Mail list logo
