On Nov 19, 2014, at 1:57 PM, Jakub Jelinek ja...@redhat.com wrote:
Though, following patch is just fine for me too, I don't think it will
make a significant difference:
This version is fine by me.
--- gcc/simplify-rtx.c2014-11-19 15:39:24.073113107 +0100
+++ gcc/simplify-rtx.c
On 10/26/14 15:34, Sebastian Pop wrote:
I have tried to understand why the code generation part ICEs on coremark: the
first problem that I have seen is that tree-ssa-threadupdate.c does not handle
more than a joiner block per path to be threaded, so we would not be able to
jump thread accross
On Wed, 2014-11-19 at 22:36 +0100, Richard Biener wrote:
On November 19, 2014 10:09:56 PM CET, Andrew MacLeod amacl...@redhat.com
wrote:
On 11/19/2014 03:43 PM, Richard Biener wrote:
On November 19, 2014 8:26:23 PM CET, Andrew MacLeod
amacl...@redhat.com wrote:
On 11/19/2014 01:12 PM,
On Wed, 2014-11-19 at 17:24 -0500, David Malcolm wrote:
On Wed, 2014-11-19 at 22:36 +0100, Richard Biener wrote:
On November 19, 2014 10:09:56 PM CET, Andrew MacLeod amacl...@redhat.com
wrote:
On 11/19/2014 03:43 PM, Richard Biener wrote:
On November 19, 2014 8:26:23 PM CET, Andrew
Third and final patch of the series, dealing this time with the test output
patterns for darwin when llvm-symbolizer is not present.
Here, the only issue is cosmetic: we have an extra space after each frame
pointer, i.e.
#0 0x106ddaf14 (/Users/fx/devel/gcc/irun2/./a.out+0x10f14)
#1
On 11/19/2014 05:28 PM, David Malcolm wrote:
On Wed, 2014-11-19 at 17:24 -0500, David Malcolm wrote:
On Wed, 2014-11-19 at 22:36 +0100, Richard Biener wrote:
On November 19, 2014 10:09:56 PM CET, Andrew MacLeod amacl...@redhat.com
wrote:
On 11/19/2014 03:43 PM, Richard Biener wrote:
On
On 11/15/2014 06:46 PM, Sandra Loosemore wrote:
On 11/15/2014 04:49 PM, Jan-Benedict Glaw wrote:
Hi,
On Sun, 2014-11-16 00:36:27 +0100, Jan Hubicka hubi...@ucw.cz wrote:
Yep, it is because my code does not handle streaming of arrays
into the target optimization nodes. I will take a look on
On 11/19/2014 05:24 PM, David Malcolm wrote:
On Wed, 2014-11-19 at 22:36 +0100, Richard Biener wrote:
On November 19, 2014 10:09:56 PM CET, Andrew MacLeod amacl...@redhat.com
wrote:
On 11/19/2014 03:43 PM, Richard Biener wrote:
On November 19, 2014 8:26:23 PM CET, Andrew MacLeod
On Nov 14, 2014, at 2:26 AM, Richard Biener richard.guent...@gmail.com wrote:
On Fri, Nov 14, 2014 at 2:10 AM, Jeff Law l...@redhat.com wrote:
On 11/13/14 12:37, Mike Stump wrote:
I was doing a merge, and it failed to even compile the runtime
libraries due to checking in bitmap. bitmap goes
Hi,
For ILP32 on AARCH64, we have ptr_mode != Pmode (we have ptr_mode
being SImode while Pmode is DImode and POINTER_SIZE is 32). This
breaks ipa-polymorphic-call assumption that Pmode is the correct mode
for pointers. Right now before this patch we get many testcase
failures in the C++
On Wed, Nov 19, 2014 at 4:54 PM, Andrew Pinski pins...@gmail.com wrote:
Hi,
For ILP32 on AARCH64, we have ptr_mode != Pmode (we have ptr_mode
being SImode while Pmode is DImode and POINTER_SIZE is 32). This
breaks ipa-polymorphic-call assumption that Pmode is the correct mode
for pointers.
On Wed, Nov 19, 2014 at 5:11 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Nov 19, 2014 at 4:54 PM, Andrew Pinski pins...@gmail.com wrote:
Hi,
For ILP32 on AARCH64, we have ptr_mode != Pmode (we have ptr_mode
being SImode while Pmode is DImode and POINTER_SIZE is 32). This
breaks
On Wed, Nov 19, 2014 at 5:23 PM, Andrew Pinski pins...@gmail.com wrote:
On Wed, Nov 19, 2014 at 5:11 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Nov 19, 2014 at 4:54 PM, Andrew Pinski pins...@gmail.com wrote:
Hi,
For ILP32 on AARCH64, we have ptr_mode != Pmode (we have ptr_mode
being
On Wed, Nov 19, 2014 at 5:35 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Nov 19, 2014 at 5:23 PM, Andrew Pinski pins...@gmail.com wrote:
On Wed, Nov 19, 2014 at 5:11 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Nov 19, 2014 at 4:54 PM, Andrew Pinski pins...@gmail.com wrote:
Hi,
For
On Wed, Nov 19, 2014 at 5:36 PM, Andrew Pinski pins...@gmail.com wrote:
On Wed, Nov 19, 2014 at 5:35 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Nov 19, 2014 at 5:23 PM, Andrew Pinski pins...@gmail.com wrote:
On Wed, Nov 19, 2014 at 5:11 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Nov
On Wed, Nov 19, 2014 at 5:37 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Nov 19, 2014 at 5:36 PM, Andrew Pinski pins...@gmail.com wrote:
On Wed, Nov 19, 2014 at 5:35 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Nov 19, 2014 at 5:23 PM, Andrew Pinski pins...@gmail.com wrote:
On Wed, Nov
I didn't make the change conditional for C++14 or any other version. Volatile
scalars weren't memcpyable anyway, so I thought that this should just
apply to all standard versions we support. Tested on Linux-x64.
/cp
2014-11-20 Ville Voutilainen ville.voutilai...@gmail.com
PR c++/63959
On Wed, Nov 19, 2014 at 5:39 PM, Andrew Pinski pins...@gmail.com wrote:
On Wed, Nov 19, 2014 at 5:37 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Nov 19, 2014 at 5:36 PM, Andrew Pinski pins...@gmail.com wrote:
On Wed, Nov 19, 2014 at 5:35 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Nov
On Wed, Nov 19, 2014 at 5:53 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Nov 19, 2014 at 5:39 PM, Andrew Pinski pins...@gmail.com wrote:
On Wed, Nov 19, 2014 at 5:37 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Nov 19, 2014 at 5:36 PM, Andrew Pinski pins...@gmail.com wrote:
On Wed, Nov
On Wed, Nov 19, 2014 at 5:55 PM, Andrew Pinski pins...@gmail.com wrote:
On Wed, Nov 19, 2014 at 5:53 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Nov 19, 2014 at 5:39 PM, Andrew Pinski pins...@gmail.com wrote:
On Wed, Nov 19, 2014 at 5:37 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Nov
On 11/20/14 1:20, Joseph Myers wrote:
On Wed, 19 Nov 2014, Chen Gang wrote:
OK, thanks, what you said sounds reasonable to me. We need '(' and ')'
for negative members, and LL for the members which is larger than 32
bits.
I don't think LL is a good idea when not needed - quite possibly
VRP may simplify a conditional like i = 5 to i == 5 if it is known that
the lower bound of i's range is 5, e.g. [5, +INF]. But if the upper
bound of i's range is also overflow infinity, i.e. [5, +INF(OVF)] then
this transformation is only valid if -fstrict-overflow is in effect.
Likewise for
In this testcase, the problem was that we were instantiating the
non-dependent template argument but then trying to perform conversions
on it back in the template context, so we got a confusion of template
and non-template trees. This patch changes convert_nontype_argument to
leave
OK, thanks.
Jason
On Wed, Nov 19, 2014 at 10:21 PM, Patrick Palka patr...@parcs.ath.cx wrote:
VRP may simplify a conditional like i = 5 to i == 5 if it is known that
the lower bound of i's range is 5, e.g. [5, +INF]. But if the upper
bound of i's range is also overflow infinity, i.e. [5, +INF(OVF)] then
this
Sandra,
I can explain why this is needed, at least.
The Nios II architecture optionally allows custom instructions that
are typically used to implement floating-point operations. The nios2
GCC backend knows to generate these instructions if the user tells it
what opcodes implement these
On 11/19/2014 09:34 PM, Jan Hubicka wrote:
[snip]
I see three possible fixes:
1) extend the AWk script to recognize arrays and stream them specially
(it already recognizes string so it is not hard to do, just bit wasteful)
2) add attribute to .opt file allowing user to specify his own
It's not clear to me if I can approve my own patches to the jit, so
here's a fix for PR 63969.
Tested via make check-jit on Fedora 20 x86_64; testcase segfaults
without the fix to jit-playback.c and is fixed with it; all other
testcases continue to pass.
OK for trunk?
From
On Thu, Nov 20, 2014 at 03:19:11AM +0100, Bernd Schmidt wrote:
Thomas had apparently already pointed out an issue with the new gomp_target
class (there are multiple similar types of statements we want to handle with
OpenACC, they have different codes but we want to have function pointers
On Nov 19, 2014, at 10:23 PM, David Malcolm dmalc...@redhat.com wrote:
It's not clear to me if I can approve my own patches to the jit
So, to answer that, we look at MAINTAINERS, and look up your name:
Various Maintainers
jit David Malcolm
On 19 November 2014 19:05, Charles Baylis charles.bay...@linaro.org wrote:
PR target/63870
* config/aarch64/aarch64-builtins.c (aarch64_simd_expand_args): Pass
expression to aarch64_simd_lane_bounds.
* config/aarch64/aarch64-protos.h (aarch64_simd_lane_bounds):
201 - 231 of 231 matches
Mail list logo
