On 28/08/2018 21:04, Jonathan Wakely wrote:
On 23/08/18 22:59 +0200, François Dumont wrote:
On 22/08/2018 23:45, Jonathan Wakely wrote:
On 22/08/18 23:08 +0200, François Dumont wrote:
Only operator== and != remains outside _Safe_iterator because all
my attempts to make them inline friends
OK.
On Thu, Aug 23, 2018 at 11:01 AM, David Malcolm wrote:
> Consider this bogus code (from g++.dg/diagnostic/param-type-mismatch-2.C):
>
> struct s4 { static int member_1 (int one, const char **two, float three); };
>
> int test_4 (int first, const char *second, float third)
> {
> return
The pic.md file has patterns used only for the medany code model and for pic
code. They match an unsplit 2-instruction address load pattern followed by
a load or store instruction, and emit an assembler macro that expands to two
instructions. This replaces 3 instructions with 2. Unfortunately,
In https://golang.org/cl/91796 in the master Go repository the hmap
field was removed from map types. While the Go frontend doesn't have
to be compatible, it may as well be. This implements part of that
change for the Go frontend, just the compiler change and the required
libgo change. This is
Sadly, dstbase is the PARM_DECL for d. That's where things are going
"wrong". Not sure why you're getting the PARM_DECL in that case. I'd
debug get_addr_base_and_unit_offset to understand what's going on.
Essentially you're getting different results of
get_addr_base_and_unit_offset in a case
On 08/28/2018 05:24 AM, Richard Sandiford wrote:
> The point of this patch is to put pattern statements in the same
> vec_basic_block as the statements they replace, with the pattern
> statements for S coming between S and S's original predecessor.
> This removes the need to handle them specially
On 08/27/2018 02:32 AM, Richard Biener wrote:
> On Sat, Aug 25, 2018 at 9:14 PM Jeff Law wrote:
>>
>> On 08/24/2018 01:06 PM, Martin Sebor wrote:
>>> PR 87059 points out an ICE in the recently enhanced VRP code
>>> that was traced back to a MIN_EXPR built out of operands of
>>> types with
On 08/28/2018 05:23 AM, Richard Sandiford wrote:
> The vectoriser normally leaves a later DCE pass to remove the scalar
> code, but we've accumulated various special cases for things that
> DCE can't handle, such as removing the scalar stores that have been
> replaced by vector stores, and the
Hi Aaron,
On Wed, Aug 22, 2018 at 12:31:51PM -0500, Aaron Sawdey wrote:
> This patch teaches rs6000 inline expansion of strcmp/strncmp how to
> generate vector/vsx code for power8/power9 processors. Compares 16
> bytes and longer are generated using the vector code, which is
> considerably faster
On Tue, Jul 31, 2018 at 04:38:43AM -0500, Sam Tebbs wrote:
> Hi all,
>
> This patch captures the case where an unnecessary uxtw instruction is
> generated
> after a bfxil instruction when in SI mode, and stops it from being
> generated.
> Note that this depends on my previous patch submission
>
On Wed, Aug 01, 2018 at 10:07:23AM -0500, Sam Tebbs wrote:
> Hi all,
>
> This patch adds an optimisation that exploits the AArch64 BFXIL
> instruction when or-ing the result of two bitwise and operations
> with non-overlapping bitmasks
> (e.g. (a & 0x) | (b & 0x)).
>
> Example:
>
Hi!
As mentioned in the PR, if some class has nearly empty virtual base as
primary base, it shares the vptr with that primary base; in that case,
we can't clear the vptr in the not in charge destructor of that class,
as the dtor for the virtual base will be invoked later on and needs to have
the
On 08/28/2018 05:22 AM, Richard Sandiford wrote:
> This patch adds a vec_basic_block that records the scalar phis and
> scalar statements that we need to vectorise. This is a slight
> simplification in its own right, since it avoids unnecesary statement
> lookups and shaves >50 LOC. But the main
Hi!
The following testcase ICEs in tsubst_decomp_names, because the earlier
tsubst_expr still with processing_template_decl called just
tsubst_decomp_names, but didn't arrange for DECL_VALUE_EXPR to be set on the
decomp identifier decls (which cp_finish_decomp does).
Fixed thusly,
On 08/28/2018 02:43 PM, Martin Sebor wrote:
> On 08/27/2018 10:27 PM, Jeff Law wrote:
>> On 08/27/2018 10:27 AM, Martin Sebor wrote:
>>> On 08/27/2018 02:29 AM, Richard Biener wrote:
On Sun, Aug 26, 2018 at 7:26 AM Jeff Law wrote:
>
> On 08/24/2018 09:58 AM, Martin Sebor wrote:
On Fri, Aug 03, 2018 at 11:28:08AM -0500, Matthew Malcomson wrote:
> On 02/08/18 20:18, James Greenhalgh wrote:
> > On Tue, Jul 31, 2018 at 04:53:19AM -0500, Matthew Malcomson wrote:
> >> Fixing the ilp32 issue that Christophe found.
> >>
> >> The existing testcase uses `long` to represent a 64
On 08/28/2018 02:32 PM, Julian Brown wrote:
> On Tue, 28 Aug 2018 12:23:22 -0700
> Cesar Philippidis wrote:
>> This is specific to OpenACC, and needs to be guarded as such.
>
> Are you sure that condition can be true for OpenMP? I'd assumed not...
My bad, you're correct. OMP doesn't use those
On Mon, Aug 27, 2018 at 10:05:17AM -0500, Luis Machado wrote:
> Hi,
>
> On 08/08/2018 04:54 AM, Siddhesh Poyarekar wrote:
> > On 08/01/2018 04:23 AM, James Greenhalgh wrote:
> >> On Wed, Jul 25, 2018 at 01:10:34PM -0500, Luis Machado wrote:
> >>> The adjusted vector costs give Falkor a reasonable
On Mon, Aug 27, 2018 at 10:05:21AM -0500, Luis Machado wrote:
> Hi,
>
> On 08/08/2018 04:46 AM, Siddhesh Poyarekar wrote:
> > On 08/01/2018 04:24 AM, James Greenhalgh wrote:
> >> OK if this is what is best for your subtarget.
> >>
> >
> > I have pushed this on behalf of Luis since he is on
On Tue, Aug 28, 2018 at 03:59:25AM -0500, Vlad Lazar wrote:
> Gentle ping.
>
> On 08/08/18 17:38, Vlad Lazar wrote:
> > On 01/08/18 18:35, James Greenhalgh wrote:
> >> On Wed, Aug 01, 2018 at 07:13:53AM -0500, Vlad Lazar wrote:
> >>> On 31/07/18 22:48, James Greenhalgh wrote:
> On Fri, Jul
Joern Wolfgang Rennecke writes:
> 2018-08-28 Joern Rennecke
>
> * genpreds.c (write_predicate_subfunction): Also add ATTRIBUTE_UNUSED
> to OP parmeter of generated function.
OK, thanks.
Richard
> Index: genpreds.c
>
On Tue, 28 Aug 2018 12:23:22 -0700
Cesar Philippidis wrote:
> On 08/28/2018 12:19 PM, Julian Brown wrote:
>
> > diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
> > index f038f4c..86be407 100644
> > --- a/gcc/fortran/trans-openmp.c
> > +++ b/gcc/fortran/trans-openmp.c
> > @@
In predicates.md, we have a predicate like this:
(define_special_predicate "esirisc_simd_shift_reg_operand"
(match_operand 0 "d_register_operand")
{
/* Earlier revs shifted both halves by the same amount, which is not usable.
*/
return esirisc_rev_option > 10;
})
genpreds generates for
Alexander Monakov writes:
> @@ -9120,6 +9121,15 @@ determining number of iterations requires complicated
> analysis. Later
> optimizations then may determine the number easily. Useful especially
> in connection with unrolling.
>
> +@item -ftree-scev-cprop
> +@opindex ftree-scev-cprop
>
Tamar Christina writes:
> + HOST_WIDE_INT guard_used_by_caller = STACK_CLASH_CALLER_GUARD;
> + /* When doing the final adjustment for the outgoing argument size we can't
> + assume that LR was saved at position 0. So subtract it's offset from
> the
> + ABI safe buffer so that we don't
On 08/27/2018 10:27 PM, Jeff Law wrote:
On 08/27/2018 10:27 AM, Martin Sebor wrote:
On 08/27/2018 02:29 AM, Richard Biener wrote:
On Sun, Aug 26, 2018 at 7:26 AM Jeff Law wrote:
On 08/24/2018 09:58 AM, Martin Sebor wrote:
The warning suppression for -Wstringop-truncation looks for
the next
I'll leave the AArch64 maintainers to review, but some comments.
Tamar Christina writes:
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index
> 06451f38b11822ea77323438fe8c7e373eb9e614..e7efde79bb111e820f4df44a276f6f73070ecd17
> 100644
> ---
On 08/28/2018 09:34 AM, MCC CS wrote:
> Hi again,
>
> I guess I haven't been clear enough. I don't
> have push access, is it possible for you to
> push my patch to trunk?
>
> The same patch as:
> https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01688.html
> but updated dates.
>
> 2018-08-28 MCC CS
Hi,
On Tue, 28 Aug 2018, Alexander Monakov wrote:
> > I think your proposed one
> > warrants some comments. Maybe trade speed for some clearer code?
>
> I think it's not too complicated, but how about adding this comment:
>
> profile_count m = c1.max (c2);
> /* Return 0 if counts are
On 08/28/2018 12:19 PM, Julian Brown wrote:
> diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
> index f038f4c..86be407 100644
> --- a/gcc/fortran/trans-openmp.c
> +++ b/gcc/fortran/trans-openmp.c
> @@ -1045,9 +1045,13 @@ gfc_omp_finish_clause (tree c, gimple_seq *pre_p)
>
>
On 28/08/2018 21:04, Jonathan Wakely wrote:
On 23/08/18 22:59 +0200, François Dumont wrote:
On 22/08/2018 23:45, Jonathan Wakely wrote:
On 22/08/18 23:08 +0200, François Dumont wrote:
Only operator== and != remains outside _Safe_iterator because all
my attempts to make them inline friends
This follow-up patch enables the "inheritance" of mappings for OpenACC
data constructs to work also for Fortran assumed-size arrays.
Otherwise, such arrays are (arguably, prematurely) bailed out on in the
Fortran front-end.
Tested alongside the previous patch with offloading to nvptx.
OK to
This patch implements support for array slices (with a non-zero base
element) declared on OpenACC data constructs. Any lexically-enclosed
parallel or kernels regions should "inherit" such mappings, e.g. if we
have:
#pragma acc data copy(arr[10:20])
{
#pragma acc parallel loop
for (...) {
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be installed?
This caused:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87130
H.J.
On 23/08/18 22:59 +0200, François Dumont wrote:
On 22/08/2018 23:45, Jonathan Wakely wrote:
On 22/08/18 23:08 +0200, François Dumont wrote:
Only operator== and != remains outside _Safe_iterator because all
my attempts to make them inline friends failed. I understand that
an inline friend
On 25/08/18 22:44 +0200, François Dumont wrote:
The last optimizations that get disabled when Debug mode is enable are
the algo specializations for std::deque iterators.
This patch move those algos in std namespace as they should even when
Debug mode is enable so that they get considered even
On 25/08/18 22:44 +0200, François Dumont wrote:
Note that I try to use typename deque<>::iterator or typename
deque<>::const_iterator to define Debug algos but it didn't work, gcc
was just not considering those overloads. I wonder why ?
Because you can't deduce the template arguments from
On 08/28/2018 05:21 AM, Richard Sandiford wrote:
> All callers to vec_info::lookup_single_use are asking about the lhs of a
> statement that they're already examining. It makes more sense to pass
> that statement instead of the SSA name, since it is then easier to
> handle statements that have
On 08/28/2018 05:20 AM, Richard Sandiford wrote:
> Several callers of gimple_get_lhs deal with statements that might
> be phis. This patch makes gimple_get_lhs handle that case too,
> so that the callers don't have to.
>
>
> 2018-08-28 Richard Sandiford
>
> gcc/
> * gimple.c
On Fri, Aug 17, 2018 at 12:16:07AM -0700, Omar Sandoval wrote:
> On Thu, Aug 16, 2018 at 11:54:53PM -0700, Omar Sandoval wrote:
> > On Thu, Aug 16, 2018 at 10:27:48PM -0700, Andrew Pinski wrote:
> > > On Thu, Aug 16, 2018 at 9:29 PM Omar Sandoval wrote:
> > > >
> > > > Hi,
> > > >
> > > > This
On 08/28/2018 06:18 AM, Tamar Christina wrote:
> Hi All,
>
> Since this patch series now contains SVE support I am removing the changes
> to the SVE tests in this patch series. I assume the OK still stands as the
> only change here is undoing updates to three files.
>
> Thanks,
> Tamar
>
>
With -mavx, for
[hjl@gnu-cfl-1 skx-2]$ cat foo.i
extern float f;
extern double d;
extern int i;
void
foo (void)
{
d = f;
f = i;
}
we need to generate
vxorp[ds] %xmmN, %xmmN, %xmmN
...
vcvtss2sd f(%rip), %xmmN, %xmmX
...
vcvtsi2ss
Ping?
The original thread started at:
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00707.html
On Fri, 17 Aug 2018 at 00:19, Christophe Lyon
wrote:
>
> Ping?
>
> Le mer. 1 août 2018 à 10:03, Christophe Lyon a écrit
> :
>>
>> Ping?
>>
>>
>> On 13/07/2018 18:10, christophe.l...@st.com wrote:
>>
On Tue, 28 Aug 2018, Richard Biener wrote:
> On Tue, Aug 28, 2018 at 11:22 AM Alexander Monakov wrote:
> >
> > This converts the use in bb-reorder. I had to get a little bit creative
> > with
> > the comparator as profile_count::operator> does not implement a strict weak
> > order.
>
> So the
Hi again,
I guess I haven't been clear enough. I don't
have push access, is it possible for you to
push my patch to trunk?
The same patch as:
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01688.html
but updated dates.
2018-08-28 MCC CS
gcc/
PR tree-optimization/87009
*
Previously the logic that turned "a/b/c/../.." into "a/" failed to
preserve an empty path at the end of the iteration sequence, as required
by the trailing slash. That meant the result didn't meet the class
invariants, and that "a/b/c/d/../../.." would remove four components
instead of the three
I am testing the following.
Richard.
2018-08-28 Richard Biener
PR tree-optimization/87126
* tree-ssa-sccvn.c (vn_reference_insert): Remove assert.
* gcc.dg/tree-ssa/pr87126.c: New testcase.
Index: gcc/tree-ssa-sccvn.c
Hi,
PR 86726 is pointing out that -ftree-scev-cprop is not documented.
Here's documentation for the final-value-replacement aspect of the
option. It technically can also replace in-loop references by
constants, but that doesn't seem very useful.
I'm not aware of any required order for option
On Tue, 2018-08-28 at 14:26 +0200, Jakub Jelinek wrote:
> On Tue, Aug 28, 2018 at 08:43:59AM +0200, Jakub Jelinek wrote:
> > On Mon, Aug 27, 2018 at 08:32:11PM -0400, David Malcolm wrote:
> > > gcc/ChangeLog:
> > > * dumpfile.h (ATTRIBUTE_GCC_DUMP_PRINTF): Change version check
> > > on
> > >
On 08/26/2018 03:18 PM, Stafford Horne wrote:
> -mm-dd Stafford Horne
> Richard Henderson
>
> gcc/ChangeLog:
>
> * common/config/or1k/or1k-common.c: New file.
> * config/or1k/*: New.
> * config.gcc (or1k*-*-*): New.
> * configure.ac (or1k*-*-*): New
On 08/28/18 11:25, Bernd Edlinger wrote:
> On 08/28/18 04:55, Jeff Law wrote:
>> On 08/23/2018 08:48 AM, Bernd Edlinger wrote:
>>> On 08/23/18 16:24, Jeff Law wrote:
>
> Yes, and which one was the earlier, more controversial patch from me?
Another one.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2018-08-28 Richard Biener
PR tree-optimization/87117
* tree-ssa-sccvn.c (eliminate_dom_walker::eliminate_stmt): Only
re-value-number released SSA VDEFs.
*
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2018-08-28 Richard Biener
PR tree-optimization/87124
* tree-ssa-sccvn.c (vn_lookup_simplify_result): Guard against
constants before looking up avail.
* g++.dg/torture/pr87124.C: New
On Tue, Aug 28, 2018 at 11:22 AM Alexander Monakov wrote:
>
> This converts the use in bb-reorder. I had to get a little bit creative with
> the comparator as profile_count::operator> does not implement a strict weak
> order.
So the previously used comparator was invalid? I think your proposed
On 08/28/2018 08:43 AM, Paolo Carlini wrote:
Hi,
this low priority ICE on invalid happens only in c++98 mode but I think
we can as well avoid it and have consistent error recovery across std
modes. Essentially, the VAR_DECL for 'b' with erroneous TREE_TYPE (the
type is incomplete) reaches
On Tue, Aug 28, 2018 at 11:17 AM Alexander Monakov wrote:
>
> This converts std::stable_sort use in tree-loop-distribution to
> gcc_stablesort.
>
> * gcc/tree-loop-distribution.c (offset_cmp): Convert to C-qsort-style
> tri-state comparator.
> (fuse_memset_builtins):
On Tue, Aug 28, 2018 at 11:14 AM Alexander Monakov wrote:
>
> This adds a stable sort to sort.cc: mergesort implementation is stable, so
> we just need network sort limited to sizes 2-3 to get the complete sort
> stable.
>
> As I don't want to duplicate code for this, I've chosen to have
Hi Joseph,
On Mon, Aug 27, 2018 at 05:24:51PM +, Joseph Myers wrote:
> On Mon, 27 Aug 2018, Stafford Horne wrote:
>
> > gcc/config/or1k/elf.opt | 33 +
>
> > gcc/config/or1k/or1k.opt | 41 +
>
> Command-line options need documenting in invoke.texi. This patch
Hi,
this low priority ICE on invalid happens only in c++98 mode but I think
we can as well avoid it and have consistent error recovery across std
modes. Essentially, the VAR_DECL for 'b' with erroneous TREE_TYPE (the
type is incomplete) reaches cxx_eval_constant_expression and we ICE when
we
Committed as r263916.
Thanks for taking a look over it, Thomas.
Paul
On Mon, 27 Aug 2018 at 20:26, Thomas Koenig wrote:
>
> Hi Paul,
>
> > Bootstrapped and regtested on FC28/x86_64 - OK for trunk?
>
> OK, and thanks for the patch!
>
> Regards
>
> Thomas
--
"If you can't explain it
ping
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00108.html
On 08/01/2018 04:07 PM, Sam Tebbs wrote:
Hi all,
This patch adds an optimisation that exploits the AArch64 BFXIL
instruction when or-ing the result of two bitwise and operations
with non-overlapping bitmasks
(e.g. (a & 0x)
On Tue, Aug 28, 2018 at 08:43:59AM +0200, Jakub Jelinek wrote:
> On Mon, Aug 27, 2018 at 08:32:11PM -0400, David Malcolm wrote:
> > gcc/ChangeLog:
> > * dumpfile.h (ATTRIBUTE_GCC_DUMP_PRINTF): Change version check on
> > GCC_VERSION for usage of "__gcc_dump_printf__" format from
> > >=
Hi all,
This patch adds basic support for SVE stack clash protection.
It is a first implementation and will use a loop to do the
probing and stack adjustments.
An example sequence is:
.cfi_startproc
mov x15, sp
cntbx16, all, mul #11
add x16, x16, 304
Hi All,
As requested this patch series now contains basic SVE support, following that
I am updating this patch to remove the error/warnings generated when SVE is
used.
The series now consists of 7 patches but I will only send updates for those
that changed.
Ok for trunk?
Thanks,
Tamar
gcc/
Hi All,
Since this patch series now contains SVE support I am removing the changes
to the SVE tests in this patch series. I assume the OK still stands as the
only change here is undoing updates to three files.
Thanks,
Tamar
gcc/testsuite/
2018-08-28 Tamar Christina
PR target/86486
H
The attached patch extends malloc_candidate_p to handle multiple phis.
There's a lot of noise in the patch because I moved most of
malloc_candidate_p into
new function malloc_candidate_p_1. The only real change is following hunk:
+ gimple *arg_def = SSA_NAME_DEF_STMT (arg);
+
One of the warts of the vectoriser IR is that it doesn't link SSA name
uses for pattern statements, leading to complicated special cases in
vect_mark_stmts_to_be_vectorized and (especially) vect_detect_hybrid_slp.
It also makes it harder to check how an SSA name is used after pattern
replacement
The point of this patch is to put pattern statements in the same
vec_basic_block as the statements they replace, with the pattern
statements for S coming between S and S's original predecessor.
This removes the need to handle them specially in various places.
2018-08-28 Richard Sandiford
The vectoriser normally leaves a later DCE pass to remove the scalar
code, but we've accumulated various special cases for things that
DCE can't handle, such as removing the scalar stores that have been
replaced by vector stores, and the scalar calls to internal functions.
(The latter must be
This patch adds a vec_basic_block that records the scalar phis and
scalar statements that we need to vectorise. This is a slight
simplification in its own right, since it avoids unnecesary statement
lookups and shaves >50 LOC. But the main reason for doing it is
to allow the rest of the series
All callers to vec_info::lookup_single_use are asking about the lhs of a
statement that they're already examining. It makes more sense to pass
that statement instead of the SSA name, since it is then easier to
handle statements that have been replaced by pattern statements.
A later patch adds
Several callers of gimple_get_lhs deal with statements that might
be phis. This patch makes gimple_get_lhs handle that case too,
so that the callers don't have to.
2018-08-28 Richard Sandiford
gcc/
* gimple.c (gimple_get_lhs): Handle gphis.
* tree-ssa-phionlycprop.c
The goal of this series is to make vector pattern statements
less special compared to normal bb statements, and thus make
them easier to work with. It picks up the tail end of:
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01821.html
Patch 08/11 from that series turned out to be wrong, for
Hi,
thanks for the answer.
> Switching on the frame pointer typically costs 1-2% performance, so
it's a bad
> idea to use it. However changing the frame pointer like in the
proposed patch
> will have a much larger cost - both in performance and codesize.
You'd be
> lucky if it is less than
On Tue, Aug 28, 2018 at 12:31 PM Richard Sandiford
wrote:
>
> This test was failing for Power 7 due to the lack of hw support
> for unaligned accesses.
>
> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
> OK to install?
OK.
> Richard
>
>
> 2018-08-28 Richard Sandiford
On Tue, Aug 28, 2018 at 12:39 PM Richard Sandiford
wrote:
>
> Fixes many testsuite failures for SVE.
>
> Tested on aarch64-linux-gnu (with and without SVE), aarch64_be-elf
> and x86_64-linux-gnu. OK to install?
OK.
Richard.
> Richard
>
>
> 2018-08-28 Richard Sandiford
>
> gcc/
> *
Fixes many testsuite failures for SVE.
Tested on aarch64-linux-gnu (with and without SVE), aarch64_be-elf
and x86_64-linux-gnu. OK to install?
Richard
2018-08-28 Richard Sandiford
gcc/
* tree-ssa-sccvn.c (fully_constant_vn_reference_p): Fix unguarded
use of tree_to_shwi.
This test was failing for Power 7 due to the lack of hw support
for unaligned accesses.
Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
OK to install?
Richard
2018-08-28 Richard Sandiford
gcc/testsuite/
PR testsuite/87078
* gcc.dg/vect/slp-37.c:
On Tue, Aug 28, 2018 at 9:11 AM Martin Liška wrote:
>
> On 08/27/2018 05:21 PM, Richard Biener wrote:
> > On Mon, Aug 27, 2018 at 4:05 PM Martin Liška wrote:
> >>
> >> Hi.
> >>
> >> Now we should not meet a degenerated gswitch statements.
> >>
> >> Patch can bootstrap on x86_64-linux-gnu and
On Tue, Aug 28, 2018 at 7:59 AM Alexander Monakov wrote:
>
> > > > So - how difficult is it to fix BRIG to not use MULT_HIGHPART_EXPR if
> > > > not supported?
>
> Richard, how should we proceed from here? Do you like the solution in the
> initial mail, or would you prefer something else? FWIW
On Tue, Aug 28, 2018 at 11:55 AM Richard Biener
wrote:
>
> On Tue, Aug 28, 2018 at 6:27 AM Jeff Law wrote:
> >
> > On 08/27/2018 10:27 AM, Martin Sebor wrote:
> > > On 08/27/2018 02:29 AM, Richard Biener wrote:
> > >> On Sun, Aug 26, 2018 at 7:26 AM Jeff Law wrote:
> > >>>
> > >>> On 08/24/2018
On Tue, Aug 28, 2018 at 6:27 AM Jeff Law wrote:
>
> On 08/27/2018 10:27 AM, Martin Sebor wrote:
> > On 08/27/2018 02:29 AM, Richard Biener wrote:
> >> On Sun, Aug 26, 2018 at 7:26 AM Jeff Law wrote:
> >>>
> >>> On 08/24/2018 09:58 AM, Martin Sebor wrote:
> The warning suppression for
On Tue, Aug 28, 2018 at 4:37 AM Martin Sebor wrote:
>
> Richard, please let me know if the patch is acceptable as is
> (with the RejectNegative property added). As I said, I realize
> it's not ideal, but neither is any of the alternatives we have
> discussed. They all involve trade- offs, and I
On Tue, 28 Aug 2018, Jakub Jelinek wrote:
> Hi!
>
> The following patch fixes some bugs in maybe_warn_nonstring_arg.
> The testcase ICEs, because lenrng[1] is a PLUS_EXPR, but the code assumes
> without checking that it must be INTEGER_CST and feeds it into
> tree_int_cst_lt. If the upper bound
On Mon, Aug 27, 2018 at 10:31 PM Jeff Law wrote:
>
>
> We recently changes tree-ssa-dse.c to not trim stores outside the bounds
> of the referenced object. This is generally a good thing.
>
> However, there are cases where the object doesn't have a usable size.
> We see this during kernel
On 08/28/2018 05:27 AM, Richard Biener wrote:
On Mon, Aug 27, 2018 at 2:24 PM Aldy Hernandez wrote:
Howdy!
Phew, I think this is the last abstraction. This handles the unary
CONVERT_EXPR_P code.
It's the usual story-- normalize the symbolics to [-MIN,+MAX] and handle
everything
On Mon, Aug 27, 2018 at 2:24 PM Aldy Hernandez wrote:
>
> Howdy!
>
> Phew, I think this is the last abstraction. This handles the unary
> CONVERT_EXPR_P code.
>
> It's the usual story-- normalize the symbolics to [-MIN,+MAX] and handle
> everything generically.
>
> Normalizing the symbolics
On 08/28/18 04:55, Jeff Law wrote:
> On 08/23/2018 08:48 AM, Bernd Edlinger wrote:
>> On 08/23/18 16:24, Jeff Law wrote:
Yes, and which one was the earlier, more controversial patch from me?
>>>
>>> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
>>>
>>>
>>> Which is the issue
This converts the use in bb-reorder. I had to get a little bit creative with
the comparator as profile_count::operator> does not implement a strict weak
order.
* gcc/bb-reorder.c (edge_order): Convert to C-qsort-style
tri-state comparator.
(reorder_basic_blocks_simple):
On Tue, Aug 28, 2018 at 11:03 AM Alexander Monakov wrote:
>
> Hi,
>
> This is an independently useful patch that makes it easier to introduce
> gcc_stablesort.
>
> Swap responsibilities of gcc_qsort and qsort_chk: call the checking function
> from the sorting function instead of wrapping
This converts std::stable_sort use in tree-loop-distribution to gcc_stablesort.
* gcc/tree-loop-distribution.c (offset_cmp): Convert to C-qsort-style
tri-state comparator.
(fuse_memset_builtins): Change std::stable_sort to gcc_stablesort .
diff --git
This adds a stable sort to sort.cc: mergesort implementation is stable, so
we just need network sort limited to sizes 2-3 to get the complete sort stable.
As I don't want to duplicate code for this, I've chosen to have gcc_qsort
accept bit-inverted 'size' parameter to request stable sorting.
Hi,
This is an independently useful patch that makes it easier to introduce
gcc_stablesort.
Swap responsibilities of gcc_qsort and qsort_chk: call the checking function
from the sorting function instead of wrapping gcc_qsort with qsort_chk.
* gcc/sort.cc (gcc_qsort) [CHECKING_P]: Call
Gentle ping.
On 06/08/18 17:14, Vlad Lazar wrote:
Hi,
The patch adds support for the TARGET_COMPUTE_FRAME_LAYOUT hook on AArch64
and removes unneeded frame layout recalculation.
The removed aarch64_layout_frame calls are unnecessary because the functions in
which
they appear will be called
Gentle ping.
On 08/08/18 17:38, Vlad Lazar wrote:
On 01/08/18 18:35, James Greenhalgh wrote:
On Wed, Aug 01, 2018 at 07:13:53AM -0500, Vlad Lazar wrote:
On 31/07/18 22:48, James Greenhalgh wrote:
On Fri, Jul 20, 2018 at 04:37:34AM -0500, Vlad Lazar wrote:
Hi,
The patch adds implementations
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
2018-08-28 Richard Biener
PR tree-optimization/87117
* tree-ssa-sccvn.c (eliminate_dom_walker::eliminate_cleanup):
Handle removed stmt without LHS (GIMPLE_NOP).
Index: gcc/tree-ssa-sccvn.c
For now give up on predicated values when doing PRE (there's a
similar hunk in PHI-translation already). I need to sit down
and decide whether it's worth handling them or whether we'd
better prune them from the hash tables when assigning value-ids.
Bootstrap and regtest running on
Err, see comment of [1/4] ;)
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
2018-08-28 Richard Biener
PR tree-optimization/87117
* tree-ssa-operands.c (add_stmt_operand): STRING_CST may
get virtual operands.
(get_expr_operands): Handle STRING_CST
I believe Micha stumbled over this as well. For stores to
string literals we miss VDEFs and loads from STRING_CSTs miss
VUSEs.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
2018-08-28 Richard Biener
PR tree-optimization/87117
* tree-ssa-sccvn.c
Hi!
The following patch fixes some bugs in maybe_warn_nonstring_arg.
The testcase ICEs, because lenrng[1] is a PLUS_EXPR, but the code assumes
without checking that it must be INTEGER_CST and feeds it into
tree_int_cst_lt. If the upper bound is NULL or is some expression
other than INTEGER_CST,
1 - 100 of 103 matches
Mail list logo
