On 09/13/2016 04:24 PM, Jason Merrill wrote:
But we could define TARGET_ABSOLUTE_BIGGEST_ALIGNMENT on nvptx instead
of on x86; is this OK?
That's what I had in mind. It would be good if Thomas or Nathan could
give this patch a spin, I'm not currently really set up for it. But it
looks like a
On 09/13/2016 01:15 PM, Bernd Schmidt wrote:
On 09/12/2016 08:57 PM, David Malcolm wrote:
I'm not sure I follow - this sounds like a dedicated target for
selftesting.
Would it be a separate configuration i.e. something like:
../src/configure --target=rtl-selftest
or somesuch?
The
On 09/14/2016 02:45 AM, David Malcolm wrote:
In combination with -fdiagnostics-generate-patch this can generate output
like this:
--- ../../src/gcc/testsuite/c-c++-common/fix-missing-initializer-1.c
+++ ../../src/gcc/testsuite/c-c++-common/fix-missing-initializer-1.c
@@ -2,7 +2,7 @@
in
On 09/14/2016 03:04 PM, Segher Boessenkool wrote:
Then rs6000 (and many other ports probably) will just turn it off again.
It is actively harmful.
The data that was posted showed a code size decrease on a number of
targets. I'm really not sure where this irrational hate for regrename
comes fr
On 09/14/2016 03:55 PM, Segher Boessenkool wrote:
On Wed, Sep 14, 2016 at 03:08:21PM +0200, Bernd Schmidt wrote:
The data that was posted showed a code size decrease on a number of
targets. I'm really not sure where this irrational hate for regrename
comes from.
It increases the numb
On 09/14/2016 11:47 PM, Jakub Jelinek wrote:
http://gcc.gnu.org/ml/gcc-patches/2016-09/msg00088.html
- PR77425 - fix UB in sd_iterator_cond
Ok.
Bernd
On 09/14/2016 09:21 PM, tbsaunde+...@tbsaunde.org wrote:
Basically $subject. First change variable's type to rtx_insn * where possible.
Then change the functions and fixup callers where it is still necessary to
cast.
#2, #4 and #8 look good and can be applied if they work independently of
th
On 09/15/2016 03:38 PM, Wilco Dijkstra wrote:
__rawmemchr is not the fastest on any target I tried, including x86,
Interesting. Care to share your test program? I just looked at the libc
sources and strlen/rawmemchr are practically identical code so I'd
expect any difference to be lost in the
On 09/16/2016 12:10 PM, Trevor Saunders wrote:
ok, going through all the casts added here I see the following reasons
for them.
- in md files operands is a array of rtx, we should probably have a
different way to pass insns to the C code here. That seems worth
investigating incrementally.
On 09/16/2016 10:40 AM, Kyrill Tkachov wrote:
2016-09-16 Kyrylo Tkachov
* simplify-rtx.c (simplify_relational_operation_1): Add transformation
(GTU (PLUS a C) (C - 1)) --> (LTU a -C).
2016-09-16 Kyrylo Tkachov
* gcc.target/aarch64/gtu_to_ltu_cmp_1.c: New test.
Ok. Don't kn
On 09/16/2016 11:12 PM, David Malcolm wrote:
There are some interrelated questions here:
(a) where do the dumps live? (string fragments embedded in the source
file vs external files)
(b) -fself-test vs DejaGnu tests that use a real frontend. In the
latter case, is the frontend "rtl1", or an exte
On 09/18/2016 02:51 PM, Jan Hubicka wrote:
to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);
-
- /* If the field has a mode, we want to access it in the
-field's mode, not the computed mode.
-If a MEM has VOIDmode (external with incomplete type),
-
On 09/19/2016 04:43 PM, Kyrill Tkachov wrote:
Ok?
Sure.
Bernd
On 09/20/2016 01:16 AM, Segher Boessenkool wrote:
On Mon, Sep 19, 2016 at 06:07:46PM -0400, Trevor Saunders wrote:
- JUMP_LABEL can be a return which is not an insn. That also seems
like something that should be improved at some point.
The JUMP_LABEL field within a JUMP_INSN? That sounds
On 09/20/2016 04:32 PM, David Malcolm wrote:
To summarize so far: you want every pseudo to have its regno dumped
with a 'p' prefix, and renumber them on dump (and then on load).
OK.
Renumbering is not helpful because it interferes with the view you have
in the debugger. So, IMO just a prefix,
On 09/20/2016 05:18 PM, Jeff Law wrote:
I assume HARD_FRAME_POINTER_REGNUM is never zero.
It could be zero. It's just a hard register number. No target has the
property that its hard frame pointer register is 0 though :-)
git blame to the rescue. The current state comes from one of tbsaunde'
On 09/20/2016 05:20 PM, Jeff Law wrote:
On 09/20/2016 08:34 AM, Bernd Schmidt wrote:
(reg/f:DI v1 virtual-stack-vars)
this.
Doesn't the same apply to the number of virtual stack regs? Those are
in the same array as pseudos. So ISTM we prefix in the dump, but do
adjustment of the n
On 09/21/2016 01:09 AM, Trevor Saunders wrote:
I thought I remember discussing this macro with you, but see what was
checked in I'll believe I'm thinking of something similar but different.
I think this here was an earlier patch and the one we were discussing
recently was the other macro with
On 09/21/2016 01:46 PM, Renlin Li wrote:
* ira.c (ira): Move ira_use_lra_p initialization code to ...
(ira_init_once): Here.
LGTM.
Bernd
On 09/20/2016 08:51 PM, Segher Boessenkool wrote:
* doc/rtl.texi (JUMP_LABEL): Document RETURN and SIMPLE_RETURN values.
Ok, thanks.
Bernd
On 09/22/2016 01:48 PM, Jan Hubicka wrote:
* postreload.c (reload_cse_simplify): Also accept USE in noop move
patterns.
diff --git a/gcc/postreload.c b/gcc/postreload.c
index 61c1ce8..4f3a526 100644
--- a/gcc/postreload.c
+++ b/gcc/postreload.c
@@ -153,7 +153,8 @@ reload_cse_sim
On 09/22/2016 10:07 PM, Jakub Jelinek wrote:
I've noticed lots of vec_safe_length (CONSTRUCTOR_ELTS (...)) uses
in the sources, which IMHO are less readable than the much more often
used CONSTRUCTOR_NELTS (...) macro that does the same thing.
Bootstrapped/regtested on x86_64-linux and i686-linux
While trying to get the following benchmarks to run:
https://codesign.llnl.gov/lulesh.php
I came across some cases where the code and the compiler differed in its
interpretation of the OpenACC spec. Specifically, this occurs for acc
data clauses with arrays, like:
#pragma acc data copyin(a[
On 09/26/2016 04:34 PM, Kyrill Tkachov wrote:
Hi all,
This patch implements the minimal fixes for the issues that
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01547.html was supposed to
address
as suggested by Alexander.
Bootstrapped and tested on aarch64-none-linux-gnu and
arm-none-linux-gnue
On 09/16/2016 09:02 PM, Senthil Kumar Selvaraj wrote:
Does this make sense? I ran a reg test for the avr target with a
slightly older version of this patch, it did not show any regressions.
If this is the right fix, I'll make sure to run reg tests on x86_64
after backporting to a gcc vers
On 09/27/2016 01:09 PM, Richard Biener wrote:
On Tue, Sep 27, 2016 at 1:06 PM, Eric Botcazou wrote:
The accepted style is already very permissive, we don't allow just one
spelling as various lint tools.
Well, it cannot even handle the variations of a single codebase, GCC itself,
so I'm afraid
On 09/26/2016 09:08 PM, Denys Vlasenko wrote:
+@gccoptlist{-faggressive-loop-optimizations @gol
+-falign-functions[=@var{n}[,@var{m},[@var{n}[,@var{m} @gol
+-falign-jumps[=@var{n}[,@var{m}]] @gol
+-falign-labels[=@var{n}[,@var{m}]] -falign-loops[=@var{n}[,@var{m}]] @gol
@itemx -falign-fun
On 09/27/2016 01:51 PM, Marek Polacek wrote:
But the C/C++ keywords are all English, too; lint tools only accept English,
and so it wouldn't seem unreasonable to only accept English keywords in the
comments. And in any case, I don't see how a compiler can be expected to
be able to parse non-Engl
On 09/27/2016 12:58 PM, Nathan Sidwell wrote:
In working on some new code I got sufficiently frustrated to implement
pretty printing on internal function discriminators, as I think one of
you suggested a while back. With this patch we get:
.data_dep.2 = UNIQUE (OACC_FORK, .data_dep.2, -1);
ra
On 09/27/2016 02:01 PM, Marek Polacek wrote:
On Tue, Sep 27, 2016 at 01:55:22PM +0200, Bernd Schmidt wrote:
On 09/27/2016 01:51 PM, Marek Polacek wrote:
But the C/C++ keywords are all English, too; lint tools only accept English,
and so it wouldn't seem unreasonable to only accept En
On 09/27/2016 03:49 PM, Jakub Jelinek wrote:
On Tue, Sep 27, 2016 at 03:48:07PM +0200, Bernd Schmidt wrote:
On 09/27/2016 02:01 PM, Marek Polacek wrote:
On Tue, Sep 27, 2016 at 01:55:22PM +0200, Bernd Schmidt wrote:
On 09/27/2016 01:51 PM, Marek Polacek wrote:
But the C/C++ keywords are all
On 09/27/2016 05:04 PM, Jakub Jelinek wrote:
On Tue, Sep 27, 2016 at 9:56 AM, Michael Matz wrote:
All those bugs would also have been found as well when it had simply
accepted
/fall.*thr/i
anywhere in the preceding comment on one line. But all the recent
spelling changes of comments to cater
On 09/28/2016 06:23 PM, Jeff Law wrote:
(reg/i:SI h0 ax)
(reg/i:SF h21 xmm0)
(Replying to myself, in the hope of better demonstrating the idea)
The following patch implements this idea for RTL dumps, so that all REGNO
values in dumps get a one character prefix: 'h' for hard registers, 'v'
On 09/28/2016 06:36 PM, Jeff Law wrote:
A "p" prefix for pseudos might still be a good idea, but there's still
the issue of a real "p0" register name causing confusion.
So how do you think we should deal with distinguishing between the
different registers that may appear in a dump file?
I thin
On 09/28/2016 02:15 PM, Michael Matz wrote:
P.S.: Initially I even wanted to argue that the mere existence of _any_
comment before a case label would disable the warning. I don't have the
numbers but I bet even that version would have found the very same bugs
that the picky version has.
Sounds
On 09/28/2016 09:24 PM, Jakub Jelinek wrote:
I'd like to ping the
http://gcc.gnu.org/ml/gcc-patches/2016-09/msg01436.html
patch, containing various fixes for gimple-ssa-sprintf.c.
If the 0 < var to var > 0 changes are deemed too controversial, I can
separate them from the other changes.
I'd l
On 09/28/2016 09:47 PM, Jakub Jelinek wrote:
And here are the 0 < var to var > 0 changes. Thoughts on those?
I kind of meant it the other way round, so yeah, please install.
Bernd
On 09/28/2016 11:40 PM, Jakub Jelinek wrote:
On Wed, Sep 28, 2016 at 11:17:55PM +0200, Bernd Schmidt wrote:
On 09/28/2016 09:47 PM, Jakub Jelinek wrote:
And here are the 0 < var to var > 0 changes. Thoughts on those?
I kind of meant it the other way round, so yeah, please install.
On 09/28/2016 02:57 PM, Denys Vlasenko wrote:
This change makes it possible to align functions to 64-byte boundaries *if*
this does not introduce huge amount of padding.
I'm still somewhat undecided, but it seems like a decent enough way to
expose these possibilities to the user, so unless so
On 09/29/2016 07:47 PM, David Malcolm wrote:
This patch adds a new function, print_rtx_function, intended for use
for generating function dumps suitable for parsing by the RTL frontend,
but also intended to be human-readable, and human-authorable.
(note 1 0 4 (nil) NOTE_INSN_DELETED)
On 09/30/2016 11:45 AM, Jakub Jelinek wrote:
See Tom Tromey's explanation why accepting too much is bad (at least unless
we want multiple levels).
And I still don't buy it. The case where someone writes "Don't fall
through" is artificial to begin with, and also forgetting to put the
break; t
On 09/30/2016 12:51 PM, Jakub Jelinek wrote:
On Fri, Sep 30, 2016 at 12:42:20PM +0200, Bernd Schmidt wrote:
On 09/30/2016 11:45 AM, Jakub Jelinek wrote:
See Tom Tromey's explanation why accepting too much is bad (at least unless
we want multiple levels).
And I still don't buy it
On 09/29/2016 07:32 PM, Denys Vlasenko wrote:
On 09/29/2016 04:45 PM, Bernd Schmidt wrote:
On 09/28/2016 02:57 PM, Denys Vlasenko wrote:
- /* Comes from final.c -- no real reason to change it. */
-#define MAX_CODE_ALIGN 16
-
case OPT_malign_loops_:
warning_at (loc, 0, "-m
On 10/03/2016 12:02 AM, Martin Sebor wrote:
I couldn't find a good uclibc-only file where to put the new
definition of the hook so I conditionally added it to
targethooks.c.
diff --git a/gcc/targhooks.c b/gcc/targhooks.c
index d75650f..77b4a18 100644
--- a/gcc/targhooks.c
+++ b/gcc/targhooks.c
On 09/30/2016 05:41 AM, David Malcolm wrote:
This patch adds rudimentary column-number tracking to read-md.c, to
give more precise locations for messages for problems in .md files
(and in the RTL frontend I'm working on):
../../src/gcc/config/i386/i386.md:1204:22: error: unknown rtx code
`defin
On 10/04/2016 04:34 PM, Martin Sebor wrote:
I copied the conditional from config/linux.h but I admit I don't
fully understand when the macro is defined.
AFAICT it's done in config.gcc, for a limited set of targets.
Should I still remove it from targhooks.c?
That is compiled for all targets
On 10/04/2016 10:25 PM, Martin Sebor wrote:
Sounds good. Attached is an updated patch reflecting these changes.
Restested by building the powerpc64-linux and tic6x-uclinux cross
toolchains. (Sharing the Glibc and uClibc implementation of the
target hook and defining it in targhooks.c also obvi
On 10/05/2016 04:06 PM, Kyrill Tkachov wrote:
The fix in this patch makes the logic in native_encode_real match the
logic in native_interpret_real,
I just copied the logic across.
Looks reasonable to me. Ok.
Bernd
On 10/05/2016 04:14 PM, David Malcolm wrote:
Thanks. I'm not able to formally approve these changes, but FWIW these
patches look good to me (assuming usual testing).
LGTM too, so OK.
Bernd
On 10/05/2016 06:14 PM, David Malcolm wrote:
Move this part of "expand"'s initialization of crtl into its own
method so that it can used by the RTL frontend when postprocessing
RTL dumps.
gcc/ChangeLog:
* cfgexpand.c (pass_expand::execute): Move stack initializations
to rtl_data:
On 10/05/2016 06:15 PM, David Malcolm wrote:
- /* Make sure regno_pointer_align, and regno_reg_rtx are large
- enough to have an element for this pseudo reg number. */
+ int cur_size = crtl->emit.regno_pointer_align_length;
+ if (reg_rtx_no == cur_size)
+crtl->emit.ensure_regno_capaci
On 10/05/2016 06:15 PM, David Malcolm wrote:
- regno_reg_rtx = ggc_vec_alloc (crtl->emit.regno_pointer_align_length);
+ regno_reg_rtx =
+ggc_cleared_vec_alloc (crtl->emit.regno_pointer_align_length);
Oops, also: formatting, operators go first on a newline.
Bernd
On 10/05/2016 06:15 PM, David Malcolm wrote:
+void require_char (char expected)
> +void require_word_ws (const char *expected)
Function name goes on a new line. Otherwise ok.
Bernd
On 10/05/2016 06:14 PM, David Malcolm wrote:
The selftests for the RTL frontend require supporting multiple
reader instances being alive one after another in-process, so
this lack of cleanup would become a leak.
+ /* Initialize global data. */
+ obstack_init (&string_obstack);
+ ptr_locs =
On 10/05/2016 06:15 PM, David Malcolm wrote:
* errors.c: Use consistent pattern for bconfig.h vs config.h
includes.
(progname): Wrap with #ifdef GENERATOR_FILE.
(error): Likewise. Add "error: " to message.
(fatal): Likewise.
(internal_error): Likew
On 10/05/2016 06:15 PM, David Malcolm wrote:
selftest: s-selftest
s-selftest: $(GCC_PASSES) cc1$(exeext) stmp-int-hdrs
- $(GCC_FOR_TARGET) -xc -S -c /dev/null -fself-test
+ $(GCC_FOR_TARGET) -xc -S -c /dev/null -fself-test=$(srcdir)
$(STAMP) $@
I suspect the Makefile parts
On 10/05/2016 06:51 PM, Marek Polacek wrote:
On Wed, Oct 05, 2016 at 05:29:49PM +0200, Jakub Jelinek wrote:
Hi!
When writing test for this PR, I've noticed ICE if the header is compiled
without -fsanitize=undefined, but source is compiled with it.
We had various issues like this in the past, a
On 09/30/2016 07:54 PM, Denys Vlasenko wrote:
+struct target_flag_state {
+ /* Each falign-foo can generate up to two levels of alignment:
+ -falign-foo=N,M[,N2,M2] */
+ struct align_flags x_align_loops[2];
+ struct align_flags x_align_jumps[2];
+ struct align_flags x_align_labels[2];
+
On 10/05/2016 06:15 PM, David Malcolm wrote:
+;; MEM[(struct isl_obj *)&obj1] = &isl_obj_map_vtable;
+(insn 1045 0 1046 2 (set (reg:SI 480)
+(high:SI (symbol_ref:SI ("isl_obj_map_vtable")
+[flags 0xc0]
+)))
+ y.c:12702 -1
+ (nil))
+(insn 104
Let me just make a first pass over this for minor/obvious issues.
+we have little control of the input to that specific pass. We
"control over" maybe?
+The testsuite is below @file{gcc/testsuite/rtl.dg}.
Not sure this needs to be in the manual (I have similar doubts about the
entire moti
On 10/06/2016 09:53 PM, David Malcolm wrote:
A benefit of keeping the INSN_UIDs is that if you've spent half an hour
single-stepping through RTL modification and know that INSN_UID 1045 is
the one that gets corrupted, you can have that insn have UID 1045 in
the testcase. Otherwise the UIDs get d
On 10/07/2016 09:20 AM, Richard Biener wrote:
Index: gcc/sched-deps.c
===
--- gcc/sched-deps.c(revision 240829)
+++ gcc/sched-deps.c(working copy)
@@ -3992,8 +3992,14 @@ remove_from_deps (struct deps_desc *deps
removed = r
On 10/07/2016 01:19 PM, Richard Biener wrote:
On Fri, 7 Oct 2016, Richard Biener wrote:
I think the main issue is that it is not documented what is safe to do
(and what are the results) when you modify a bitmap while you are
iterating over it.
Does the following look ok?
Sure.
Bernd
On 10/07/2016 01:07 PM, Richard Biener wrote:
On Fri, 7 Oct 2016, Bernd Schmidt wrote:
Here, if necessary I'd prefer we create a to_clear bitmap and perform an
and_compl operation after the loop.
But that's way more expensive -- you allocate memory and perform an
additional loo
eLog
===
--- gcc/ChangeLog (revision 240861)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2016-10-07 Bernd Schmidt
+
+ PR tree-optimization/77880
+ * expr.c (by_pieces_ninsns): Use unsigned HOST_WIDE_INT where
+ necessary.
+
2016-10-07 Marek Polacek
PR c++/7
On 07/21/2016 08:39 PM, Jeff Law wrote:
On 07/15/2016 07:04 AM, Bernd Schmidt wrote:
c/
PR c++/69733
* c-decl.c (smallest_type_quals_location): New static function.
(grokdeclarator): Try to find the correct location for an ignored
qualifier.
cp/
PR c++/69733
* decl.c
On 10/07/2016 03:26 PM, David Malcolm wrote:
We could simply print the INSN_UID for CODE_LABELs; something like this
(see the "(code_label 16" below):
I think that should work.
You appear to have trimmed the idea of enclosing the insns with
(basic-block) directives without commenting on it.
On 10/07/2016 04:08 PM, Kyrill Tkachov wrote:
* simplify-rtx.c (simplify_immed_subreg): Zero-initialize tmp array
before merging in bytes to pass down to real_from_target.
Ok.
Bernd
On 10/10/2016 12:51 PM, Andreas Schwab wrote:
On ia64 the doloop pattern can only work with DImode, so it should
reject any other mode. Bootstrapped and regtested on ia64-suse-linux.
Andreas.
PR target/77738
* config/ia64/ia64.md ("doloop_end"): Reject if mode of loop
On 10/11/2016 12:56 PM, Jakub Jelinek wrote:
On Tue, Oct 11, 2016 at 11:47:21AM +0100, Kyrill Tkachov wrote:
check_GNU_style.sh complains a lot about dg-* directives in the testsuite and
in particular about line lengths.
There's nothing we can do about the directives and sometimes they're suppo
Denys has submitted some patches to add more capabilities to the
-falign-* options, but these still have some issues, and the original
ideas seems to have been to allow for large alignments without
over-aligning small functions. The following patch implements that idea
by taking into account th
On 10/11/2016 05:34 PM, David Malcolm wrote:
+static void print_rtx_operand (const_rtx in_rtx, int idx);
+static void print_rtx_operand_code_0 (const_rtx in_rtx, int idx);
+static void print_rtx_operand_code_e (const_rtx in_rtx, int idx);
+static void print_rtx_operand_codes_E_and_V (const_rtx i
On 10/05/2016 06:15 PM, David Malcolm wrote:
- rtx_reader_ptr->get_top_level_filename ());
+ base_rtx_reader_ptr->get_top_level_filename ());
I wonder if the number of changes could be minimized by retaining the
name rtx_reader for the base class, and using something more speci
On 10/11/2016 04:23 PM, Denys Vlasenko wrote:
This is better than current behavior, but this is not what I want.
15-byte function does not need to be aligned to 16 bytes on a machine
with 128-byte L1I cachelines. It needs to be aligned to 128 bytes
if there are less than 15 bytes remaining; if
On 10/11/2016 11:52 PM, Jakub Jelinek wrote:
The following patch introduces difference warning levels for
-Wimplicit-fallthrough warning, so projects can choose if they want to
honor only attributes (-Wimplicit-fallthrough=5), or what kind of comments.
=4 is very picky and accepts only very small
On 10/12/2016 12:34 AM, Bernd Schmidt wrote:
* c.opt (Wextra): Add as C/C++/ObjC/ObjC++ option.
(Wimplicit-fallthrough=): Enable for these languages by -Wextra.
This bit looks like it does a bit more magic than is immediately
obvious. Could you elaborate how this works?
Ok, so it
On 10/12/2016 01:12 AM, Jakub Jelinek wrote:
What I perhaps should try is removing the Common keyword from the
Wimplicit-fallthrough and Wimplicit-fallthrough= entries, e.g. similarly
to how Wnonnull-compare is defined just as Var(...) Warning in common.opt
(so that it can be used in the middle-e
On 10/12/2016 11:31 AM, Markus Trippelsdorf wrote:
On 2016.10.12 at 00:34 +0200, Bernd Schmidt wrote:
It's a discussion we should have, but I agree it should be done
incrementally. I would argue for =1 as the default.
Here are some numbers for an allmodconfig Linux kernel on pc
On 10/12/2016 12:08 PM, Markus Trippelsdorf wrote:
Actually looking more closely it appears that all of the 136 additional
warnings for level 2 are bogus, too. Here is an example:
switch (class) {
case ATA_DEV_SEMB:
class = ATA_DEV_ATA;/* some hard drives
On 10/12/2016 12:26 PM, Jakub Jelinek wrote:
What do you mean at most? level 0 is the warning disabled, that is the
default except for -Wextra.
I think level 0 has to be on the table for -Wextra as well, depending on
the signal-to-noise ratio of level 1.
Collapsing 3-5 levels is a bad idea
On 10/12/2016 12:36 PM, Markus Trippelsdorf wrote:
Here are some examples:
/* Don't break */
/* drop through */ //very popular
/* fall though */
/* pass through... */
/* break intentionally omitted */
/* fallthough */
/* Don't break, this is a failed frame! */
/* leave break out int
On 10/12/2016 01:15 PM, David Malcolm wrote:
+/* Determine if INSN is of a kind that can have a basic block. */
+
+static bool
+can_have_basic_block_p (const rtx_insn *insn)
+{
+ return GET_RTX_FORMAT (GET_CODE (insn))[2] == 'B';
+}
Oof. I suppose they're all at least that long, but still - w
On 10/12/2016 01:59 PM, Georg-Johann Lay wrote:
This is a no-op change that just adds comments how the various RTX flags
will appear in RTL dumps.
Ok.
Bernd
On 10/12/2016 02:10 PM, Marek Polacek wrote:
While implementing a warning I noticed this in gcov-io.c:
187 else if (mode == 0)
188 {
189 struct stat st;
190
191 if (fstat (fd, &st) < 0)
192 {
193 fclose (gcov_var.file);
194 gcov_var.file = 0;
On 10/12/2016 02:12 PM, John David Anglin wrote:
On 2016-10-12, at 4:02 AM, Jakub Jelinek wrote:
Since this is PA-RISC, which is essentially dead (neither HPE nor Debian
ship it anymore), I stand by my suggestion to bump the fundamental alignment
Or just drop support for a dead arch?
Hardwa
On 10/12/2016 02:43 PM, Richard Biener wrote:
I'd say what applies to PA should apply equally well to the pdp11 and
the alpha port ...
But usually the question is just whether the port has a maintainer
and/or whether it is
a maintainance burden to keep it (say, last user of obsolete feature X).
On 10/10/2016 09:32 PM, Pedro Alves wrote:
From: Pedro Alves
Date: 2016-10-10 19:25:47 +0100
Move OVERRIDE/FINAL from gcc/coretypes.h to include/ansidecl.h
So that GDB and other projects that share the top level can use them.
Seems reasonable. OK unless someone objects by the end of the week
On 10/12/2016 01:04 PM, Markus Trippelsdorf wrote:
I'm more concerned about the first impression that people will get from
this warning. If the fist couple of samples they will look at are
clearly bogus (as with the example comments above) they will very
quickly disable the warning.
And if a sma
On 10/12/2016 04:09 PM, Pedro Alves wrote:
Thanks. Here's a follow up patch that I was just testing.
Need this if building with "g++ -std=gnu++11", with gcc < 4.7.
Lovely. That's ok too if the other one goes in.
Bernd
On 10/12/2016 07:48 PM, David Malcolm wrote:
This patch implements a "compact" mode for print_rtx_function,
implementing most of the ideas above.
Example of output can be seen here:
https://dmalcolm.fedorapeople.org/gcc/2016-10-12/test-switch-compact.rtl
which can be contrasted with the non-co
On 10/13/2016 01:25 AM, Jakub Jelinek wrote:
Seems 2 functions in varasm.c just use TREE_PUBLIC on LABEL_DECLs together
with other kinds of decls, but as TREE_PUBLIC on LABEL_DECLs means now
something different, it breaks badly.
Which functions are these?
PR c/77946
* tree.h (
On 10/12/2016 10:37 PM, David Malcolm wrote:
It didn't pass, due to this change:
(print_rtx_operand_code_i): When printing source locations, wrap
xloc.file in quotes. [...snip...]
[...]
The following is a revised version of the patch which updates this test case.
Also ok. This remi
On 10/12/2016 11:04 PM, David Malcolm wrote:
This patch implements:
* the renumbering of non-virtual pseudos, using
LAST_VIRTUAL_REGISTER + 1 as a base.
* omitting the edge "(flags)" directive if there aren't any
Bootstrap & regrtest in progress.
OK for trunk if they pass?
I tend to think
On 10/13/2016 12:20 PM, Jakub Jelinek wrote:
both relied on TREE_PUBLIC be actually false for LABEL_DECLs, because
otherwise they have code later on that can't handle LABE_DECLs (plus callers
also not expecting LABEL_DECLs might not bind locally or might not bind to
the current def.
Ok, thanks
On 09/30/2016 10:02 PM, Andreas Schwab wrote:
On Feb 11 2016, Kelvin Nilsen wrote:
* opts-global.c (handle_common_deferred_options): Introduce and
initialize two global variables to remember command-line options
specifying a stack-limiting register.
* opts.h: Ad
On 10/06/2016 07:43 AM, Prathamesh Kulkarni wrote:
Pinging patch: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01038.html
If I understand correctly this is a latent issue where nonexistant
libfunc names are stored (but not currently used). If that's correct,
then OK.
Bernd
On 10/13/2016 03:49 PM, Richard Biener wrote:
Does it really run a single pass only? Thus you can't do a { dg-do run } test
with __RTL?
I think that's really not the intended use-case. To my mind this is for
unit-testing: ensuring that a given rtl pass performs the expected
transformation on
On 10/13/2016 04:08 PM, David Malcolm wrote:
I thought it might be useful to brainstorm [1] some ideas on this,
so here are various possible ways it could be printed for this use-case:
* Offset by LAST_VIRTUAL_REGISTER + 1 (as in the patch), and printed
just as a number, giving:
(reg:SI 3)
On 10/13/2016 05:52 PM, David Malcolm wrote:
Alternatively, it seems that we might want an additional flag for
this.
Probably - I imagine most testcases won't care (it's obviously easier to
read without locations) but some will. The writing side is maybe less
interesting than the reading sid
On 10/13/2016 07:18 PM, Prathamesh Kulkarni wrote:
On 13 October 2016 at 16:56, Bernd Schmidt wrote:
On 10/06/2016 07:43 AM, Prathamesh Kulkarni wrote:
Pinging patch: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01038.html
If I understand correctly this is a latent issue where
1101 - 1200 of 2198 matches
Mail list logo
