On Mon, 2014-06-09 at 20:32 +0100, Richard Sandiford wrote:
Steven Bosscher stevenb@gmail.com writes:
On Sat, Jun 7, 2014 at 7:54 PM, Richard Sandiford wrote:
The two parts of the loop condition are really handling two different
kinds of block: ones like entry and exit that are
On Wed, 2014-06-25 at 14:39 -0600, Jeff Law wrote:
On 06/25/14 03:36, Richard Sandiford wrote:
I think this is an example of another problem with gcc coding style:
that we're far too afraid of temporary variables. In David's scheme
I think this would be:
Historical coding style :(
On Wed, 2014-06-25 at 10:36 +0100, Richard Sandiford wrote:
Oleg Endo oleg.e...@t-online.de writes:
Personally, I'd like to see usage of standard STL-like iterator usage.
I've proposed something for edge_iterator a while ago, but people don't
seem very fond of it. See also
/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,3 +1,14 @@
+2014-07-14 David Malcolm dmalc...@redhat.com
+
+ * internal-api.c (gcc::jit::recording::context::new_array_type):
+ Reject attempts to create an array of a struct if the fields of
+ the struct haven't yet been set
/ChangeLog.jit b/gcc/ChangeLog.jit
index f8235f1..3a6ea52 100644
--- a/gcc/ChangeLog.jit
+++ b/gcc/ChangeLog.jit
@@ -1,3 +1,9 @@
+2014-07-14 David Malcolm dmalc...@redhat.com
+
+ * cgraph.h (ipa_cp_c_finalize): Add prototype.
+ * ipa-cp.c (ipa_cp_c_finalize): New.
+ * toplev.c (toplev
-type.c
diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index 65fba51..3db15e8 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,3 +1,16 @@
+2014-07-25 David Malcolm dmalc...@redhat.com
+
+ * TODO.rst (error-checking): Remove various items that either
On Mon, 2014-07-28 at 02:35 +0530, Prathamesh Kulkarni wrote:
- if (o-type == operand::OP_CAPTURE)
+ if (is_acapture * (o))
{
- capture *c = static_castcapture * (o);
- fprintf (f, @%s, (static_castcapture * (o))-where);
+ capture *c = as_acapture * (o);
FWIW, if
On Tue, 2014-07-29 at 19:36 +0200, Marc Glisse wrote:
On Sun, 27 Jul 2014, Richard Sandiford wrote:
Marc Glisse marc.gli...@inria.fr writes:
Hello,
I followed the advice in this discussion:
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html
and here is a new patch. I made an
On Tue, 2014-07-29 at 21:13 +0200, Marek Polacek wrote:
On Tue, Jul 29, 2014 at 02:58:03PM -0400, David Malcolm wrote:
This is possibly a dumb question, but what happens for a static local,
rather than an auto local? e.g.
int *f (void)
{
static int i;
return i
A complaint I heard at Cauldron with the C++ification of GCC passes is
that it's become much more difficult to set breakpoints on the execute
hooks of a pass, now that the passes are classes within anonymous
namespaces.
When this was first done, the execute methods were trivial
implementations
On Tue, 2014-07-29 at 16:44 -0400, David Malcolm wrote:
A complaint I heard at Cauldron with the C++ification of GCC passes is
that it's become much more difficult to set breakpoints on the execute
hooks of a pass, now that the passes are classes within anonymous
namespaces.
When
On Sat, 2014-11-08 at 14:56 +0100, Jakub Jelinek wrote:
On Sat, Nov 08, 2014 at 01:07:28PM +0100, Richard Biener wrote:
To be constructive here - the above case is from within a
GIMPLE_ASSIGN case label
and thus I'd have expected
case GIMPLE_ASSIGN:
{
gassign *a1
The attached patch adds a news entry about the JIT merge to the
frontpage of the website.
The page seems to have some pre-existing validation errors; I don't
think this adds any new ones.
OK?
Thanks
Dave
Index: htdocs/index.html
On Wed, 2014-11-12 at 12:33 +0100, Jakub Jelinek wrote:
On Wed, Nov 12, 2014 at 12:18:13PM +0100, Thomas Schwinge wrote:
On Wed, 12 Nov 2014 11:06:26 +0100, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Nov 11, 2014 at 01:53:23PM +, Julian Brown wrote:
--- a/libgomp/configure.ac
On Wed, 2014-11-12 at 14:16 +0100, Tom de Vries wrote:
I can't speak to the rest of the patch, but one readability nitpick:
diff --git a/gcc/passes.def b/gcc/passes.def
index 2305d67..dd91718 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -241,6 +241,9 @@ along with GCC; see the file
We make assumptions in the codebase about when the GC can run, and when
it can't (e.g. within numerous passes) but these aren't captured in a way
that's verifiable.
This patch introduces macros GGC_{BEGIN|END}_ASSERT_NO_COLLECTIONS for
marking regions of code where we assume that a GC can't
On Wed, 2014-11-12 at 14:47 +0100, Jakub Jelinek wrote:
On Wed, Nov 12, 2014 at 08:33:34AM -0500, David Malcolm wrote:
Apologies for bikeshedding, and I normally dislike cute names, but
renaming it to
GNU Offloading and Multi Processing library
would allow a backronym of libgomp
On Wed, 2014-11-12 at 21:30 +0100, Jakub Jelinek wrote:
On Wed, Nov 12, 2014 at 03:22:21PM -0500, David Malcolm wrote:
On Wed, 2014-11-12 at 14:47 +0100, Jakub Jelinek wrote:
On Wed, Nov 12, 2014 at 08:33:34AM -0500, David Malcolm wrote:
Apologies for bikeshedding, and I normally dislike
On Wed, 2014-11-12 at 13:16 -0500, David Malcolm wrote:
We make assumptions in the codebase about when the GC can run, and when
it can't (e.g. within numerous passes) but these aren't captured in a way
that's verifiable.
This patch introduces macros GGC_{BEGIN|END}_ASSERT_NO_COLLECTIONS
On Tue, 2014-11-11 at 11:43 +0100, Richard Biener wrote:
On Tue, Nov 11, 2014 at 8:26 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Nov 10, 2014 at 05:27:50PM -0500, David Malcolm wrote:
On Sat, 2014-11-08 at 14:56 +0100, Jakub Jelinek wrote:
On Sat, Nov 08, 2014 at 01:07:28PM +0100
On Tue, 2014-11-11 at 08:26 +0100, Jakub Jelinek wrote:
On Mon, Nov 10, 2014 at 05:27:50PM -0500, David Malcolm wrote:
On Sat, 2014-11-08 at 14:56 +0100, Jakub Jelinek wrote:
On Sat, Nov 08, 2014 at 01:07:28PM +0100, Richard Biener wrote:
To be constructive here - the above case is from
On Thu, 2014-11-13 at 11:22 +0100, Richard Biener wrote:
On Wed, Nov 12, 2014 at 11:04 PM, David Malcolm dmalc...@redhat.com wrote:
On Wed, 2014-11-12 at 13:16 -0500, David Malcolm wrote:
We make assumptions in the codebase about when the GC can run, and when
it can't (e.g. within numerous
On Thu, 2014-11-13 at 11:45 +0100, Richard Biener wrote:
On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm dmalc...@redhat.com wrote:
On Tue, 2014-11-11 at 11:43 +0100, Richard Biener wrote:
On Tue, Nov 11, 2014 at 8:26 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Nov 10, 2014 at 05:27
On Thu, 2014-11-13 at 11:45 +0100, Richard Biener wrote:
On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm dmalc...@redhat.com wrote:
On Tue, 2014-11-11 at 11:43 +0100, Richard Biener wrote:
On Tue, Nov 11, 2014 at 8:26 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Nov 10, 2014 at 05:27
On Mon, 2014-11-17 at 11:06 +0100, Richard Biener wrote:
On Sat, Nov 15, 2014 at 12:00 PM, David Malcolm dmalc...@redhat.com wrote:
On Thu, 2014-11-13 at 11:45 +0100, Richard Biener wrote:
On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm dmalc...@redhat.com wrote:
On Tue, 2014-11-11 at 11:43
On Tue, 2014-11-18 at 10:53 +0100, Richard Biener wrote:
On Tue, Nov 18, 2014 at 2:59 AM, David Malcolm dmalc...@redhat.com wrote:
On Mon, 2014-11-17 at 11:06 +0100, Richard Biener wrote:
On Sat, Nov 15, 2014 at 12:00 PM, David Malcolm dmalc...@redhat.com
wrote:
On Thu, 2014-11-13 at 11
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
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
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
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
such testing?).
Successfully bootstrappedregrtested the cumulative effect of the
patches on x86_64-unknown-linux-gnu (Fedora 20).
Are the non-JIT parts OK for trunk?
(Presumably I can give myself approval for the JIT parts)
David Malcolm (21):
PR jit/63854: Fix memory leak within gcc_options
PR jit
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
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
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
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::reservepre_expr_d*(vecpre_expr_d*, va_heap,
vl_embed*,
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.
---
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
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:
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
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.
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:
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:
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()
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:
vecjump_thread_edge * *path = new vecjump_thread_edge * ();
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,
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
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.
Hence
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 dmalc...@redhat.com wrote:
Valgrind complains about uninitialized data within sparseset_bit_p.
Provide a suppression file to silence these warnings
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 bootstrappedregrested it on x86_64-unknown-linux-gnu
(Fedora 20)].
This is the the 89-patch kit from
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.
Hence
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 0x5D75D4F: xrealloc
, David Malcolm wrote:
(A) could become:
greturn *stmt = gsi-as_a_greturn ();
(B) could become:
stmt = gsi-dyn_cast gcall * ();
if (!stmt)
or:
stmt = gsi-dyn_cast_gcall ();
if (!stmt)
or maybe:
stmt = gsi-is_a_gcall ();
if (!stmt
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
0901383f1a1ad296b939687298b8321446bc54e3 Mon Sep 17 00:00:00 2001
From: David Malcolm dmalc...@redhat.com
Date: Thu, 20 Nov 2014 01:06:14 -0500
Subject: [PATCH] PR jit/63969: Fix segfault in error-handling when driver
isn't found
If the driver isn't found on the path, pex_one attempts to print an
error message
On Wed, 2014-11-19 at 23:09 -0800, Mike Stump wrote:
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
On Fri, 2014-11-21 at 21:13 +0100, Richard Biener wrote:
On November 21, 2014 8:45:09 PM CET, Diego Novillo
dnovi...@google.com wrote:
On Fri, Nov 21, 2014 at 1:48 PM, Andrew MacLeod amacl...@redhat.com
wrote:
1 - introduce a TYPE_REF tree node, which is effectively just a
'typed' tree
On Tue, 2014-11-25 at 10:15 -0700, Jeff Law wrote:
On 11/25/14 10:14, Segher Boessenkool wrote:
On Tue, Nov 25, 2014 at 09:44:35AM -0700, Jeff Law wrote:
On 11/24/14 20:37, Segher Boessenkool wrote:
`lcc' is not an insn but just a pattern. This caused a build error in
libgcc.
A good
Various fixes/improvements to jit.exp
Successfully bootstrapped regrtested on x86_64-unknown-linux-gnu
(Fedora 20).
OK for trunk?
(am not yet officially blessed as the JIT maintainer, so I require
review for the non-obvious patches)
Various fixes/improvements to jit.exp
Successfully bootstrapped regrtested on x86_64-unknown-linux-gnu
(Fedora 20).
OK for trunk?
(am not yet officially blessed as the JIT maintainer, so I require
review for the non-obvious patches)
DejaGnu's host_execute has an erroneous line that appears to be a
merge conflict that went awry followed up by a reindent, and jit.exp
has inherited this bug within fixed_host_execute.
Fix it within jit.exp.
Reported to DejaGnu as:
This makes it easier to compare jit.sum files from different runs
gcc/testsuite/ChangeLog:
* jit.dg/jit.exp (jit-dg-test): Use $name rathen than $prog
when calling jit_check_compile to avoid embedding the full path of
the testcase into the test results.
---
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
Add command-line option-parsing to the testcases, so that we can
manipulate them without needing a recompile (e.g. varying
optimization levels etc).
This uses getopt_long, which is a GNU extension to libc. Is that
acceptable?
Implement a --num-iterations option, to override the default of 5.
gcc/testsuite/ChangeLog:
* jit.dg/jit.exp (verify_exit_status): New function.
(fixed_host_execute): Verify the exit status of the spawnee.
---
gcc/testsuite/jit.dg/jit.exp | 30 ++
1 file changed, 30 insertions(+)
diff --git
Various fixes/improvements to jit.exp
Successfully bootstrapped regrtested on x86_64-unknown-linux-gnu
(Fedora 20).
OK for trunk?
Running testsuite/jit.dg/test-functions.c under valgrind showed this
leak (amongst others):
400 bytes in 10 blocks are definitely lost in loss record 142 of 181
at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5DCDF2F: xrealloc (xmalloc.c:177)
by
Running testsuite/jit.dg/test-functions.c under valgrind showed this
leak (amongst others):
520 (320 direct, 200 indirect) bytes in 5 blocks are definitely lost in loss
record 144 of 181
at 0x4A06965: operator new(unsigned long) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
Valgrind of testsuite/jit.dg/test-types.c showed this leak in real.c
when converting the strings in init_ext_80387_constants to real.
160 bytes in 5 blocks are definitely lost in loss record 89 of 144
at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by
Running various JIT testcases under valgrid showed this one-time leak:
8,464 (336 direct, 8,128 indirect) bytes in 1 blocks are definitely lost in
loss record 144 of 147
at 0x4A081D4: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5DF4EA0: xcalloc (xmalloc.c:162)
cgraph*.c and ipa-*.c use xstrdup on strings when dumping them via
fprintf, leaking all of the duplicated buffers.
Is/was there a reason for doing this?
Taking them out fixes these leaks (seen when dumping is enabled):
12 bytes in 1 blocks are definitely lost in loss record 11 of 148
at
Introduce a struct toyvm_compiled_function so that we can clean things
up fully, avoiding warnings from valgrind.
gcc/jit/ChangeLog:
PR jit/63854
(toyvm_compiled_function): New typedef.
(toyvm_compiled_func) Rename to...
(toyvm_compiled_code) ...this.
I suspect this is papering over a real problem, but I've been
applying this workaround locally to keep my valgrind output clean.
gcc/ChangeLog:
PR/64003
* final.c (shorten_branches): Allocate insn_lengths with
XCNEWVEC rather than XNEWVEC; remove subsequent per-element
Various functions in tree-pretty-print.c take a param
pretty_printer *buffer
and there's also a static pretty_printer *buffer;
Additionally, pretty_printer instances are not buffers; they
*contain* buffers (inasmuch as they have a field buffer).
This patch renames such params from buffer to
Continue to refactor playback::context::compile, moving the DSO-generation
into its own function.
gcc/jit/ChangeLog:
* jit-playback.c (gcc::jit::playback::context::compile): Move DSO
creation code into...
(gcc::jit::playback::context::convert_to_dso): New function.
Various cleanups of the jit code
Successfully bootstrapped regrtested on x86_64-unknown-linux-gnu
(Fedora 20).
OK for trunk?
(am not yet officially blessed as the JIT maintainer, so I require
review for the non-obvious patches)
100644
index 000..9e1e6d8
--- /dev/null
+++ b/gcc/jit/jit-result.c
@@ -0,0 +1,73 @@
+/* Internals of libgccjit: implementation of gcc_jit_result
+ Copyright (C) 2013-2014 Free Software Foundation, Inc.
+ Contributed by David Malcolm dmalc...@redhat.com.
+
+This file is part of GCC.
+
+GCC is free
The body of playback::context::compile is rather long, at 200 lines.
Start splitting it out parts of it into smaller member functions.
Also, eliminate a fixed-size buffer with bounds check in favor of an
auto_vec.
gcc/jit/ChangeLog:
* jit-playback.c
gcc/jit/ChangeLog:
* docs/examples/tut02-square.c (main): Release the context
earlier, to show that this is possible. Update error-handling
to avoid a double-release of the context, and to avoid
releasing a NULL result.
* docs/intro/tutorial02.rst: Discuss
Various improvements to jit documentation
Touches one of the tutorial examples, which is also used as part of the
testsuite: successfully bootstrapped regrtested on
x86_64-unknown-linux-gnu (Fedora 20).
OK for trunk?
(am not yet officially blessed as the JIT maintainer, so I require
review for
gcc/jit/ChangeLog:
PR jit/64018
* docs/intro/tutorial02.rst: Spell out lifetime of generated code.
Add description of error-handling, taken in part from...
* docs/topics/contexts.rst (Error-handling): Expand, and move some
content to tutorial02.rst.
---
Various fixes/improvements to builtins-handling within jit.
Successfully bootstrapped regrtested on x86_64-unknown-linux-gnu
(Fedora 20).
OK for trunk?
(am not yet officially blessed as the JIT maintainer, so I require
review for the non-obvious patches)
jit-builtins.c only supports a subset of builtin-types.def, and
can fail if the user requests a builtin that uses the unsupported
types.
Whilst fixing PR jit/64020 I noticed that these failures read through
NULL and segfault.
Fix it by checking for get_type and make_builtin_function returning
Investigating PR jit/64020 showed that tree-ssa-math-opts.c was
failing to optimize sin/cos operations within the JIT since this:
fndecl = mathfn_built_in (type, BUILT_IN_CEXPI);
was returning NULL.
Several issues were present:
(A) In the JIT we don't pre-build all builtins, just the ones
On Wed, 2014-11-26 at 09:13 +0100, Uros Bizjak wrote:
Hello!
cgraph*.c and ipa-*.c use xstrdup on strings when dumping them via
fprintf, leaking all of the duplicated buffers.
Is/was there a reason for doing this?
Yes, please see [1] and PR 53136 [2]. As said in [1]:
There is a
On Tue, 2014-09-23 at 23:27 +, Joseph S. Myers wrote:
[...]
The code for compiling a .s file should:
[...]
* use the $(target_noncanonical)-gcc-$(version) name for the driver rather
than plain gcc, to maximise the chance that it is actually the same
compiler the JIT library was built for
On Wed, 2014-09-24 at 22:04 -0600, Jeff Law wrote:
On 09/24/14 14:24, Joseph S. Myers wrote:
On Wed, 24 Sep 2014, David Malcolm wrote:
The ideal I'm aiming for here is that a well-behaved library should
never abort, so I've rewritten these functions to use vasprintf, and
added error
Committed to branch dmalcolm/jit:
gcc/testsuite/ChangeLog.jit:
* jit.dg/test-long-names.c: New test case.
* jit.dg/all-non-failing-tests.h: Add test-long-names.c
* jit.dg/test-combination.c (create_code): Likewise.
(verify_code): Likewise.
*
On Fri, 2014-09-26 at 11:45 -0700, Mike Stump wrote:
On Sep 26, 2014, at 8:14 AM, David Malcolm dmalc...@redhat.com
wrote:
* jit.dg/test-long-names.c: New test case.
+/* 65KB */
+#define NAME_LENGTH (65 * 1024)
65K was a tiny name back in 1999, 16M was a large name then. Today
On Tue, 2014-09-23 at 23:27 +, Joseph S. Myers wrote:
[...]
The code for compiling a .s file should:
[...]
* use libiberty's pexecute to run subprocesses, not system (building up
a string to pass to the shell always looks like a security hole, though in
this case it may in fact be safe);
Committed to branch dmalcolm/jit:
gcc/jit/ChangeLog.jit:
* TODO.rst: Update.
* docs/topics/expressions.rst (gcc_jit_context_new_call): Add
a note clarifying the behavior of this entrypoint.
* docs/topics/functions.rst (Creating and using functions): Markup
On Mon, 2014-09-29 at 20:24 +0100, Jiong Wang wrote:
On 29/09/14 19:32, Richard Henderson wrote:
On 09/29/2014 11:12 AM, Jiong Wang wrote:
+inline rtx single_set_no_clobber_use (const rtx_insn *insn)
+{
+ if (!INSN_P (insn))
+return NULL_RTX;
+
+ if (GET_CODE (PATTERN (insn))
David Malcolm dmalc...@redhat.com
+
+ PR plugins/63410
+ * Makefile.in (PRETTY_PRINT_H): Add wide-int-print.h.
+ (PLUGIN_HEADERS): Add pass-instances.def.
+
2014-09-30 James Greenhalgh james.greenha...@arm.com
* config/aarch64/aarch64-simd-builtins.def (sqdmull_laneq): Expand
Index: gcc
On Wed, 2014-10-01 at 16:34 -0600, Jeff Law wrote:
This was inspired by a discussion with Felix who was making changes in
this area.
Basically this promotes the init_insns field within struct equivalence
from an rtx to an rtx_insn_list.
The only thing that's really interesting here is
On Tue, 2014-09-23 at 23:27 +, Joseph S. Myers wrote:
[...]
Shouldn't the jit.pdf, jit.install-html etc. Make-lang.in hooks actually
build / install the documentation for this JIT?
[...]
I've committed the following to the branch dmalcolm/jit:
This patch implements the documentation
I've merged the last ~3 weeks of changes of svn trunk to the git branch
dmalcolm/jit, pushing it as
dbfbacdbbf727e8ab3a8cff2d5650d8000de0449.
Specifically, this is from trunk r215803 aka
68874c5d021dd6b8b740ffd23960e46e333270b5 (2014-10-02) bringing in all
changes since r215090 aka
The main function for the driver in gcc.c has grown from ~200 lines
in its original form (way back in r262) to ~1000 lines today, with a
dozen locals (if we include the params).
The following patch splits it up into 15 smaller functions, moving the
various locals into the places where they're
Committed to branch dmalcolm/jit:
Running e.g. test-factorial.exe under valgrind shows that libgccjit.so
was leaking ~13.5KB of RAM per invocation of the compiler here:
==57074== 21,440 bytes in 4 blocks are definitely lost in loss record 896 of 907
==57074==at 0x4A0645D: malloc (in
On Fri, 2014-10-03 at 11:02 -0400, David Malcolm wrote:
The main function for the driver in gcc.c has grown from ~200 lines
in its original form (way back in r262) to ~1000 lines today, with a
dozen locals (if we include the params).
The following patch splits it up into 15 smaller functions
1 - 100 of 4908 matches
Mail list logo