On 18/12/15 13:16, Bernd Schmidt wrote:
On 12/18/2015 02:07 PM, Kyrill Tkachov wrote:
In this PR we have a THEN and an ELSE block where one uses the condition
reg from the preceeding comparison
but the other block has an arithmetic operation that clobbers the CC reg.
ifcvt emits the latter firs
> It's apparently another bug in the DCE pass.
But it comes from a stalled ABNORMAL flag after the FRE3 pass so:
Index: tree-ssa-pre.c
===
--- tree-ssa-pre.c (revision 231856)
+++ tree-ssa-pre.c (working copy)
@@ -4128,6
On 19/12/15 16:50 +0200, Ville Voutilainen wrote:
PR libstdc++/66693
* include/std/tuple (tuple_element, tuple_size, tuple_element_t,
__tuple_element_t): Move to...
* include/std/utility: ...here.
* testsuite/20_util/pair/astuple/astuple.cc: Adjust.
* testsuite/20_util/pair/ast
2015-12-14 21:48 GMT+01:00 Daniel Krügler :
> This is a reimplementation of __is_swappable and
> __is_nothrow_swappable according to
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4511.html
>
> and also adds a missing usage of __is_nothrow_swappable in the swap
> overload for arrays.
This patch implements the vmaxnmQ_ST and vminnmQ_ST intrinsincs. It also
implements the __ARM_FEATURE_NUMERIC_MAXMIN macro, which is defined when
__ARM_ARCH >= 8, and which enables the intrinsincs.
Tested on arm-none-eabi, armeb-none-eabi, arm-none-linux-gnueabihf.
---
gcc/
2015-XX-XX Bilyan
On Fri, Dec 18, 2015 at 11:21:38AM +0100, Dominik Vogt wrote:
> Latest patch for r2 to r4, including a test case.
> diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
> index ed684af..cba88bb 100644
> --- a/gcc/config/s390/s390.c
> +++ b/gcc/config/s390/s390.c
> @@ -9584,10 +9584,17 @@ s3
Two patches to add missing std:: qualification to prevent ADL
problems. Both are regressions, 68276 only on trunk, but 68995 has
been broken since 4.8.0 (but only affects people mixing TR1 with
C++11, and I was already rude about them in Bugzilla so won't do it
again here ;-)
Tested powerpc64le-l
This is a respin of previous patch series:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03271.html
Minus three of the smaller patches having already been committed; with the
updated version of the main patch to SRA; and the patches to DOM reworked
to avoid constructing gimple stmt's.
IMHO this fe
This is a respin of patches
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03266.html and
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03267.html, which were
"too quickly" approved before concerns with efficiency were pointed out.
I tried to change the hashing just in tree-ssa-dom.c using C++ subc
This fixes the missed vectorization of gcc.dg/vect/pr65947-2.c following the
previous patch, by cleaning up:
i_49 = 1;
...
goto ;
:
: <--- LOOP HEADER
# i_53 = PHI
into:
:
# i_53 = PHI
Allowing scalar evolution and vectorization to proceed.
A similar sequence of partial pee
This is the same as the version conditionally approved near the end of stage 1
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01948.html, plus the
requested comment and a couple of testcases for platforms where the constants
are pushed into the constant pool. (I didn't commit this at the time becaus
On 21/12/15 13:02 +, Jonathan Wakely wrote:
Two patches to add missing std:: qualification to prevent ADL
problems. Both are regressions, 68276 only on trunk, but 68995 has
Oops, I meant 68982 not 68276. Thanks, Ville.
I'll rename the test.
...the test passes with --param sra-max-scalarization-size-Ospeed.
Verified on aarch64 and with stage1 compiler for hppa, powerpc, sparc, s390.
On alpha, tree-optimized is:
MEM[(int[8] *)&a] = { 0, 1 };
MEM[(int[8] *)&a + 8B] = { 2, 3 };
MEM[(int[8] *)&a + 16B] = { 4, 5 };
MEM[(int[8] *)
On 11/12/15 19:54, Andrew Pinski wrote:
> Hi,
> The Linux kernel calls lse as atomics in /proc/cpuinfo. We should
> change aarch64-option-extensions.def to take that into account.
>
> OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions
> and tested with -mcpu=native on Thunder
On Mon, Dec 21, 2015 at 8:13 AM, Alan Lawrence wrote:
> ...the test passes with --param sra-max-scalarization-size-Ospeed.
>
> Verified on aarch64 and with stage1 compiler for hppa, powerpc, sparc, s390.
>
> On alpha, tree-optimized is:
>
> MEM[(int[8] *)&a] = { 0, 1 };
> MEM[(int[8] *)&a + 8B
On 12/18/2015 09:23 PM, Pierre-Marie de Rodat wrote:
On 12/18/2015 06:56 PM, Jason Merrill wrote:
These broke a lot of tests in the GDB C++ testsuite. Specifically, the
commit
DWARF: handle variable-length records and variant parts
Arg, sad to hear that! I did testing at some point with
Hi,
the change in my patch was intentional, I forgot to send the email. Sorry for
that.
The reason is that labels/predictions/debug statements now go specially though
DCE
and are marked as neecessary, but not really handled so (i.e. we can remove
conditional
controlling only debug statements).
T
> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Thursday, December 17, 2015 1:06 PM
> To: Jan-Benedict Glaw
> Cc: Moore, Catherine; Denis Chertykov; Eric Christopher; Matthew Fortune;
> David Edelsohn; Alexandre Oliva; Kaz Kojima; Oleg Endo; Jonathan Wakely;
> gcc-p
H.J.,
also once we get to bootstrapland with Ada and LTO, would be possible to enable
it on the LTO bootstrap tester, so we won't break it again?
Thanks,
Honza
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Moore, Catherine
> Sent: Sunday, December 13, 2015 5:12 PM
> To: Richard Henderson; gcc-patches@gcc.gnu.org
> Cc: ja...@redhat.com; Matthew Fortune
> Subject: RE: [RFA] Compac
On Mon, 2015-12-21 at 09:10 -0500, David Edelsohn wrote:
> On Mon, Dec 21, 2015 at 8:13 AM, Alan Lawrence wrote:
> > ...the test passes with --param sra-max-scalarization-size-Ospeed.
> >
> > Verified on aarch64 and with stage1 compiler for hppa, powerpc, sparc, s390.
> >
> > On alpha, tree-optimi
Hello!
> Re-testing shows ICE in Ada build. In general the symtabnodes are produced
> transparently
> on demand, so I do not see big problem in predicate using get_create, but
> perhaps we could
> think of changing this decision and manually adding symbols into symbol table
> at a time
> they
> I suppose the CFG verifier should also catch this. I wonder how this can
> lead to wrong code as opossed to infinite loop?
> I can imagine DCE being confused about non-control-flow stmt and conclude
> the abnormal path as the path leaving the loop. I will look into the
> testcase more.
:
On 21/12/15 14:59, Bill Schmidt wrote:
On powerpc64, the test passes with -mcpu=power8 (the loop is vectorized as a
reduction); however, without that, similar code is generated to Alpha (the
vectorizer decides the reduction is not worthwhile without SIMD support), and
the test fails; hence, I've
On Mon, 2015-12-21 at 15:22 +, Alan Lawrence wrote:
> On 21/12/15 14:59, Bill Schmidt wrote:
> >>>
> >>> On powerpc64, the test passes with -mcpu=power8 (the loop is vectorized
> >>> as a
> >>> reduction); however, without that, similar code is generated to Alpha (the
> >>> vectorizer decides
OK, thanks.
Jason
On 12/21/2015 04:39 PM, Jason Merrill wrote:
OK, thanks.
Committed. Thank you again!
--
Pierre-Marie de Rodat
Hi,
it's the failure of gcc.dg/guality/param-3.c on Aarch64. The strategy to make
it pass is to selectively disable -fvar-tracking-assignments for parameters so
that the location instead of the value is tracked; this was already working
for most architectures but the calling convention of aarc
Here we have forgotten to set the type_pack_expansion_p field of the
local variable "ppd" before handing it over to cp_walk_tree /
find_parameter_packs_r, which can then read this uninitialized field.
This error was spotted when compiling boost under valgrind.
>From what I can tell by the comments
Hi,
the attached Ada testcase triggers an ICE with -mbig-endian -mhard-float:
eric@polaris:~/build/gcc/arm-linux-gnueabi> gcc/xgcc -Bgcc -S p.adb -I
gcc/ada/rts -mbig-endian -mhard-float
+===GNAT BUG DETECTED==+
| 6.0.0 20151220 (experimental)
On Fri, Dec 18, 2015 at 09:10:13PM +, Joseph Myers wrote:
> On Fri, 18 Dec 2015, Marek Polacek wrote:
>
> > + tree sz = TYPE_SIZE_UNIT (TREE_TYPE (lhs_type));
> > + rhs = fold_build2_loc (loc, MULT_EXPR, rhs_type, rhs,
> > +convert (rhs_type, sz));
>
> Conv
On 21/12/15 14:59, Bill Schmidt wrote:
On powerpc64, the test passes with -mcpu=power8 (the loop is vectorized as a
reduction); however, without that, similar code is generated to Alpha (the
vectorizer decides the reduction is not worthwhile without SIMD support), and
the test fails; hence, I've
OK, thanks.
Jason
On 12/18/2015 02:55 AM, James Greenhalgh wrote:
This is a multi-part message in MIME format.
--2.2.0.1.gd394abb.dirty
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit
Hi,
PR68232 is a testsuite failure for targets with very low branch costs.
As
On 12/18/2015 11:38 AM, Bernd Schmidt wrote:
In an earlier fix, the following change was made in varasm.c for invalid
register variables:
--- trunk/gcc/varasm.c2014/08/26 14:59:59214525
+++ trunk/gcc/varasm.c2014/08/26 17:06:31214526
@@ -1371,6 +1371,11 @@ make_decl_rtl (tree dec
On 12/18/2015 10:17 AM, Jeff Law wrote:
This patch handles that return value in the caller. I've verified the
reduced testcase and original testcase now compile without problems with
a cross compiler. I've also done an x86_64-linux-gnu bootstrap &
regression test (though we know that's of very
On 12/19/2015 09:47 AM, Nathan Sidwell wrote:
Either build_constant_desc (varasm.c) should put constants into the
varpool or decl_in_symtab_p should ignore constant pool VAR_DECLS. It
appears to me that the latter is the right choice, as constant pool
entries can't be related to regular varpool
On 12/18/2015 10:07 AM, Nick Clifton wrote:
Hi Guys,
PR 68913 notes that the test gcc.dg/lto/pr61886_0.c test fails on
targets whose C library does not provide a __fread_chk function.
Since the purpose of the test is to show that GCC will correctly
discard the invocation of __fread_
On 12/17/2015 06:00 PM, Bernd Schmidt wrote:
This is a small problem found by a static analyzer, a function in
bt-load can in theory return the address of a local variable.
Bootstrapped and tested on x86_64-linux, ok?
OK.
jeff
On 12/18/2015 01:21 PM, David Malcolm wrote:
When debugging PR c++/68819 I noticed an inefficiency during
the handling of locations > LINE_MAP_MAX_LOCATION_WITH_COLS.
When combining ranges for locations with
start == caret == finish (with a NULL data ptr)
get_combined_adhoc_loc was always buil
For basic block with two preds, allow (as single entry) only when the other
edge is a backedge. Similarly for basic block with two succs,
allow (as single exit) only when the other edge is a back edge.
2015-12-21 Aditya Kumar
* graphite-scop-detection.c
(scop_detection::get_nearest_d
On 12/18/2015 01:21 PM, David Malcolm wrote:
I don't think there's a way to fix -Wmisleading-indentation if we're
in this state, so the first part of the following patch detects if
this has happened, and effectively turns off -Wmisleading-indentation
from that point onwards. To avoid a false se
On 12/21/2015 08:46 AM, Eric Botcazou wrote:
Hi,
it's the failure of gcc.dg/guality/param-3.c on Aarch64. The strategy to make
it pass is to selectively disable -fvar-tracking-assignments for parameters so
that the location instead of the value is tracked; this was already working
for most arch
On Mon, Dec 21, 2015 at 02:10:17PM -0700, Jeff Law wrote:
> On 12/18/2015 01:21 PM, David Malcolm wrote:
>
> >I don't think there's a way to fix -Wmisleading-indentation if we're
> >in this state, so the first part of the following patch detects if
> >this has happened, and effectively turns off -
We are currently failing to fold equality comparisons involving
PTRMEM_CSTs since (I think) r229018 thus making this a GCC 6 regression.
This regression shows up in the boost testsuite.
Fixed in a straightforward way. OK to commit after bootstrap + regtest?
gcc/cp/ChangeLog:
* constexpr
As outlined in the BZ, given
(x & y) & C
reassociation will turn that into
(x & C) & y
Which inhibits bit operations on various targets.
Associating as
(x & y) & C
is what we want.
My original patch did this for all binary operations. However,
reviewing the assembly code & dump files be
The GNU linker doesn't support a zero-sized global variable that is
dynamically exported, so gccgo generates those global variables with a
size of 1 byte. Unfortunately, that means that passing a global
variable to a function that takes an argument of a zero-sized type
will actually pass 1 byte, t
On Mon, Dec 21, 2015 at 4:10 PM, Ian Lance Taylor wrote:
> The GNU linker doesn't support a zero-sized global variable that is
> dynamically exported, so gccgo generates those global variables with a
> size of 1 byte. Unfortunately, that means that passing a global
> variable to a function that t
On Mon, Dec 21, 2015 at 4:19 PM, Andrew Pinski wrote:
> On Mon, Dec 21, 2015 at 4:10 PM, Ian Lance Taylor wrote:
>> The GNU linker doesn't support a zero-sized global variable that is
>> dynamically exported, so gccgo generates those global variables with a
>> size of 1 byte. Unfortunately, that
On Mon, Dec 21, 2015 at 4:19 PM, Andrew Pinski wrote:
> On Mon, Dec 21, 2015 at 4:10 PM, Ian Lance Taylor wrote:
>> The GNU linker doesn't support a zero-sized global variable that is
>> dynamically exported, so gccgo generates those global variables with a
>> size of 1 byte. Unfortunately, that
I used this recently to help reduce an aarch64 bug. No sense in not
pushing it into the trunk.
Bootstrapped and regression tested on x86_64-linux-gnu. It may have
been in an aarch64 bootstrap as well, I'm not entirely sure about that.
Installed on the trunk.
Jeff
commit e9cce2b6bb65ddfcb
> the attached Ada testcase triggers an ICE with -mbig-endian -mhard-float:
And here it is.
--
Eric Botcazoupackage body P is
procedure Split (R : Rec; A, B, C, D : out Long_Float) is
begin
A := R.A;
B := R.B;
C := R.C;
D := R.D;
end;
end P;
package P is
type Rec is re
52 matches
Mail list logo
