On Thu, 2023-03-02 at 10:26 +, Richard Sandiford wrote:
> Xi Ruoyao writes:
> > Hi,
> >
> > This patch series fixes a lot of test failures with --enable-default-pie
> > or --enable-default-ssp for AArch64 target. Only test files are changed
> > to disable PIE or SSP to satisify the expectati
On 2023/3/6 16:11, Richard Biener wrote:
On Mon, Mar 6, 2023 at 8:22 AM Xionghu Luo wrote:
On 2023/3/2 18:45, Richard Biener wrote:
small.gcno: 648: block 2:`small.c':1, 3, 4, 6
small.gcno: 688:0145: 36:LINES
small.gcno: 700: blo
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-builtins.cc (riscv_gimple_fold_builtin): New
function.
* config/riscv/riscv-protos.h (riscv_gimple_fold_builtin): Ditto.
(gimple_fold_builtin): Ditto.
* config/riscv/riscv-vector-builtins-bases.cc (class rea
Hi
This is a proposal for addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
by integrating the UTF-8 manifest file into gcc's build process for the
64-bit mingw host.
The analysis and discussion leading up to the latest patch are written in
the bug report.
The patch attached in th
> From: Mike Stump
> Date: Mon, 6 Mar 2023 02:05:35 -0800
> Ok
Thanks! The server-side hook didn't like my ChangeLog
entry:
* lib/multiline.exp (_build_multiline_regex): Map
"{re:" to "(", ":re}" to ")" and ":re?}" to ")?".
It seems I forgot to validate that patch by
c
When processing a noexcept, constructors aren't elided: build_over_call
has
/* It's unsafe to elide the constructor when handling
a noexcept-expression, it may evaluate to the wrong
value (c++/53025). */
&& (force_elide || cp_noexcept_operand == 0))
so the
The current copy_file implementation is suboptimal. It only uses
sendfile for files smaller than 2GB, falling back to a userspace copy,
and does not support copy_file_range at all.
copy_file_range is particularly of increasing importance with the
adoption of reflinks in filesystems.
I am pretty su
Hi!
On Mon, Mar 06, 2023 at 07:13:08PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > Most importantly, what makes you think this is a problem for aarch64
> > only? If it actually is, you can fix it in the aarch64 config! Either
> > with or without new hooks, whatever works be
On Mon, Mar 06, 2023 at 04:34:59PM +, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > On Mon, Mar 06, 2023 at 03:08:00PM +, Richard Sandiford via Gcc-patches
> > wrote:
> >> Segher Boessenkool writes:
> >> > On Mon, Mar 06, 2023 at 12:47:06PM +, Richard Sandiford wrote:
> >> >>
On Mon, Mar 06, 2023 at 11:12:56AM -0500, Jason Merrill wrote:
> On 3/3/23 12:51, Marek Polacek wrote:
> > Similarly to PR107938, this also started with r11-557, whereby
> > cp_finish_decl
> > can call check_initializer even in a template for a constexpr initializer.
> >
> > Here we are rejecting
On Fri, Mar 03, 2023 at 09:30:38PM -0500, Jason Merrill wrote:
> On 3/3/23 12:50, Marek Polacek wrote:
> > switch (TREE_CODE (expr))
> > {
> > case CALL_EXPR:
> > @@ -13831,7 +13895,8 @@ do_warn_dangling_reference (tree expr)
> > std::pair v = std::minmax(1, 2);
> >
On Mar 6, 2023, at 10:52 AM, Hans-Peter Nilsson via Gcc-patches
wrote:
>
> Ok to apply?
Ok.
> * lib/target-supports.exp (check_compile): Support scanning tree-dumps.
On Mar 6, 2023, at 10:45 AM, Hans-Peter Nilsson via Gcc-patches
wrote:
>
> Ok to commit?
Ok.
> -- >8 --
> The RTL "expand" dump is the first RTL dump, and it also appears to be
> the earliest trace of the target having implemented sibcalls.
> Including the "," in the pattern searched for, to t
Ping!
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612298.html
On 2/18/23 22:21, Sandra Loosemore wrote:
I've been working on support for OpenMP imperfectly-nested loops. In
the process I have gone astray multiple times because of
incorrect/inadequate internal documentation for the
Segher Boessenkool writes:
> On Mon, Mar 06, 2023 at 04:34:59PM +, Richard Sandiford wrote:
>> Jakub Jelinek writes:
>> > Could we have a target hook to canonicalize memory addresses for combiner,
>> > like we have that targetm.canonicalize_comparison ?
>>
>> I don't think a hook makes sense
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Friday, January 27, 2023 12:26 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>> ; Marcus Shawcroft
>> ; Kyrylo Tkachov
>> Subject: Re: [PATCH]AArch64: Fix codegen regressi
This is sort-of a spin-off from effective_target_tail_call: I thought
that'd best be implemented by scanning a tree-dump, specifically
-fdump-tree-optimized, but the "tail call" found there is emitted for
*all* targets. Debugged and ready to apply, putting it out for
consideration as someone will
Borderline obvious when tail_call is available, so I'll then apply.
-- >8 --
While gcc.dg/plugin/must-tail-call-2.c passes for all targets even
without this, the error message is, for a target like cris-elf that
doesn't implement sibling calls: "error: cannot tail-call: machine
description does not
Will commit as obvious, when the 1/3 tail_call is applied.
-- >8 --
Spot-checked the PDF output for sanity.
* doc/sourcebuild.texi: Document check_effective_target_tail_call.
---
gcc/doc/sourcebuild.texi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/doc/sourcebuild.texi b/gcc
Ok to commit?
-- >8 --
The RTL "expand" dump is the first RTL dump, and it also appears to be
the earliest trace of the target having implemented sibcalls.
Including the "," in the pattern searched for, to try and avoid
possible false matches, but there doesn't appear to be any identifiers
or targe
On Mon, Mar 06, 2023 at 04:34:59PM +, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > Could we have a target hook to canonicalize memory addresses for combiner,
> > like we have that targetm.canonicalize_comparison ?
>
> I don't think a hook makes sense as a long-term design decision.
>
On Mon, Mar 06, 2023 at 05:18:50PM +0100, Jakub Jelinek wrote:
> On Mon, Mar 06, 2023 at 03:08:00PM +, Richard Sandiford via Gcc-patches
> wrote:
> That still feels like it could be risky in stage4, affecting various other
> FEs which would be expecting ANDs in their patterns instead of *_EXTE
On Wed, 22 Feb 2023 at 06:06, François Dumont via Libstdc++
wrote:
>
> Here is eventually a working proposal.
>
> Compared to the unordered container approach we need to find out what
> type is going to be used to call the comparer. Otherwise we might
> reinstantiate a temporary each time we call
Jakub Jelinek writes:
> On Mon, Mar 06, 2023 at 03:08:00PM +, Richard Sandiford via Gcc-patches
> wrote:
>> Segher Boessenkool writes:
>> > On Mon, Mar 06, 2023 at 12:47:06PM +, Richard Sandiford wrote:
>> >> How about the patch below?
>> >
>> > What about it? What would make it any bet
On Mon, Mar 06, 2023 at 03:08:00PM +, Richard Sandiford via Gcc-patches
wrote:
> Segher Boessenkool writes:
> > On Mon, Mar 06, 2023 at 12:47:06PM +, Richard Sandiford wrote:
> >> How about the patch below?
> >
> > What about it? What would make it any better than the previous?
>
> It d
On 3/3/23 12:51, Marek Polacek wrote:
Similarly to PR107938, this also started with r11-557, whereby cp_finish_decl
can call check_initializer even in a template for a constexpr initializer.
Here we are rejecting
extern const Q q;
template
constexpr auto p = q(0);
even though q has a
Segher Boessenkool writes:
> On Mon, Mar 06, 2023 at 12:47:06PM +, Richard Sandiford wrote:
>> How about the patch below?
>
> What about it? What would make it any better than the previous?
It does what Jeff suggested in the quoted message: work within the existing
extract/make_compound_oper
pan2...@intel.com writes:
> From: Pan Li
>
> Fix the bug of the rvv bool mode precision with the adjustment.
> The bits size of vbool*_t will be adjusted to
> [1, 2, 4, 8, 16, 32, 64] according to the rvv spec 1.0 isa. The
> adjusted mode precison of vbool*_t will help unde
Got it and it makes sense to me from the perspective of the defensive
programming.
Thanks a lot, and update the PATCH v4 as below link.
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613465.html
Pan
-Original Message-
From: Richard Sandiford
Sent: Monday, March 6, 2023 9:41 PM
From: Pan Li
Fix the bug of the rvv bool mode precision with the adjustment.
The bits size of vbool*_t will be adjusted to
[1, 2, 4, 8, 16, 32, 64] according to the rvv spec 1.0 isa. The
adjusted mode precison of vbool*_t will help underlying pass to
make t
On Mon, Mar 06, 2023 at 12:47:06PM +, Richard Sandiford wrote:
> How about the patch below?
What about it? What would make it any better than the previous?
Oh, and please do not send new patches in old threads :-(
Segher
pan2...@intel.com writes:
> From: Pan Li
>
> Fix the bug of the rvv bool mode precision with the adjustment.
> The bits size of vbool*_t will be adjusted to
> [1, 2, 4, 8, 16, 32, 64] according to the rvv spec 1.0 isa. The
> adjusted mode precison of vbool*_t will help unde
On 03/03/2023 17:05, Paul-Antoine Arras wrote:
Le 02/03/2023 à 18:18, Andrew Stubbs a écrit :
On 01/03/2023 16:56, Paul-Antoine Arras wrote:
This patch introduces instruction patterns for conditional min and max
operations (cond_{f|s|u}{max|min}) in the GCN machine description. It
also allows
Jeff Law via Gcc-patches writes:
> On 3/5/23 12:28, Tamar Christina via Gcc-patches wrote:
>>
>> The regression was reported during stage-1. A patch was provided during
>> stage 1 and the discussions around combine stalled.
>>
>> The regression for AArch64 needs to be fixed in GCC 13. The hit i
> Hi!
>
> On Sun, Mar 05, 2023 at 03:33:40PM -0600, Segher Boessenkool wrote:
> > On Sun, Mar 05, 2023 at 08:43:20PM +, Tamar Christina wrote:
> > Yes, *look* better: I have seen no proof or indication that this would
>
> ("looks", I cannot type, sorry)
>
> > actually generate better code, n
Hi!
On Sun, Mar 05, 2023 at 03:33:40PM -0600, Segher Boessenkool wrote:
> On Sun, Mar 05, 2023 at 08:43:20PM +, Tamar Christina wrote:
> Yes, *look* better: I have seen no proof or indication that this would
("looks", I cannot type, sorry)
> actually generate better code, not even on just aa
Gerald Pfeifer writes:
> Hi Gaius,
>
> apologies, I thought you had pushed the updated patch and only now
> realized it's not in yet.
>
> Please look into the few bits below and then go ahead and push.
>
> On Mon, 6 Feb 2023, Gaius Mulley wrote:
>> * htdocs/frontends.html: An update to say
On Mon, 6 Mar 2023, Jakub Jelinek wrote:
> On Mon, Mar 06, 2023 at 11:01:18AM +, Richard Biener wrote:
> > + auto_mpfr &operator=(const auto_mpfr &) = delete;
> > + auto_mpz &operator=(const auto_mpz &) = delete;
>
> Just formatting nit, space before (.
>
> Looks like nice improvement and
Ping,
And updated the hook to allow to differentiate between ISAs.
As Andy said before initializing a ranger instance is cheap but not free, and if
the intention is to call it often during a pass it should be instantiated at
pass startup and passed along to the places that need it. This is a big
Ping,
And updating the hook.
There are no new test as new correctness tests were added to the mid-end and
the existing codegen tests for this already exist.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
PR target/108583
Ping.
And updated the patch to reject cases that we don't expect or can handle
cleanly for now.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
PR target/108583
* gimple-range-op.h (gimple_range_op_handler): Add mayb
On Mon, Mar 06, 2023 at 11:01:18AM +, Richard Biener wrote:
> + auto_mpfr &operator=(const auto_mpfr &) = delete;
> + auto_mpz &operator=(const auto_mpz &) = delete;
Just formatting nit, space before (.
Looks like nice improvement and thanks Jonathan for the suggestions ;)
Jakub
On Mon, 6 Mar 2023 at 11:01, Richard Biener wrote:
>
> On Mon, 6 Mar 2023, Jonathan Wakely wrote:
>
> > On Mon, 6 Mar 2023 at 10:11, Richard Biener wrote:
> > >
> > > The following adds two RAII classes, one for mpz_t and one for mpfr_t
> > > making object lifetime management easier. Both former
On Mon, 6 Mar 2023, Jonathan Wakely wrote:
> On Mon, 6 Mar 2023 at 10:11, Richard Biener wrote:
> >
> > The following adds two RAII classes, one for mpz_t and one for mpfr_t
> > making object lifetime management easier. Both formerly require
> > explicit initialization with {mpz,mpfr}_init and r
On Mon, 6 Mar 2023 at 10:11, Richard Biener wrote:
>
> The following adds two RAII classes, one for mpz_t and one for mpfr_t
> making object lifetime management easier. Both formerly require
> explicit initialization with {mpz,mpfr}_init and release with
> {mpz,mpfr}_clear.
>
> I've converted two
Hi,
> This broke the tests, I'm seeing syntax errors:
> ERROR: gcc.dg/vect/slp-3.c -flto -ffat-lto-objects: error executing dg-final:
> syntax error in target selector "target ! vect_partial_vectors || vect32 ||
> s390_vx"
> ERROR: gcc.dg/vect/slp-3.c: error executing dg-final: syntax error in
The following closes a gap in double reduction detection where we
in the outer loop analysis fail to verify the inner LC PHI use is
the latch definition of the inner loop PHI. That latch definition
is used to detect that an inner loop is part of a double reduction
when later doing the inner loop a
Thank you, Kito.
Hi Richard Sandiford,
Could you please help to review this PATCH continuously? Thank you and have a
nice day!
Pan
-Original Message-
From: Kito Cheng
Sent: Friday, March 3, 2023 4:06 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; rguent...@suse.d
The following adds two RAII classes, one for mpz_t and one for mpfr_t
making object lifetime management easier. Both formerly require
explicit initialization with {mpz,mpfr}_init and release with
{mpz,mpfr}_clear.
I've converted two example places (where lifetime is trivial).
I've sofar only bui
Hi,
while adding tunes to siable scatters on znver4 I mistakely also disabled
them on generic. This patch fixes it.
Bootstraped/regtested x86_64, comitted.
Honza
gcc/ChangeLog:
2023-03-06 Jan Hubicka
* config/i386/x86-tune.def (X86_TUNE_USE_SCATTER_2PARTS): Enable for
gener
Ok
On Mar 3, 2023, at 5:58 PM, Hans-Peter Nilsson wrote:
>
> Ping...
>
>> From: Hans-Peter Nilsson
>> Date: Fri, 24 Feb 2023 20:16:03 +0100
>>
>> Ok to commit?
Hi Haochen,
on 2023/3/3 20:54, Tobias Burnus wrote:
> Hi Haochen,
>
> On 03.03.23 10:56, HAO CHEN GUI via Gcc-patches wrote:
>> Sure, I will merge it into the patch and do the regression test.
> Thanks :-)
>> Additionally, Kewen suggested:
Since this test case is powerpc only, I think it can
Hi,
According to Haochen's finding in [1], currently ppc-fortran.exp
doesn't support Fortran specific warning or error messages well.
By looking into it, it's due to that gfortran uses some different
warning/error prefixes as follows:
set gcc_warning_prefix "\[Ww\]arning:"
set gcc_error_p
Hi,
As PR108727 shows, when cleanup code called by the stack
unwinder calls function _Unwind_Resume, it goes via plt
stub like:
function .plt_call._Unwind_Resume:
=> 0x10003580 <+0>: std r2,40(r1)
0x10003584 <+4>: ld r12,-31760(r2)
0x1000
在 2023/3/6 下午4:18, Xi Ruoyao 写道:
On Mon, 2023-03-06 at 16:12 +0800, Lulu Cheng wrote:
Has the first patch been merged into the main branch yet?
I think there is one more test case that needs to be modified:
--- a/gcc/testsuite/gcc.target/loongarch/prolog-opt.c
+++ b/gcc/testsuite/gcc.target/
On Mon, 2023-03-06 at 16:12 +0800, Lulu Cheng wrote:
> Has the first patch been merged into the main branch yet?
>
> I think there is one more test case that needs to be modified:
>
> --- a/gcc/testsuite/gcc.target/loongarch/prolog-opt.c
> +++ b/gcc/testsuite/gcc.target/loongarch/prolog-opt.c
> @
在 2023/3/6 下午4:02, Xi Ruoyao 写道:
On Mon, 2023-03-06 at 13:59 +0800, Xi Ruoyao via Gcc-patches wrote:
On Mon, 2023-03-06 at 11:16 +0800, Xi Ruoyao wrote:
/* snip */
Sorry for the late reply, the first patch I think is fine. But I haven't
reproduced the problem of the second mail.
Is there a
On Mon, Mar 6, 2023 at 8:22 AM Xionghu Luo wrote:
>
>
>
> On 2023/3/2 18:45, Richard Biener wrote:
> >>
> >>
> >>small.gcno: 648: block 2:`small.c':1, 3, 4, 6
> >>small.gcno: 688:0145: 36:LINES
> >>small.gcno: 700: block 3:`small.c':8, 9
>
On Mon, 2023-03-06 at 13:59 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Mon, 2023-03-06 at 11:16 +0800, Xi Ruoyao wrote:
>
> /* snip */
>
> > > > Sorry for the late reply, the first patch I think is fine. But I
> > > > haven't
> > > > reproduced the problem of the second mail.
> > > >
> > > >
Pushed r13-6500 and r12-9225.
On Mon, 2023-03-06 at 15:21 +0800, Lulu Cheng wrote:
>
> 在 2023/3/3 下午4:16, Xi Ruoyao 写道:
> > In the toolchain convention, we describe -mfpu= as:
> >
> > "Selects the allowed set of basic floating-point instructions and
> > registers. This option should not change t
60 matches
Mail list logo
