On Sat, Jan 23, 2021 at 03:10:10PM -0600, Segher Boessenkool wrote:
> > The reason I chose the "no-strict-aliasing" attribute (and already
> > committed based on Richi's ack) was consistency with the i386
> > testcase. I can change both.
>
> Yes please. Thanks!
So like this?
Tested on x86_64-li
On Wed, Jan 27, 2021 at 03:22:45PM +0800, Hongtao Liu wrote:
> Hi：
> As desribed in PR, also remove the relevant and useless expanders
> and builtins, the user can
> directly use == and >, without calling the builtin function.
> Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
>
> gcc/Ch
On Tue, Jan 26, 2021 at 12:25:16PM +0100, Richard Biener wrote:
> On Tue, 26 Jan 2021, Jakub Jelinek wrote:
>
> > On Tue, Jan 26, 2021 at 12:16:14PM +0100, Richard Biener wrote:
> > > > + /* Unless this is called during FE folding. */
> > > > + if (cfun
> > > > + && (cfun->curr_
Hi!
This patch adds a peephole2 for the optimization requested in the PR,
namely that we emit awful code for __atomic_sub_fetch (x, y, z) == 0
or __atomic_sub_fetch (x, y, z) != 0 when y is not constant.
This can't be done in the combiner which punts on combining UNSPEC_VOLATILE
into other insns.
Hi!
On Linux, GCC emits .note.GNU-stack sections when compiling code to mark
the code as not needing or needing executable stack, missing section means
unknown. But assembly files need to be marked manually. We already
mark various *.S files in libgcc manually, but the
avx_resms64f.o
avx_resms64
On Wed, Jan 27, 2021 at 11:22:57AM +0100, Uros Bizjak wrote:
> > Bootstrapped/regtested on x86_64-linux and i686-linux. Is this ok for trunk
> > (as exception), or for GCC 12?
>
> If there is no urgent need, I'd rather see to obey stage-4 and wait
> for gcc-12. There is PR98375 meta bug to track
On Wed, Jan 27, 2021 at 06:38:23PM +0800, Hongtao Liu wrote:
> Yes, and update patch.
Ok, thanks.
Jakub
On Wed, Jan 27, 2021 at 03:40:38PM +0100, Richard Biener wrote:
> The following avoids repeatedly turning VALUE RTXen into
> sth useful and re-applying a constant offset through get_addr
> via DSE check_mem_read_rtx. Instead perform this once for
> all stores to be visited in check_mem_read_rtx.
On Wed, Jan 27, 2021 at 04:16:22PM +0100, Richard Biener wrote:
> I can check but all immediate first uses of mem_addr are in
> true_dependece_1 which does x_addr = get_addr (x_addr); as the
> first thing on it. So the concern would be that
> get_addr (get_addr (x_addr)) != get_addr (x_addr) which
On Wed, Jan 27, 2021 at 05:37:54PM +0100, Richard Biener wrote:
> Sure, more micro-optimizing is possible, including passing a flag
> to canon_true_dependence whether the addr RTX already had get_addr
> called on it. And pass in the offset as poly-rtx-int and make
> get_addr apply it if not zero.
Hi!
The https://gcc.gnu.org/legacy-ml/gcc-patches/2018-07/msg01895.html
patch that introduced this pattern claimed:
Would generate:
combine_balanced_int:
bfxil w0, w1, 0, 16
uxtwx0, w0
ret
But with this patch generates:
combine_balanced_int:
bfxil w0, w1,
On Sun, Oct 21, 2018 at 04:39:30PM -0400, Ed Smith-Rowland wrote:
> This patch implements C++2a proposal P0330R2 Literal Suffixes for ptrdiff_t
> and size_t*. It's not official yet but looks very likely to pass. It is
> incomplete because I'm looking for some opinions. 9We also might wait 'till
>
Hi!
As the testcase shows, for vars appearing in templates, we don't attach
the asm spec string to the pattern decls, nor pass it back to cp_finish_decl
during instantiation.
The following patch does that.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2021-01-27 Jakub Je
Hi!
We emit a bogus warning on the following testcase, suggesting that the
operator should return *this even when it does that already.
The problem is that normally cp_build_indirect_ref_1 ensures that *this
is folded as current_class_ref, but in templates (if return type is
non-dependent, otherwi
On Thu, Jan 28, 2021 at 09:31:46AM +0100, Richard Biener via Gcc-patches wrote:
> + if (TREE_CODE (bound) == PLUS_EXPR
> + && integer_all_onesp (TREE_OPERAND (bound, 1)))
> +{
> + bound = TREE_OPERAND (bound, 0);
> + if (TREE_CODE (bound) == NOP_EXPR)
> + bound = TREE_OPER
Hi!
I've noticed we still refer to C++20 as draft standard, and there is a pasto
in C++23 description.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk as obvious.
2021-01-28 Jakub Jelinek
* c.opt (-std=c++2a, -std=c++20, -std=gnu++2a, -std=gnu+
On Thu, Jan 28, 2021 at 10:04:12AM -0500, Jason Merrill wrote:
> > We emit a bogus warning on the following testcase, suggesting that the
> > operator should return *this even when it does that already.
> > The problem is that normally cp_build_indirect_ref_1 ensures that *this
> > is folded as cur
Hi!
When expansion emits some control flow insns etc. inside of a former GIMPLE
basic block, find_bb_boundaries needs to split it into multiple basic
blocks.
The code needs to ignore debug insns in decisions how many splits to do or
where in between some non-debug insns the split should be done, b
Hi!
The
https://gcc.gnu.org/r11-6707-g7432f255b70811dafaf325d94036ac580891de69
https://gcc.gnu.org/r11-6708-gbfab355012ca0f5219da8beb04f2fdaf757d34b7
changes moved the vashl/vashr/vlshr expanders from neon.md to vec-common.md
and changed their condition from TARGET_NEON to ARM_HAVE__ARITH,
so that
On Fri, Jan 29, 2021 at 10:51:59AM +0100, Richard Biener wrote:
> This changes the REE dataflow to change the explicit all-ones
> starting solution to be implicit via a visited flag, removing
> the need to initially start with fully populated bitmaps for
> all basic-blocks. That reduces peak memor
On Thu, Jan 21, 2021 at 07:33:34PM +, Kwok Cheung Yeung wrote:
> The detach support clearly needs more work, but is this particular patch
> okay for trunk?
Sorry for the delay.
I'm afraid it is far from being ready.
> @@ -2402,17 +2437,41 @@ ialias (omp_in_final)
> void
> omp_fulfill_event
On Fri, Jan 29, 2021 at 04:43:49PM +0100, Richard Biener wrote:
> 2021-01-29 Richard Biener
>
> PR rtl-optimization/98863
> * config/i386/i386-features.c (remove_partial_avx_dependency):
> Do not perform DF analysis.
> (pass_data_remove_partial_avx_dependency): Remove
>
On Fri, Jan 29, 2021 at 05:27:13PM +0100, Richard Biener wrote:
> > > + df_process_deferred_rescans ();
> >
> > rather than here?
> > The pass these days does two separate optimizations, and only one of those
> > creates the use uninitialized pseudo and at the end initialize it.
> > The other opt
On Fri, Jan 29, 2021 at 11:18:54AM -0800, sunil.k.pandey via Gcc-patches wrote:
> On Linux/x86_64,
>
> a7f52181a6a16bb6d216ff41d9c6a9da95c19b5c is the first bad commit
> commit a7f52181a6a16bb6d216ff41d9c6a9da95c19b5c
> Author: Richard Biener
> Date: Fri Jan 29 16:02:36 2021 +0100
>
> rtl-
Hi!
GCC 11 ICEs on all -fdirectives-only preprocessing when the files don't end
with a newline.
The problem is in the assertion, for empty TUs buffer->cur == buffer->rlimit
and so buffer->rlimit[-1] access triggers UB in the preprocessor, for
non-empty TUs it refers to the last character in the f
On Sat, Jan 30, 2021 at 09:17:45AM +0100, Richard Biener wrote:
> >The following patch fixes it, ok for trunk if it passes
> >bootstrap/regtest?
>
> Hmm, that's odd. Who relies on deferred rescan being the default? Finish
> pass, via processing deferred insns also resets it back. Or is this
> d
Hi!
The test (intentionally) is not gcc.dg/vect/, as it needs -fopenmp and uses
OpenMP directives other than simd and therefore can't rely on default
VECTFLAGS and so I think can't safely use vect_int effective target
either. So, I'm just making sure it is vectorized on x86 and on aarch64 (the
la
On Sat, Jan 30, 2021 at 10:46:17AM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Sat, Jan 30, 2021 at 09:17:45AM +0100, Richard Biener wrote:
> > >The following patch fixes it, ok for trunk if it passes
> > >bootstrap/regtest?
> >
> > Hmm, that's odd. W
On Sat, Jan 30, 2021 at 11:47:24AM +0100, Richard Biener wrote:
> OK, so I'd prefer we simply unset the flag after processing deferred rescan.
> I clearly misread the function to do that.
This works too, will bootstrap/regtest it now.
2021-01-29 Jakub Jelinek
* config/i386/i386-feat
On Sun, Jan 31, 2021 at 01:49:29PM +0100, Eric Botcazou wrote:
> > The important difference is for strn{,case}cmp folding, we pass that s2
> > value as the last argument to the host functions comparing the c_getstr
> > results. If s2 fits into size_t, then my patch makes no difference,
> > but if
On Sun, Jan 31, 2021 at 02:12:46PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Sun, Jan 31, 2021 at 01:49:29PM +0100, Eric Botcazou wrote:
> > > The important difference is for strn{,case}cmp folding, we pass that s2
> > > value as the last argument to the host fu
On Sun, Jan 31, 2021 at 07:07:32PM +0100, Eric Botcazou wrote:
> > Why not just:
> >
> > #ifndef SIZE_MAX
> > # define SIZE_MAX INTTYPE_MAXIMUM (size_t)
> > #endif
> >
> > just below UCHAR_MAX in system.h?
>
> Or rather just below
>
> #ifdef HAVE_STDINT_H
> #include
> #endif
>
> #ifdef HAVE_I
On Sun, Jan 31, 2021 at 07:07:32PM +0100, Eric Botcazou wrote:
> > Why not just:
> >
> > #ifndef SIZE_MAX
> > # define SIZE_MAX INTTYPE_MAXIMUM (size_t)
> > #endif
> >
> > just below UCHAR_MAX in system.h?
>
> Or rather just below
>
> #ifdef HAVE_STDINT_H
> #include
> #endif
>
> #ifdef HAVE_I
On Sun, Jan 31, 2021 at 09:19:07PM +0100, Eric Botcazou wrote:
> > Whatever works, I can't test such patches except on Linux, so can you just
> > create a patch and test it on Solaris where it failed before?
>
> Maybe a safer fix is the attached one. Tested on old RedHat and SuSE distros.
>
>
>
On Sun, Jan 31, 2021 at 10:48:53PM +0100, Eric Botcazou wrote:
> > But next time we use SIZE_MAX somewhere it is going to break again this way.
> > If we just define SIZE_MAX if not defined after all includes in system.h, I
> > think it is better than this.
>
> The existing practice seems to defin
On Mon, Feb 01, 2021 at 05:38:46PM +0800, Kito Cheng wrote:
> - Check `TO` mode is not BLMmode before call store_expr, calling store_expr
>with BLKmode will cause ICE.
How do you end up with a SUBREG_PROMOTED* of something that has bitsize of 0
(GET_MODE_BITSIZE of BLKmode is 0, right)?
That
On Mon, Feb 01, 2021 at 05:57:28PM +0800, Kito Cheng wrote:
> > > - Check `TO` mode is not BLMmode before call store_expr, calling
> > > store_expr
> > >with BLKmode will cause ICE.
> >
> > How do you end up with a SUBREG_PROMOTED* of something that has bitsize of 0
> > (GET_MODE_BITSIZE of B
On Mon, Feb 01, 2021 at 09:11:20AM -0700, Martin Sebor via Gcc-patches wrote:
> > > > Because free_lang_data only frees anything when LTO is enabled and
> > > > we want these trees cleared regardless to keep them from getting
> > > > clobbered during gimplification, this change also modifies the pa
On Mon, Feb 01, 2021 at 01:46:13PM -0500, Ed Smith-Rowland wrote:
> @@ -0,0 +1,8 @@
> +// { dg-do compile { target c++23 } }
> +
> +#include
> +#include
> +
> +static_assert(std::is_same_v);
> +static_assert(std::is_same_v);
Shouldn't this be std::make_signed::type instead of std::ptrdiff_t
> +
On Mon, Feb 01, 2021 at 08:23:18PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Feb 01, 2021 at 01:46:13PM -0500, Ed Smith-Rowland wrote:
> > @@ -0,0 +1,8 @@
> > +// { dg-do compile { target c++23 } }
> > +
> > +#include
> > +#include
> &
On Mon, Feb 01, 2021 at 12:54:50PM -0700, Jeff Law wrote:
> >>> So I see no difference for stage2-gcc/*.o dse1/dse2 with/without the
> >>> patch but counts are _extremely_ small. Statistics:
> >>>
> >>> 70148 dse: local deletions = 0, global deletions = 0
> >>> 32 dse: local deletions = 0,
On Tue, Feb 02, 2021 at 03:21:24PM +0800, Kito Cheng wrote:
> - Check `from` mode is not BLMmode before call store_expr, calling store_expr
>with BLKmode will cause ICE.
>
> - Verified with riscv64, x86_64 and aarch64, no introduce new regression.
>
> Note: Those logic was introduced by 3e6
On Tue, Feb 02, 2021 at 08:51:07AM +0100, Richard Biener wrote:
> > Shouldn't we gather statistics from larger codebase first and perhaps
> > compare against tree-ssa-dse statistics? I mean, in many functions there
> > are no DSE opportunities at all.
>
> Of course. Some DSE will definitely be r
Hi!
This testcase has been fixed by
r11-5904-g4cf70c20cb10acd6fb1016611d05540728176b60
so I'm checking it in so that we can close the PR.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as
obvious.
2021-02-02 Jakub Jelinek
PR tree-optimization/97960
Hi!
As discussed in the PR, the reduction code isn't able to cope with type
promotions/demotions in the reduction computation, so if we recognize an
over-widening pattern that has vect_reduction_def type, we most likely make
it non-vectorizable.
Fixed thusly, bootstrapped/regtested on x86_64-linu
Hi!
The following testcase ICEs, because after the veclower pass which is the
last point which lowers unsupported vector operations to supported ones
(or scalars) match.pd simplifies a supported vector operation into
unsupported one (vec << 1 >> 1 into vec & { ~1, ... }).
Guarding each match.pd pa
Hi!
The following testcase has ice-on-invalid, it can't be reloaded, but we
shouldn't ICE the compiler because the user typed non-sense.
In current_insn_transform we have:
if (process_alt_operands (reused_alternative_num))
alt_p = true;
if (check_only_p)
return ! alt_p || best_lose
Hi!
As the testcase shows, RTL ifcvt can throw random RTL (whatever it found in
some insns) at expand_binop or expand_unop and expects it to do something
(and then will check if it created valid insns and punts if not).
These functions in the end if the operands don't match try to
copy_to_mode_reg
On Tue, Feb 02, 2021 at 09:38:09AM +, Richard Sandiford wrote:
> > +/* In PROP_gimple_lvec mode, perform extra checking if RES_OP and return
> > + true if RES_OP is not appropriate - would require vector operations that
> > + would need to be lowered before expansion. */
> > +
> > +bool
>
On Tue, Feb 02, 2021 at 11:06:33AM +0100, Richard Biener wrote:
> So I fear this only covers parts of the paths simplifications can
> end up used. Now one question is whether we want to allow
> "invalid" intermediate transforms if a final match makes it
> "valid" again. If not then doing the veri
On Tue, Feb 02, 2021 at 02:23:55PM +0100, Richard Biener wrote:
> Btw, I just can find V1DI mentioned in mmx.md but I can't find
> rotate or shift patterns that would match?
The backend has several V1?Imode shifts, but optab only for those V1DImode
ones:
grep '[la]sh[lr]v1[qhsdtox]' tmp-mddump.md
On Tue, Feb 02, 2021 at 11:39:30AM -0700, Jeff Law wrote:
> > This patch adds some ctz simplifications (e.g. ctz (x) >= 3 can be done by
> > testing if the low 3 bits are zero, etc.).
> >
> > In addition, I've noticed that in the CLZ case, the
> > #ifdef CLZ_DEFINED_VALUE_AT_ZERO don't really work
On Wed, Feb 03, 2021 at 12:58:12PM +0100, Martin Liška wrote:
> The patch is about filling a padding byte that is later
> streamed with memcpy.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> P
Hi!
This testcase got fixed with the PR98463
r11-6895-g94ff4c9dd98f39280fba22d1ad0958fb25a5363b fix.
Regtested on x86_64-linux, committed to trunk and 10 branch.
2021-02-03 Jakub Jelinek
PR c++/97804
* g++.dg/cpp2a/no_unique_address11.C: New test.
--- gcc/testsuite/g++.dg/cp
Hi!
We ICE on the following testcase, for incomplete array a on auto [b] { a };
without
giving any kind of diagnostics, with auto [c] = a; during error-recovery.
The problem is that we get too far through check_initializer and e.g.
store_init_value -> constexpr stuff can't deal with incomplete ar
Hi!
The following patch uses make_signed_t instead of
make_signed::type in the diagnostics, because the former is shorter.
It is true that one can't use make_signed::type in C++11 code (which
is why I haven't changed it in the testcase which is c++11 effective
target), but the message talks about
On Thu, Feb 04, 2021 at 12:24:10PM +0100, Tobias Burnus wrote:
> This issue came up when looking at Julian's OpenACC patches
> and by coincidence it was also discussed for OpenMP
> yesterday (lang-spec F2F meeting; Issue #2607).
>
> OpenACC rather explicitly lists what counts as 'var' and
> substr
On Thu, Feb 04, 2021 at 01:31:52PM +0800, Hongtao Liu via Gcc-patches wrote:
* gcc.target/i386/avx512vl-pr92686-vpcmp-1.c: This test is
used to guard code generation of integer mask comparison, but
for vector comparison to vector dest, integer mask comparison
is disl
On Thu, Feb 04, 2021 at 11:03:10AM -0500, Jason Merrill wrote:
> > --- gcc/cp/decl.c.jj2021-01-28 16:13:04.0 +0100
> > +++ gcc/cp/decl.c 2021-02-03 15:57:16.980557836 +0100
> > @@ -6837,7 +6837,8 @@ check_initializer (tree decl, tree init,
> > /* We will have already complai
Hi!
On Mon, Nov 16, 2020 at 06:14:52PM -0500, David Edelsohn via Gcc-patches wrote:
> Jenkins does function on AIX. I will take an action item to create
> another LPAR on the AIX systems at OSUOSL for Jenkins and coordinate
> with you to connect it to the terrific Jenkins infrastructure for GCC
>
Hi!
As written in the PR, TARGET_QIMODE_MATH was meant to be set for all
tunings and it was the case for GCC <= 7, but as the number of
PROCESSOR_* enumerators grew, some AMD tunings (which are at the end
of the list) over time got enumerators with values >= 32 and
TARGET_QIMODE_MATH became disabl
On Fri, Feb 05, 2021 at 10:38:44AM +0100, Uros Bizjak wrote:
> > > --- gcc/config/i386/i386-options.c.jj 2021-01-14 19:34:06.041425286
> > > +0100
> > > +++ gcc/config/i386/i386-options.c 2021-02-04 16:30:18.424999701
> > > +0100
> > > @@ -98,6 +98,8 @@ along with GCC; see the file COPYING
Hi!
With -fno-delete-null-pointer-checks which is e.g. implied by
-fsanitize=undefined or default on some embedded targets, the middle-end
folder doesn't consider addresses of global VAR_DECLs to be non-NULL, as one
of them could have address 0. Still, I think malloc/operator new (at least
the no
Hi!
The print_generic_expr_to_str function ends with
return xstrdup (...); and therefore expects the caller to free
the argument.
The following patch does that after it has been copied.
Instead of doing const_cast to cast away const char * to char *,
because the code uses s0 and s1 in so few plac
Hi!
In the PR there are several possibilities how to improve _M_disjunct at
least in certain cases so that the compiler can figure out at least in some
cases where __s is provably disjunct from _M_data() ... _M_data() + this->size()
but it is probably GCC 12 material.
The false positive warning i
On Tue, Feb 09, 2021 at 07:47:00AM +0100, Richard Biener via Gcc-patches wrote:
> On February 8, 2021 10:44:26 PM GMT+01:00, Mikael Pettersson via Gcc-patches
> wrote:
> >PR98860 is a gcc-11 regression where bootstrap fails on Windows since
> >the switch to enable DWARF5 by default. The symptoms
Hi!
As mentioned in the PR, we don't support arithmetic right V2DImode or
V4DImode on x86 without -mavx512vl or -mxop. The ISAs indeed don't have
{,v}psraq instructions until AVX512VL, but we actually can emulate it quite
easily.
One case is arithmetic >> 63, we can just emit {,v}pxor; {,v}pcmpgt
On Tue, Feb 09, 2021 at 12:52:55PM +0100, Richard Biener wrote:
> Yeah, it does look useful in the end. Note that you might want
> to adjust ix86_add_stmt_cost (or ix86_shift_rotate_cost, that is)
> to reflect the complex expansion.
Yeah, the patch does that, see the i386.c hunks.
I guess for V2
On Tue, Feb 09, 2021 at 02:38:44PM +0100, Andrea Corallo via Gcc-patches wrote:
> >From c8216ed1313d670e79b28141dadd644e698c83cf Mon Sep 17 00:00:00 2001
> From: Andrea Corallo
> Date: Wed, 3 Feb 2021 15:21:54 +0100
> Subject: [PATCH] arm: Low overhead loop handle long range branches [PR98931]
>
On Tue, Feb 09, 2021 at 03:09:43PM +0100, Jakub Jelinek via Gcc-patches wrote:
> >"TARGET_32BIT && TARGET_HAVE_LOB"
> > - "le\t%|lr, %l0")
> > + "*
> > + if (get_attr_length (insn) == 4)
> > +return \"le\\t%
On Tue, Feb 09, 2021 at 06:25:10AM -0800, H.J. Lu via Gcc-patches wrote:
> My patch does nothing for GCC 10.
>
> > files from GCC 11
> > and -fcf-protection=none (aka the long-year default)?
> >
>
> Yes, if __builtin_setjmp and __builtin_longjmp aren't used.
> No, if they are.
Therefore ABI chan
On Tue, Feb 09, 2021 at 02:40:12PM -0500, Jason Merrill wrote:
> For GCC 11, I think let's fix the regression with your (Jakub) earlier
> patch, maybe only for DIEs with DW_AT_const_value.
Thanks.
Following works too, so I'll test it tonight.
2021-02-09 Jakub Jelinek
PR debug/98755
On Tue, Feb 09, 2021 at 03:00:20PM -0500, Jason Merrill wrote:
> > With -fno-delete-null-pointer-checks which is e.g. implied by
> > -fsanitize=undefined or default on some embedded targets, the middle-end
> > folder doesn't consider addresses of global VAR_DECLs to be non-NULL, as one
> > of them
On Tue, Feb 09, 2021 at 08:55:26PM +0100, Jakub Jelinek wrote:
> On Tue, Feb 09, 2021 at 02:40:12PM -0500, Jason Merrill wrote:
> > For GCC 11, I think let's fix the regression with your (Jakub) earlier
> > patch, maybe only for DIEs with DW_AT_const_value.
>
> Thanks.
> Following works too, so I'
Hi!
gimplify_scan_omp_clauses was already calling gimplify_expr with false as
last argument to make sure it is not an SSA_NAME, but as the testcases show,
that is not enough, SSA_NAME temporaries created during that gimplification
can be reused too and we can't allow SSA_NAMEs to be used across Op
On Wed, Feb 10, 2021 at 11:30:42AM +0100, Richard Biener wrote:
> The optimize pragma/attribute parsing calls decode_cmdline_options_to_array
> but doesn't free the array. The following fixes that.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
>
> Thanks,
> Richard.
>
> 2021-02-1
On Tue, Feb 09, 2021 at 04:08:03PM -0500, Jason Merrill via Gcc-patches wrote:
> > They are not in the symtab from the C++ FE. And we don't allow those
> > VAR_DECLs or their
> > addresses to leak into the IL anyway.
> > But, they are TREE_STATIC because pretending they are automatic didn't
> > r
Hi!
In these patterns, we call simplify_gen_subreg on the input operand
to create paradoxical subregs that have 2x, 4x or 8x elements as the input
operand. That works fine if the input operand is a REG, but when it is a
SUBREG, RTL doesn't allow SUBREG of SUBREG and so relies on simplify_subreg
a
Hi!
My FE change from 2 years ago uses TREE_ASM_WRITTEN in -fsyntax-only
mode more aggressively to avoid "expanding" functions multiple times.
With -fsyntax-only nothing is really expanded, so I think it is acceptable
to adjust the assert and allow declare_weak at any time, with -fsyntax-only
we k
Hi!
array_type_nelts returns error_mark_node for type of flexible array members
and build_zero_init_1 was placing an error_mark_node into the CONSTRUCTOR,
on which e.g. varasm ICEs. I think there is nothing erroneous on zero
initialization of flexible array members though, such arrays should simp
On Thu, Feb 11, 2021 at 11:55:30AM +0100, Richard Biener wrote:
> 2021-02-11 Richard Biener
>
> PR tree-optimization/38474
> * params.opt (-param=max-store-chains-to-track=): New param.
> (-param=max-stores-to-track=): Likewise.
> * doc/invoke.texi (max-store-chains-to-t
Hi!
As the testcase shows, if we reach CPP_EOF during parsing of requirement
sequence, we end up with endless loop where we always report invalid
requirement expression, don't consume any token (as we are at eof) and
repeat.
This patch stops the loop when we reach CPP_EOF.
Ok for trunk if it pas
On Thu, Feb 11, 2021 at 07:44:53PM +0100, Uros Bizjak wrote:
> 2021-02-11 Uroš Bizjak
>
> libgomp/
> * config/linux/x86/futex.h (__futex_wait): New static inline
> wrapper function. Correct output type to int and
> timeout type to void *.
> (__futex_wake): New static inline wra
Hi!
The vla15.C testcase ICEs with
-mcpu=cortex-m1 -mpure-code -fstack-protector -mthumb
as what force_const_mem returns (a SYMBOL_REF) is not a valid
memory address.
Previously the code was moving the address of the force_const_mem
into a register rather than the content of that MEM, so that inst
On Thu, Feb 11, 2021 at 03:03:38PM +, Richard Sandiford via Gcc-patches
wrote:
> gcc/
> * df-problems.c (df_lr_bb_local_compute): Treat partial definitions
> as read-modify operations.
>
> gcc/testsuite/
> * gcc.dg/rtl/aarch64/multi-subreg-1.c: New test.
The test fails ever
Hi!
Since the x86 backend enabled V2SImode vectorization (with
TARGET_MMX_WITH_SSE), slp vectorization can kick in and emit
movq(%rdi), %xmm1
pshufd $225, %xmm1, %xmm0
movq%xmm0, (%rdi)
instead of
rolq$32, (%rdi)
we used to emit (or emit when slp vector
Hi!
As mentioned in the PR, we have 5 split passes (+ splitting during final).
split1 is before RA and is unconditional,
split2 is after RA and is gated on optimize > 0,
split3 is before sched2 and is gated on
defined(INSN_SCHEDULING) && optimize > 0 && flag_schedule_insns_after_reload
split4 is
Hi!
The (mod @0 (convert?@3 (power_of_two_cand@1 @2))) simplification
uses tree_nop_conversion_p (type, TREE_TYPE (@3)) condition, but I believe
it doesn't check what it was meant to check. On convert?@3
TREE_TYPE (@3) is not the type of what it has been converted from, but
what it has been conve
On Sat, Feb 13, 2021 at 09:59:57AM +0100, Uros Bizjak wrote:
> BTW: I wonder if this optimization triggers frequently, the code in
> the PR looks quite useful.
On my next bootstrap/regtest I can gather some statistics.
Jakub
On Sat, Feb 13, 2021 at 02:54:38PM +0100, Richard Biener wrote:
> Ok. But if required splitting is an IL property maybe we can see sth like
> RTL_split_insns, clear it from passes like selsched and gate split on the
> property and not being present?
I guess better would be to track it after reloa
Hi!
As mentioned in the PR, ix86_simd_clone_usable didn't make it more desirable
to use 'e' mangled AVX512F entrypoints over 'd' mangled ones (AVX2) with the
same simdlen. This patch fixes that. I have tweaked the generic code too
to make more room for these target specific badness factors.
Boo
Hi!
The following testcase started ICEing with my recent changes to enable
split4 after sel-sched, but it seems the bug is more general.
Some of the i386 splitter condition functions use and rely on df, but
the split passes don't really df_analyze/df_finish_pass, so the DF info
may be stale or not
Hi!
fixup_partitions sometimes changes some basic blocks from hot partition to
cold partition, in particular if after unreachable block removal or other
optimizations a hot partition block is dominated by cold partition block(s).
It fixes up the edges and jumps on those edges, but when after reord
On Tue, Feb 16, 2021 at 09:42:22AM +0100, Richard Biener wrote:
> Just to get an idea whether it's worth doing the extra df_analyze.
> Since we have possibly 5 split passes it's a lot of churn for things
> like that WRF ltrans unit that already spends 40% of its time in DF ...
Yeah, df_analyze can
On Tue, Feb 16, 2021 at 08:56:13AM +, Richard Sandiford wrote:
> Yeah, but the updates are incremental. I think in many cases we'll
df_analyze e.g. computes postorder, so it has some costs even if everything
is really up to date.
Jakub
On Tue, Feb 16, 2021 at 09:16:40AM +, Richard Sandiford wrote:
> But doing it on demand like this seems fragile. And the targets aren't
> a fixed… target. I think we need to design the interface so that things
> are unlikely to go wrong in future rather than design it on the basis
> that thin
On Tue, Feb 16, 2021 at 09:55:40AM +, Richard Sandiford wrote:
> I assume that's because pass_df_initialize_no_opt is slightly after
> the first pass_split_all_insns? Seems like it should just be a case
> of moving it up.
>
> > And for noflow where the cfg doesn't really exit I wouldn't even
On Tue, Feb 16, 2021 at 11:47:51AM +0100, Uros Bizjak wrote:
> > In this case the match_scratch wouldn't work, since CC_REGNUM is fixed.
> > But as you said on irc, there's peep2_regno_dead_p instead.
> >
> > Haven't tried it and so don't know whether it would work with only
> > one construct in th
On Tue, Feb 16, 2021 at 12:39:39PM +0100, Uros Bizjak wrote:
> > @@ -5197,7 +5209,7 @@ (define_insn_and_split "*lea"
> >
> >/* ix86_avoid_lea_for_addr re-recognizes insn and may
> > change operands[] array behind our back. */
> > - pat = PATTERN (curr_insn);
> > + pat = PATTERN (peep2_
On Tue, Feb 16, 2021 at 01:09:43PM +, Richard Sandiford wrote:
> Can I put in a plea to put this in recog.[hc], and possibly also make
> it a copy constructor for recog_data_d? I can't think of any legitimate
> cases in which we'd want to copy the whole structure, instead of just
> the active
401 - 500 of 4686 matches
Mail list logo
