Hi Segher,
Thanks for the comments!
on 2021/9/7 上午7:43, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Jul 28, 2021 at 10:59:50AM +0800, Kewen.Lin wrote:
+/* As a visitor function for each statement cost entry handled in
+ function add_stmt_cost, gather some information and update its
>
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572555.html
BR,
Kewen
on 2021/7/15 上午10:00, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> Gentle ping this:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572555.html
>
> BR,
> Kewen
>
> on 2021/6/28 下午3:00, Kew
On 9/7/21 22:41, Hans-Peter Nilsson wrote:
With r12-3379, the testsuite got such a fatal syntax error,
causing the gcc test-run to abort at (e.g.):
Thank you for the fix! I haven't noticed the problem as I only grep for '^FAIL'
lines in the corresponding log files.
Cheers,
Martin
Hi!
As the testcase shows, we miscompile @xorsign3_1 if both input
operands are in the same register, because the splitter overwrites op1
before with op1 & mask before using op0.
For dest = xorsign op0, op0 we can actually simplify it from
dest = (op0 & mask) ^ op0 to dest = op0 & ~mask (aka abs)
Hi!
Power ISA 2.07 (Power8) introduces transactional memory feature
but ISA3.1 (Power10) removes it. It exposes one troublesome
issue as PR102059 shows. Users define some function with
target pragma cpu=power10 then it calls one function with
attribute always_inline which inherits command line o
On 07/09/2021 15:35, Richard Earnshaw wrote:
On 07/09/2021 13:05, Christophe LYON wrote:
On 07/09/2021 11:42, Richard Earnshaw wrote:
On 07/09/2021 10:15, Christophe Lyon via Gcc-patches wrote:
At some point during the development of this patch series, it appeared
that in some cases the
on 2021/9/8 下午2:57, Kewen.Lin via Gcc-patches wrote:
> Hi Bill,
>
> Thanks for the review comments!
>
> on 2021/9/3 下午11:57, Bill Schmidt wrote:
>> Hi Kewen,
>>
>> Sorry that we lost track of this patch! The heuristic approach looks good.
>> It is limited in scope and won't kick in often, and
When running the testsuite under Windows, we noticed failures in
testcase which attempt to match compiler error messages containing the
name of the executable.
For instance, gcc.dg/analyzer/signal-4a.c tries to match 'cc1:' which
obviously fails when the executable is called cc1.exe.
This patch r
On Wed, Sep 08, 2021 at 10:37:17AM +0800, Hongtao Liu wrote:
> Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
> Ok for trunk?
>
> libgcc/ChangeLog:
>
> * config/i386/t-softfp: Compile __{mul,div}hc3 into
> libgcc_s.so.1.
I think this is ok, but not really useful until
For the testcase in PR101555 lookup_anon_field takes the majority
of parsing time followed by get_class_binding_direct/fields_linear_search
which is PR83309. The situation with anon aggregates is particularly
dire when we need to build accesses to their members and the anon
aggregates are nested.
On Wed, Sep 8, 2021 at 3:43 PM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> As the testcase shows, we miscompile @xorsign3_1 if both input
> operands are in the same register, because the splitter overwrites op1
> before with op1 & mask before using op0.
>
> For dest = xorsign op0, op0 we can
On Wed, Sep 8, 2021 at 5:09 PM Jakub Jelinek wrote:
>
> On Wed, Sep 08, 2021 at 10:37:17AM +0800, Hongtao Liu wrote:
> > Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
> > Ok for trunk?
> >
> > libgcc/ChangeLog:
> >
> > * config/i386/t-softfp: Compile __{mul,div}hc3 into
> >
On Wed, Sep 08, 2021 at 05:23:40PM +0800, Hongtao Liu wrote:
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> >
> Patch LGTM.
Thanks, committed.
> PS:
> I'm curious why we need the post_reload splitter @xorsign3_1
> for scalar mode, can't we just expand them into and/
On Tuesday, 7 September 2021 19:36:22 CEST Jason Merrill wrote:
> > case PAREN_EXPR:
> > - RETURN (finish_parenthesized_expr (RECUR (TREE_OPERAND (t, 0;
> > + if (REF_PARENTHESIZED_P (t))
> > + RETURN (finish_parenthesized_expr (RECUR (TREE_OPERAND (t, 0;
> > + else
> >
On Wed, Sep 8, 2021 at 5:33 PM Jakub Jelinek wrote:
>
> On Wed, Sep 08, 2021 at 05:23:40PM +0800, Hongtao Liu wrote:
> > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> > >
> > Patch LGTM.
>
> Thanks, committed.
>
> > PS:
> > I'm curious why we need the post_reload spli
Hi:
As decribed in PR, valign{d,q} can be used for vector extract one element.
For elements located in the lower 128 bits, only one instruction is needed,
so this patch only optimizes elements located above 128 bits.
The optimization is like:
- vextracti32x8 $0x1, %zmm0, %ymm0
- v
On Wed, Sep 08, 2021 at 06:00:50PM +0800, Hongtao Liu wrote:
> Yes, I think so.
> And I find paradoxical subreg like (subreg:V4SF (reg:SF)) are not
> allowed by validate_subreg until r11-621.
> That's why post_reload splitter is needed here.
Following seems to work for all the testcases I've find
On Wed, Sep 08, 2021 at 06:00:50PM +0800, Hongtao Liu wrote:
> And I find paradoxical subreg like (subreg:V4SF (reg:SF)) are not
> allowed by validate_subreg until r11-621.
My reading of the r11-621 change is that it allowed (subreg:V4SF (reg:V2SF) 0)
but that (subreg:V4SF (reg:SF) 0) has been val
On Wed, Sep 8, 2021 at 6:02 PM Jakub Jelinek wrote:
>
> On Wed, Sep 08, 2021 at 06:00:50PM +0800, Hongtao Liu wrote:
> > Yes, I think so.
> > And I find paradoxical subreg like (subreg:V4SF (reg:SF)) are not
> > allowed by validate_subreg until r11-621.
> > That's why post_reload splitter is neede
> From: Martin Liaka
> Date: Wed, 8 Sep 2021 09:29:52 +0200
> On 9/7/21 22:41, Hans-Peter Nilsson wrote:
> > With r12-3379, the testsuite got such a fatal syntax error,
> > causing the gcc test-run to abort at (e.g.):
>
> Thank you for the fix! I haven't noticed the problem as I only grep for
>
Hi Hans-Peter,
>> From: Martin Liaka
>> Date: Wed, 8 Sep 2021 09:29:52 +0200
>
>> On 9/7/21 22:41, Hans-Peter Nilsson wrote:
>> > With r12-3379, the testsuite got such a fatal syntax error,
>> > causing the gcc test-run to abort at (e.g.):
>>
>> Thank you for the fix! I haven't noticed the probl
Hi Jeff & Richard,
> If you can turn that example into a test, even if it's just in the
> aarch64 directory, that would be helpful
The second patch 2/2 has various tests for this as the cost model had to
be made more accurate for it to work.
>
> As mentioned in the 2/2 thread, I think we should
Slightly updated patch correcting some modes that were giving warnings.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
* config/aarch64/aarch64-simd.md (*aarch64_faddp_scalar,
*aarch64_addp_scalarv2di, *aarch64_faddp_
On Tue, 2021-09-07 at 16:18 +, Petter Tomner via Gcc-patches wrote:
> I realized I still managed to mess up some WS. I have attached a
> patch that is the same, except fixes the WS issue
> underneath.
>
> Regards, Petter
>
> + FOR_EACH_VEC_ELT (m_globals, i, global)
> + rest_of_decl_
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, August 31, 2021 7:38 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: Re: [PATCH 2/2]AArch64: Add better costing for vector constants
> and op
On 9/8/21 5:37 AM, Matthias Kretz wrote:
On Tuesday, 7 September 2021 19:36:22 CEST Jason Merrill wrote:
case PAREN_EXPR:
- RETURN (finish_parenthesized_expr (RECUR (TREE_OPERAND (t, 0;
+ if (REF_PARENTHESIZED_P (t))
+ RETURN (finish_parenthesized_expr (RECUR (TREE_OPERAND (t
On 9/8/21 5:13 AM, Richard Biener wrote:
For the testcase in PR101555 lookup_anon_field takes the majority
of parsing time followed by get_class_binding_direct/fields_linear_search
which is PR83309. The situation with anon aggregates is particularly
dire when we need to build accesses to their m
On Wednesday, 8 September 2021 15:44:28 CEST Jason Merrill wrote:
> On 9/8/21 5:37 AM, Matthias Kretz wrote:
> > On Tuesday, 7 September 2021 19:36:22 CEST Jason Merrill wrote:
> >>> case PAREN_EXPR:
> >>> - RETURN (finish_parenthesized_expr (RECUR (TREE_OPERAND (t, 0;
> >>> + if (REF
We cannot use r12 here, it is already in use as the GEP (for sibling
calls).
Committed to trunk. Will backport later, too.
Segher
2021-09-08 Segher Boessenkool
PR target/102107
* config/rs6000/rs6000-logue.c (rs6000_emit_epilogue): For ELFv2 use
r11 instead of r12 f
When testing for Nios II (gcc-testresults shows this for MIPS as
well), failures of gcc.dg/array-quals-1.c appear where a symbol was
found in .sdata rather than one of the expected sections.
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?a$ (found
a) has section ^\\.(const|r
On Wed, Sep 08, 2021 at 03:25:24PM +, Joseph Myers wrote:
> When testing for Nios II (gcc-testresults shows this for MIPS as
> well), failures of gcc.dg/array-quals-1.c appear where a symbol was
> found in .sdata rather than one of the expected sections.
>
> FAIL: gcc.dg/array-quals-1.c scan-a
On Tue, Sep 07, 2021 at 06:07:30PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Sep 07, 2021 at 03:12:36AM -0400, Michael Meissner wrote:
> > [PATCH] Fix SFmode subreg of DImode and TImode
> >
> > This patch fixes the breakage in the PowerPC due to a recent change in
> > SUBREG
> > behavio
Hi!
On Wed, Sep 08, 2021 at 08:42:44AM +0200, Richard Biener wrote:
> On Wed, Sep 8, 2021 at 1:08 AM Segher Boessenkool
> wrote:
> > The core of the problem is that subreg of pseudos has three meanings:
> > -- Paradoxical subregs;
> > -- Actual subregs;
> > -- "bit_cast" thingies: treat the
On Wed, Sep 8, 2021 at 1:10 PM Segher Boessenkool
wrote:
>
> Hi!
>
> On Wed, Sep 08, 2021 at 08:42:44AM +0200, Richard Biener wrote:
> > On Wed, Sep 8, 2021 at 1:08 AM Segher Boessenkool
> > wrote:
> > > The core of the problem is that subreg of pseudos has three meanings:
> > > -- Paradoxical
On September 8, 2021 7:08:09 PM GMT+02:00, Segher Boessenkool
wrote:
>Hi!
>
>On Wed, Sep 08, 2021 at 08:42:44AM +0200, Richard Biener wrote:
>> On Wed, Sep 8, 2021 at 1:08 AM Segher Boessenkool
>> wrote:
>> > The core of the problem is that subreg of pseudos has three meanings:
>> > -- Paradox
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-3422-ge66b9f6779f46433b0e2c093b58403604ed131cc.
gcc/analyzer/ChangeLog:
PR analyzer/102225
* analyzer.h (compat_types_p): New decl.
* constraint-manager.cc
(constraint_manager::get
On Fri, 3 Sep 2021, Gerald Pfeifer wrote:
> On Mon, 30 Aug 2021, David Malcolm via Gcc-patches wrote:
>> gcc/analyzer/ChangeLog:
>> PR analyzer/99260
>> * analyzer.h (class custom_edge_info): New class, adapted from
>> exploded_edge::custom_info_t. Make member functions const.
>>
On Wed, Sep 08, 2021 at 08:39:31PM +0200, Richard Biener wrote:
> On September 8, 2021 7:08:09 PM GMT+02:00, Segher Boessenkool
> wrote:
> >It is not a good idea to do allow all those things. Most backends can
> >only support a few combinations of them, and everything else results in
> >*worse*
Ping
Note: I don't have commit privileges for gcc.
On 8/27/2021 2:59 PM, Patrick McGehearty via Gcc-patches wrote:
This revision (v5) adds a test in libgcc/libgcc2.c for when
"__LIBGCC_TF_MANT_DIG__ == 106" to use __LIBGCC_DF_EPSILON__ instead
of __LIBGCC_TF_EPSILON__. That is specific to IBM 12
Ping (and remember to CC a maintainer this time).
On 31/08/21 09:53 +0100, Jonathan Wakely wrote:
The description of behaviour is incorrect, the virtual base gets
assigned before entering the bodies of A::operator= and B::operator=,
not after.
The example is also ill-formed (passing a string l
On 9/8/21 3:52 PM, Jonathan Wakely via Gcc-patches wrote:
Ping (and remember to CC a maintainer this time).
OK, thanks.
On 31/08/21 09:53 +0100, Jonathan Wakely wrote:
The description of behaviour is incorrect, the virtual base gets
assigned before entering the bodies of A::operator= and B:
On 9/2/21 7:53 PM, Martin Sebor wrote:
@@ -4622,28 +4622,94 @@ warn_for_null_address (location_t location, tree op,
tsubst_flags_t complain)
if (!warn_address
|| (complain & tf_warning) == 0
|| c_inhibit_evaluation_warnings != 0
- || warning_suppressed_p (op, OPT_Waddres
I'd like to ping the following MMA patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578288.html
Message-ID: <8393a33f-50ab-6720-0017-3f012803b...@linux.ibm.com>
Peter
Fwprop will happily optimize two xxsetaccz instructions into one xxsetaccz
by propagating the results of the f
On Thu, Sep 9, 2021 at 3:17 AM Segher Boessenkool
wrote:
>
> On Wed, Sep 08, 2021 at 08:39:31PM +0200, Richard Biener wrote:
> > On September 8, 2021 7:08:09 PM GMT+02:00, Segher Boessenkool
> > wrote:
> > >It is not a good idea to do allow all those things. Most backends can
> > >only support
On Thu, Sep 9, 2021 at 3:17 AM Segher Boessenkool
wrote:
>
> On Wed, Sep 08, 2021 at 08:39:31PM +0200, Richard Biener wrote:
> > On September 8, 2021 7:08:09 PM GMT+02:00, Segher Boessenkool
> > wrote:
> > >It is not a good idea to do allow all those things. Most backends can
> > >only support
On 2021/8/26 19:33, Richard Biener wrote:
On Tue, Aug 10, 2021 at 4:03 AM Xionghu Luo wrote:
Hi,
On 2021/8/6 20:15, Richard Biener wrote:
On Mon, Aug 2, 2021 at 7:05 AM Xiong Hu Luo wrote:
There was a patch trying to avoid move cold block out of loop:
https://gcc.gnu.org/pipermail/gcc
1. Add TARGET_AVX256_MOVE_BY_PIECES to perform move by-pieces operation
with 256-bit AVX instructions.
2. Add TARGET_AVX256_STORE_BY_PIECES to perform move and store by-pieces
operations with 256-bit AVX instructions.
They are enabled only for Intel Alder Lake and Intel processors with
AVX512.
gc
On Thu, Sep 9, 2021 at 11:21 AM H.J. Lu via Gcc-patches
wrote:
>
> 1. Add TARGET_AVX256_MOVE_BY_PIECES to perform move by-pieces operation
> with 256-bit AVX instructions.
> 2. Add TARGET_AVX256_STORE_BY_PIECES to perform move and store by-pieces
> operations with 256-bit AVX instructions.
>
> The
On Wed, Sep 8, 2021 at 9:18 PM Segher Boessenkool
wrote:
>
> On Wed, Sep 08, 2021 at 08:39:31PM +0200, Richard Biener wrote:
> > On September 8, 2021 7:08:09 PM GMT+02:00, Segher Boessenkool
> > wrote:
> > >It is not a good idea to do allow all those things. Most backends can
> > >only support
On 2021/9/2 18:37, Richard Biener wrote:
On Thu, 2 Sep 2021, Xionghu Luo wrote:
On 2021/9/2 16:50, Richard Biener wrote:
On Thu, 2 Sep 2021, Richard Biener wrote:
On Thu, 2 Sep 2021, Xionghu Luo wrote:
On 2021/9/1 17:58, Richard Biener wrote:
This fixes the CFG walk order of fill_a
50 matches
Mail list logo
