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
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
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.
>
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
>> ---
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
> 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
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,
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
> 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
> 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
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
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
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
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
> 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
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
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
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
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
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
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
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_
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
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
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
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
>
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
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
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
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
>
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/
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
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
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
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
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
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
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
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
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
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
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'
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;
>
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.
>
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.
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
on 2024/4/22 17:35, Alexandre Oliva wrote:
> Ping?
> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/593947.html
>
>
> vec-mul is an execution test, but it only requires a powerpc_vsx_ok
> effective target, which is enough only for compile tests. In order to
> To check for runtime and
Hi Patrick,
After some investigation and double confirm, I think the
gcc.dg/graphite/pr111878.c ice may have nothing to do
with the patches of revert series as it exists for quit a while. It may related
to below commit
2e7abd09621a4401d44f4513adf126bce4b4828b RISC-V: Block VLSmodes according
on 2024/4/22 17:31, Alexandre Oliva wrote:
>
> From: Olivier Hainque
>
> Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu. Also tested with
> gcc-13 on ppc64-vx7r2 and ppc-vx7r2. Ok to install?
OK, thanks!
BR,
Kewen
>
> for gcc/testsuite/ChangeLog
>
> *
on 2024/4/22 17:27, Alexandre Oliva wrote:
> Ping?
> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566524.html
>
> The loop we're supposed to try to vectorize in
> gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c is turned into a memset
> before the vectorizer runs.
>
> Various other tests
on 2024/4/22 17:23, Alexandre Oliva wrote:
>
> These ppc lp64 tests check for errors or warnings on -mno-powerpc64.
> On powerpc64-*-vxworks* we get the same errors as on most other
> covered platforms, but the tests did not mark them as expected for
> this target. On powerpc-*-vxworks*, the
60 matches
Mail list logo
