Hello.
Following patch fixes off by one in loop unroller where wont_exit has
not enough elements that are later on asked for.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be installed?
Martin
gcc/ChangeLog:
2017-11-08 Martin Liska
PR rtl-optim
On 12/18/2017 12:39 PM, Sandra Loosemore wrote:
> On 12/17/2017 05:05 PM, Tsimbalist, Igor V wrote:
>> -fcf-protection -mcet is incompatible with makecontext family functions
>> since they can't properly set up and destroy shadow stack pointer. This
>> change provides a mechanism to help detection
On 12/13/2017 07:39 AM, Jakub Jelinek wrote:
> Hi!
>
> While the PRED_NEGATIVE_RETURN heuristics generally works quite well, for
> qsort comparison functions and similar, including the planned C++
> spaceship operator <=> where typically negative and positive are
> approximately even it doesn't wo
On 12/18/2017 02:50 PM, Jakub Jelinek wrote:
> Hi!
>
> When backporting the wrong-code bugfix parts of PR80631 to 7.3, I've noticed
> that we perform the optimization to use the induc_val only when reduc_fn is
> IFN_REDUC_{MAX,MIN}. That is true e.g. for AVX2, but not plain SSE2, so if
> we have
On 12/14/2017 06:25 PM, Richard Sandiford wrote:
> Jeff Law writes:
>> On 10/23/2017 11:00 AM, Richard Sandiford wrote:
>>> This patch adds an rtl representation of poly_int values.
>>> There were three possible ways of doing this:
>>>
>>> (1) Add a new rtl code for the poly_ints themselves and st
On 12/12/2017 11:57 AM, Jakub Jelinek wrote:
> Hi!
>
> We ICE on the following testcase, because we first gather all cgraph nodes
> in an array and then we walk it backwards and flatten_function anything
> that has "flatten" attribute. But flatten_function can result in cgraph
> node removal and
On 12/18/2017 05:27 PM, Jakub Jelinek wrote:
On Mon, Dec 18, 2017 at 05:03:22PM -0700, Martin Sebor wrote:
Your warning is about restrict and argument overlap, what does it have to do
with unprototyped calls? Nothing. There is no restrict in that case, and
it isn't handled as builtin if it doe
On 11/21/2017 07:56 AM, Richard Biener wrote:
>>
>>
>> I considered trying to key behavior on EDGE_DFS_BACK (6->8). It'd be
>> something like don't record equivalences from a degenerate PHI where the
>> remaining edge(s) are EDGE_DFS_BACK. But I just couldn't convince
>> myself that was actually
On 12/07/2017 05:10 AM, Nathan Sidwell wrote:
> There's an unfortunate interaction between -save-temps=obj and
> -fdump-tree- when subdirectories are in play.
>
> Consider:
> g++ -fdump-tree-all -save-temps=obj -c -o tgt/x.o sub/x.cc
> we end up with a bunch of errors of the form:
> sub/x.cc:1:
On 11/27/2017 11:44 AM, James Greenhalgh wrote:
> On Wed, Nov 22, 2017 at 06:28:24PM +, Jeff Law wrote:
>> On 11/21/2017 04:57 AM, James Greenhalgh wrote:
>>> I've finally built up enough courage to start getting my head around this...
>> Can't blame you for avoiding :-) This stuff isn't my ide
On Mon, Dec 18, 2017 at 05:03:22PM -0700, Martin Sebor wrote:
> > Your warning is about restrict and argument overlap, what does it have to do
> > with unprototyped calls? Nothing. There is no restrict in that case, and
> > it isn't handled as builtin if it doesn't match the builtin's prototype.
GCC maintainers:
The following patch adds support for some missing instances of builtins,
vec_mergee, vec_mergeo, vec_float2. This patch adds the missing GCC
functionality and test cases for the builtins. The patch has been run
on:
powerpc64le-unknown-linux-gnu (Power 8 LE)
powerpc64le-unkn
On 12/18/2017 04:41 PM, Jakub Jelinek wrote:
On Mon, Dec 18, 2017 at 04:04:11PM -0700, Martin Sebor wrote:
On 12/18/2017 12:04 PM, Jakub Jelinek wrote:
On Mon, Dec 18, 2017 at 11:08:19AM -0700, Martin Sebor wrote:
It isn't optimized either way. In fact, the only indication
of a problem in the
On Mon, Dec 18, 2017 at 04:04:11PM -0700, Martin Sebor wrote:
> On 12/18/2017 12:04 PM, Jakub Jelinek wrote:
> > On Mon, Dec 18, 2017 at 11:08:19AM -0700, Martin Sebor wrote:
> > > It isn't optimized either way. In fact, the only indication
> > > of a problem in the code below is the new -Wrestric
On 12/11/2017 08:44 AM, James Greenhalgh wrote:
> Hi,
>
> In the testcase in this patch we create an SLP vector with only two
> elements. Our current vector initialisation code will first duplicate
> the first element to both lanes, then overwrite the top lane with a new
> value.
>
> This duplica
On 12/11/2017 03:54 PM, Martin Sebor wrote:
> The attr-nonstring-3.c test fails on targets that expand
> the calls to some of the tested string functions in builtins.c,
> before they reach the checker in calls.c. The failures were
> reported on powrrpc64le but tests can be constructed that fail
>
On 12/18/2017 12:04 PM, Jakub Jelinek wrote:
On Mon, Dec 18, 2017 at 11:08:19AM -0700, Martin Sebor wrote:
It isn't optimized either way. In fact, the only indication
of a problem in the code below is the new -Wrestrict warning:
So just call it as memcpy (0, 0, (size_t) 0); or memcpy (0, 0, 0
On 12/18/2017 02:45 PM, Jakub Jelinek wrote:
> Hi!
>
> As the testcase shows, we fold strlen (str) == 0 into *str == 0 before
> the strlen pass has a chance to optimize. The following patch optimizes
> loads from the known termination '\0' into lhs = '\0' and loads from the
> part of the string k
Jakub,
I'd like your thoughts on the following problem.
One of the offloading bottlenecks with GPU acceleration in OpenACC is
the nontrivial offloaded function invocation overhead. At present, GCC
generates code to pass a struct containing one field for each of the
data mappings used in the OMP c
On 12/14/2017 12:04 PM, Jeff Law wrote:
On 12/14/2017 11:55 AM, Jakub Jelinek wrote:
On Thu, Dec 14, 2017 at 11:51:26AM -0700, Martin Sebor wrote:
Well, it would be nice to get sanitizers diagnose this at runtime. If we
know the array length at compile time, simply compare after the strlen
cal
Ping: https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00665.html
On 12/11/2017 03:54 PM, Martin Sebor wrote:
The attr-nonstring-3.c test fails on targets that expand
the calls to some of the tested string functions in builtins.c,
before they reach the checker in calls.c. The failures were
reporte
On 12/13/2017 02:38 PM, Jason Merrill wrote:
On Wed, Dec 13, 2017 at 12:54 PM, Martin Sebor wrote:
The attached update also fixes both instances of the ICE
reported in bug 83322 and supersedes Jakub's patch for that
bug (https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00765.html).
This passes boo
Hi!
When backporting the wrong-code bugfix parts of PR80631 to 7.3, I've noticed
that we perform the optimization to use the induc_val only when reduc_fn is
IFN_REDUC_{MAX,MIN}. That is true e.g. for AVX2, but not plain SSE2, so if
we have a loop like:
void foo (int *v)
{
int found_index = -17;
Hi!
As the testcase shows, we fold strlen (str) == 0 into *str == 0 before
the strlen pass has a chance to optimize. The following patch optimizes
loads from the known termination '\0' into lhs = '\0' and loads from the
part of the string known to be non-zero results in ~[0, 0] range being
record
OK.
On Mon, Dec 18, 2017 at 2:56 PM, Marek Polacek wrote:
> On Mon, Dec 18, 2017 at 01:07:18PM -0500, Jason Merrill wrote:
>> On Mon, Dec 18, 2017 at 10:09 AM, Marek Polacek wrote:
>> > Here the problem was that cxx_eval_call_expression can cache the result of
>> > a
>> > constexpr call in cons
On Mon, Dec 18, 2017 at 01:07:18PM -0500, Jason Merrill wrote:
> On Mon, Dec 18, 2017 at 10:09 AM, Marek Polacek wrote:
> > Here the problem was that cxx_eval_call_expression can cache the result of a
> > constexpr call in constexpr_call_table, but we have to be careful, after
> > store_init_value
On December 18, 2017 5:06:25 PM GMT+01:00, Jeff Law wrote:
>On 12/18/2017 03:15 AM, Richard Biener wrote:
>> On Fri, Dec 15, 2017 at 6:00 PM, Richard Biener
>> wrote:
>>> On December 15, 2017 5:19:14 PM GMT+01:00, Jeff Law
>wrote:
I hate this patch.
The fundamental problem we have
On 11/17/2017 07:56 AM, Richard Sandiford wrote:
> This patch adds support for using a single fully-predicated loop instead
> of a vector loop and a scalar tail. An SVE WHILELO instruction generates
> the predicate for each iteration of the loop, given the current scalar
> iv value and the loop bo
On 12/17/2017 05:05 PM, Tsimbalist, Igor V wrote:
-fcf-protection -mcet is incompatible with makecontext family functions
since they can't properly set up and destroy shadow stack pointer. This
change provides a mechanism to help detection shadow stack compatibility.
The current proposal is to ad
--- Begin Message ---
On Mon, Dec 18, 2017 at 02:35:07PM +0100, Jakub Jelinek wrote:
> On Mon, Dec 18, 2017 at 02:17:18PM +0100, Jakub Jelinek wrote:
> > One option would be to deal with that in pop_stmt_list and the C++ caller
> > thereof, where we right now have:
> >
> > /* If the stateme
On 12/16/2017 02:03 PM, Segher Boessenkool wrote:
> In PR83424 combine's move_deaths puts a REG_DEAD not in the wrong place
> because dead_or_set_regno_p does not account for CLOBBER insns. This
> fixes it.
>
> Bootstrapped and tested on powerpc64-linux {-m32,-m64} and on x86_64-linux.
> Is this
On Mon, Dec 18, 2017 at 11:08:19AM -0700, Martin Sebor wrote:
> It isn't optimized either way. In fact, the only indication
> of a problem in the code below is the new -Wrestrict warning:
So just call it as memcpy (0, 0, (size_t) 0); or memcpy (0, 0, 0UL);
on targets where size_t is unsigned long
On 12/18/2017 11:32 AM, Bernd Edlinger wrote:
Hi Martin,
In all cases all the information necessary to detect and diagnose
or even avoid the problem is available. In fact, one might argue
that optimizing such calls (expanding them inline) would be
preferable to doing nothing and allowing the u
Hi Martin,
> In all cases all the information necessary to detect and diagnose
> or even avoid the problem is available. In fact, one might argue
> that optimizing such calls (expanding them inline) would be
> preferable to doing nothing and allowing the undefined behavior
> to cause a bug at run
On 12/18/2017 10:14 AM, David Malcolm wrote:
> Is the tweak to prune.exp at the end of this patch OK? (I can self-
> approve the rest of this).
Yes.
jeff
As noted in the BZ, this test has been compromised by Martin's changes
in .
I contemplated turning the test into pure C code, but that turns out not
to be a terribly useful thing to do.
I also contemplated gathering the CPP output prior to Martin's changes
and using that for the test. But that
On 12/18/2017 10:45 AM, Jakub Jelinek wrote:
On Mon, Dec 18, 2017 at 10:37:19AM -0700, Martin Sebor wrote:
On 12/18/2017 10:07 AM, Jakub Jelinek wrote:
On Mon, Dec 18, 2017 at 10:00:36AM -0700, Martin Sebor wrote:
On 12/18/2017 08:10 AM, Marek Polacek wrote:
I'm not entirely up to speed with
On Mon, Dec 18, 2017 at 10:09 AM, Marek Polacek wrote:
> Here the problem was that cxx_eval_call_expression can cache the result of a
> constexpr call in constexpr_call_table, but we have to be careful, after
> store_init_value the result might be invalid. So I believe we also have to
> clear the
On 16 December 2017 at 12:30, Ville Voutilainen wrote:
> The compiler-powered is_constructible that we have in gcc 8 is powerful
> enough to give the right answer to an is_constructible question
> that would be hard for a pure-library implementation to get right
> in a well-formed fashion. This is
On 15 December 2017 at 21:19, François Dumont wrote:
> Here is a patch to fix those failures of the latest report:
>
> UNRESOLVED: 23_containers/map/modifiers/extract.cc compilation failed to
> produce executable
> FAIL: 23_containers/set/modifiers/extract.cc (test for excess errors)
> UNRESOLVED:
On Mon, Dec 18, 2017 at 10:37:19AM -0700, Martin Sebor wrote:
> On 12/18/2017 10:07 AM, Jakub Jelinek wrote:
> > On Mon, Dec 18, 2017 at 10:00:36AM -0700, Martin Sebor wrote:
> > > On 12/18/2017 08:10 AM, Marek Polacek wrote:
> > > > I'm not entirely up to speed with this code, but this one seemed
On 12/18/2017 10:07 AM, Jakub Jelinek wrote:
On Mon, Dec 18, 2017 at 10:00:36AM -0700, Martin Sebor wrote:
On 12/18/2017 08:10 AM, Marek Polacek wrote:
I'm not entirely up to speed with this code, but this one seemed sufficiently
obvious: check INTEGRAL_TYPE_P before looking at a tree's min/max
Is the tweak to prune.exp at the end of this patch OK? (I can self-
approve the rest of this).
On Mon, 2017-12-11 at 15:44 -0500, David Malcolm wrote:
> In theory, the diagnostics subsystem can print context information on
> code inlining when diagnostics are emitted by the middle-end,
> describ
On Mon, Dec 18, 2017 at 10:00:36AM -0700, Martin Sebor wrote:
> On 12/18/2017 08:10 AM, Marek Polacek wrote:
> > I'm not entirely up to speed with this code, but this one seemed
> > sufficiently
> > obvious: check INTEGRAL_TYPE_P before looking at a tree's min/max value.
> > Otherwise, go with max
On 12/18/2017 08:10 AM, Marek Polacek wrote:
I'm not entirely up to speed with this code, but this one seemed sufficiently
obvious: check INTEGRAL_TYPE_P before looking at a tree's min/max value.
Otherwise, go with maxobjsize.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
Thanks for th
On 12/15/2017 06:25 AM, Tom de Vries wrote:
Proposed Solution:
The patch addresses the problem, by:
- marking the hard regs that have been used in lra_spill in
hard_regs_spilled_into
- using hard_regs_spilled_into in lra_create_live_ranges to
make sure those registers are marked in the co
On Mon, Dec 18, 2017 at 09:36:46AM -0700, Jeff Law wrote:
> On 12/18/2017 08:10 AM, Marek Polacek wrote:
> > I'm not entirely up to speed with this code, but this one seemed
> > sufficiently
> > obvious: check INTEGRAL_TYPE_P before looking at a tree's min/max value.
> > Otherwise, go with maxobjs
On 12/18/2017 08:10 AM, Marek Polacek wrote:
> I'm not entirely up to speed with this code, but this one seemed sufficiently
> obvious: check INTEGRAL_TYPE_P before looking at a tree's min/max value.
> Otherwise, go with maxobjsize.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 20
On 12/18/2017 03:35 AM, Marek Polacek wrote:
> While looking into something else I noticed that because of the missing
> warn_logical_op check we do unnecessary work in warn_logical_operator, like
> calling fold_for_warn which can put stuff into cv/fold_cache etc. It also
> causes more noise when
On 12/18/2017 03:15 AM, Richard Biener wrote:
> On Fri, Dec 15, 2017 at 6:00 PM, Richard Biener
> wrote:
>> On December 15, 2017 5:19:14 PM GMT+01:00, Jeff Law wrote:
>>> I hate this patch.
>>>
>>> The fundamental problem we have is that there are times when we very
>>> much want to thread jumps
I'm not entirely up to speed with this code, but this one seemed sufficiently
obvious: check INTEGRAL_TYPE_P before looking at a tree's min/max value.
Otherwise, go with maxobjsize.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2017-12-18 Marek Polacek
PR middle-end/83463
Here the problem was that cxx_eval_call_expression can cache the result of a
constexpr call in constexpr_call_table, but we have to be careful, after
store_init_value the result might be invalid. So I believe we also have to
clear the constexpr call table. I've lumped it together with clearing
cv
this patch fixes the handling of template friend classes of template
classes. Our current handling was somewhat messed up, possibly because
of now-clarified ambiguities in earlier versions of the std. In
particular we'd search too many namespaces looking for an existing
declaration, and if no
Hi,
On Mon, 18 Dec 2017, Richard Biener wrote:
> where *unroll is similar to *max_vf I think. dist_v[0] is the innermost loop.
[0] is always outermost loop.
> The vectorizer does way more complicated things and only looks at the
> distance with respect to the outer loop as far as I can see wh
Hi, I tried to replace 2 flags variable with c++ bitset(in patch attached).
What do you think?
> Please add these options first.
2 options left(they are under Kirill's review currently), I'll add PTAs for
them to the patch, as soon as they will be commited.
Thanks,
Julia
> -Original Messa
On Mon, Dec 18, 2017 at 02:17:18PM +0100, Jakub Jelinek wrote:
> One option would be to deal with that in pop_stmt_list and the C++ caller
> thereof, where we right now have:
>
> /* If the statement list contained exactly one statement, then
> extract it immediately. */
> if
On Sun, Dec 10, 2017 at 12:20 AM, Richard Sandiford
wrote:
> This patch adds a function for creating a VECTOR_CST from a
> vec_perm_indices, operating directly on the encoding.
Ok.
>
> 2017-12-09 Richard Sandiford
>
> gcc/
> * vec-perm-indices.h (vec_perm_indices_to_tree): Declare.
>
On Sun, Dec 10, 2017 at 12:08 AM, Richard Sandiford
wrote:
> The vec_perm code falls back to doing byte-level permutes if
> element-level permutes aren't supported. There were two copies
> of the code to calculate the mode, and later patches add another,
> so this patch splits it out into a helpe
On Mon, Dec 18, 2017 at 1:37 PM, Richard Biener
wrote:
> On Fri, Dec 15, 2017 at 7:39 PM, Bin.Cheng wrote:
>> On Fri, Dec 15, 2017 at 1:19 PM, Richard Biener
>> wrote:
>>> On Fri, Dec 15, 2017 at 1:35 PM, Bin.Cheng wrote:
On Fri, Dec 15, 2017 at 12:09 PM, Bin.Cheng wrote:
> On Fri, De
On Mon, Dec 18, 2017 at 02:02:52PM +0100, Jakub Jelinek wrote:
> Because make_node (STATEMENT_LIST) sets TREE_SIDE_EFFECTS, but the above
> memset clears it, we start with inconsistent TREE_SIDE_EFFECTS from the
> beginning.
>
> I've tried to track TREE_SIDE_EFFECTS precisely, as below, but that s
On Fri, Dec 15, 2017 at 09:34:44AM +0100, Richard Biener wrote:
> I don't like this too much. Iff then we should do "real" lazy
> computation, like adding a TREE_SIDE_EFFECTS_VALID flag on STATEMENT_LIST,
> keeping TREE_SIDE_EFFECTS up-to-date when easily possible and when doing
> the expensive th
On Fri, Dec 15, 2017 at 7:39 PM, Bin.Cheng wrote:
> On Fri, Dec 15, 2017 at 1:19 PM, Richard Biener
> wrote:
>> On Fri, Dec 15, 2017 at 1:35 PM, Bin.Cheng wrote:
>>> On Fri, Dec 15, 2017 at 12:09 PM, Bin.Cheng wrote:
On Fri, Dec 15, 2017 at 11:55 AM, Richard Biener
wrote:
> On Fr
Hi Jakub,
> On Mon, Dec 18, 2017 at 11:21:35AM +0100, Rainer Orth wrote:
>> I've been using the following in my tree. Still need to try and get
>> this upstream.
>
> Please. If that doesn't work, I think we need to do it in configure,
> sanitizer_internal_defs.h seems to be included very early,
On 14.12.2017 21:44, Gerald Pfeifer wrote:
Hi Johann,
On Wed, 13 Dec 2017, Georg-Johann Lay wrote:
This adds AVR improvements to v8 Release Notes.
that's quite impressive a set of improvements!
Index: changes.html
===
The ne
On 14/12/17 10:38, Sudakshina Das wrote:
Hi
On 13/12/17 16:56, James Greenhalgh wrote:
On Wed, Dec 13, 2017 at 04:45:33PM +, Sudi Das wrote:
On 13/12/17 16:42, Sudakshina Das wrote:
Hi
This patch is a follow up to the existing discussions on
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg
With the attached patch we get rid of the following build failure:
/home/andreas/build/../gcc/gcc/config/s390/s390.c: In function ‘void
s390_option_override()’:
/home/andreas/build/../gcc/gcc/config/s390/s390.c:15361:16: error: ‘char*
strncpy(char*, const char*, size_t)’ specified bound 256 equals
On Fri, Dec 15, 2017 at 3:19 PM, Martin Jambor wrote:
>
> Hello,
>
> the patch below prevents creation if fused-multiply-and-add instructions
> in the widening_mul gimple pass on the Zen-based AMD CPUs and as a
> result fixes regressions of native znver1 tuning when compared to
> generic tuning in
While looking into something else I noticed that because of the missing
warn_logical_op check we do unnecessary work in warn_logical_operator, like
calling fold_for_warn which can put stuff into cv/fold_cache etc. It also
causes more noise when debugging.
Bootstrapped/regtested on x86_64-linux, o
On Mon, Dec 18, 2017 at 11:21:35AM +0100, Rainer Orth wrote:
> I've been using the following in my tree. Still need to try and get
> this upstream.
Please. If that doesn't work, I think we need to do it in configure,
sanitizer_internal_defs.h seems to be included very early, so there
is no easy
Hi Jakub,
> On Tue, Nov 14, 2017 at 01:57:21PM +0100, Rainer Orth wrote:
>> > And the preexisting:
>> > case "$host" in
>> > *-*-darwin*) MAC_INTERPOSE=true ; enable_static=no ;;
>> > *) MAC_INTERPOSE=false ;;
>> > esac
>> > AM_CONDITIONAL(USING_MAC_INTERPOSE, $MAC_INTERPOSE)
>> > looks wrong
On Fri, Dec 15, 2017 at 6:00 PM, Richard Biener
wrote:
> On December 15, 2017 5:19:14 PM GMT+01:00, Jeff Law wrote:
>>I hate this patch.
>>
>>The fundamental problem we have is that there are times when we very
>>much want to thread jumps and yet there are other times when we do not.
>>
>>To date
On 18/12/17 04:09, Sandra Loosemore wrote:
On 12/14/2017 10:50 PM, Sandra Loosemore wrote:
On 12/14/2017 11:48 AM, Kyrill Tkachov wrote:
[snip]
Thanks, done. I haven't created a new Target-specific developers
options table but instead listed the targets the options apply to in
parentheses.
On Tue, Nov 14, 2017 at 01:57:21PM +0100, Rainer Orth wrote:
> > And the preexisting:
> > case "$host" in
> > *-*-darwin*) MAC_INTERPOSE=true ; enable_static=no ;;
> > *) MAC_INTERPOSE=false ;;
> > esac
> > AM_CONDITIONAL(USING_MAC_INTERPOSE, $MAC_INTERPOSE)
> > looks wrong too.
>
> Wrong in w
On 12/05/2017 10:27 AM, Jakub Jelinek wrote:
> On Tue, Nov 21, 2017 at 12:59:46PM +0100, Martin Liška wrote:
>> On 10/16/2017 10:39 PM, Martin Liška wrote:
>>> Hi.
>>>
>>> All nits included in mainline review request I've just done:
>>> https://reviews.llvm.org/D38971
>>>
>>> Martin
>>
>> Hi.
>>
>>
On Sun, Dec 17, 2017 at 09:07:54PM -0500, David Malcolm wrote:
> What do you think?
>
> Successfully bootstrapped®rtested on x86_64-pc-linux-gnu, as
> part of the kit.
>
> gcc/ChangeLog:
> * fold-const.c (operand_equal_p): Strip any location wrappers,
> before computing hashes.
> ---
75 matches
Mail list logo
