On 19 November 2014 19:05, Charles Baylis 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): Update
> prot
On Nov 19, 2014, at 10:23 PM, David Malcolm 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
So, this means th
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
> op
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 0901383f1a1ad296b9
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
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 i
On Wed, Nov 19, 2014 at 10:21 PM, Patrick Palka 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 transformation is
OK, thanks.
Jason
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 processing_
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 tran
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
On Wed, Nov 19, 2014 at 5:55 PM, Andrew Pinski wrote:
> On Wed, Nov 19, 2014 at 5:53 PM, H.J. Lu wrote:
>> On Wed, Nov 19, 2014 at 5:39 PM, Andrew Pinski wrote:
>>> On Wed, Nov 19, 2014 at 5:37 PM, H.J. Lu wrote:
On Wed, Nov 19, 2014 at 5:36 PM, Andrew Pinski wrote:
> On Wed, Nov 19,
On Wed, Nov 19, 2014 at 5:53 PM, H.J. Lu wrote:
> On Wed, Nov 19, 2014 at 5:39 PM, Andrew Pinski wrote:
>> On Wed, Nov 19, 2014 at 5:37 PM, H.J. Lu wrote:
>>> On Wed, Nov 19, 2014 at 5:36 PM, Andrew Pinski wrote:
On Wed, Nov 19, 2014 at 5:35 PM, H.J. Lu wrote:
> On Wed, Nov 19, 2014 a
On Wed, Nov 19, 2014 at 5:39 PM, Andrew Pinski wrote:
> On Wed, Nov 19, 2014 at 5:37 PM, H.J. Lu wrote:
>> On Wed, Nov 19, 2014 at 5:36 PM, Andrew Pinski wrote:
>>> On Wed, Nov 19, 2014 at 5:35 PM, H.J. Lu wrote:
On Wed, Nov 19, 2014 at 5:23 PM, Andrew Pinski wrote:
> On Wed, Nov 19,
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
PR c++/63959
* tree.c (trivially_copyable
On Wed, Nov 19, 2014 at 5:37 PM, H.J. Lu wrote:
> On Wed, Nov 19, 2014 at 5:36 PM, Andrew Pinski wrote:
>> On Wed, Nov 19, 2014 at 5:35 PM, H.J. Lu wrote:
>>> On Wed, Nov 19, 2014 at 5:23 PM, Andrew Pinski wrote:
On Wed, Nov 19, 2014 at 5:11 PM, H.J. Lu wrote:
> On Wed, Nov 19, 2014 a
On Wed, Nov 19, 2014 at 5:36 PM, Andrew Pinski wrote:
> On Wed, Nov 19, 2014 at 5:35 PM, H.J. Lu wrote:
>> On Wed, Nov 19, 2014 at 5:23 PM, Andrew Pinski wrote:
>>> On Wed, Nov 19, 2014 at 5:11 PM, H.J. Lu wrote:
On Wed, Nov 19, 2014 at 4:54 PM, Andrew Pinski wrote:
> Hi,
> For
On Wed, Nov 19, 2014 at 5:35 PM, H.J. Lu wrote:
> On Wed, Nov 19, 2014 at 5:23 PM, Andrew Pinski wrote:
>> On Wed, Nov 19, 2014 at 5:11 PM, H.J. Lu wrote:
>>> On Wed, Nov 19, 2014 at 4:54 PM, Andrew Pinski wrote:
Hi,
For ILP32 on AARCH64, we have ptr_mode != Pmode (we have ptr_mode
On Wed, Nov 19, 2014 at 5:23 PM, Andrew Pinski wrote:
> On Wed, Nov 19, 2014 at 5:11 PM, H.J. Lu wrote:
>> On Wed, Nov 19, 2014 at 4:54 PM, Andrew Pinski wrote:
>>> Hi,
>>> For ILP32 on AARCH64, we have ptr_mode != Pmode (we have ptr_mode
>>> being SImode while Pmode is DImode and POINTER_SIZE
On Wed, Nov 19, 2014 at 5:11 PM, H.J. Lu wrote:
> On Wed, Nov 19, 2014 at 4:54 PM, Andrew Pinski 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
On Wed, Nov 19, 2014 at 4:54 PM, Andrew Pinski 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. Right now b
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++ testsui
On Nov 14, 2014, at 2:26 AM, Richard Biener wrote:
> On Fri, Nov 14, 2014 at 2:10 AM, Jeff Law 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 to remove set bits
>>> from t
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
wrote:
On 11/19/2014 03:43 PM, Richard Biener wrote:
On November 19, 2014 8:26:23 PM CET, Andrew MacLeod
wrote:
On 11/19/2014 01:12 PM
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 wrote:
Yep, it is because my code does not handle streaming of arrays
into the target optimization nodes. I will take a look on why
that array i
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
wrote:
On 11/19/2014 03:43 PM, Richard Biener wrote:
On November 19, 2014 8:26:2
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 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
> > wrote:
> > >On 11/19/2014 03:43 PM, Richard Biener wrote:
> > >> On November 19, 2014 8:26:23 PM CET, Andrew MacLeod
> >
On Wed, 2014-11-19 at 22:36 +0100, Richard Biener wrote:
> On November 19, 2014 10:09:56 PM CET, Andrew MacLeod
> wrote:
> >On 11/19/2014 03:43 PM, Richard Biener wrote:
> >> On November 19, 2014 8:26:23 PM CET, Andrew MacLeod
> > wrote:
> >>> On 11/19/2014 01:12 PM, David Malcolm wrote:
> >>>
>
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 th
On Nov 19, 2014, at 1:57 PM, Jakub Jelinek 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.c2014-11-19 2
Alessandro Fanfarillo wrote:
The sum of the three indexes, k, j and i returns a wrong image index.
Fixed as confirmed off list by the attached patch.
I intent to commit it as obvious once building and regtesting has
finally finished.
Comments are nontheless welcome.
Tobias
* trans-expr.c
> Ok. If anyone has a better idea, feel free to suggest it.
Thanks, committed along with the same trivial patch for
g++.dg/asan/large-func-test-1.C.
FX
2014-11-19 Francois-Xavier Coudert
PR sanitizer/63939
* g++.dg/asan/large-func-test-1.C: Ajust dg-output.
Index: g++.d
In this testcase we found ourselves trying to evaluate the address of a
CONSTRUCTOR and didn't have an object for the CONSTRUCTOR to associate
with. Fixed by handling lvalue uses of TARGET_EXPR properly. And then
we needed to fix handling of REFERENCE_TYPE parameters in the new call
mechanism
On Wed, Nov 19, 2014 at 08:52:40PM +0100, Bernd Schmidt wrote:
> Another change that's required is (something like) the following. For ptx,
> we need to know whether to output something as a .func (callable from ptx
> code) or a .kernel (callable from the host). That means we need to mark the
> ker
In some cases we were accepting in constant-expressions const variables
of non-integral type, which is not correct; variables of non-integral
type must be marked constexpr to be usable in constant expressions.
When fixing this we need to preserve the optimization that lets us use
such constant
On Wed, Nov 19, 2014 at 10:38:57AM -0800, Mike Stump wrote:
> On Nov 19, 2014, at 4:24 AM, Richard Biener wrote:
> > On Wed, 19 Nov 2014, Jakub Jelinek wrote:
> >> For TARGET_SUPPORTS_WIDE_INT == 0 should be hopefully ok. Not sure
> >> about TARGET_SUPPORTS_WIDE_INT != 0, can it express any gener
Jakub Jelinek writes:
> On Wed, Nov 19, 2014 at 09:59:45AM +0100, Richard Biener wrote:
>> > OImode/XImode on i?86/x86_64 are not <= MAX_BITSIZE_MODE_ANY_INT, because
>> > they are never used for integer arithmetics (and there is no way
>> > to represent all their values in RTL if not using CONST_
Here's an updated patch with Kyrill's and Andrew's comments integrated.
I left the file in the config/arm-directory, as XGene-family is capable of
executing ARMv7 and we will wire this into the 32bit backend in the near
future (moving it now would just cause another move in the near future).
We
On November 19, 2014 10:09:56 PM CET, Andrew MacLeod
wrote:
>On 11/19/2014 03:43 PM, Richard Biener wrote:
>> On November 19, 2014 8:26:23 PM CET, Andrew MacLeod
> wrote:
>>> On 11/19/2014 01:12 PM, David Malcolm wrote:
>>>
(A) could become:
greturn *stmt = gsi->as_a_greturn ()
On 11/19/2014 03:43 PM, Richard Biener wrote:
On November 19, 2014 8:26:23 PM CET, Andrew MacLeod wrote:
On 11/19/2014 01:12 PM, David Malcolm wrote:
(A) could become:
greturn *stmt = gsi->as_a_greturn ();
(B) could become:
stmt = gsi->dyn_cast ();
if (!stmt)
or:
stmt = g
Hello!
libcpp/lex.c includes "../gcc/config/i386/cpuid.h", and is picked up
by the system compiler during stage1. Recently, cpuid.h was changed to
account for %ebx changes and now uses "b" asm constraint for i686 even
with __PIC__.
Attached patch solves this issue by including system for GCC < 5
Updated patch:
Index: gcc/testsuite/go.test/go-test.exp
===
--- gcc/testsuite/go.test/go-test.exp (revision 217768)
+++ gcc/testsuite/go.test/go-test.exp (working copy)
@@ -241,7 +241,11 @@ proc go-set-goarch { } {
if
On November 19, 2014 8:26:23 PM CET, Andrew MacLeod wrote:
>On 11/19/2014 01:12 PM, David Malcolm wrote:
>
>>
>> (A) could become:
>>
>>greturn *stmt = gsi->as_a_greturn ();
>>
>> (B) could become:
>>
>>stmt = gsi->dyn_cast ();
>>if (!stmt)
>
>> or:
>>
>>stmt = gsi->dyn_cast_gcall
Hi,
after Martin's ipa-cp reorg, get_binfo_at_offset is finally used only
for lookup of base at given offset (not to walk into fields that it
used to do too even if it is not documented and old BINFO code in
ipa-cp relied on it.)
This also allows us to drop BINFOs that are not important for
debug o
Hello!
Carry flag checks from overflow tests can propagate into FP cmove
instructions. However, while "c" and "nc" suffixes are allowed as
suffixes in integer cmove insns, they are not allowed in FP cmove
insns. Patch generates equivalent "b" and "nb" suffixes for FP mode.
2014-11-19 Uros Bizjak
On 19/11/14 16:39, Marek Polacek wrote:
On Wed, Nov 19, 2014 at 04:32:43PM +, Andrew Stubbs wrote:
+if (warning_at (gimple_location (elt->stmt),
+OPT_Waggressive_loop_optimizations,
+"Loop exit may on
On 11/19/2014 11:44 AM, Bernd Schmidt wrote:
> I'm attaching the patch in the form in which I've made it work locally,
> plus Cesar's patch which is needed on top of it. Julian, you'll probably
> want to look for that patch since it also included testsuite changes.
> Cesar - have a look over this
On 15-11-14 13:14, Tom de Vries wrote:
Don't allow flto-partition=balance for fopenacc
Unsubmitted. This works around a compilation problem for
libgomp/testsuite/libgomp.oacc-c-c++-common/asyncwait-2.c that I ran into on
our internal dev branch. I'll investigate whether I can repro
On Wed, 2014-11-19 at 09:59 -0700, Jeff Law wrote:
> On 11/19/14 03:46, David Malcolm wrote:
> > Fix this leak:
> >
> > 160 bytes in 5 blocks are definitely lost in loss record 154 of 228
> > at 0x4A0645D: malloc (in
> > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> > by 0x5D75D
On 11/19/14 03:46, David Malcolm wrote:
This fixes three leaks in IPA seen in jit testcases with valgrind:
This one:
96 bytes in 4 blocks are definitely lost in loss record 102 of 205
at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5D76447: xmalloc (
On Wed, Nov 19, 2014 at 10:04 AM, Jakub Jelinek wrote:
> On Wed, Nov 19, 2014 at 03:58:50PM +0100, Richard Henderson wrote:
>> As opposed to always being a decl. This is a prerequisite
>> to allowing the static chain to be loaded for indirect calls.
>>
>> * targhooks.c (default_static_cha
Another change that's required is (something like) the following. For
ptx, we need to know whether to output something as a .func (callable
from ptx code) or a .kernel (callable from the host). That means we need
to mark the kernel functions somehow in omp-low.c, and the following
does that by
On 11/19/14 03:46, David Malcolm wrote:
Valgrind showed a leak of 1640 bytes per iteration of one of the jit
testcases (I think this is per-function in a compile):
8,200 bytes in 5 blocks are definitely lost in loss record 214 of 223
at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_me
On Wed, Nov 19, 2014 at 10:54 AM, Paolo Carlini
wrote:
> I was just aiming for consistency, from a very, very, general point of view.
Not a problem. Thank you actually, since it's obviously good for us :)
--
Regards,
Tim Shen
Kyrill,
The XGene-cores all support AArch32.
We plan to wire this up, but I’d like to merge this as-is (i.e. without wiring
it up for AArch32) initially, as we haven’t done the same amount of QA on these
with AArch32 as with AArch64.
Do you have any issue with this going into the config/arm-dir
On 11/19/2014 01:12 PM, David Malcolm wrote:
(A) could become:
greturn *stmt = gsi->as_a_greturn ();
(B) could become:
stmt = gsi->dyn_cast ();
if (!stmt)
or:
stmt = gsi->dyn_cast_gcall ();
if (!stmt)
or maybe:
stmt = gsi->is_a_gcall ();
if (!stmt)
An earlier ver
On 11/19/2014 02:50 AM, Bernd Schmidt wrote:
@@ -8417,6 +8926,9 @@ expand_omp_target (struct omp_region *region)
/* Add the new function to the offload table. */
vec_safe_push (offload_funcs, child_fn);
+ /* Add the new function to the offload table. */
+ vec_safe_pu
As discussed in the PR, the problem here is that when running gfortran,
the __builtin_object_size decl isn't available, because c-family's
c_define_builtins wasn't called. One way how to fix this is to build
the __builtin_object_size decl in initialize_sanitizer_builtins, if
needed. Alternatively
On Nov 19, 2014, at 5:51 AM, FX wrote:
> The attached patch fixes 23 asan testsuite failures on x86_64-apple-darwin14,
> where the backtrace features e.g. wrap_malloc instead of interceptor_malloc.
> So I adjusted the dg-output patterns to match.
>
> OK to commit to trunk?
Ok. If anyone has a
We can't rely on valp continuing to be a pointer into the hash table
slot. I fixed that earlier for the store, but forgot to fix the return
statement as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit dfac7dd2d46c5c0f52f6138c68d7e926d90f99be
Author: jason
Date: Wed Nov 19 19:03:
On 19 November 2014 16:51, Marcus Shawcroft wrote:
>
> In the meantime could you respin the patch to drop the default args
> and pass explicit NULL ?
Done.
Charles Baylis
PR target/63870
* config/aarch64/aarch64-builtins.c (aarch64_simd_expand_args): Pass
expression
Sorry. I ran 'make check-go' assuming it ran both m32 and m64 on a
ppc64 machine. I'll fix and retest.
On 11/19/2014 10:08 AM, Segher Boessenkool wrote:
On Wed, Nov 19, 2014 at 09:01:35AM -0600, Lynn A. Boger wrote:
+ "powerpc-*-*" {
+ set goarch "ppc"
}
+ "pow
Hi,
On 11/19/2014 07:43 PM, Daniel Krügler wrote:
2014-11-19 19:42 GMT+01:00 Tim Shen :
On Wed, Nov 19, 2014 at 8:16 AM, Paolo Carlini wrote:
Good. To be clear, not having carefully analyzed whatsoever, my point was
more about changing _M_end too, to non-const, than about not touching
_M_begi
On Nov 19, 2014, at 4:07 AM, Jakub Jelinek wrote:
>
> For TARGET_SUPPORTS_WIDE_INT == 0 should be hopefully ok. Not sure
> about TARGET_SUPPORTS_WIDE_INT != 0, can it express any generic_wide_int, or
> is it still bound to wide_int (i.e. MAX_BITSIZE_MODE_ANY_INT rounded up)
> precision? Mike?
2014-11-19 19:42 GMT+01:00 Tim Shen :
> On Wed, Nov 19, 2014 at 8:16 AM, Paolo Carlini
> wrote:
>> Good. To be clear, not having carefully analyzed whatsoever, my point was
>> more about changing _M_end too, to non-const, than about not touching
>> _M_begin. Would that make sense?
>
> Currently w
On Wed, 2014-11-19 at 09:57 -0700, Jeff Law wrote:
> On 11/19/14 03:46, David Malcolm wrote:
> > This commit updates jit.exp so that if RUN_UNDER_VALGRIND is present
> > in the environment, all of the built client code using libgccjit.so is
> > run under valgrind, with --leak-check=full.
> >
> > He
On Wed, Nov 19, 2014 at 8:16 AM, Paolo Carlini wrote:
> Good. To be clear, not having carefully analyzed whatsoever, my point was
> more about changing _M_end too, to non-const, than about not touching
> _M_begin. Would that make sense?
Currently we never mutate _M_end. I *believe* that we still
On Wed, Nov 19, 2014 at 10:11 AM, Jan Hubicka wrote:
>> On Fri, Nov 14, 2014 at 11:13 AM, Jan Hubicka wrote:
> nz
>> > Hi,
>> > this patch kills lto's code to rebuilt DECL_FUNCTION_SPECIFIC_TARGET from
>> > target
>> > attributes. This code was never complete and it should be no-op now when
>>
On Nov 19, 2014, at 4:24 AM, Richard Biener wrote:
> On Wed, 19 Nov 2014, Jakub Jelinek wrote:
>> For TARGET_SUPPORTS_WIDE_INT == 0 should be hopefully ok. Not sure
>> about TARGET_SUPPORTS_WIDE_INT != 0, can it express any generic_wide_int, or
>> is it still bound to wide_int (i.e. MAX_BITSIZE_M
On Wed, Nov 12, 2014 at 5:45 PM, mliska wrote:
> gcc/ChangeLog:
>
> 2014-11-13 Martin Liska
>
> * bb-reorder.c (mark_bb_visited): New fibonacci_heap is used.
> (find_traces): Likewise.
> (find_traces_1_round): Likewise.
This caused:
https://gcc.gnu.org/bugzilla/show_bu
I forgot to mention that i have no write privileges, please commit
this for me if it's OK
On 11/13/2014 10:47 AM, Andrew Pinski wrote:
On Thu, Nov 13, 2014 at 9:42 AM, Sandra Loosemore
wrote:
On 11/13/2014 10:27 AM, Richard Earnshaw wrote:
On 13/11/14 17:05, Ramana Radhakrishnan wrote:
On Thu, Nov 13, 2014 at 4:55 PM, Sandra Loosemore
wrote:
This patch to the AArch64 back end
On 11/19/14 03:46, David Malcolm wrote:
We weren't cleaning up the context, pass_manager or dump_manager.
An earlier version of the context and pass_manager classes had them
allocated in the GC-heap, but they were moved to the system heap
before that patch was committed; they were never cleaned
On 11/19/14 06:12, Richard Biener wrote:
PR63677 shows that late complete unrolling can expose quite some memory
CSE opportunities
Yes, we saw the same thing with unrolling in RTL. So this is not a
surprise at all.
(and followup simplifications) which we fail to
exploit because currently
I've committed the cut-down version of the gimple statement subclasses
work to svn trunk [specifically the gimple-classes-v2-option-3 git
branch, having bootstrapped®rested it on x86_64-unknown-linux-gnu
(Fedora 20)].
This is the the 89-patch kit from
https://gcc.gnu.org/ml/gcc-patches/2014-04/
Hi!
I've bootstrapped/regtested this patch for Manuel (just small formatting
changes from me), and committed to trunk.
2014-11-19 Manuel López-Ibáñez
Jakub Jelinek
PR driver/36312
PR driver/63837
* gcc.c (process_command): Don't check for input/output
> On Fri, Nov 14, 2014 at 11:13 AM, Jan Hubicka wrote:
nz
> > Hi,
> > this patch kills lto's code to rebuilt DECL_FUNCTION_SPECIFIC_TARGET from
> > target
> > attributes. This code was never complete and it should be no-op now when
> > we save
> > tehe target nodes.
> > It also makes free_land_
2014-11-19 20:55 GMT+03:00 Jeff Law :
> On 11/19/14 07:15, Ilya Enkovich wrote:
>
>> --
>> 2014-11-19 Ilya Enkovich
>>
>> * Makefile.def: Add libmpx.
>> * configure.ac: Add libmpx.
>> * Makefile.in: Regenerate.
>> * configure: Regenerate.
>>
>> gcc/
>>
>> 2014-11-
> I opened:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63963
I am testing the following. This hunk apparently slipped from my earlier patch
Index: tree-streamer-out.c
===
--- tree-streamer-out.c (revision 217668)
+++ tree-stre
A few other comments.
On Wed, Nov 19, 2014 at 9:32 AM, Philipp Tomsich
wrote:
> ---
> gcc/ChangeLog | 6 +
> gcc/config/aarch64/aarch64.md | 4 +-
> gcc/config/arm/xgene1.md | 739
> ++
> 3 files changed, 748 insertions(+), 1 dele
Hi Philipp,
One more comment...
On 19/11/14 17:32, Philipp Tomsich wrote:
@@ -4211,3 +4211,5 @@
;; Atomic Operations
(include "atomics.md")
+
+(include "../arm/xgene1.md")
Do you expect to add arm support for this core? If so, you should wire
it up there as well.
If not, I think Andrew
On Wed, Nov 19, 2014 at 03:58:50PM +0100, Richard Henderson wrote:
> As opposed to always being a decl. This is a prerequisite
> to allowing the static chain to be loaded for indirect calls.
>
> * targhooks.c (default_static_chain): Remove check for
> DECL_STATIC_CHAIN.
>
Hi Philipp,
Some comments inline
On 19/11/14 17:32, Philipp Tomsich wrote:
---
gcc/ChangeLog | 6 +
gcc/config/aarch64/aarch64.md | 4 +-
gcc/config/arm/xgene1.md | 739 ++
3 files changed, 748 insertions(+), 1 deletion(-)
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Tony Wang
>
>
> Hi all,
>
> The bug is reported at
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846, and it’s about the
> problem that
> when exception handler is involved in the function, then
> _U
On 11/19/14 07:15, Ilya Enkovich wrote:
--
2014-11-19 Ilya Enkovich
* Makefile.def: Add libmpx.
* configure.ac: Add libmpx.
* Makefile.in: Regenerate.
* configure: Regenerate.
gcc/
2014-11-19 Ilya Enkovich
* gcc.c (LIBMPX_LIBS): New.
(LIB
To keep this change separately buildable from the pipeline model,
this patch directs the APM XGene-1 to use the generic scheduling
model.
v2: Revised to document -mcpu=xgene1 in invoke.texi
---
gcc/ChangeLog| 8 +++
gcc/config/aarch64/aarch64-cores.def | 1 +
gcc/conf
Hi Philipp,
The new -mcpu option needs documenting in invoke.texi and a note to
wwwdocs in changes.html would be nice too.
Kyrill
On 19/11/14 17:32, Philipp Tomsich wrote:
To keep this change separately buildable from the pipeline model,
this patch directs the APM XGene-1 to use the generic
On Wed, 19 Nov 2014, David Malcolm wrote:
> There's no clean way to release them: retrofitting logic to decide if
> we're dealing with a string literal vs a dynamically-allocated buffer
> (and if something else is pointing to said buffer) is messy and
> error-prone; they are also unconnected to th
OK.
Jason
On 11/19/14 07:58, Richard Henderson wrote:
We need to be able to set the static chain on a few calls within the
Go runtime, so expose this with __builtin_call_with_static_chain.
* c-family/c-common.c (c_common_reswords): Add
__builtin_call_with_static_chain.
* c-famil
Hi,
New revision of Intel ISA reference [1] has new instructions:
Clwb, pcommit and new flavors of AVX512. Patch bellow adds them.
I understand that stage 1 is closed, however those changes shouldn't
affect anything outside if i386 backend. And are extremely unlikely to
break existing functionalit
---
gcc/ChangeLog | 6 +
gcc/config/aarch64/aarch64.md | 4 +-
gcc/config/arm/xgene1.md | 739 ++
3 files changed, 748 insertions(+), 1 deletion(-)
create mode 100644 gcc/config/arm/xgene1.md
diff --git a/gcc/ChangeLog b/gcc/Change
To keep this change separately buildable from the pipeline model,
this patch directs the APM XGene-1 to use the generic scheduling
model.
---
gcc/ChangeLog| 7 +++
gcc/config/aarch64/aarch64-cores.def | 1 +
gcc/config/aarch64/aarch64-tune.md | 2 +-
gcc/config/aarc
As briefly discussed with Marcus yesterday, I'm attaching two patches
to enable a mode accurate instruction selection and scheduling on the
APM X-Gene 1.
Ok for master?
-Philipp.
Philipp Tomsich (2):
Core definition for APM XGene-1 and associated cost-table.
Pipeline model for APM XGene-1
On 11/19/14 07:58, Richard Henderson wrote:
And, at the same time, allow indirect calls to have a static chain.
We'll always eliminate the static chain if we can prove it's unused.
* calls.c (prepare_call_address): Allow decl or type for first arg.
(expand_call): Pass type to p
On 11/19/14 10:11, David Malcolm wrote:
Thanks - though the patch I posted uses the contrib/valgrind.supp file,
which I added before seeing the --enable-valgrind-annotations configure
option that does a better job of this. So I'll revise it to remove that
suppression file (and add some usage no
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 some of
the macros are expected or requ
On Wed, 2014-11-19 at 10:09 -0700, Jeff Law wrote:
> On 11/19/14 04:47, Richard Biener wrote:
> > On Wed, Nov 19, 2014 at 11:46 AM, David Malcolm wrote:
> >> Valgrind complains about uninitialized data within sparseset_bit_p.
> >> Provide a suppression file to silence these warnings.
> >>
> >> Val
On Wed, 2014-11-19 at 09:57 -0700, Jeff Law wrote:
> On 11/19/14 03:46, David Malcolm wrote:
> > This commit updates jit.exp so that if RUN_UNDER_VALGRIND is present
> > in the environment, all of the built client code using libgccjit.so is
> > run under valgrind, with --leak-check=full.
> >
> > He
1 - 100 of 231 matches
Mail list logo
