On 04/22/17 01:50, Martin Sebor wrote:
> On 04/20/2017 02:35 PM, Bernd Edlinger wrote:
>> Hi!
>>
>>
>> This implements a new -Wall enabled warning for a rather common, but
>> completely wrong way to compute an array size by dividing the
>> sizeof(pointer) / sizeof(pointer[0]) or sizeof(*pointer).
>
Bug 80486 - spurious -Walloc-size-larger-than and
-Wstringop-overflow in dominance.c during profiledbootstrap
points out a number of warnings that show up in dominance.c
during a profiledbootstrap. I'm pretty sure the warnings
are due to the size check the C++ new expression introduces
to avoid u
On 04/20/2017 02:35 PM, Bernd Edlinger wrote:
Hi!
This implements a new -Wall enabled warning for a rather common, but
completely wrong way to compute an array size by dividing the
sizeof(pointer) / sizeof(pointer[0]) or sizeof(*pointer).
It is often hard to find this kind of error by simple c
Bug 77671 - missing -Wformat-overflow warning on sprintf overflow
with "%s", is caused by gimple-fold.c transforming s{,n}printf
calls with a plain "%s" format string into strcpy regardless of
whether they are valid well before the -Wformtat-overflow warning
has had a chance to validate them.
The
> On Apr 21, 2017, at 5:41 AM, James Greenhalgh
> wrote:
>
> On Tue, Apr 18, 2017 at 05:38:48PM -0500, Bill Schmidt wrote:
>> Hi,
>>
>> While investigating a performance issue, I happened to notice that vectorized
>> COND_EXPRs were not contributing to the vectorizer cost model. This patch
>>
2017-04-21 20:47 GMT+02:00 Janus Weil :
> 2017-04-21 19:49 GMT+02:00 Steve Kargl :
>> The patch looks ok to me.
>
> Thanks, Steve. I will at least commit to trunk now.
Committed to trunk as r247069.
Cheers,
Janus
>> On Fri, Apr 21, 2017 at 06:57:14PM +0200, Janus Weil wrote:
>>> Ping! I was ho
On 04/21/17 21:50, Joseph Myers wrote:
> On Fri, 21 Apr 2017, Bernd Edlinger wrote:
>
>> So I would like to add a -fprofile-abs-path option that
>> forces absolute path names in gcno files, which allows gcov
>> to get the true canonicalized source name.
>
> I don't see any actual documentation of
On Fri, Apr 21, 2017 at 08:47:47PM +0200, Janus Weil wrote:
> 2017-04-21 19:49 GMT+02:00 Steve Kargl :
>
> > You'll need Release Manager
> > approval (jakub, richi, or maybe law) to apply the
> > patch to the 7-branch.
>
> I know. Would anyone of those gentlemen see the possibility of
> accepting
On Fri, 21 Apr 2017, Bernd Edlinger wrote:
> So I would like to add a -fprofile-abs-path option that
> forces absolute path names in gcno files, which allows gcov
> to get the true canonicalized source name.
I don't see any actual documentation of this option in the patch (you add
it to the summ
The check for matching type when initializing a subaggregate needed to
know about flexible array types.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 251d142a1046a1a6cfcbafd29fabd163ec78d7cb
Author: Jason Merrill
Date: Mon Apr 17 16:55:21 2017 -0400
PR c++/80179 - ICE with
Hello!
With proper pattern shadowing, we don't need UNSPEC_NOREX_MEM tag.
2017-04-21 Uros Bizjak
* config/i386/i386.md (*extzvqi_mem_rex64): Move above *extzv.
Remove UNSPEC_NOREX_MEM tag. Update corresponding peephole2 pattern.
(*insvqi_1_mem_rex64): Move above insv_1. Remove
On Fri, Apr 21, 2017 at 7:15 AM, Markus Trippelsdorf
wrote:
> On 2017.04.20 at 22:29 +0200, Uros Bizjak wrote:
>>
>> PR target/79804
>> * gcc.target/i386/pr79804.c: New test.
>>
>> Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
>>
>> Committed to mainline SVN.
>
> The test
Hi!
This removes some dead and unreachable code in c_common_get_alias_set:
Because cc1 was recently changed to be only called with one file at a
time, the code after "if (num_in_fnames == 1) return -1;" is no longer
reachable, and can thus be removed.
Bootstrapped and reg-tested on x86_64-pc-li
2017-04-21 19:49 GMT+02:00 Steve Kargl :
> The patch looks ok to me.
Thanks, Steve. I will at least commit to trunk now.
> You'll need Release Manager
> approval (jakub, richi, or maybe law) to apply the
> patch to the 7-branch.
I know. Would anyone of those gentlemen see the possibility of
acc
Hi!
If gcov is used in projects where gcc is invoked in different
directories, it may happen that the same source is compiled
with different relative names, and the gcov tool is thus unable
to find out, if it is the same source file or not, or to dump the
source at all, which is a limitation of t
On 4 April 2017 at 20:44, Jonathan Wakely wrote:
> We got a bug report from a customer pointing out that calling
> promise::set_value on a moved-from promise crashes instead of throwing
> an exception with error code future_errc::no_state.
>
> This fixes it, by moving the _S_check calls to *before*
On April 21, 2017 4:06:59 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>This patch attempts to implement the optimization mentioned in
>http://gcc.gnu.org/ml/gcc-patches/2017-02/msg00945.html
>If we know a (relatively small) value range for ARRAY_REF index
>in constant array load and the values in th
Something like that?
diff --git a/gcc/tree-chkp.c b/gcc/tree-chkp.c
index 3ef73a9..3fb76bc 100644
--- a/gcc/tree-chkp.c
+++ b/gcc/tree-chkp.c
@@ -3700,6 +3700,11 @@ chkp_find_bounds_1 (tree ptr, tree ptr_src,
gimple_stmt_iterator *iter)
case ARRAY_REF:
case COMPONENT_REF:
addr = g
This problem reports an assertion error when certain rtl expressions
which are not eligible as producers or consumers of a store bypass
optimization are passed as arguments to the store_data_bypass_p
function. Since the problem surfaced with tests targeting the rs6000
architecture, the proposed p
Hi,
the following patch adds fix-it info to error messages in 4 places
where the C++ parser complains about duplicate tokens.
The fix-it infos suggest to remove the duplicates.
Bootstrapped and regtested on x86_64-pc-linux-gnu.
OK for trunk?
Regards,
Volker
2017-04-21 Volker Reichelt
On Tue, 11 Apr 2017, Ximin Luo wrote:
> Copyright disclaimer
>
>
> I dedicate these patches to the public domain by waiving all of my rights to
> the work worldwide under copyright law, including all related and neighboring
> rights, to the extent allowed by law.
>
> See htt
The patch looks ok to me. You'll need Release Manager
approval (jakub, richi, or maybe law) to apply the
patch to the 7-branch.
Hmmm, gcc.gnu.org seems to be unreachable at the moment.
--
steve
On Fri, Apr 21, 2017 at 06:57:14PM +0200, Janus Weil wrote:
> Ping! I was hoping this would still m
Ping! I was hoping this would still make it into GCC 7, which
apparently is very close to being released now (branched already) ...
Cheers,
Janus
2017-04-17 11:07 GMT+02:00 Janus Weil :
> Hi all,
>
> the attached patch fixes an ICE-on-valid regression, where the
> compiler runs into an infinite
Hi!
This patch attempts to implement the optimization mentioned in
http://gcc.gnu.org/ml/gcc-patches/2017-02/msg00945.html
If we know a (relatively small) value range for ARRAY_REF index
in constant array load and the values in the array for all the indexes
in the array are the same (and constant)
This disables deprecated warnings within our own headers, so that you
don't get loads of warnings about std::auto_ptr from -Wsystem-headers
just because std::shared_ptr and std::unique_ptr (and std::auto_ptr
itself!) refer to it.
Users will still get warnings if they use std::auto_ptr directly.
Hi! Thank you for looking at this.
On Fri, Apr 21, 2017 at 02:39:36PM +0200, Gerald Pfeifer wrote:
> On Thu, 20 Apr 2017, Segher Boessenkool wrote:
> > + There are new options -mstack-protector-guard=global,
> > +-mstack-protector-guard=tls,
> > +-mstack-protector-guard-reg=, and
> > +
On Fri, 17 Feb 2017, Richard Biener wrote:
> On Thu, 16 Feb 2017, Richard Biener wrote:
>
> >
> > I am testing the following patch for PR79547. Those builtins do not
> > return anything that can be used to re-construct the pointer(s) passed
> > to them.
> >
> > Queued for GCC 8.
>
> Actually
Hi Segher,
On Thu, 20 Apr 2017, Segher Boessenkool wrote:
> + There are new options -mstack-protector-guard=global,
> +-mstack-protector-guard=tls,
> +-mstack-protector-guard-reg=, and
> +-mstack-protector-guard-offset=, to change how the stack
> +protector gets the value to use a
On Thu, 9 Feb 2017, Richard Biener wrote:
>
> The following patch fixes a missed optimization caused by niter analysis
> returning a complex pointer subtraction expression instead of a constant
> for a loop with a pointer IV (it looks like pointer IVs are quite common
> in libstdc++).
>
> Bootst
On Fri, Apr 21, 2017 at 12:41 PM, James Greenhalgh
wrote:
> On Tue, Apr 18, 2017 at 05:38:48PM -0500, Bill Schmidt wrote:
>> Hi,
>>
>> While investigating a performance issue, I happened to notice that vectorized
>> COND_EXPRs were not contributing to the vectorizer cost model. This patch
>> addr
This adds handling of uninitialized uses of members in constructors
to the uninit warning machinery.
Bootstrap and regtest on x86_64-unknown-linux-gnu in progress together
with a bootstrap fix to the pass_manager.
Richard.
2017-04-21 Richard Biener
PR c++/2972
* tree-ssa-uni
The following fixes uninitialized uses in pass_manager::pass_manager
which causes bootstrap failure when a fix for PR2972 is applied.
Bootstrap and regtest in progress on x86_64-unknown-linux-gnu
(together with the 2972 fix).
Richard.
2017-04-21 Richard Biener
PR bootstrap/79814
On Tue, Apr 18, 2017 at 05:38:48PM -0500, Bill Schmidt wrote:
> Hi,
>
> While investigating a performance issue, I happened to notice that vectorized
> COND_EXPRs were not contributing to the vectorizer cost model. This patch
> addresses that.
>
> Bootstrapped and tested on powerpc64le-unknown-l
On 13 April 2017 at 09:55, Ramana Radhakrishnan
wrote:
> On Wed, Apr 12, 2017 at 6:55 PM, Christophe Lyon
> wrote:
>> Hi,
>>
>> It looks like we forgot to backport the fix for PR68390 to gcc-5-branch.
>> The patch applies cleanly, and fwiw we've had it in the linaro-5
>> branch for a while.
>>
>>
Hi Bernd,
On 20 April 2017 at 21:11, Bernd Edlinger wrote:
> Hi!
>
> This is my new attempt to clean up the different cross compiler
> configurations. It turned out to be a very complicated matter,
> so I thought it would be better to postpone it to the stage1.
>
> In a canadian cross compiler s
On Sat, Feb 18, 2017 at 3:45 AM, Jason Merrill wrote:
> On Fri, Feb 17, 2017 at 6:51 AM, Richard Biener wrote:
>>
>> The following annotates two key wrappers around copy_node in the C++ FE
>> with MEM-STAT info (and with CXX_MEM_STAT_INFO this is surprisingly
>> easy, without adding _stat variant
On 04/20/2017 11:31 PM, Mike Stump wrote:
> On Apr 20, 2017, at 6:04 AM, Bin.Cheng wrote:
>>
>> On Thu, Apr 20, 2017 at 9:35 AM, Martin Liška wrote:
>>> Hello.
>>>
>>> The patch adds a new test-case for the mentioned PR. Tested on
>>> x86_64-linux-gnu
>>> and ppc64le-linux-gnu.
>>>
>>> Ready for
Hi all,
Consider the code:
typedef long long v2di __attribute__ ((vector_size (16)));
void
store_laned (v2di x, long long *y)
{
y[0] = x[1];
y[3] = x[0];
}
AArch64 GCC will generate:
store_laned:
umovx1, v0.d[0]
st1 {v0.d}[1], [x0]
str x1, [x0, 24]
Hi all,
For the testcase in the patch we currently miss a combination and generate:
foo:
dup h1, v1.h[2]
ins v0.h[3], v1.h[0]
ret
bar:
dup h1, v1.h[2]
ins v0.h[3], v1.h[0]
ret
This is because the *aarch64_simd_vec_copy_lane pattern
Hi all,
A pattern that sometimes occurs in the wild is to subtract two operands and
separately
compare them. This can be implemented as a single SUBS instruction and we
actually have
a define_insn for this: sub3_compare1.
However, I'm not sure if that's enough by itself to match these construct
Hi all,
Our sub3_compare1 pattern is not enough to catch cases where we subtract
an immediate
and compare against in PARALLEL. This is due to the RTL canonicalisation rules
that require
subtractions of immediate IMM be represented as (plus x -IMM).
So we need a bit of trickery to catch those ca
This fixes a missed PRE which causes a missed tailcall.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2017-04-21 Richard Biener
PR tree-optimization/80237
* tree-ssa-pre.c (find_leader_in_sets): Add third set argument,
defaulted to N
On Tue, Feb 14, 2017 at 3:53 PM, Richard Biener wrote:
>
> The following patch improves the constant_after_peeling estimate of
> the GIMPLE unroller by not requiring a strictly "simple-iv" but
> an evolution w/o symbols. It also avoids computing any of this for
> ops defined in a subloop of the l
On Fri, Apr 21, 2017 at 08:22:34AM +0200, Jakub Jelinek wrote:
> Hi!
>
> finish_declspecs when an error has been reported earlier when parsing
> declspecs sets specs->type = integer_type_node; for easier error recovery,
> e.g.:
> case cts_floatn_nx:
> gcc_assert (!specs->long_p && !specs
44 matches
Mail list logo
