Hi!
My patch to save/restore opts_set rather than essentially treating
global_options_set as a logical or whether some option has ever been
explicitly set somewhere apparently broke -mcmodel= vs. target attribute
(and as the patch shows some other options too).
The thing is, at least for options f
On 1/8/21 1:17 AM, Ilya Leoshkevich wrote:
> + s390_def_or_undef_macro (
> + pfile,
> + [] (const struct cl_target_option *opts) { return TARGET_Z14_P (opts);
> },
> + old_opts, opts, "__LONG_DOUBLE_VX__", "__LONG_DOUBLE_VX__");
Shouldn't this rather check TARGET_VXE_P instead?
On Fri, Jan 8, 2021 at 9:24 AM Jakub Jelinek wrote:
>
> Hi!
>
> My patch to save/restore opts_set rather than essentially treating
> global_options_set as a logical or whether some option has ever been
> explicitly set somewhere apparently broke -mcmodel= vs. target attribute
> (and as the patch s
On Thu, 7 Jan 2021, Sergei Trofimovich wrote:
> From: Sergei Trofimovich
>
> * ipa-modref.c (merge_call_side_effects): Fix
> linebreak split by reordering two print calls.
OK.
Richard.
> ---
> gcc/ipa-modref.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>
On Jan 7, 2021, Bernd Edlinger wrote:
> I don't know why that is there in the first place, as there
> are no C++ test cases, these files should not be created at all.
collect2, on platforms that use it, create .cdtor files even for C.
David Edelsohn told me so back then; the problem was on AIX
On Fri, 8 Jan 2021, 00:50 Paul Fee via Libstdc++,
wrote:
> Derived from the changes that added C++2a support in 2017.
> https://gcc.gnu.org/g:026a79f70cf33f836ea5275eda72d4870a3041e5
>
> No C++2b features are added here.
> Use of -std=c++2b sets __cplusplus to 202101L.
>
I wonder if 202100L woul
> Since R10 is preserved when calling mcount, R10 can be used a scratch
> register to call mcount in large model.
Please mention that R10 can be used as a static chain registers and is
preserved when calling mcount for nested functions.
> gcc/
>
> PR target/98482
> * config/i386/i386.c (x86_funct
On Fri, Jan 08, 2021 at 12:48:51AM +, Paul Fee via Gcc-patches wrote:
> Derived from the changes that added C++2a support in 2017.
> https://gcc.gnu.org/g:026a79f70cf33f836ea5275eda72d4870a3041e5
>
> No C++2b features are added here.
> Use of -std=c++2b sets __cplusplus to 202101L.
What Jon w
Hi All,
This fixes a logical inconsistency with the SVE2 ACLE tests where the SVE2 tests
are checking for SVE support in the assembler instead of SVE2.
This makes all these tests fail when the user has an SVE enabled assembler but
not an SVE2 one.
Ok for master?
Thanks,
Tamar
gcc/testsuite/Cha
On Mon, 28 Dec 2020, Tamar Christina wrote:
> Hi All,
>
> This adds support for complex multiply and complex multiply and accumulate to
> the vect pattern detector.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu
> and no issues.
>
> Ok for master?
>
> Thanks,
> Tamar
On Mon, 28 Dec 2020, Tamar Christina wrote:
> Hi All,
>
> This adds support for FMA and FMA conjugated to the slp pattern matcher.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu
> and no issues.
>
> Ok for master?
>
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> *
On Mon, 28 Dec 2020, Tamar Christina wrote:
> Hi All,
>
> This adds support for FMS and FMS conjugated to the slp pattern matcher.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu
> and no issues.
>
> Ok for master?
Interestingly this patch looks different from the FMA
On Mon, 28 Dec 2020, Tamar Christina wrote:
> Hi All,
>
> This introduces a common class complex_operations_pattern which encapsulates
> the complex add, mul, fma and fms pattern in such a way so that the first
> match
> is shared.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc
Hi Christophe,
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 17 December 2020 17:48
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 1/3] arm: Add movmisalign patterns for MVE (PR
> target/97875)
>
> This patch adds new movmisalign_mve_loa
Tamar Christina writes:
> Hi All,
>
> This fixes a logical inconsistency with the SVE2 ACLE tests where the SVE2
> tests
> are checking for SVE support in the assembler instead of SVE2.
>
> This makes all these tests fail when the user has an SVE enabled assembler but
> not an SVE2 one.
>
> Ok fo
Hi Richi,
> -Original Message-
> From: Richard Biener
> Sent: Friday, January 8, 2021 9:45 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; o...@ucw.cz
> Subject: Re: [PATCH 6/8 v9]middle-end slp: support complex FMA and
> complex FMA conjugate
>
> On Mon, 28 Dec 2020, Tamar
> -Original Message-
> From: Richard Biener
> Sent: Friday, January 8, 2021 9:49 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH 7/8 v9]middle-end slp: support complex FMS and
> complex FMS conjugate
>
> On Mon, 28 Dec 2020, Tamar Christina wrote:
>
>
On Fri, 8 Jan 2021, Tamar Christina wrote:
> Hi Richi,
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Friday, January 8, 2021 9:45 AM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; o...@ucw.cz
> > Subject: Re: [PATCH 6/8 v9]middle-end slp: support complex FMA
> -Original Message-
> From: Richard Biener
> Sent: Friday, January 8, 2021 10:17 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; o...@ucw.cz
> Subject: RE: [PATCH 6/8 v9]middle-end slp: support complex FMA and
> complex FMA conjugate
>
> On Fri, 8 Jan 2021, Tamar Christin
Hi all,
Sometime ago we changed the RTL representation of the (SU)ABD instructions in
RTL to
a (MINUS (MAX) (MIN)) rather than a (MINUS (ABS) (ABS)) as it is more correctly
models the semantics.
We should do the same for the accumulation forms of these instructions:
UABA/SABA.
This patch does
Hi all,
This patch reimplements the vaba* arm_neon.h intrinsics using RTL builtins that
expand to proper RTL patterns
rather than using inline asm.
The implementation is fairly straightforward by defining new builtins and using
them in the header.
Bootstrapped and tested on aarch64-none-linux-g
Hi all,
This patch reimplements the vabd* intrinsics using RTL builtins.
It's fairly straightforward with new builtins + arm_neon.h changes.
Bootstrapped and tested on aarch64-none-linux-gnu.
Pushing to trunk.
Thanks,
Kyrill
gcc/
* config/aarch64/aarch64-simd.md (aarch64_abd_3): Rename t
Hi all,
This patch reimplements most of the vpadal intrinsics to use RTL builtins in
the normal way.
The ones that aren't converted are the int32x2_t -> int64x1_t ones as the RTL
pattern doesn't currently handle
these modes. We don't have a V1DI mode so it would need to return a DImode
value or
This patch extends the conditional UXT patterns from SVE_FULL_I
to SVE_I. It doesn't matter in this case whether the type suffix
is taken from the element size or the container size.
Tested on aarch64-linux-gnu and aarch64_be-elf, pushed to trunk.
Richard
gcc/
* config/aarch64/aarch64-
This patch adds unpacked support for unconditional and
conditional CNOT. The type suffix has to be taken from
the element size rather than the container size.
Tested on aarch64-linux-gnu and aarch64_be-elf. Pushed to trunk.
Richard
gcc/
* config/aarch64/aarch64-sve.md (*cnot): Extend
Qian Jianhua writes:
> This patch add cost tables for A64FX.
>
> ChangeLog:
> 2021-01-08 Qian jianhua
>
> gcc/
> * config/aarch64/aarch64-cost-tables.h (a64fx_extra_costs): New.
> * config/aarch64/aarch64.c (a64fx_addrcost_table): New.
> (a64fx_regmove_cost, a64fx_vector_cost):
On Fri, 8 Jan 2021 at 10:50, Kyrylo Tkachov wrote:
>
> Hi Christophe,
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of
> > Christophe Lyon via Gcc-patches
> > Sent: 17 December 2020 17:48
> > To: gcc-patches@gcc.gnu.org
> > Subject: [PATCH 1/3] arm: Add movmisalign patterns for
Remove fallout from commit 0bd675183d94 ("match.pd: Add ~(X - Y) -> ~X
+ Y simplification [PR96685]") and paper over the regression caused as
it is not the matter of the test cases affected.
Previously assembly like this:
.text
.align 1
.globl eq_notsi
.type eq_notsi,
On Fri, Jan 8, 2021 at 1:24 AM Uros Bizjak wrote:
>
> > Since R10 is preserved when calling mcount, R10 can be used a scratch
> > register to call mcount in large model.
>
> Please mention that R10 can be used as a static chain registers and is
> preserved when calling mcount for nested functions.
Permute nodes are not transparent to the permute of their children.
Instead we have to materialize child permutes always and in future
may treat permute nodes as the source of arbitrary permutes as
we can permute the lane permutation vector at will (as the target
supports in the end).
Bootstrapped
v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563034.html
v1 -> v2: Use TARGET_VXE_P instead of TARGET_Z14_P.
Give end users the opportunity to find out whether long doubles are
stored in floating-point register pairs or in vector registers, so that
they could fine-tune their asm st
On Fri, Jan 8, 2021 at 4:50 AM H.J. Lu wrote:
>
> On Fri, Jan 8, 2021 at 1:24 AM Uros Bizjak wrote:
> >
> > > Since R10 is preserved when calling mcount, R10 can be used a scratch
> > > register to call mcount in large model.
> >
> > Please mention that R10 can be used as a static chain registers
This plugs two memleaks in the vectorizer.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2021-01-08 Richard Biener
* tree-vect-slp.c (scalar_stmts_to_slp_tree_map_t): Fix.
(vect_build_slp_tree): On cache hit release the matched
scalar stmts v
When running FRE in the loop pipeline (as part of the conditionally
scheduled scalar cleanups) we have to reset the SCEV hashtable as
otherwise we can end up with stale entries and all sorts of problems.
Catched by my out-of-tree verifier for this problem.
Bootstrap & regtest pending on x86_64-un
On Thu, Jan 7, 2021 at 5:18 PM Bernd Edlinger wrote:
>
> Hi,
>
> On 1/7/21 5:12 PM, Rainer Orth wrote:
> > The unsetenv needs to be wrapped in
> >
> > if [info exists env(MAKEFLAGS)] {
> >
>
> Done.
>
> > @@ -163,6 +167,9 @@ proc outest { test sources opts dirs out
> > if { $ogl !=
The patch removes some memory leaks spotted by valgrind.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
* gimple-if-to-switch.cc (struct condition_info): Use auto_var.
(if_chain::is_beneficial): Delet
On Fri, Jan 8, 2021 at 2:28 PM H.J. Lu wrote:
>
> On Fri, Jan 8, 2021 at 4:50 AM H.J. Lu wrote:
> >
> > On Fri, Jan 8, 2021 at 1:24 AM Uros Bizjak wrote:
> > >
> > > > Since R10 is preserved when calling mcount, R10 can be used a scratch
> > > > register to call mcount in large model.
> > >
> >
On Fri, Jan 8, 2021 at 3:27 PM Martin Liška wrote:
>
> The patch removes some memory leaks spotted by valgrind.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
OK.
Richard.
> Thanks,
> Martin
>
>
> gcc/ChangeLog:
>
> * gimple-if-to-s
On Fri, Jan 8, 2021 at 6:31 AM Uros Bizjak wrote:
>
> On Fri, Jan 8, 2021 at 2:28 PM H.J. Lu wrote:
> >
> > On Fri, Jan 8, 2021 at 4:50 AM H.J. Lu wrote:
> > >
> > > On Fri, Jan 8, 2021 at 1:24 AM Uros Bizjak wrote:
> > > >
> > > > > Since R10 is preserved when calling mcount, R10 can be used a
> On Jan 7, 2021, at 8:50 PM, Maciej W. Rozycki wrote:
>
> ...
>
> Provide a new iterator to provide copies of FP substitutions across the
> FP modes supported as the substitutions now need to match the mode of
> the operands.
>
> gcc/
> * config/pdp11/pdp11.md (PDPfp): New mod
I think we should consider making this -std=c++23 right away this time,
since we're on a three-year release schedule. Up to Jason though.
Marek
On Thu, 7 Jan 2021, Jason Merrill wrote:
> On 1/7/21 5:47 PM, Patrick Palka wrote:
> > On Thu, 7 Jan 2021, Jason Merrill wrote:
> >
> > > On 1/6/21 1:19 PM, Patrick Palka wrote:
> > > > In the first testcase below, we incorrectly reject the use of the
> > > > protected non-static member A::var0 f
On Thu, 7 Jan 2021, Jason Merrill wrote:
> On 1/7/21 10:10 AM, Patrick Palka wrote:
> > We shouldn't do replace_result_decl after evaluating a call that returns
> > a PMF because PMF temporaries aren't wrapped in a TARGET_EXPR (and so we
> > can't trust ctx->object), and PMF initializers can't be
On 1/8/21 2:14 PM, Ilya Leoshkevich wrote:
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563034.html
> v1 -> v2: Use TARGET_VXE_P instead of TARGET_Z14_P.
>
>
>
> Give end users the opportunity to find out whether long doubles are
> stored in floating-point register pairs or in ve
Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
The destination register is only partially overwritten, so + should be
used instead of =.
gcc/ChangeLog:
2021-01-08 Ilya Leoshkevich
* config/s390/vector.md (*tf_to_fprx2_0): Rename from
*mov_tf_to_fprx2_0 fo
On Fri, Jan 8, 2021 at 6:43 AM H.J. Lu wrote:
>
> On Fri, Jan 8, 2021 at 6:31 AM Uros Bizjak wrote:
> >
> > On Fri, Jan 8, 2021 at 2:28 PM H.J. Lu wrote:
> > >
> > > On Fri, Jan 8, 2021 at 4:50 AM H.J. Lu wrote:
> > > >
> > > > On Fri, Jan 8, 2021 at 1:24 AM Uros Bizjak wrote:
> > > > >
> > >
On 1/8/21 5:35 PM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
>
> The destination register is only partially overwritten, so + should be
> used instead of =.
>
> gcc/ChangeLog:
>
> 2021-01-08 Ilya Leoshkevich
>
> * config/s390/vect
On Thu, Nov 12, 2020, 21:55 Antony Polukhin wrote:
> Final bits for libstdc/71579
>
Gentle reminder on last patch
>
Hi,
I stumbled across PR 47059 from 2010 which has been addressed by
store-merging. I am going to close it but would like to add its
testcase too.
OK for trunk?
Thanks,
Martin
gcc/testsuite/ChangeLog:
2021-01-08 Martin Jambor
PR tree-optimization/47059
* gcc.dg/tree-ssa/
On 06/01/21 19:41 -0500, David Edelsohn wrote:
Thanks for clarifying the issue.
As you implicitly point out, GCC knows the type of INT64 and defines
the macro __INT64_TYPE__ . The revised code can use that directly,
such as:
#if defined(_GLIBCXX_HAVE_INT64_T_LONG) \
|| defined(_GLIBCXX_HAVE
On Fri, Jan 08, 2021 at 06:37:03PM +, Jonathan Wakely wrote:
> This uses __INT64_TYPE__ if that's defined, and long long otherwise. I
> think that should be equivalent in all practical cases (I can imagine
> some strange target where __INT64_TYPE__ is defined by the compiler,
> but int64_t isn'
On 1/8/21 3:23 PM, David Edelsohn wrote:
> On Thu, Jan 7, 2021 at 5:18 PM Bernd Edlinger
> wrote:
>>
>> Hi,
>>
>> On 1/7/21 5:12 PM, Rainer Orth wrote:
>>> The unsetenv needs to be wrapped in
>>>
>>> if [info exists env(MAKEFLAGS)] {
>>>
>>
>> Done.
>>
>>> @@ -163,6 +167,9 @@ proc outest { test
On 1/7/21 11:47 AM, Jakub Jelinek wrote:
In GCC10 cp_walk_subtrees has been changed to walk template arguments.
As the following testcase, that changed the mangling of some functions.
Argh.
I believe the previous behavior that find_abi_tags_r doesn't recurse into
template args has been the co
Hi, Bernd
Thanks for investigating this and creating a revised version of the
patch. With the second patch, the gcc.misc-test/outputs.exp results
are clean on AIX.
Thanks, David
On Fri, Jan 8, 2021 at 1:59 PM Bernd Edlinger wrote:
>
> On 1/8/21 3:23 PM, David Edelsohn wrote:
> > On Thu, Jan 7,
On Fri, Jan 08, 2021 at 02:22:59PM -0500, Jason Merrill wrote:
> I like the idea to use *walk_subtrees to distinguish between walking
> syntactic subtrees and walking type-identity subtrees. But it should be
> more general; how does this look to you?
LGTM, thanks.
> diff --git a/gcc/cp/class.c b
Hi,
Is there an utility routine in GCC to query the pointer width of the current
target? Whether it’s 32bit pointer or 64 bit pointer for the target?
Thanks a lot for the help.
Qing
On 1/8/21 5:49 AM, Maciej W. Rozycki wrote:
> Remove fallout from commit 0bd675183d94 ("match.pd: Add ~(X - Y) -> ~X
> + Y simplification [PR96685]") and paper over the regression caused as
> it is not the matter of the test cases affected.
>
> Previously assembly like this:
>
> .text
>
On 1/7/21 6:50 PM, Maciej W. Rozycki wrote:
> Handle machine mode specification with `const_double_zero' and handle
> the rtx with callable code produced from named insns. Complementing
> commit 20ab43b5cad6 ("RTL: Add `const_double_zero' syntactic rtx") and
> removing a commit c60d0736dff7
On 1/7/21 6:50 PM, Maciej W. Rozycki wrote:
> For predictable semantics propagate the mode from operands referred by
> the FP substitution to the `const_double_zero' expressions used with the
> associated condition code calculation. Use an iterator to make copies
> of the FP substitution acr
On 1/7/21 6:51 PM, Maciej W. Rozycki wrote:
> Remove the `cc' mode attribute that duplicates the implicitly defined
> `mode' attribute. No change to semantics.
>
> gcc/
> * config/vax/vax.md (cc): Remove mode attribute.
> (subst_, subst_f): Rename to...
> (subst_, subst
On 1/8/21 12:55 PM, Qing Zhao via Gcc-patches wrote:
> Hi,
>
> Is there an utility routine in GCC to query the pointer width of the current
> target? Whether it’s 32bit pointer or 64 bit pointer for the target?
>
> Thanks a lot for the help.
You can look at the GET_MODE_SIZE (Pmode) or POINTER
On 1/7/21 9:14 AM, Martin Liška wrote:
> On 1/6/21 12:36 AM, Jeff Law wrote:
>> unresolved "could not find python interpreter $testcase" in
>> run-gcov-pytest if you find the right magic in the output of your spawn.
>
> Achieved that with the updated patch.
>
> Ready for master?
> Thanks,
> Mart
On Fri, Jan 8, 2021 at 12:15 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 1/8/21 12:55 PM, Qing Zhao via Gcc-patches wrote:
> > Hi,
> >
> > Is there an utility routine in GCC to query the pointer width of the
> > current target? Whether it’s 32bit pointer or 64 bit pointer for the target?
> >
>
On Fri, Jan 8, 2021 at 1:52 PM Jakub Jelinek wrote:
>
> On Fri, Jan 08, 2021 at 06:37:03PM +, Jonathan Wakely wrote:
> > This uses __INT64_TYPE__ if that's defined, and long long otherwise. I
> > think that should be equivalent in all practical cases (I can imagine
> > some strange target wher
On 1/5/21 8:12 PM, Kewen.Lin wrote:
> on 2021/1/6 上午2:19, Jeff Law wrote:
>>
>> On 1/4/21 7:36 PM, Kewen.Lin wrote:
>>> Hi Jeff,
>>>
>>> on 2021/1/5 上午7:13, Jeff Law wrote:
On 12/22/20 11:40 PM, Kewen.Lin via Gcc-patches wrote:
> Hi Segher,
>
> on 2020/12/22 下午9:55, Segher Boess
Hi,
The armv8_arm manual [C6.2.226, ROR (immediate)] uses a # in front
of the immediate rotation quantity.
Although, it seems, GAS is able to infer the # (or is leninent about
its absence) assemblers based on the LLVM back end expect it and error out.
tested on aarch64-linux-gnu (gcc115) and aar
On 1/7/21 5:53 PM, Martin Sebor via Gcc-patches wrote:
> In PR 98097 Richard expects -Wstring-compare for a call to strcmp()
> with a member array and a string literal of larger size, used in
> an equality test.
>
> In virtually all cases the test will indicate the two are unequal
> because the
Hi Jason,
Thank you!
> To start with, do you have a copyright assignment on file or in the
> works already?
Good point. I incorrectly assumed it would only be a minor
contribution copyright-wise. Mr Edelsohn gave me a template which I've
now filled out and sent to ass...@gnu.org. I'm assuming I
68 matches
Mail list logo
