On Tue, Nov 18, 2014 at 04:34:12PM -0800, Mike Stump wrote:
> On Nov 18, 2014, at 3:42 PM, Jakub Jelinek wrote:
> > No, I'm not touching tmp array at all in that case, only look at vp
> > individual bytes. Either they are all 0, or all 0xff, or I return NULL.
>
> Oh, sorry, I misread where the b
* gcc.dg/pure-2.c: Update line numbers.
diff --git a/gcc/testsuite/gcc.dg/pure-2.c b/gcc/testsuite/gcc.dg/pure-2.c
index 638bd7c..fe6e2bc 100644
--- a/gcc/testsuite/gcc.dg/pure-2.c
+++ b/gcc/testsuite/gcc.dg/pure-2.c
@@ -8,14 +8,14 @@ extern int v;
/* Trivial. */
int
foo1(int a) /* {
On Tue, 18 Nov 2014, Tom de Vries wrote:
> Richard,
>
> this (trunk) patch fixes PR62167.
>
> The patch fixes a problem that triggers with the test-case on the 4.8 branch,
> when tail-merge makes a dead type-unsafe load alive.
>
> I'm not able to reproduce this bug on 4.9 and trunk with the sam
On Tue, 18 Nov 2014, Jakub Jelinek wrote:
> Hi!
>
> This patch fixes instrumentation of bool/enum loads if they could
> throw. We want to keep the EH on the load, and push
> further statements on the fallthru edge.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 20
On Tue, 18 Nov 2014, Jakub Jelinek wrote:
> Hi!
>
> 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_WIDE_INT).
> As the following testcase shows,
On Tue, 18 Nov 2014, Jakub Jelinek wrote:
> Hi!
>
> Apparently, expand_expr with EXPR_WRITE can return
> a SUBREG with SUBREG_PROMOTED_VAR_P set on it. For
Huh, that looks bogus to me. But of course I know nothing
(read: not enough) to really tell. Eric?
Richard.
> UBSAN_CHECK_{ADD,SUB,MUL}
The following improves code-generation for PR63844 by using
a restrict qualified reference type for the OMP receiver decl.
This improves alias analysis and points-to analysis enough to
usually allow invariant and store motion where that was possible
in the non-split-out variant.
Bootstrapped and
On Wed, Nov 19, 2014 at 10:02:18AM +0100, Richard Biener wrote:
> On Tue, 18 Nov 2014, Jakub Jelinek wrote:
> > Apparently, expand_expr with EXPR_WRITE can return
> > a SUBREG with SUBREG_PROMOTED_VAR_P set on it. For
>
> Huh, that looks bogus to me. But of course I know nothing
> (read: not eno
On Wed, Nov 19, 2014 at 10:07:07AM +0100, Richard Biener wrote:
>
> The following improves code-generation for PR63844 by using
> a restrict qualified reference type for the OMP receiver decl.
> This improves alias analysis and points-to analysis enough to
> usually allow invariant and store motio
On 14/11/14 15:12, Maxim Kuvyrkov wrote:
On Nov 14, 2014, at 8:38 AM, Jeff Law wrote:
On 10/20/14 22:06, Maxim Kuvyrkov wrote:
Hi,
Ramana, this change requires benchmarking, which I can't easily do
at
the moment. I would appreciate any benchmarking results that you can
share. In particular
> > Sorry for missing the point. It seems to me that 't2' here will conflict
> > with
> condition of the pattern *movhi_insn_arch4:
> >"TARGET_ARM
> > && arm_arch4
> > && (register_operand (operands[0], HImode)
> > || register_operand (operands[1], HImode))"
> >
> > #define TA
On Tue, 18 Nov 2014, Jakub Jelinek wrote:
> Hi!
>
> Simd clone vectorization uses vect_finish_stmt_generation which
> handles adding the new calls properly to EH tables, but afterwards
> we replace the original call with a normal assignment, and if the original
> call can throw, we need to remove
On Tue, 18 Nov 2014, Jeff Law wrote:
> On 11/18/14 09:57, Tom de Vries wrote:
> > Richard,
> >
> > this (trunk) patch fixes PR62167.
> >
> > The patch fixes a problem that triggers with the test-case on the 4.8
> > branch, when tail-merge makes a dead type-unsafe load alive.
> >
> > I'm not abl
On Nov 19, 2014, at 12:27 PM, Ramana Radhakrishnan
wrote:
>
>
> On 14/11/14 15:12, Maxim Kuvyrkov wrote:
>> On Nov 14, 2014, at 8:38 AM, Jeff Law wrote:
>>
>>> On 10/20/14 22:06, Maxim Kuvyrkov wrote:
Hi,
Ramana, this change requires benchmarking, which I can't easily do
at
>>
On Wed, 19 Nov 2014, Jakub Jelinek wrote:
> On Wed, Nov 19, 2014 at 10:02:18AM +0100, Richard Biener wrote:
> > On Tue, 18 Nov 2014, Jakub Jelinek wrote:
> > > Apparently, expand_expr with EXPR_WRITE can return
> > > a SUBREG with SUBREG_PROMOTED_VAR_P set on it. For
> >
> > Huh, that looks bogu
On 19/11/14 09:29, Yangfei (Felix) wrote:
Sorry for missing the point. It seems to me that 't2' here will conflict with
condition of the pattern *movhi_insn_arch4:
"TARGET_ARM
&& arm_arch4
&& (register_operand (operands[0], HImode)
|| register_operand (operands[1], HIm
On Tue, Nov 18, 2014 at 10:04 PM, David Malcolm wrote:
> On Tue, 2014-11-18 at 10:53 +0100, Richard Biener wrote:
>> On Tue, Nov 18, 2014 at 2:59 AM, David Malcolm wrote:
>> > On Mon, 2014-11-17 at 11:06 +0100, Richard Biener wrote:
>> >> On Sat, Nov 15, 2014 at 12:00 PM, David Malcolm
>> >> wr
On Tue, Nov 18, 2014 at 5:33 PM, Thomas Preud'homme
wrote:
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>> Sent: Monday, November 17, 2014 12:47 PM
>>
>> Hmm. I am a little bit concerned about the malloc traffic generated here.
>> So why not use a vec, get rid of the ->next pointer
Hello!
2014-11-19 Uros Bizjak
* testsuite/libgomp.c/examples-4/e.53.5.c: Require
vect_simd_clones effective target.
* testsuite/libgomp.fortran/examples-4/e.53.5.f90: Ditto.
Tested on x86_64-linux-gnu {,-m32} CentOS 5.11.
OK for mainline?
Uros.
Index: testsuite/libgomp.fortran/e
On Wed, Nov 19, 2014 at 11:26:25AM +0100, Uros Bizjak wrote:
> 2014-11-19 Uros Bizjak
>
> * testsuite/libgomp.c/examples-4/e.53.5.c: Require
> vect_simd_clones effective target.
> * testsuite/libgomp.fortran/examples-4/e.53.5.f90: Ditto.
>
> Tested on x86_64-linux-gnu {,-m32} CentO
Valgrind shows this fixes ~1 KB of leak per iteration (on x86_64) by
plugging these leaks allocated at opts.c lines 286 and 289:
==57820== 2,752 bytes in 4 blocks are definitely lost in loss record 875 of 917
==57820==at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux
Valgrind shows this fixes ~4 KB of leak per iteration (on x86_64) by
plugging this leak allocated at reginfo.c:1327:
gcc_obstack_init (&valid_mode_changes_obstack);
==57820== 16,256 bytes in 4 blocks are definitely lost in loss record 906 of 917
==57820==at 0x4A0645D: malloc (in
/usr/lib64/
This was leaking about 4KB per iteration:
16,256 bytes in 4 blocks are definitely lost in loss record 233 of 239
at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5D75C17: xmalloc (xmalloc.c:147)
by 0x30958842DB: _obstack_begin (obstack.c:184)
by 0x5
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 up, so e.g.
all passes leak on each in-pro
Running the jit testsuite under valgrind showed various memory leaks.
Some are per-invocation of the compiler, and hence only affect
libgccjit.so (although presumably it's useful to cc1 etc to get
valgrind clean).
Others appear to be per-function and hence affect the non-JIT use
cases.
The follo
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 0x5D75D4F: xrealloc (xmalloc.c:177)
by 0x4DE1710: void
va_heap::reserve(vec*&, unsigned int, bool) (vec.h:310)
by 0x4D
this_target_ira_int->free_ira_costs () is called by ira_init_costs,
but this isn't called after the compile, causing noise when running
under valgrind.
This patch adds a ira_costs_c_finalize function to clean this up,
and calls it from toplev::finalize (and hence this isn't called by
cc1/cc1plus/e
This was leaking ~4KB per iteration:
16,256 bytes in 4 blocks are definitely lost in loss record 234 of 239
at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5D75C17: xmalloc (xmalloc.c:147)
by 0x30958842DB: _obstack_begin (obstack.c:184)
by 0x4DFECD
Fix this leak:
120 bytes in 5 blocks are definitely lost in loss record 141 of 227
at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5D75D8F: xrealloc (xmalloc.c:177)
by 0x550DEBA: void va_heap::reserve(vec*&, unsigned int, bool) (vec.h:310)
by 0x550
Valgrind complains about uninitialized data within sparseset_bit_p.
Provide a suppression file to silence these warnings.
Valgrind requires suppression files for C++ code to use the mangled
names, so we do that here.
contrib/ChangeLog:
PR jit/63854
* valgrind.supp: New.
---
contr
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.
Hence:
RUN_UNDER_VALGRIND= make check-jit
will run all jit testcases under valgrind (taking 27 mins on my
machin
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_memcheck-amd64-linux.so)
by 0x5D75D1F: xre
Valgrind showed this leaking 200 bytes per iteration in one of
my testcases:
1,000 bytes in 5 blocks are definitely lost in loss record 200 of 241
at 0x4A083AA: realloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5D75C5C: xrealloc (xmalloc.c:179)
by 0x4E10734: void va
This fixes various leaks of vec buffers seen via valgrind within jit
(both recording and playback).
Various vec<> within jit::recording are converted to auto_vec<>.
Various playback::wrapper subclasses containing vec<> gain a finalizer
so they can release the vec when they are collected.
gcc/jit
Valgrind showed a per-iteration leak of pass_ipa_pta (and presumably
pass_omp_simd_clone):
704 (352 direct, 352 indirect) bytes in 4 blocks are definitely lost in loss
record 198 of 241
at 0x4A06965: operator new(unsigned long) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by
ipa-icf.c was leaking 16 bytes per iteration in the jit testcases here:
80 bytes in 5 blocks are definitely lost in loss record 94 of 199
at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5D764B7: xmalloc (xmalloc.c:147)
by 0x5C962FF: ipa_icf::sem_item_
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 (xmalloc.c:147)
by 0x4E35C23: symbol_table
Fix this small per-iteration leak with debuginfo:
424 bytes in 4 blocks are definitely lost in loss record 185 of 230
at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5D75CA7: xmalloc (xmalloc.c:147)
by 0x4ECE9E4: gen_producer_string() (dwarf2out.c:194
This commit fixes this leak from opts-common.c, about 4KB per iteration.
==57820== 18,816 (2,560 direct, 16,256 indirect) bytes in 4 blocks are
definitely lost in loss record 907 of 917
==57820==at 0x4A083AA: realloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==57820==by
Some places in the startup code use char * values that can sometimes be
string literals, and can sometimes be dynamically built using xstrdup or
concat.
This isn't a problem for cc1 etc since this is only called once, but
for libgccjit they are small per-invocation leaks.
There's no clean way to
Paths are allocated as:
vec *path = new vec ();
i.e. the vec itself is on the heap, so a mere:
path->release ();
is merely releasing the buffer the vec holds, not the vec itself.
This patch updates the two sites that release paths to also delete them,
fixing leaks like this seen by valgri
gcc/testsuite/ChangeLog:
PR jit/63854
* jit.dg/test-fuzzer.c (fuzzer_init): Free malloced buffers.
(make_random_function): Free ff->locals.
---
gcc/testsuite/jit.dg/test-fuzzer.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/gcc/testsuite/jit.dg/test-fuzzer.c
b
On 10/11/14 16:55, Renlin Li wrote:
On 06/11/14 15:00, Renlin Li wrote:
Hi all,
Dose anybody have time to review this?
Kind regards,
Renlin Li
On 31/10/14 14:51, Renlin Li wrote:
Hi all,
This is a patch which will fix PR63424.
It implements signed/unsigned max/min pattern for V2DI mode in
The problem here is that negate_expr_p returns true (as it should)
for UINT_MAX(OVF), but fold_negate_expr didn't actually fold it,
and that is a no-no; if negate_expr_p is true, fold_negate_expr must
not return NULL_TREE. I added the following hunk for bootstrap and
regtest for better coverage:
On Wed, Nov 19, 2014 at 11:46 AM, David Malcolm wrote:
> Valgrind shows this fixes ~1 KB of leak per iteration (on x86_64) by
> plugging these leaks allocated at opts.c lines 286 and 289:
>
> ==57820== 2,752 bytes in 4 blocks are definitely lost in loss record 875 of
> 917
> ==57820==at 0x4A0
On Wed, Nov 19, 2014 at 11:46 AM, David Malcolm wrote:
> Valgrind shows this fixes ~4 KB of leak per iteration (on x86_64) by
> plugging this leak allocated at reginfo.c:1327:
> gcc_obstack_init (&valid_mode_changes_obstack);
Ok.
Thanks,
Richard.
> ==57820== 16,256 bytes in 4 blocks are defin
On 10/31/2014 03:51 PM, Renlin Li wrote:
> +(define_expand "v2di3"
> + [(parallel [
> +(set (match_operand:V2DI 0 "register_operand" "")
> + (MAXMIN:V2DI (match_operand:V2DI 1 "register_operand" "")
> + (match_operand:V2DI 2 "register_operand" "")))
> +(clobber (reg:CC C
On Wed, Nov 19, 2014 at 11:46 AM, David Malcolm wrote:
> This was leaking about 4KB per iteration:
Ok.
Thanks,
Richard.
> 16,256 bytes in 4 blocks are definitely lost in loss record 233 of 239
>at 0x4A0645D: malloc (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
>by 0x5D75
On Wed, Nov 19, 2014 at 11:46 AM, David Malcolm wrote:
> This was leaking ~4KB per iteration:
Ok.
Thanks,
Richard.
> 16,256 bytes in 4 blocks are definitely lost in loss record 234 of 239
>at 0x4A0645D: malloc (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
>by 0x5D75C17:
On Wed, Nov 19, 2014 at 11:46 AM, David Malcolm wrote:
> this_target_ira_int->free_ira_costs () is called by ira_init_costs,
> but this isn't called after the compile, causing noise when running
> under valgrind.
>
> This patch adds a ira_costs_c_finalize function to clean this up,
> and calls it
On Wed, Nov 19, 2014 at 11:46 AM, David Malcolm wrote:
> Fix this leak:
Ok.
Thanks,
Richard.
> 120 bytes in 5 blocks are definitely lost in loss record 141 of 227
>at 0x4A0645D: malloc (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
>by 0x5D75D8F: xrealloc (xmalloc.c:177)
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.
>
> Valgrind requires suppression files for C++ code to use the mangled
> names, so we do that here.
There is --enab
On Wed, Nov 19, 2014 at 11:46 AM, David Malcolm wrote:
> Valgrind showed a per-iteration leak of pass_ipa_pta (and presumably
> pass_omp_simd_clone):
Ok.
Thanks,
Richard.
> 704 (352 direct, 352 indirect) bytes in 4 blocks are definitely lost in loss
> record 198 of 241
>at 0x4A06965: opera
On Wed, Nov 19, 2014 at 11:46 AM, David Malcolm wrote:
> Valgrind showed this leaking 200 bytes per iteration in one of
> my testcases:
Ok.
Thanks,
Richard.
> 1,000 bytes in 5 blocks are definitely lost in loss record 200 of 241
>at 0x4A083AA: realloc (in
> /usr/lib64/valgrind/vgpreload_me
On Wed, Nov 19, 2014 at 11:46 AM, David Malcolm wrote:
> This commit fixes this leak from opts-common.c, about 4KB per iteration.
Ok.
Thanks,
Richard.
> ==57820== 18,816 (2,560 direct, 16,256 indirect) bytes in 4 blocks are
> definitely lost in loss record 907 of 917
> ==57820==at 0x4A083A
On Wed, Nov 19, 2014 at 11:46 AM, David Malcolm wrote:
> ipa-icf.c was leaking 16 bytes per iteration in the jit testcases here:
Ok.
Tahnks,
Richard.
> 80 bytes in 5 blocks are definitely lost in loss record 94 of 199
>at 0x4A0645D: malloc (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64
On Wed, Nov 19, 2014 at 11:46 AM, David Malcolm wrote:
> Fix this small per-iteration leak with debuginfo:
Ok.
Thanks,
Richard.
> 424 bytes in 4 blocks are definitely lost in loss record 185 of 230
>at 0x4A0645D: malloc (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
>by 0
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_WIDE_INT).
> > As the follow
On Wed, Nov 19, 2014 at 11:46 AM, David Malcolm wrote:
> Paths are allocated as:
>vec *path = new vec ();
> i.e. the vec itself is on the heap, so a mere:
> path->release ();
> is merely releasing the buffer the vec holds, not the vec itself.
Ok.
Thanks,
RIchard.
> This patch updates
On Wed, 19 Nov 2014, Marek Polacek wrote:
> The problem here is that negate_expr_p returns true (as it should)
> for UINT_MAX(OVF), but fold_negate_expr didn't actually fold it,
> and that is a no-no; if negate_expr_p is true, fold_negate_expr must
> not return NULL_TREE. I added the following hu
On Wed, 19 Nov 2014, Jakub Jelinek wrote:
> 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
On Wed, Nov 19, 2014 at 12:59:06PM +0100, Richard Biener wrote:
> > So perhaps something like this? Don't know how much more inefficient it is
> > compared to what it used to do before.
>
> Yes, that looks good.
>
> > Or just keep the existing code and just remove the assert and instead return
>
Hi,
today I wanted to simply close this Bug as fixed, but then I noticed
that Richard Smith in the audit trail argued, correctly in my opinion,
that we should accept things like:
constexpr const char* x() { return __func__; }
in C++11 mode too, because the "as if" local variable specificatio
On Wed, 19 Nov 2014, Jakub Jelinek wrote:
> On Wed, Nov 19, 2014 at 12:59:06PM +0100, Richard Biener wrote:
> > > So perhaps something like this? Don't know how much more inefficient it
> > > is
> > > compared to what it used to do before.
> >
> > Yes, that looks good.
> >
> > > Or just keep t
On 11/18/2014 11:25 PM, Martin Jambor wrote:
On Tue, Nov 18, 2014 at 07:59:26PM +0100, Jan Hubicka wrote:
Hi,
On Tue, Nov 18, 2014 at 04:39:00PM +0100, Jan Hubicka wrote:
On Fri, Nov 14, 2014 at 08:59:10PM +0100, Jan Hubicka wrote:
b) with GTY, we cannot call destructor
Everything in symb
Hi,
It has come to my attention that we create suboptimal code for the
`__call_stub_fp_' variant of the MIPS16 call stubs. These stubs are
used for outgoing calls made from MIPS16 code to standard MIPS code that
return floating-point results and may also pass floating-point
arguments.
This
PR63677 shows that late complete unrolling can expose quite some memory
CSE opportunities (and followup simplifications) which we fail to
exploit because currently DOMs ability to do memory CSE is quite
limited (it requires the redundant load to optimize to directly follow the
load or store). Thi
Hello Ramana,
Here is the attribute revisited after your comments, so
- thumb1 is now supported
- -mflip-thump option added for testing.
- inlining is allowed between modes.
This set of patches was tested on rev#217709 as:
no regressions with:
arm-sim/
arm-sim/-march=armv7-a
arm
On Tue, 18 Nov 2014, Matthew Fortune wrote:
> > > I admit to being a bit more nervous about 4.9 but the test coverage
> > > seems thorough enough. I guess I would have been less concerned if the
> > > optimisation was still just tied to TARGET_MICROMIPS for the 4.9
> > branch.
> > >
> > > Catherin
> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Tuesday, November 18, 2014 9:42 AM
> To: Andrew Bennett; gcc-patches@gcc.gnu.org
> Cc: Moore, Catherine; Rozycki, Maciej
> Subject: RE: [PATCH] If using branch likelies in MIPS sync code fill the dela
In preparation of the target attribute,
reorganize ´arm_option_override´ into 3 entities:
arm_option_override_internal_p
arm_option_check_internal
arm_option_param_internal
Also define and use TREE_TARGET macros instead of file-scope variables
in the machine description.
Thanks,
Christian
20
As omp target and offloading support is committed to trunk,
I think it's reasonable to add some new warnings.
On 06 Nov 15:27, Ilya Tocar wrote:
> Ping.
> On 30 Oct 18:31, Ilya Tocar wrote:
> > Ping.
> > On 20 Oct 19:26, Ilya Tocar wrote:
> > > Ping.
> > >
> > > On 02 Oct 17:38, Ilya Tocar wrote:
In preparation of the pragma target
reorganize ´TARGET_CPU_CPP_BUILTINS´ to redefine mode dependent macros
based on current thumb_p.
Thanks,
Christian
2014-09-23 Christian Bruel
* config/arm/arm-c.c (cpp_def_or_undef): New functions.
(arm_cpp_builtins): Likewise.
* config/arm/arm.h (TA
Re-implement ARM_DECLARE_FUNCTION_NAME as a function. That will make
changed related to unified/divided and mode directives easier to insert.
Thanks
Christian
2014-09-23 Christian Bruel
* config/arm/arm-protos.h (arm_declare_function_name): Declare.
(is_called_in_ARM_mode): Remove.
* con
On Tue, Nov 18, 2014 at 9:29 AM, Jan Hubicka wrote:
>> On Tue, Nov 18, 2014 at 9:27 AM, Jan Hubicka wrote:
>> >> https://gcc.gnu.org/ml/gcc-regression/2014-11/msg00473.html
>> >>
>> >> /export/gnu/import/git/gcc-test-profiled/bld/./prev-gcc/xg++
>> >> -B/export/gnu/import/git/gcc-test-profiled/bl
Implements and document the hooks to support target_attributes.
The emission of blx is handled directly for armv5 to overcome a bug with
the current binutils that fails with calls to a static symbol in a
different section. (e.g .text -> .text.startup) in different modes.
(ref https://sourcewar
As the testcase shows, we should really check first that we
have a MEM_REF, otherwise subsequent TREE_OPERAND might ICE.
On an invalid testcase we might get e.g. STRING_CST.
Bootstrapped/regtested on power8-linux, ok for trunk?
2014-11-19 Marek Polacek
PR sanitizer/63690
* ubs
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?
2014-11-19 Francois-Xavier Coudert
* c-c++-common/asan/h
On Wed, Nov 19, 2014 at 05:46:17AM -0500, David Malcolm wrote:
> This fixes various leaks of vec buffers seen via valgrind within jit
> (both recording and playback).
>
> Various vec<> within jit::recording are converted to auto_vec<>.
>
> Various playback::wrapper subclasses containing vec<> gai
Implements the hooks for #pragma GCC target
A test included to check that macros were correctly defined/undefined on
pragma regions.
Thanks
Christian
2014-09-23 Christian Bruel
* config/arm/arm.h (REGISTER_TARGET_PRAGMAS):
Call arm_register_target_pragmas.
* config/arm/arm-protos.h (a
Implement the -mflip-thump option. Undocumented for internal testing
only. This option artificially inserts alternative attribute thumb/modes
on functions.
This close the patch set. Thanks for your review,
Christian
2014-09-23 Christian Bruel
* config/arm/arm.c (add_attribute, arm_insert_
On Wed, Nov 19, 2014 at 02:51:11PM +0100, Marek Polacek wrote:
> As the testcase shows, we should really check first that we
> have a MEM_REF, otherwise subsequent TREE_OPERAND might ICE.
> On an invalid testcase we might get e.g. STRING_CST.
Well, addr_object_size should handle STRING_CSTs just f
On 13 Nov 20:56, Joseph Myers wrote:
> On Thu, 13 Nov 2014, Ilya Enkovich wrote:
>
> > > You can leave it as a single library - it's just that imposes libgcc-like
> > > constraints on what the library does and how it does things, so as to be
> > > usable for arbitrary programs built with MPX (e.g.
On Wed, Nov 19, 2014 at 03:12:05PM +0100, Jakub Jelinek wrote:
> On Wed, Nov 19, 2014 at 02:51:11PM +0100, Marek Polacek wrote:
> > As the testcase shows, we should really check first that we
> > have a MEM_REF, otherwise subsequent TREE_OPERAND might ICE.
> > On an invalid testcase we might get e.
> Yes, removing the second NOP is worth the additional effort.
The updated patch is below.
Ok to commit?
Regards,
Andrew
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 02268f3..368c6f0 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -12997,7 +12997,1
On Wed, Nov 19, 2014 at 1:24 PM, Christian Bruel wrote:
> I think I missed the stage3, Anyway would it be OK for stage1 when it
> reopens ?
Since you submitted this well during stage1 and given that these
patches address comments from earlier in the review process we should
aim to get these in f
Hi!
This patch:
1) adds unary op overload to gimple_build_assign_with_ops
so that many callers don't need to pass NULL_TREE as the last
argument explicitly
2) adds unary op overload to gimple_assign_set_rhs_with_ops for similar
reasons
3) renames gimple_assign_set_rhs_with_ops_1 to
gim
On Wed, Nov 19, 2014 at 03:12:05PM +0100, Jakub Jelinek wrote:
> On Wed, Nov 19, 2014 at 02:51:11PM +0100, Marek Polacek wrote:
> > As the testcase shows, we should really check first that we
> > have a MEM_REF, otherwise subsequent TREE_OPERAND might ICE.
> > On an invalid testcase we might get e.
> diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c index
> 02268f3..368c6f0 100644
> --- a/gcc/config/mips/mips.c
> +++ b/gcc/config/mips/mips.c
> @@ -12997,7 +12997,12 @@ mips_process_sync_loop (rtx_insn *insn, rtx
> *operands)
> This will sometimes be a delayed branch; see the w
Hi Jiong,
Can you commit this please?
2014-11-19 Wilco Dijkstra
* gcc/config/aarch64/aarch64.c (generic_regmove_cost):
Increase FP move cost (PR61915).
---
gcc/config/aarch64/aarch64.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/gcc/config/aarc
Committed as pre-approved by Jakub in PR62132.
It took me three commits (revisions ) to get it right. I apologize for that,
and I’ll stop coding for the day :(
2014-11-19 Francois-Xavier Coudert
PR sanitizer/62132
* c-c++-common/asan/misalign-1.c: Pass -fno-omit-frame-pointe
On Wed, 19 Nov 2014, Jakub Jelinek wrote:
> Hi!
>
> This patch:
> 1) adds unary op overload to gimple_build_assign_with_ops
>so that many callers don't need to pass NULL_TREE as the last
>argument explicitly
> 2) adds unary op overload to gimple_assign_set_rhs_with_ops for similar
>re
On Wed, 19 Nov 2014, Matthew Fortune wrote:
> > @@ -12997,7 +12997,12 @@ mips_process_sync_loop (rtx_insn *insn, rtx
> > *operands)
> > This will sometimes be a delayed branch; see the write code below
> > for details. */
> >mips_multi_add_insn (is_64bit_p ? "scd\t%0,%1" : "sc\t%0
On Thu, Nov 13, 2014 at 7:57 PM, Ulrich Weigand wrote:
> Richard Henderson wrote:
>> On 11/12/2014 09:41 PM, Ulrich Weigand wrote:
>> > * optabs.c (prepare_operand): Gracefully fail if the mode of X
>> > does not match the operand mode expected by the insn pattern.
>>
>> This is ok.
>
> I'
On 11/19/2014 03:18 PM, Ramana Radhakrishnan wrote:
On Wed, Nov 19, 2014 at 1:24 PM, Christian Bruel wrote:
I think I missed the stage3, Anyway would it be OK for stage1 when it
reopens ?
Since you submitted this well during stage1 and given that these
patches address comments from earlier
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.
* config/moxie/moxie.c (moxie_static_chain): Likewise.
* config/i386/i3
This is the middle-end and C front end parts of the gccgo related
patch set first posted here.
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01009.html
I've re-tested these patches in isolation and have committed them
to mainline. I'm currently submitting the Go portions for the
upstream revie
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-family/c-common.h (RID_BUILTIN_CALL_WITH_STATIC_CHAIN)
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 prepare_call_address if no decl.
* gimple
The following patch is to avoid needlessly recursing to generic_simplify
from fold_unary when we ask to perform constant folding. Similar
fold_binary is currently entered to constant fold from
gimple/generic_simplify and will do extra work in case it isn't able
to fold the constant operation.
T
1 - 100 of 231 matches
Mail list logo
