Temporary source files created by the selftests weren't generated
correctly if they contained a "%" character (seen whilst writing
selftests for the locations-within-string-literals patch I'm
working on).
Root cause was a buggy fprintf in the selftest::temp_source_file ctor.
Fixed thusly.
Succes
This patch updates c-format.c to use the new class substring_loc, added
in the previous patch, replacing location_column_from_byte_offset.
Hence with this patch, Wformat can underline the precise erroneous
format string in many more cases.
The patch also introduces two new functions for emitting W
This is an updated version of:
"[PATCH] RFC: On-demand locations within string-literals"
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00441.html
Changes in v2:
- Tweaks to substring location selftests
- Many more selftests (EBCDIC, the various wide string types, etc)
- Clean up conditions i
This adds fix-it hints to c-format.c so that it can (sometimes) suggest
the format string the user should have used.
The patch adds selftests for the new code in c-format.c. These
selftests are thus lang-specific. This is the first time we've had
lang-specific selftests, and hence the patch also
C++11 has a
static_assert (COND, MESSAGE)
which gives more readable error messages for STATIC_ASSERT than our
current implementation.
This patch makes us use it if __cplusplus >= 201103L
There's also a provisional static_assert (COND) in C++1z, but presumably
we should wait until that one is fu
On Mon, 2016-07-25 at 10:36 +0200, Richard Biener wrote:
> On Fri, Jul 22, 2016 at 4:11 PM, Jakub Jelinek
> wrote:
> > On Fri, Jul 22, 2016 at 10:33:50AM -0400, David Malcolm wrote:
> > > gcc/cp/ChangeLog:
> > > * parser.h (struct cp_token): Add a STATIC_ASS
On Tue, 2016-07-26 at 19:05 +0100, Manuel López-Ibáñez wrote:
> On 26/07/16 18:11, David Malcolm wrote:
>
> > gcc/ChangeLog:
> > * gcc.c (cpp_options): Rename string to...
> > (cpp_options_): ...this, to avoid clashing with struct in
> > cpplib.h.
>
For some reason I added make_location and some related functions to
tree.h/c, rather than to input.h/c. Move them there, so we can use them
without requiring tree, and add some selftest coverage.
Bootstrapped®rtested on x86_64-pc-linux-gnu.
Committed to trunk as r238792.
gcc/ChangeLog:
On Wed, 2016-07-27 at 17:17 +0200, Thomas Schwinge wrote:
> Hi!
>
> I found that for a lot of OpenACC (and potentially also OpenMP)
> clauses
> (in C/C++ front ends; didn't look at Fortran), we use wrong location
> information. The problem is that
> c_parser_oacc_all_clauses/c_parser_omp_all_clau
On Wed, 2016-07-27 at 23:41 +0100, Manuel López-Ibáñez wrote:
> On 27 July 2016 at 15:30, David Malcolm wrote:
> > > Perhaps it could live for now in c-format.c, since it is the only
> > > place using it?
> >
> > Martin Sebor [CC-ed] wants to use it from the midd
On Thu, 2016-07-28 at 15:16 -0600, Martin Sebor wrote:
> On 07/28/2016 02:38 PM, Martin Sebor wrote:
> > On 07/28/2016 02:12 PM, David Malcolm wrote:
> > > On Wed, 2016-07-27 at 23:41 +0100, Manuel López-Ibáñez wrote:
> > > > On 27 July 2016 at 15:30
On Fri, 2016-07-29 at 08:22 -0600, Martin Sebor wrote:
> > Currently all that we need from the C family of frontends is the
> > cpp_reader and the string concatenation records. I think we can
> > reconstruct the cpp_reader if we have the options, though
> > presumably
> > that's per TU, so to supp
On Fri, 2016-07-29 at 10:46 -0400, David Malcolm wrote:
> On Fri, 2016-07-29 at 08:22 -0600, Martin Sebor wrote:
> > > Currently all that we need from the C family of frontends is the
> > > cpp_reader and the string concatenation records. I think we can
> > > reconst
On Fri, 2016-07-29 at 17:53 +0100, Manuel López-Ibáñez wrote:
> On 29 July 2016 at 16:25, David Malcolm wrote:
> >
> > FWIW, it appears that clang uses the on-demand approach; the
> > relevant
> > code appears to be StringLiteral::getLocationOfByte:
> &
On Fri, 2016-07-29 at 21:42 +, Joseph Myers wrote:
> On Tue, 26 Jul 2016, David Malcolm wrote:
>
> > This patch implements precise tracking of source locations for the
> > individual chars within string literals, so that we can e.g.
> > underline
> > specific
On Mon, 2016-11-28 at 14:44 -0700, Jeff Law wrote:
> On 11/23/2016 04:55 PM, Segher Boessenkool wrote:
> > Combine can turn a conditional trap into an unconditional trap. If
> > it
> > does that it should make the code after it unreachable (an
> > unconditional
> > trap should be the last insn in
On Mon, 2016-11-28 at 15:02 -0700, Jeff Law wrote:
> On 11/28/2016 03:00 PM, David Malcolm wrote:
> > On Mon, 2016-11-28 at 14:44 -0700, Jeff Law wrote:
> > > On 11/23/2016 04:55 PM, Segher Boessenkool wrote:
> > > > Combine can turn a conditional trap into an un
On Mon, 2016-11-28 at 14:47 +0100, Bernd Schmidt wrote:
> Been looking at this off and on, and I'm still not sure I entirely
> get
> it - sorry.
>
> On 11/11/2016 10:15 PM, David Malcolm wrote:
> > > > Implementing an RTL frontend by using the RTL reader from r
On Tue, 2016-11-29 at 18:23 +0100, Bernd Schmidt wrote:
> On 11/29/2016 06:20 PM, David Malcolm wrote:
> >
> > if that distinction makes sense. Clearly we already have a
> > diagnostics
> > subsystem on the host; what this patch is adding is the separate,
>
libiberty's implementations of strndup and xstrndup call strlen on
the input string, and hence can read past the end of the input buffer
if it isn't zero-terminated (such as is the case in PR c/78498, where
the input string is from the input.c line cache).
This patch converts them to use strnlen i
le
> > -objc-gc
> > and --with-target-bdw-gc.
[...]
r242985 seems to have broken the build, for me at least (with texinfo
5.1):
../../src/gcc/doc/install.texi:2199: use braces to give a command as an
argument to @=
make[2]: *** [doc/gccinstall.info] Error 1
The attached pat
The ICE in PR preprocessor/78569 appears to be due to an attempt to
generate substring locations in a .i file where the underlying .c file
has changed since the .i file was generated.
This can't work, so it seems safest for the on-demand substring
locations to be unavailable for such files, fallin
On Tue, 2016-11-29 at 18:20 -0700, Sandra Loosemore wrote:
> On 11/29/2016 06:10 PM, David Malcolm wrote:
> > [snip]
> >
> > r242985 seems to have broken the build, for me at least (with
> > texinfo
> > 5.1):
> >
> > ../../src/gcc/doc/install.texi
On Wed, 2016-11-30 at 17:18 +0100, Bernd Schmidt wrote:
> On 11/29/2016 10:13 PM, Bernd Schmidt wrote:
> > On 11/29/2016 07:53 PM, David Malcolm wrote:
> >
> > > Would you prefer that I went with approach (B), or is approach
> > > (A)
> > > acceptable?
On Thu, 2016-12-01 at 15:40 +0100, Bernd Schmidt wrote:
Thanks for looking at this.
> On 11/11/2016 10:15 PM, David Malcolm wrote:
> > #include "gt-aarch64.h"
> > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> > index 6c608e0..0dda786 100644
&
All of the jit testcases that generate debuginfo appear to have been
failing since r240228 on their 2nd in-process iteration on this
assertion in set_early_dwarf's ctor:
gcc_assert (! early_dwarf_finished);
Root cause is that the global is never reset at the end of compilation,
which this p
On Thu, 2016-12-01 at 14:29 +0100, Bernd Schmidt wrote:
> On 11/11/2016 10:15 PM, David Malcolm wrote:
> > + /* Makefile.in has -fself-test=$(srcdir)/testsuite/selftests, so
> > that
> > + flag_self_test contains the path to the selftest subdirectory
> > of the
>
gcc/ChangeLog:
* function-tests.c (selftest::verify_three_block_rtl_cfg): Remove
"static".
* read-rtl-function.c (selftest::assert_edge_at): New function.
(ASSERT_EDGE): New macro.
(selftest::test_loading_dump_fragment_1): New function.
(selftest::tes
This patch adds more selftests for class function_reader, where
the dumps to be read contain aarch64-specific features.
In an earlier version of the patch kit, these were handled using
#ifndef GCC_AARCH64_H to conditionalize running them.
This version instead runs them via a target hook for runnin
Changed in v6:
- split out dump-reading selftests into followup patches
(target-independent, and target-specific)
- removes unneeded headers from read-rtl-function.c
- numerous other cleanups identified in review
Changed in v5:
- updated for change to emit_status::ensure_regno_capacity
Changed
This patch adds more selftests for class function_reader, where
the dumps to be read contain x86_64-specific features.
In an earlier version of the patch kit, these were handled using
This version instead runs them via a target hook for running
target-specific selftests, thus putting them within i
Changed in v6:
- Handle EOF in c_parser_parse_rtl_body
- Various fixups from review
Changed in v5:
- rebased from r242065 to r242392. In particular, this
brings in the gimple FE; rewrote the "startwith" pass-skipping
mechanism to work with both __GIMPLE and __RTL.
- rewrote the "__RTL" parse
On Thu, 2016-12-01 at 16:05 -0700, Jeff Law wrote:
> On 11/11/2016 02:15 PM, David Malcolm wrote:
> > Posted earlier here:
> > https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00651.html
> > Link to earlier discussion:
> > https://gcc.gnu.org/ml/gcc-patches/2016-10/
On Fri, 2016-12-02 at 15:41 +0100, Bernd Schmidt wrote:
> On 12/02/2016 03:00 AM, David Malcolm wrote:
> > Changed in v6:
> > - split out dump-reading selftests into followup patches
> > (target-independent, and target-specific)
> > - removes unneeded heade
On Fri, 2016-12-02 at 16:28 +0100, Bernd Schmidt wrote:
> On 12/01/2016 10:43 PM, David Malcolm wrote:
> > > > + rtx_insn *jump_insn = get_insn_by_uid (1);
> > > > + ASSERT_EQ (JUMP_INSN, GET_CODE (jump_insn));
> > > > + ASSERT_EQ (ret_rtx, JUMP_LABEL (ju
On Thu, 2016-12-01 at 13:40 +0100, Bernd Schmidt wrote:
> On 11/30/2016 09:24 PM, David Malcolm wrote:
>
> > gcc/ChangeLog:
> > * read-md.c (have_error): New global, copied from errors.c.
> > (fatal): New function, copied from errors.c.
>
> I would have ex
As part of the fix for PR c/78498 I added selftests for xstrndup in
r243030, and seeing the implementation of strndup in libiberty, I
also made the selftests verify strndup.
This turned out to be overzealous, as strndup is not necessarily available
in every configuration when the selftests run.
T
On Tue, 2016-12-06 at 17:22 +, James Greenhalgh wrote:
> On Thu, Dec 01, 2016 at 09:00:11PM -0500, David Malcolm wrote:
> > This patch adds more selftests for class function_reader, where
> > the dumps to be read contain aarch64-specific features.
> >
> > In an e
In r243317 I accidentally introduced an assumption in a selftest
in i386.c that Pmode == DImode. This patch conditionalizes the
overzealous string comparison to avoid breaking the build on
32-bit i386.c targets.
Committed to trunk as r243332 as obvious.
Sorry about the breakage.
gcc/ChangeLog:
The RTL frontend patch kit failed to build on powerpc-ibm-aix7.1.3.0
(gcc111), with this error:
build/genmddeps ../../src/gcc/common.md ../../src/gcc/config/rs6000/rs6000.md >
tmp-mddeps
../../src/gcc/config/rs6000/rs6000.md:2255:1: unterminated construct
due to the final close paren on line 225
Testing the patch kit on i686 showed numerous failures of this
assertion in set_mem_attributes_minus_bitpos in emit-rtl.c:
1821gcc_assert (!defattrs->offset_known_p);
when expanding "main" in the rtl.exp test files, after parsing
an __RTL-tagged function.
Root cause is various assignme
On Thu, 2016-12-01 at 14:29 +0100, Bernd Schmidt wrote:
> On 11/11/2016 10:15 PM, David Malcolm wrote:
> > + /* Makefile.in has -fself-test=$(srcdir)/testsuite/selftests, so
> > that
> > + flag_self_test contains the path to the selftest subdirectory
> > of the
>
On Thu, 2016-12-08 at 21:08 +0100, Bernd Schmidt wrote:
> On 12/08/2016 09:39 PM, David Malcolm wrote:
> >
> > OK as adjustments to patches 8a and 8b?
>
> Ok. Is it possible to adjust these macros to return something like a
> const reference to ensure people can&#
On Fri, 2016-12-09 at 12:56 +, Richard Sandiford wrote:
> This patch adds a scalar_float_mode class, which wraps a mode enum
> that is known to satisfy SCALAR_FLOAT_MODE_P. Things like "SFmode"
> now give a scalar_float_mode object instead of a machine_mode.
> This in turn needs a change to th
On Fri, 2016-12-09 at 02:48 +0100, Bernd Schmidt wrote:
> On 12/08/2016 10:47 PM, David Malcolm wrote:
>
> > Is (A) OK, or would you prefer (B)? (I prefer (A) fwiw)
>
> Oh well, just keep it as it is.
>
>
> Bernd
Thanks. Unfortunately, applying the "locate_f
PR preprocessor/78680 identifies a crash when attempting to issue
a -Wformat warning, where the format string includes a string token
split across multiple physical source lines via backslash-continued
lines.
The issue is that libcpp is generating bogus range information for
such tokens.
For exam
On Wed, 2016-12-14 at 11:54 +0100, Andreas Schwab wrote:
> This crashes the compiler on ia64.
Sorry about the breakage.
I'm able to reproduce this under valgrind on x86_64 (looks like a read
after free); I'm working on a fix.
Thanks
Dave
> FAIL: c-c++-common/raw-string-6.c -Wc++-compat (test
The RTL frontend parses the output of print_rtx_function's "compact"
mode.
Currently non-virtual pseudo regs in such dumps have a '%' prefix,
based on the discussion here (me):
* " Re: [PATCH] Tweaks to print_rtx_function"
* https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01033.html
and here (
On Wed, 2016-12-14 at 15:02 +0100, Bernd Schmidt wrote:
> On 12/09/2016 08:32 PM, David Malcolm wrote:
> > Thanks. Unfortunately, applying the "locate_file" patch
> > https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01186.html
> > would now introduce a regressio
On Thu, 2016-12-15 at 17:39 +, Jonathan Wakely wrote:
> This patch tries to improve the user experience when debugging
> container iterators, for cases where some of the typedefs used by the
> printers are not in the debuginfo, so gdb.lookup_type() calls fail.
> That happens if the iterator's o
On Fri, 2016-12-16 at 14:28 +0100, Bernd Schmidt wrote:
> On 12/14/2016 05:57 PM, David Malcolm wrote:
> > Any preferences? (or other syntax ideas?). My preference is one of
> > the
> > currently-unused sigils e.g. "@3", or to wrap them in braces "{3}".
&
For reference, here are the changes to patch 8a to update it to the
new syntax.
I'm assuming that this (and the changes to the various dumpfiles in
patches 8b-8d) count as "obvious".
gcc/ChangeLog:
* read-rtl-function.c (lookup_reg_by_dump_name): Rework to expect
regno wrapped in
On Fri, 2016-12-16 at 10:32 -0500, David Malcolm wrote:
> On Fri, 2016-12-16 at 14:28 +0100, Bernd Schmidt wrote:
> > On 12/14/2016 05:57 PM, David Malcolm wrote:
> > > Any preferences? (or other syntax ideas?). My preference is one
> > > of
> > > the
> &g
Our -Wattributes warnings can be rather cryptic. The following patch
improves this warning:
../../src/pr70186.c:1:8: warning: 'visbility' attribute directive ignored
[-Wattributes]
struct S *foo __attribute__ ((visbility("hidden")));
^
by adding suggestions when unrecognized attributes
Note to i386 maintainters: this patch is part of the RTL frontend.
It adds selftests for verifying that the RTL dump reader works as
expected, with a mixture of real and hand-written "dumps" to
exercise various aspects of the loader. Many RTL dumps contain
target-specific features (e.g. names of
This is the final part of the RTL "frontend" patch kit, implemented as
a special case for functions marked with __RTL within the C frontend.
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu on top
of the rest of the RTL frontend patch kit.
OK for trunk?
Changed in v7:
- remove i?86-*-* f
The patch updates the example dump in the comment for
print_rtx_function to reflect various changes:
- r241593: addition of insn UIDs
- r241908: removal of trailing "(nil)" and other default values
- r242023: addition of "param" directives
- r243798: change of format of regnos in non-virtual pseudo
On Mon, 2016-12-19 at 15:10 -0700, Jeff Law wrote:
> On 12/08/2016 01:39 PM, David Malcolm wrote:
> > Testing the patch kit on i686 showed numerous failures of this
> > assertion in set_mem_attributes_minus_bitpos in emit-rtl.c:
> >
> > 1821gcc_assert
Commit r210360 removed the first "i" field from the various instruction
nodes in rtx.def, moving it to an explicit "int insn_uid;" field
of the union "u2" within rtx_def.
Update the comment in rtl.def to reflect this change. Also, fix
a stray apostrophe.
Successfully bootstrapped & regrtested on
Whilst debugging an issue in df, I noticed that there are
some #define constants that could be an enum (thus making them known
to gdb).
Convert them to a new enum, and update the "id" field of
struct df_problem.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu
OK for trunk?
gcc/Cha
The various struct df_problem instances are constant data; mark them
as such.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu
OK for trunk?
gcc/ChangeLog:
* df-core.c (df_add_problem): Make the problem param be const.
(df_remove_problem): Make local "problem" be con
The function maybe_set_first_label_num acts on a CODE_LABEL; we can
capture that in the type system.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu; it's
only used from stmt.c (not in any of the config subdirs), so I didn't
attempt a many-config test.
OK for trunk?
gcc/ChangeLog:
When we emit a hint about a misspelled member name, it will slightly
aid readability if we use a fixit-hint to show the proposed
name in context within the source code (and in the future this
might support some kind of auto-apply in an IDE).
This patch adds such a hint to the C++ frontend, taking
This is a resend of a patch kit I sent in stage 3; the original post
was here:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01933.html
I've rebased the patches against yesterday's trunk and retested them.
They add various fix-it hints to existing diagnostics (PR 62314 is a
catch-all for adding
Looking over the discussion of missing semicolons in
"Quality of Implementation and Attention to Detail"
within
http://clang.llvm.org/diagnostics.html
and comparing with
https://gcc.gnu.org/wiki/ClangDiagnosticsComparison
I noticed that of the cases we do handle [1], there's room for
improvem
Similar to the C++ case, but more involved as the location of the
pertinent token isn't readily available. The patch adds it as a param
to build_component_ref. All callers are updated to provide the info,
apart from objc_build_component_ref; fixing the latter would lead to
a cascade of other chan
This patch makes the argv param to read_md_files const, needed
so that the RTL frontend can call it on a const char *.
While we're at it, it similarly makes const the argv for all
of the "main" functions of the various gen*.
OK for trunk?
gcc/ChangeLog:
* genattr-common.c (main): Convert
The RTL frontend needs to be able to lookup passes by name.
passes.c has global state name_to_pass_map (albeit static, scoped
to passes.c), for use by enable_disable_pass.
Move it to be a field of class pass_manager, and add
a get_pass_by_name method.
OK for trunk?
gcc/ChangeLog:
* pass
to use the current value of VIRTUAL_STACK_VARS_REGNUM on the
target rtl1 was built for?
TODO items
**
* test with other architectures
* roundtrip.exp: strip out comments in source when comparing roundtrip
* example with "-g"
* implement a fuzzer (or use AF
In order to faithfully load RTL dumps that contain references to
source locations, the RTL frontend needs to be able to parse file
and line information and turn then into location_t values.
Unfortunately, the libcpp API makes it rather fiddly to create
location_t values from a sequence of arbitrar
C++11 adds the ability to add "override" after an implementation of a
virtual function in a subclass, to:
(A) document that this is an override of a virtual function
(B) allow the compiler to issue a warning if it isn't (e.g. a mismatch
of the type signature).
Similarly, it allows us to add a "fin
Mark most virtual functions in gcc/jit as being FINAL OVERRIDE.
gcc::jit::recording::lvalue::access_as_rvalue is the sole OVERRIDE
that isn't a FINAL.
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu.
I can self-approve this, but as asked in patch 1,
does "final" imply "override"? Is "fi
On Fri, 2016-05-06 at 18:20 +0200, Jakub Jelinek wrote:
> On Fri, May 06, 2016 at 12:40:45PM -0400, David Malcolm wrote:
> > C++11 adds the ability to add "override" after an implementation of
> > a
> > virtual function in a subclass, to:
> > (A) document
opts-common.c's cmdline_handle_error handles invalid arguments
for options with CL_ERR_ENUM_ARG by building a strings listing the
valid arguments. By also building a vec of valid arguments, we
can use find_closest_string and provide a hint if we see a close
misspelling.
Successfully bootstrapped®
When debugging diagnostic-show-locus.c, it's invaluable to have a
"ruler" showing column numbers.
This patch adds in support via a new "show_ruler_p" flag within
the diagnostic_context. There's no direct way for end-users to enable
this, but plugins can enable it by setting the flag, so the
plugi
On Wed, 2016-05-04 at 16:49 -0400, David Malcolm wrote:
[...snip...]
>
> I wrote this by compiling a test.c with -fdump-rtl-all on
> x86_64-pc-linux-gnu, and then attempting to load the state at each
> pass, and then trying to run just one pass, and fixing bugs until the
> dump o
read-md.c and read-rtl.c repeatedly use this pattern:
c = read_skip_spaces ();
if (c != ')')
fatal_expected_char (')', c);
Simplify them by introduce a helper function to do this.
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu.
OK for trunk?
gcc/ChangeLog:
* rea
[CCing Prasad since this may be useful for his gimple FE work, by
replacing "rtl" with "gimple" in the patch]
On Mon, 2016-05-09 at 11:44 +0200, Richard Biener wrote:
> On Wed, May 4, 2016 at 10:49 PM, David Malcolm
> wrote:
> > This patch kit introduces an RTL
On Tue, 2016-05-10 at 22:09 +0200, Bernhard Reutner-Fischer wrote:
> On Mon, May 09, 2016 at 08:14:47PM -0400, David Malcolm wrote:
>
> > - inform (loc, "valid arguments to %qs are: %s", option
> > ->opt_text, s);
> > + const char *hint =
On Wed, 2016-05-11 at 11:57 +0200, Richard Biener wrote:
> On Wed, May 11, 2016 at 3:31 AM, Trevor Saunders <
> tbsau...@tbsaunde.org> wrote:
> > On Tue, May 10, 2016 at 05:01:00PM -0400, David Malcolm wrote:
> > > [CCing Prasad since this may be useful for his gimple
On Fri, 2016-05-06 at 12:40 -0400, David Malcolm wrote:
> Mark most virtual functions in gcc/jit as being FINAL OVERRIDE.
> gcc::jit::recording::lvalue::access_as_rvalue is the sole OVERRIDE
> that isn't a FINAL.
>
> Successfully bootstrapped®rtested on x86_64-pc-linux-
Every version of libgccjit.h in trunk has had
gcc_jit_context_new_call_through_ptr, but it wasn't
documented until now.
Committed to trunk as r236341.
gcc/jit/ChangeLog:
* docs/topics/expressions.rst (Function calls): Document
gcc_jit_context_new_call_through_ptr.
* docs/_
libgccjit performs numerous checks at the API boundary, but
if these succeed, it ignores errors and other diagnostics emitted
within the core of gcc, and treats the compile of a gcc_jit_context
as having succeeded.
This patch ensures that if any diagnostics are emitted, they
are visible from the l
This implements the libgccjit support for must-tail-call via
a new:
gcc_jit_rvalue_set_bool_require_tail_call
API entrypoint.
(I didn't implement a wrapper for this within the C++ bindings)
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu.
gcc/jit/ChangeLog:
* docs/topics/compa
ssue.
Patch 3 implements the libgccjit.h API support to allow client
code to set the flag.
[1] https://gcc.gnu.org/ml/jit/2016-q2/msg00010.html
David Malcolm (3):
Introduce can_implement_as_sibling_call_p
Implement CALL_EXPR_MUST_TAIL_CALL
jit: implement gcc_jit_rvalue_set_bool_requir
This patch implements support for marking CALL_EXPRs
as being mandatory for tail-call-optimization. expand_call
tries harder to perform the optimization on such CALL_EXPRs,
and issues an error if it fails.
Currently this flag isn't accessible from any frontend,
so the patch uses a plugin for testi
This patch moves part of the logic for determining if tail
call optimizations are possible to a new helper function.
There are no functional changes.
expand_call is 1300 lines long, so there's arguably a
case for doing this on its own, but this change also
enables the followup patch.
The patch c
On Wed, 2016-05-18 at 17:05 +0200, Paolo Carlini wrote:
> Hi,
>
> On 18/05/2016 16:39, Jason Merrill wrote:
> > On 05/17/2016 04:47 PM, Paolo Carlini wrote:
> > > this ICE during error recovery exposes a rather more general
> > > weakness:
> > > we should never call cp_lexer_peek_nth_token (*, 2)
On Wed, 2016-05-18 at 19:59 +0300, Pekka Jääskeläinen wrote:
> Hi Joseph,
>
> Thanks for the comments. Updated&rebased patch attached. Hopefully I
> didn't miss any diags.
It looks like the attachment doesn't contain the patch; on unzipping I
just see a 27 byte file reading "The BRIG frontend it
The source-range handling for the array form of operator
new/delete erroneously assumed that the "]" was present,
leading to a dereference of NULL when it's absent.
Fix it thusly.
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu;
adds 6 PASS results to g++.sum.
OK for trunk and gcc-6-bra
PR c/71171 reports yet another instance of the src_range of a
c_expr being used without initialization. Investigation shows
that this was due to error-handling, where the "value" field of
a c_expr is set to error_mark_node without touching the
src_range, leading to complaints from valgrind.
This
On Fri, 2016-05-20 at 18:03 +0100, Kyrill Tkachov wrote:
[...snip...]
> REG_PARM_STACK_SPACE is not defined on arm, which makes
> reg_parm_stack_space
> unused in this function and so breaks bootstrap on arm.
> Can you please add an ATTRIBUTE_UNUSED to reg_parm_stack_space?
>
> Thanks,
> Kyrill
[.
On Tue, 2016-05-17 at 18:49 -0400, Trevor Saunders wrote:
> On Tue, May 17, 2016 at 06:01:32PM -0400, David Malcolm wrote:
> > This implements the libgccjit support for must-tail-call via
> > a new:
> > gcc_jit_rvalue_set_bool_require_tail_call
> > API entrypoint.
>
The following fixes the known failures of the must-tail-call tests.
Tested with --target=
* aarch64-unknown-linux-gnu
* ia64-unknown-linux-gnu
* m68k-unknown-linux-gnu
* x86_64-pc-linux-gnu
OK for trunk?
gcc/testsuite/ChangeLog:
* gcc.dg/plugin/must-tail-call-2.c (test_2_caller): Genera
On Thu, 2015-08-13 at 01:58 +0200, Markus Trippelsdorf wrote:
> On 2015.08.12 at 13:03 -0600, Jeff Law wrote:
> > On 08/12/2015 12:57 PM, Richard Sandiford wrote:
> > > Jeff Law writes:
> > >> On 08/10/2015 06:05 AM, tbsaunde+...@tbsaunde.org wrote:
> > >>> From: Trevor Saunders
> > >>>
> > >>> H
Reported as fixing the library on OS X Yosemite:
https://gcc.gnu.org/ml/jit/2015-q3/msg00147.html
Committed to trunk as r226882.
Committed to gcc-5-branch as r226883.
gcc/jit/ChangeLog:
* jit-playback.c (invoke_driver): On OS X, add
"-Wl,-undefined,dynamic_lookup" to the driver
On Fri, 2015-08-14 at 12:25 -0600, Jeff Law wrote:
> On 08/14/2015 02:02 AM, Richard Biener wrote:
> > On Fri, Aug 14, 2015 at 3:04 AM, Mikhail Maltsev wrote:
> >> The second part removes all global state accesses (i.e. accesses to cfun
> >> and
> >> it's members) from dominance.c. This requires
On Wed, 2015-08-19 at 11:50 -0400, tbsaunde+...@tbsaunde.org wrote:
> From: tbsaunde
>
> Hi,
>
> more typedef cleanup.
>
> bootstrapped + regtested on x86_64-linux-gnu, commited since preapproved
> by richi.
[...]
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index db23a0f..32421c5 100644
>
On Thu, 2015-08-06 at 10:52 -0400, David Malcolm wrote:
Ping:
https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00355.html
In particular, I'm hoping for review of patch 1, which provides a way to
clean up state within the driver code (patch 2 uses this from libgccjit
to embed it in-process, r
On Tue, 2015-08-25 at 13:48 +, Joseph Myers wrote:
> On Thu, 6 Aug 2015, David Malcolm wrote:
>
> > gcc/ChangeLog:
> > * gcc-main.c (main): Add params to driver ctor.
> > * gcc.c (class env_manager): New.
> > (env): New global.
&g
3201 - 3300 of 5457 matches
Mail list logo
