On Fri, Feb 03, 2017 at 05:39:21PM +0100, Jakub Jelinek wrote:
> Say in the http://gcc.gnu.org/ml/gcc-patches/2017-02/msg00234.html
> patch, you would with my patch need just the tree_digits part,
> and then the very last hunk in gimple-ssa-sprintf.c (with
> likely_adjust &&
> removed). Because y
On Fri, 3 Feb 2017, David Malcolm wrote:
> I took the liberty of committing this, under the "obvious" rule.
Thanks! No liberty, no need to quote the "obvious" rule, just
be my guest making changes like this (and beyond). :-)
Gerald
> On Feb 3, 2017, at 8:12 PM, Kyrill Tkachov
> wrote:
>
> Hi all,
>
> While evaluating Maxim's SW prefetch patches [1] I noticed that the aarch64
> prefetch pattern is
> overly restrictive in its address operand. It only accepts simple register
> addressing modes.
> In fact, the PRFM instruct
Hi,
The following test-case ICE's with -fgimple:
int __GIMPLE foo(int a)
{
int t1;
t1_1 = __builtin_abs (a);
return t1_1;
}
gimplefe-2.c:4:3: internal compiler error: in get_callee_fndecl, at tree.c:9500
t1_1 = __builtin_abs (a);
^~~~
0xe96e8d get_callee_fndecl(tree_node const*)
../..
Hi all,
attached patch fixes a regression when a polymorphic pointer component was
present. The results was a double free. The attached patch fixes this, by not
caring about freeing pointer components as part of gfortran's memory management,
i.e., the programmer has to take care about freeing/disa
> Hi,
> This is the main patch improving control flow graph for vectorized loop. It
> generally rewrites loop peeling stuff in vectorizer. As described in patch,
> for a typical loop to be vectorized like:
>
>preheader:
> LOOP:
>header_bb:
>loop_body
>if (e
Hi all,
attached patch takes the _len-component of unlimited polymorphic objects into
account, when source-ALLOCATEing an unlimited polymorphic object. The testcase
for this gcc/testsuite/gfortran.dg/alloc_comp_class_5.f03 with
valgrind/sanitizer. I therefore added no additional testcase.
Bootstr
Hi all,
attached patch fixes the access of uninitialized data. Thanks Martin for
analyzing this so far. The symbol_attributes on the stack was used
without initializing it from the symbol's attributes.
Bootstraps and regstests ok on x86_64-linux-gnu/f25. Ok for trunk?
Regards,
Andre
--
> This patch fixes the __atomic builtins to not implement supposedly
> lock-free atomic loads based on just a compare-and-swap operation.
> …
Commit r245098 caused
New failures:
FAIL: libgomp.c/atomic-2.c (test for excess errors)
FAIL: libgomp.c/atomic-4.c (test for excess errors)
FAIL: libgomp.c
This is the first of a 4 part series to address the issues around 79095.
This patch addresses improvements in determining ranges of binary
expressions in three ways.
First if we are otherwise unable to find a range for the result of a
MINUS_EXPR, if we know the arguments are not equal, then w
This is the second in the 4 part series to address 79095. This patch
introduces a new function into tree-vrp.c to allow for the detection of
overflow checks of the form A OP A + CST (for unsigned/wrapping A).
This is implemented by first checking for A OP B, we then conditionally
walk the A
These are the tests.
The tests in g++.dg start with a reduced test from Martin (pr79095-1.C)
that includes a size check. With the size != 0 check this testcase
should not issue any warnings as the path that turns into a
__builtin_memset should get eliminated.
pr79095-2.C is the same test,
This is the actual optimization piece of the patchseries and uses the
overflow test detection function in patch #2.
First, when we detect an overflow test, we register additional
ASSERT_EXPRs for the given name. So instead of an ASSERT_EXPR for an
expression like A < B, we get an assert lik
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the French team of translators. The file is available at:
http://translationproject.org/latest/gcc/fr.po
(This file, 'gcc-7.1-b20170101.fr.po', h
Hi Andre,
This looks fine to me - OK for trunk.
Thanks
Paul
On 4 February 2017 at 11:59, Andre Vehreschild wrote:
> Hi all,
>
> attached patch fixes a regression when a polymorphic pointer component was
> present. The results was a double free. The attached patch fixes this, by not
> caring ab
Hi Andre,
This looks to be OK for trunk.
Thanks for the patch.
Paul
On 4 February 2017 at 13:11, Andre Vehreschild wrote:
> Hi all,
>
> attached patch takes the _len-component of unlimited polymorphic objects into
> account, when source-ALLOCATEing an unlimited polymorphic object. The testcase
Hi Andre,
This is getting to be a bit monotonous :-) OK for trunk.
Thanks for the three patches.
Paul
PS Are you in a position to have a stab at PR79344? This would go a
long way to sorting out Juergen's test suite. Also, this must be the
third time that I have been involved in breaking iso_var
There's a "thinko" in the get_range_strlen() function that computes
the range of possible string lengths for a character pointer that
may point to an array holding a string of unknown length and a string
literal. The bug lets the function return the length of the string
as the lower bound (and th
Thanks Segher. I will address your comments and repost for GCC 8.
> What is this for? It isn't triggered by the testcase in the PR.
It was triggered by our strcmp code, but I didn't have a simple test case for
it. I will try to generate one.
Walter
Hi Paul,
> PS Are you in a position to have a stab at PR79344? This would go a
> long way to sorting out Juergen's test suite. Also, this must be the
> third time that I have been involved in breaking iso_varying_string
> and I think that others have too :-( We must start running the
> testsuite o
On Sat, Feb 04, 2017 at 03:28:42PM +0100, Dominique d'Humières wrote:
> > This patch fixes the __atomic builtins to not implement supposedly
> > lock-free atomic loads based on just a compare-and-swap operation.
> > …
>
> Commit r245098 caused
>
> New failures:
> FAIL: libgomp.c/atomic-2.c (test
Hi all,
attached patch fixes the issue of losing the data in the SOURCE= expression of
an ALLOCATE() when the source-expression is just a simple variable. The issue
was that internally a temporary variable was created, whose components were
freed afterwards. Now the components are only freed on te
On Wed, Jan 11, 2017 at 11:13:07AM +0100, Christophe Lyon wrote:
> Ping?
>
> James, I'm not sure whether your comment was a request for a new
> version of my patch or just FYI?
Sorry that this was unclear. I was looking for a new version of the patch
covering this comment. Otherwise we just have
23 matches
Mail list logo
