LGTM.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-04-24 10:48
To: gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc; Pan Li
Subject: [PATCH v1] RISC-V: Add xfail test case for highpart overlap of vext.vf
From: Pan Li
We reverted below patch for register group overlap, add the related
ins
PS ignore the chunk in trans-array.cc. It is an attempt to fix PR93678 that
literally did nothing.
Paul
On Wed, 24 Apr 2024 at 07:05, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi,
>
> The linaro pre-commit error testing picked up errors for arm and aarch
> since they set the
Hi,
The linaro pre-commit error testing picked up errors for arm and aarch
since they set the option -pedantic-errors.
/home/tcwg-build/workspace/tcwg_gnu_4/abe/snapshots/gcc.git~master/gcc/testsuite/gfortran.dg/pr89462.f90:6:14:
Warning: Obsolescent feature: Old-style character length at (1)
/hom
Hi all,
When we are using -mavx10.1-256 in command line and avx10.1-256 in
target attribute together, zmm should never be generated. But current
GCC will generate zmm since it wrongly enables EVEX512 for non-explicitly
set AVX512. This patch will fix that issue.
Regtested on x86_64-pc-linux-gnu.
When we update the dominator of the redirected exit after peeling
we check whether the immediate dominator was the loop header rather
than the exit source when we later want to just update it to the
new source. The following fixes this oversight.
Bootstrap and regtest running on x86_64-unknown-l
From: Pan Li
We reverted below patch for register group overlap, add the related
insn test and mark it as xfail. And we will remove the xfail
after we support the register overlap in GCC-15.
62685890d88 RISC-V: Support highpart overlap for vext.vf
The below test suites are passed for this patc
On Apr 22, 2024, at 2:56 AM, Alexandre Oliva wrote:
>
> This patch takes feedback received for 3 earlier patches, and adopts a
> simpler approach to skip the still-failing tests, that I believe to be
> in line with ppc maintainers' expressed preferences.
> https://gcc.gnu.org/pipermail/gcc-patche
Yes, it's my typo.
Thanks.
Gui Haochen
在 2024/4/23 17:10, rep.dot@gmail.com 写道:
> On 12 April 2024 07:30:10 CEST, HAO CHEN GUI wrote:
>
>
>>
>>
>> patch.diff
>> diff --git a/gcc/gimple-range-op.cc b/gcc/gimple-range-op.cc
>> index 9de130b4022..99c511728d3 100644
>> --- a/gcc/gimple-range-o
On Tue, 2024-04-23 at 17:45 +0200, Jakub Jelinek wrote:
> On Tue, Apr 23, 2024 at 11:40:55AM -0400, David Malcolm wrote:
> > > So, I think at least for the MAJOR.MINOR.0 releases we want to
> > > use
> > > URLs like above rather than the trunk ones and we can use the
> > > same
> > > process
> > >
On 4/23/24 11:28, Patrick Palka wrote:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
Is the test being run for multiple standard levels? I'd rather restrict
it to one and keep fully testing GC-safety.
-- >8 --
The below testcase uses --param=ggc-min-expand=0 which forces a f
> On Apr 23, 2024, at 15:51, Joseph Myers wrote:
>
> On Fri, 19 Apr 2024, Qing Zhao wrote:
>
>> gcc/c/ChangeLog:
>>
>> * c-decl.cc (finish_struct): Change errors to pedwarns for the cases
>> flexible array members in union or alone in structures.
>
> The C front-end changes are OK
Ping for the middle-end change approval.
And an update on the status of the patch set:
**Approval status:
All C FE changes have been approved.
**Review status:
All Middle-end changes have been reviewed by Sid, no remaining issue.
Okay for GCC15?
thanks.
Qing
> On Apr 12, 2024, at
On Fri, 19 Apr 2024, Qing Zhao wrote:
> gcc/c/ChangeLog:
>
> * c-decl.cc (finish_struct): Change errors to pedwarns for the cases
> flexible array members in union or alone in structures.
The C front-end changes are OK for GCC 15 once everything else in the
series is ready for inclu
> On Apr 23, 2024, at 14:53, Joseph Myers wrote:
>
> On Fri, 19 Apr 2024, Qing Zhao wrote:
>
>> gcc/testsuite/ChangeLog:
>>
>> * gcc.dg/flex-array-in-union-1.c: New test.
>> * gcc.dg/flex-array-in-union-2.c: New test.
>
> There should also be a -pedantic-errors test that these con
> On Apr 23, 2024, at 15:03, Joseph Myers wrote:
>
> On Tue, 23 Apr 2024, Qing Zhao wrote:
>
>> However, I am not very confident on the wording of the doc, is the
>> current wording good enough for this? Or do you have any suggestion on
>> how to make it better?
>
> I'm not convinced the s
Hi Marc and all that are involved,
On 4/18/24 15:24, Marc Poulhiès wrote:
> Co-authored-by: Fernando Oleo Blanco
> ---
> Hello Fernando,
>
> Thanks again for your changes. After consulting other colleagues, I'm
> proposing this revised version.
> Does that look ok to you?
>
> As it was simpler
On Tue, 23 Apr 2024, Qing Zhao wrote:
> However, I am not very confident on the wording of the doc, is the
> current wording good enough for this? Or do you have any suggestion on
> how to make it better?
I'm not convinced the statement about size (in relation to a structure
with the member om
On Fri, 19 Apr 2024, Qing Zhao wrote:
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/flex-array-in-union-1.c: New test.
> * gcc.dg/flex-array-in-union-2.c: New test.
There should also be a -pedantic-errors test that these constructs get
errors with -pedantic-errors.
The tests mix two case
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
The below testcase uses --param=ggc-min-expand=0 which forces a full GC
during every collection point and in turn takes over two minutes to run
and ends up being the main bottleneck of the modules.exp testsuite.
This patch spee
> On Apr 23, 2024, at 14:04, Joseph Myers wrote:
>
> On Fri, 19 Apr 2024, Qing Zhao wrote:
>
>> +The size of the union is as if the flexiable array member were omitted
>> +except that it may have more trailing padding than the omission would imply.
>
> "trailing padding" is more a concept for
On Fri, 19 Apr 2024, Qing Zhao wrote:
> +The size of the union is as if the flexiable array member were omitted
> +except that it may have more trailing padding than the omission would imply.
"trailing padding" is more a concept for structures than for unions (where
padding depends on which unio
On Tue, Apr 23, 2024 at 5:50 PM Jakub Jelinek wrote:
>
> Hi!
>
> As discussed in the PR, on ia32 with its 8 GPRs, where 1 is always fixed
> and other 2 often are as well having an alternative which needs 3
> double-word registers is just too much for RA.
> The following patch splits that alternati
On 4/23/24 09:41, Patrick Palka wrote:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
When merging an imported function template specialization with an
existing one, if the existing one has an undeduced return type and the
imported one's is already deduced, we need to prop
On Tue, Apr 23, 2024 at 7:24 AM Jakub Jelinek wrote:
>
> What we could do is drop the HAVE_COMPRESSED_DEBUG stuff altogether, and
> instead similarly how we have HAVE_COMPRESSED_DEBUG_ZSTD have
> HAVE_COMPRESSED_DEBUG_{ZLIB,ZLIB_GABI,ZLIB_GNU} and for each of those
> if linker supports them test w
On Tue, 23 Apr 2024 07:45:03 PDT (-0700), Patrick O'Neill wrote:
Hi Pan,
Sorry about that. It looks like there was difference between my local
machine and CI machine.
From the CI it looks like we're back to the failure list we had on friday.
I'll do some local testing to manually confirm this
On Tue, 23 Apr 2024, Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> -- >8 --
>
> When merging an imported function template specialization with an
> existing one, if the existing one has an undeduced return type and the
> imported one's is already deduced,
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
When merging an imported function template specialization with an
existing one, if the existing one has an undeduced return type and the
imported one's is already deduced, we need to propagate the deduced type
since once we inst
On Mon, Apr 22, 2024 at 11:14:35PM -0400, Jason Merrill wrote:
> > > The following testcase regressed with Marek's r14-5979 change,
> > > when pr113208_0.C is compiled where the ctor is marked constexpr,
> > > we no longer perform this optimization, where
> > > _ZN6vectorI12QualityValueEC2ERKS1_ wa
On Mon, Apr 15, 2024 at 02:19:36PM +0200, Jakub Jelinek wrote:
> They weren't the same, one was trying to evaluate the convert_from_reference
> with vc_glvalue, the other evaluates it without that and with vc_prvalue.
> Now, I guess the
> + /* Undo convert_for_arg_passing work here. */
> +
Hi!
As discussed in the PR, on ia32 with its 8 GPRs, where 1 is always fixed
and other 2 often are as well having an alternative which needs 3
double-word registers is just too much for RA.
The following patch splits that alternative into two, one with o is used
even on ia32, but one with the 3x r
On Tue, Apr 23, 2024 at 11:40:55AM -0400, David Malcolm wrote:
> > So, I think at least for the MAJOR.MINOR.0 releases we want to use
> > URLs like above rather than the trunk ones and we can use the same
> > process
> > of updating *.opt.urls as well for that.
>
> Would it make sense to instead u
Hi!
The nullability-00.m* tests unfortunately check the exact spelling of
the diagnostics I've changed earlier today.
Tested on x86_64-linux and i686-linux, committed to trunk as obvious.
2024-04-23 Jakub Jelinek
* objc.dg/attributes/nullability-00.m: Adjust expected diagnostic
On Wed, 2024-04-17 at 13:16 +0200, Jakub Jelinek wrote:
> Hi!
>
> Starting with GCC 14 we have the nice URLification of the options
> printed
> in diagnostics, say for in
> test.c:4:23: warning: format ‘%d’ expects argument of type ‘int’, but
> argument 2 has type ‘long int’ [-Wformat=]
> the -Wfo
On Mon, 22 Apr 2024, Alexandre Oliva wrote:
> [Revamped version of this patch, combined with others, to follow]
>
> On Mar 10, 2021, Hans-Peter Nilsson wrote:
Time flies...
> > On Wed, 10 Mar 2021, Alexandre Oliva wrote:
> Is mmix a sqrt_insn effective target? proc
> check_effective_target_sq
Hi All,
Jakub pinpointed the source of this bug in comment 6 of the PR. The rest
was 'obvious' :-)
I plan to push the patch to mainline in the next 24 hours unless there are
opinions to the contrary. Backporting is proposed to occur a couple of
weeks later.
Best regards
Paul
Fortran: Generate
Hi Pan,
Sorry about that. It looks like there was difference between my local
machine and CI machine.
From the CI it looks like we're back to the failure list we had on friday.
I'll do some local testing to manually confirm this.
Thanks,
Patrick
On 4/22/24 23:50, Li, Pan2 wrote:
Hi Patric
On 4/21/24 19:59, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This fixes a null dereference issue when decl_specifiers.type is not yet
provided.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_parameter_declaration): Check if
decl_sp
On Tue, Apr 23, 2024 at 04:18:49PM +0200, Jakub Jelinek wrote:
> Then you have two tests (ctestg and ctesta) doing exactly the same thing,
> that can't be right.
> I guess it might be fine to use zlib when it is an alias to zlib-gabi,
> but zlib-gnu shouldn't be replaced.
>
> I must say I don't re
On Tue, Apr 23, 2024 at 04:05:07PM +0200, Rainer Orth wrote:
> I noticed that libbacktrace make check FAILs on Solaris with the native
> ld already when building the tests:
>
> libtool: link: /var/gcc/regression/master/11.4-gcc/build/./gcc/xgcc
> -B/var/gcc/r
> egression/master/11.4-gcc/build/./g
I noticed that libbacktrace make check FAILs on Solaris with the native
ld already when building the tests:
libtool: link: /var/gcc/regression/master/11.4-gcc/build/./gcc/xgcc -B/var/gcc/r
egression/master/11.4-gcc/build/./gcc/ -B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/
vol/gcc/sparc-sun-solaris2.1
Hi,
we have:
-ftree-loop-distribute-patterns
Perform loop distribution of patterns that can be code generated
with calls to a library. This flag is enabled by default at -O2 and higher,
and by -fprofile-use and -fauto-profile.
This pass distributes the initializati
On Tue, Apr 23, 2024 at 11:32:08AM +0100, Jonathan Wakely wrote:
> On Mon, 22 Apr 2024 at 22:30, Jakub Jelinek wrote:
> Yup:
> https://gcc.gnu.org/codingconventions.html#Spelling
>
> That spelling is explicitly mentioned at the link above, so they
> should be "ize" really.
Ok. I've committed th
On Thu, Nov 23, 2023 at 11:01 PM Richard Sandiford
wrote:
>
> Manolis Tsamis writes:
> > The existing implementation of need_cmov_or_rewire and
> > noce_convert_multiple_sets_1 assumes that sets are either REG or SUBREG.
> > This commit enchances them so they can handle/rewire arbitrary set
> >
On Thu, Oct 19, 2023 at 10:46 PM Richard Sandiford
wrote:
>
> Manolis Tsamis writes:
> > Currently the operations allowed for if conversion of a basic block with
> > multiple sets are few, namely REG, SUBREG and CONST_INT (as controlled by
> > bb_ok_for_noce_convert_multiple_sets).
> >
> > This c
On Thu, Oct 19, 2023 at 10:41 PM Richard Sandiford
wrote:
>
> Manolis Tsamis writes:
> > This is an extension of what was done in PR106590.
> >
> > Currently if a sequence generated in noce_convert_multiple_sets clobbers the
> > condition rtx (cc_cmp or rev_cc_cmp) then only seq1 is used afterwar
Currently the operations allowed for if conversion of a basic block with
multiple sets are few, namely REG, SUBREG and CONST_INT (as controlled by
bb_ok_for_noce_convert_multiple_sets).
This commit allows more operations (arithmetic, compare, etc) to participate
in if conversion. The target's prof
The existing implementation of need_cmov_or_rewire and
noce_convert_multiple_sets_1 assumes that sets are either REG or SUBREG.
This commit enchances them so they can handle/rewire arbitrary set statements.
To do that a new helper struct noce_multiple_sets_info is introduced which is
used by noce_
This is an extension of what was done in PR106590.
Currently if a sequence generated in noce_convert_multiple_sets clobbers the
condition rtx (cc_cmp or rev_cc_cmp) then only seq1 is used afterwards
(sequences that emit the comparison itself). Since this applies only from the
next iteration it ass
noce_convert_multiple_sets has been introduced and extended over time to handle
if conversion for blocks with multiple sets. Currently this is focused on
register moves and rejects any sort of arithmetic operations.
This series is an extension to allow more sequences to take part in if
conversio
The original motivation for this pattern was that the following function does
not fold to 'return 1':
int foo(int *a, int j)
{
int k = j - 1;
return a[j - 1] == a[k];
}
The expression ((unsigned long) (X +- C1) * C2) appears frequently as part of
address calculations (e.g. arrays). These patt
On Mon, 22 Apr 2024 at 22:30, Jakub Jelinek wrote:
>
> Hi!
>
> I've run aspell on gcc.pot (just quickly skimming, so pressing
> I key hundreds of times and just stopping when I catch something that
> looks like a misspelling).
>
> I plan to commit this tomorrow as obvious unless somebody finds som
Hi Folks,
> On 23 Apr 2024, at 09:59, Kewen.Lin wrote:
>
> Hi,
>
> on 2024/4/22 17:56, Alexandre Oliva wrote:
>> This patch takes feedback received for 3 earlier patches, and adopts a
>> simpler approach to skip the still-failing tests, that I believe to be
>> in line with ppc maintainers' expr
On 12 April 2024 07:30:10 CEST, HAO CHEN GUI wrote:
>
>
>patch.diff
>diff --git a/gcc/gimple-range-op.cc b/gcc/gimple-range-op.cc
>index 9de130b4022..99c511728d3 100644
>--- a/gcc/gimple-range-op.cc
>+++ b/gcc/gimple-range-op.cc
>@@ -1192,6 +1192,56 @@ public:
> }
> } op_cfn_isinf;
>
>+//Imple
Hi,
on 2024/4/22 17:56, Alexandre Oliva wrote:
> This patch takes feedback received for 3 earlier patches, and adopts a
> simpler approach to skip the still-failing tests, that I believe to be
> in line with ppc maintainers' expressed preferences.
> https://gcc.gnu.org/pipermail/gcc-patches/2021-F
Hi,
on 2024/4/22 18:00, Alexandre Oliva wrote:
> On Mar 10, 2021, Joseph Myers wrote:
>
>> On Wed, 10 Mar 2021, Alexandre Oliva wrote:
>>> operand exception for quiet NaN. I couldn't find any evidence that
>>> the rs6000 backend ever outputs fcmpo. Therefore, I'm adding the same
>>> execution
Hi Arthur,
> On 4/17/24 10:13, Rainer Orth wrote:
>> Andrew Pinski writes:
>>
>>> On Mon, Apr 8, 2024 at 9:39 AM wrote:
From: Pierre-Emmanuel Patry
Hello,
The rust frontend requires cargo to build some of it's components,
it's presence was not checked during
The requirements of the vec_xl/vec_xst intrinsincs wrt aliasing of the
pointer argument are not really documented. As it turns out, users
are likely to get it wrong. With this patch we let the pointer
argument alias everything in order to make it more robust for users.
Committed to mainline. Wil
The following plugs a hole with computing whether a SLP node has any
pattern stmts which is important to know when we want to replace it
by a CTOR from external defs.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/114799
* tree-vect-slp.cc (vect_
58 matches
Mail list logo
