On 04/25/2016 03:30 PM, Trevor Saunders wrote:
On Mon, Apr 25, 2016 at 02:28:51PM +0200, Bernd Schmidt wrote:
On 04/20/2016 08:22 AM, tbsaunde+...@tbsaunde.org wrote:
From: Trevor Saunders
+ unsigned int len = cond_list.length ();
+ for (unsigned int i = len
On 04/20/2016 08:22 AM, tbsaunde+...@tbsaunde.org wrote:
-/* Remove INSN from queue. */
+/* Remove INSN at idx from queue. */
+static void
+queue_remove (unsigned int q, unsigned int idx)
+{
+ QUEUE_INDEX (insn_queue[q][idx]) = QUEUE_NOWHERE;
+ insn_queue[q].ordered_remove (idx);
+ q_size--;
On 04/20/2016 08:22 AM, tbsaunde+...@tbsaunde.org wrote:
-static rtx_expr_list *
+static vec
extract_mentioned_regs (rtx x)
{
- rtx_expr_list *mentioned_regs = NULL;
+ vec mentioned_regs = vNULL;
subrtx_var_iterator::array_type array;
FOR_EACH_SUBRTX_VAR (iter, array, x, NONCONST)
On 04/20/2016 08:22 AM, tbsaunde+...@tbsaunde.org wrote:
- remove_node_from_insn_list (insn, &nonlocal_goto_handler_labels);
+
+ unsigned int len = vec_safe_length (nonlocal_goto_handler_labels);
+ for (unsigned int i = 0; i < len; i++)
+ if ((*nonlocal_goto_handler_labels)[i
On 04/21/2016 01:24 AM, Trevor Saunders wrote:
On Wed, Apr 20, 2016 at 06:03:01AM -0700, Andi Kleen wrote:
A vector can have very different performance than a list, depending how
it is used. Do your patches cause any measure performance difference for
the compiler?
I haven't measured, but I
On 04/20/2016 08:22 AM, tbsaunde+...@tbsaunde.org wrote:
From: Trevor Saunders
+ unsigned int len = cond_list.length ();
+ for (unsigned int i = len - 1; i < len; i--)
This is a really icky way to write a loop, the i < len condition makes
it look like a forw
On 04/22/2016 09:45 PM, Sandra Loosemore wrote:
On 04/22/2016 10:42 AM, paul_kon...@dell.com wrote:
Would you expect people to conform to the abridged version or the
full standard? If the full standard, then publishing an abridged
version is not a good idea, it will just cause confusion. Let
On 04/21/2016 02:16 PM, Kirill Yukhin wrote:
Hello,
This looks like a typo to me.
GCC 6 Stage 4 (starts 2016-01-20)GCC 5.3 release (2015-12-04)
|
+-- GCC 5 branch created +
| \
v v
On 04/18/2016 02:26 PM, Dhole wrote:
A few months ago I submited a patch to allow the embedded timestamps by
C/C++ macros to be set externally [2], which was already an improvement
over [1]. I was told to wait until the GCC 7 stage 1 started to send
this patch again.
+/* Read SOURCE_DATE_EPOC
On 04/16/2016 01:12 AM, David Wohlferd wrote:
There were basically 3 changes I was trying for in that doc patch. Are
any of them worth keeping? Or are we done?
1) "Do not clobber flags if they are being used as outputs."
2) Output flags sample (with #if removed).
3) "On the x86 platform, flags
On 04/20/2016 04:57 PM, H.J. Lu wrote:
On Wed, Apr 20, 2016 at 7:54 AM, Jakub Jelinek wrote:
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01080.html
This is wrong, see my other comment on the libgomp patch.
See my reply to your reply on the libgomp patch.
Since Jakub has said it is wrong
On 04/20/2016 08:22 AM, tbsaunde+...@tbsaunde.org wrote:
- rtx_insn_list *merged_insns = 0;
+ auto_vec, 10> merged_insns;
I see Jeff has already acked this, but some of the expressions here are
getting unwieldy. can we maybe shorten some of this using typedefs?
Bernd
On 03/02/2016 10:53 PM, Vladimir Makarov wrote:
The patch is ok for me. But I'd wait for GCC7. People are sensitive to
their code performance degradation. Even in most cases the patch
improves performance, in some case it can worsen code and people might
fill new PRs after such change.
I'v
On 04/22/2016 03:57 PM, Jason Merrill wrote:
This looks good, but can we move the code into c-common rather than
duplicate it?
That would be this patch. Also passes testing on x86_64-linux.
Bernd
* doc/invoke.texi (Warning Options): Add -Wmemset-elt-size.
(-Wmemset-elt-size): New item.
c-fa
On 04/19/2016 10:48 PM, Mikhail Maltsev wrote:
On 04/18/2016 12:14 PM, Richard Biener wrote:
Enlarging tree_function_decl is bad.
Probably using 3 bits for malloc_flag, operator_new_flag and free_flag is
redundant. I packed the state into 2 bits.
Passes should get at the info via flags_from_
(Apologies if you get this twice, the mailing list didn't like the html
attachment in the first attempt).
We frequently get malformatted patches, and it's been brought to my
attention that some people don't even make the effort to read the GNU
coding standards before trying to contribute code.
On 04/22/2016 05:31 PM, Jason Merrill wrote:
On Fri, Apr 22, 2016 at 11:24 AM, Bernd Schmidt wrote:
On 04/22/2016 03:57 PM, Jason Merrill wrote:
This looks good, but can we move the code into c-common rather than
duplicate it?
Probably not without a fair amount of surgery, since the cdw_
On 04/22/2016 03:57 PM, Jason Merrill wrote:
This looks good, but can we move the code into c-common rather than
duplicate it?
Probably not without a fair amount of surgery, since the cdw_ and ds_
codes are private to each frontend.
Bernd
We had this problem in the C frontend until very recently:
int array[some_count];
memset (array, 0, some_count);
which forgets to multiply by sizeof int. The following patch implements
a new warning option for this.
Bootstrapped and tested (a while ago, will retest) on x86_64-linux. Ok
f
The PR is for a C++ form of the form
const double val() const { ... }
where the warning location is at the second const (by accident, in
reality it's just past the function's declarator), while the first const
is the one that we are warning about.
This patch adds some logic to the C and C++
On 04/15/2016 10:32 AM, Uros Bizjak wrote:
This fixes possible wrong code with a tricky failure mode, so OK now.
Thanks.
[...]
While changing this part, it can be rewritten using dg-additional options, e.g.:
/* { dg-options "-Os -fomit-frame-pointer -fasynchronous-unwind-tables
-mno-red-zon
On 04/13/2016 03:04 PM, Marcel Böhme wrote:
Hi Bernd,
Shouldn't we check for overflows before performing the +1 addition
(i.e. 0 <= num < INT_MAX)? Ideally we'd also have a way to signal
from d_number if we had an overflow while parsing that number.
Without an overflow signal, d_number will alr
On 04/15/2016 02:35 AM, Segher Boessenkool wrote:
This now also shows up on GCC 5, see PR70672. It there happens in
the jump1 pass already.
Is this okay to backport to 5 and 4.9?
Ok.
Bernd
On 04/14/2016 03:36 PM, Thomas Schwinge wrote:
I don't know how meaningful it is to create/discuss/review/commit the
following patch until the overall approach has been agreed upon?
Why not? We agree the file should be split, and this makes it easier. So
I'll approve it for stage1, or earlier
On 04/13/2016 07:56 PM, Thomas Schwinge wrote:
Best way to present this might be to do
diff -du old-omp-low.c .
OK, I found Git "-C5%" produce something very similar to that;
0001-Split-up-gcc-omp-low.c-plain.patch.xz attached.
That looks much better. However, the //OMPWHATEVER comments are
On 04/13/2016 06:01 PM, Thomas Schwinge wrote:
The attached 0001-Split-up-gcc-omp-low.c.patch.xz is a Git "--color
--word-diff --ignore-space-change" patch, purely meant for manual review;
I'm intentionally ;-) not attaching a "patch-applyable" patch at this
point, to minimize the risk of other
On 04/13/2016 06:11 PM, David Malcolm wrote:
Your approach encapsulates the logic for rejecting this situation
within should_warn_for_misleading_indentation, rather than at the
callers, which is arguably better for modularity (similar to how we
already call it for "do", which is then always rejec
On 04/13/2016 04:14 PM, Marek Polacek wrote:
This patch is meant to be applied on top of the "Wparentheses overhaul" patch.
I really think that warning about the dangling else problem isn't appropriate
as a part of the -Wparentheses warning, which I think should only deal with
stuff like precede
On 04/13/2016 04:14 PM, Marek Polacek wrote:
I revamped the warning so that it follows what the C++ FE does (i.e. passing
IF_P bools here and there) and it seems to work quite well. I didn't mean to
tackle the OMP bits but I bet it would be just a matter of passing IF_P
somewhere.
Bootstrapped
On 04/12/2016 10:34 PM, Jakub Jelinek wrote:
+ return temp ? gen_rtx_fmt_ee (GET_CODE (x), to_mode,
+ temp, XEXP (x, 1))
+ : temp;
Wrap multi-line expressions in parens. No need for a full retest, just
make sure the file still b
On 04/12/2016 10:06 PM, Jakub Jelinek wrote:
On Tue, Apr 12, 2016 at 10:02:18PM +0200, Bernd Schmidt wrote:
On 04/12/2016 05:10 PM, Jakub Jelinek wrote:
This patch arranges for a new argument to
convert_memory_address_addr_space_1 and calls it with that new argument set
to true, to make sure
On 04/12/2016 05:10 PM, Jakub Jelinek wrote:
This patch arranges for a new argument to
convert_memory_address_addr_space_1 and calls it with that new argument set
to true, to make sure it never emits instructions or creates pseudos.
I think the approach looks sensible, but I don't know if you n
On 04/12/2016 12:49 AM, David Wohlferd wrote:
First draft is attached. It tests all 28 (14 conditions plus 14
inverted). I wasn't sure what to set for optimization (O2? O3? O0?),
so I left the default.
I've had it in a successful test run, and committed it with a minor
tweak (__builtin_abort
With some changes I was working on, I produced a situation where one of
the x86 peepholes made an incorrect transformation. In the prologue
expansion code, we have
/* When using red zone we may start register saving before allocating
the stack frame saving one cycle of the prologue. However
As shown by Roger Orr in the comments of this PR, cpp_get_token can
cause a reallocation that invalidates some of the variables in
do_linemarker. It seems to occur in this call to linemap_add:
/* Allocate the new line_map. However, if the current map only has a
single line we ca
On 04/08/2016 07:05 PM, Jakub Jelinek wrote:
After IRC discussions, I've bootstrapped/regtested following patch that
just punts if *loc contains any paradoxical subregs, together with
additional statistics gathering that proved that the new testcase is
the only spot in which this patch makes a di
I've been looking through this patch. I had intended to commit it, but
after looking through it a little more carefully I think there are a few
things left to solve.
So, d_number/d_compact_number now return ints rather than longs, which
makes sense since the lengths in things like struct deman
On 04/01/2016 05:03 AM, Marcel Böhme wrote:
This fixes the invalid write of size 8 detailed in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70492
Handle the special case when consume_count returns -1 due to an integer
overflow when parsing the length of the virtual table qualifier in
cplus-de
On 04/07/2016 11:56 PM, Jakub Jelinek wrote:
Not sure if this patch catches everything though, perhaps there could be
e.g.
(set (reg:SI ...) (plus:SI ((subreg:SI (reg:QI ...) 0) (const_int ...)))
and we'd still assign REG_EQUAL note. So maybe instead we should walk the
*loc expression and look f
On 04/07/2016 01:52 PM, Senthil Kumar Selvaraj wrote:
The below patch fixes PR 60040 by not halting with a hard error on
a spill failure, if reload knows that it has to run again anyway.
Some additional information as to how this situation creates a spill
failure would be useful. It's ha
On 03/22/2016 03:15 PM, Marcos Díaz wrote:
the attached patch adds a new attribute 'security_sensitive' for functions.
The idea was discussed in PR middle-end/69976.
The first question would be: I see several submissions from folks
@tallertechnologies.com. Do you and your employer have cop
On 04/04/2016 09:39 AM, Eric Botcazou wrote:
The audit trail of the PR is quite confused: __LIBGCC_EH_FRAME_SECTION_NAME__
needs to be (and is correctly) defined during the libgcc build because DWARF2
exceptions are used. The problem is that libgcc2.c expects the usual non-ELF
setup, with __EH_F
On 04/02/2016 11:49 AM, Marcel Böhme wrote:
Bootstrapped and regression tested on x86_64-pc-linux-gnu. Test cases
added + checked PR70498 is resolved.
Richard - any objections from an RM perspective to check in such
potentially security-related fixes now even if not regressions?
The patch no
On 04/01/2016 07:41 PM, Pedro Alves wrote:
On 04/01/2016 11:21 AM, Marcel Böhme wrote:
static inline void
-d_append_num (struct d_print_info *dpi, long l)
+d_append_num (struct d_print_info *dpi, int l)
{
char buf[25];
sprintf (buf,"%ld", l);
Doesn't this warn about %ld format vs i
On 04/01/2016 11:08 AM, Richard Biener wrote:
{
! if (canon_true_dependence (s_info->mem,
!GET_MODE (s_info->mem),
!s_info->mem_addr,
!mem, mem_addr))
{
On 04/01/2016 05:05 PM, Jakub Jelinek wrote:
with my usual pair of rtl,yes checking bootstraps/regtests (x86_64-linux
and i686-linux, former one with ada, latter without), both without your
patch and with the patch.
Without the patch got 66555 successful replace_reads, with your patch
only 65971,
On 04/01/2016 04:51 PM, Jakub Jelinek wrote:
On Fri, Apr 01, 2016 at 03:35:19PM +0200, Bernd Schmidt wrote:
On 04/01/2016 03:14 PM, Jakub Jelinek wrote:
As the testcase below shows, we can end up with lots of useless
instructions from multi-word arithmetics.
simplify-rtx.c can optimize x
On 04/01/2016 03:39 PM, Marcel Böhme wrote:
Hi Bernd,
Thanks for the feedback!
Patches need to be bootstrapped and regression tested, and patch
submissions should include which target this was done on.
Ideally you'd also want to include testcases along with your
patches, although I'm not enti
On 03/31/2016 06:56 AM, Marcel Böhme wrote:
Hi Bernd,
Are all the places being patched really problematic ones where an input file
could realistically cause an overflow, or just the string functions?
The loop in demangle_args allows to call the patched register*- and
remember*-methods arbitr
On 04/01/2016 03:14 PM, Jakub Jelinek wrote:
As the testcase below shows, we can end up with lots of useless
instructions from multi-word arithmetics.
simplify-rtx.c can optimize x {&,|,^}= {0,-1}, but while
x &= 0 or x {|,^}= -1 are optimized into constants and CSE can handle those
fine, we keep
Cc'ing Matt Thomas who is listed as the vax maintainer; most of the
patch should be reviewed by him IMO. If he is no longer active I'd
frankly rather deprecate the port rather than invest effort in keeping
it running.
Index: gcc/except.c
===
On 04/01/2016 12:21 PM, Marcel Böhme wrote:
This fixes the write access violation detailed in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70498 (and a few other
unreported cases).
Sometimes length-variables for strings and arrays are of type long
other times of type int. Since cp-demangle.h exp
On 03/31/2016 10:53 PM, Patrick Palka wrote:
This patch fixes the new -Wparentheses warnings (implemented by the
subsequent patch) that are encountered during bootstrap:
/home/patrick/code/gcc/gcc/omp-low.c: In function ‘void
scan_sharing_clauses(tree, omp_context*, bool)’:
/home/patrick/code/g
On 03/31/2016 07:22 PM, Jeff Law wrote:
@@ -1237,11 +1237,13 @@ squangle_mop_up (struct work_stuff *work)
Thanks. I've just installed this patch, along with suitable tests from
70481 and 67394.
What are the rules for modifying libiberty again? Do we have to patch
binutils/gdb at the same ti
On 03/30/2016 11:27 PM, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, we are miscompiling glibc on i686-linux, because
the new indirect_jump_optimize mini-pass thinks that a insn
which has REG_LABEL_OPERAND note necessarily has to set the target register
to that label, while in the glibc case
On 03/25/2016 04:43 AM, Aldy Hernandez wrote:
If Bernd is fine with this, I'm happy to retract my patch and any
possible followups. I'm just interested in having no path causing a
possible out of bounds access. If your patch will do that, I'm cool.
I'll need to see that patch first to comment
On 03/29/2016 07:28 PM, Jeff Law wrote:
On 03/29/2016 11:23 AM, Jakub Jelinek wrote:
Hi!
The recent change to num_imm_uses (to add support for NULL USE_STMT)
broke it totally, fortunately we have just one user of this function
right now. I've filed a PR for GCC 7 so that we get a warning on th
On 03/03/2016 03:55 PM, Marcel Böhme wrote:
@@ -4254,7 +4255,9 @@
Please use "diff -p" so that we get information about which function is
being patched. Are all the places being patched really problematic ones
where an input file could realistically cause an overflow, or just the
string func
On 03/28/2016 12:03 AM, David Wohlferd wrote:
On 3/24/2016 8:00 AM, Bernd Schmidt wrote:
> More problematic than a lack of documentation is that I haven't been
able to find an executable testcase. If you could adapt your example for
use in gcc.target/i386, that would be even more import
On 03/25/2016 11:00 PM, Alan Modra wrote:
I'll also prepare a patch to delete REG_LIVE_LENGTH everywhere.
Like this. Bootstrapped and regression tested x86_64-linux.
OK for stage1?
Oh wow that's a lot of stuff removed. Ok for this and the
FREQ_CALLS_CROSSED patch.
Bernd
In principle we probably should have an example, but once again I have
some problems with the style of the added documentation. I prefer
concise writing without unnecessary repetition. Any other reviewers can
of course override me, but the following is my opinion on these changes.
More problem
On 03/23/2016 03:21 PM, Richard Biener wrote:
On Wed, Mar 23, 2016 at 2:15 PM, Bernd Schmidt wrote:
On 03/23/2016 01:41 PM, Richard Biener wrote:
Btw, the issue in the PR is also fixed with a simple
Index: libcpp/line-map.c
On 03/24/2016 11:17 AM, Aldy Hernandez wrote:
On 03/23/2016 10:25 AM, Bernd Schmidt wrote:
It looks like this block of code is written by a helper function that is
really intended for other purposes than for maximal_insn_latency. Might
be worth changing to
int insn_code = dfa_insn_code
On 03/24/2016 11:32 AM, Aldy Hernandez wrote:
On x86, PIC_OFFSET_TABLE_REGNUM calls a function
(ix86_use_pseudo_pic_reg) so its value can theoretically change between
its first and second use in the following conditional:
if ((unsigned) PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM
&&
On 03/23/2016 07:47 AM, Thomas Schwinge wrote:
Want me to re-word that? :-| I thought it would be obvious from looking
at the test case code; will not be a problem in practice. It's because
of constructs used in the test cases, like the following, for example:
if (__builtin_acc_on
On 03/23/2016 01:41 PM, Richard Biener wrote:
Btw, the issue in the PR is also fixed with a simple
Index: libcpp/line-map.c
===
--- libcpp/line-map.c (revision 234415)
+++ libcpp/line-map.c (working copy)
@@ -543,7 +543,7 @@ lin
On 03/21/2016 02:43 AM, Alan Modra wrote:
+enum valid_equiv { valid_none, valid_combine, valid_reload };
+
Might be worth documenting that each step represents a superset of the
previous one.
+ ret = valid_combine;
+ if (! MEM_READONLY_P (memref)
+ && ! RTL_CONS
On 03/22/2016 11:23 AM, Thomas Schwinge wrote:
diff --git libgomp/testsuite/libgomp.oacc-c-c++-common/routine-w-1.c
libgomp/testsuite/libgomp.oacc-c-c++-common/routine-w-1.c
index 01d1dc8..5806cb3 100644
--- libgomp/testsuite/libgomp.oacc-c-c++-common/routine-w-1.c
+++ libgomp/testsuite/libgomp.
On 03/21/2016 02:42 AM, Alan Modra wrote:
* ira.c (combine_and_move_insns): Rather than scanning insns,
use DF infrastucture to find use and def insns.
- remove_death (regno, insn);
This call appears to have gone missing. Is that intentional?
Other than tha
On 03/22/2016 10:24 AM, Christophe Lyon wrote:
The ARM test isn't sufficiently protected against non-compliant configurations,
and fails if GCC is configured for arm*linux-gnueabihf for instance
(see
http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/234342/report-build-info.h
On 03/21/2016 09:15 PM, David Malcolm wrote:
On Mon, 2016-03-14 at 14:20 +0100, Bernd Schmidt wrote:
On 03/11/2016 11:09 PM, David Malcolm wrote:
+ cpp_error (pfile, CPP_DL_ERROR,
+"file \"%s\" left but not ent
On 03/21/2016 08:06 PM, Jeff Law wrote:
As noted last week, find_removable_extensions initializes several
bitmaps, but doesn't clear them.
This is not strictly a leak as the GC system should find dead data, but
it's better to go ahead and clear the bitmaps. That releases the
elements back to t
Ping.
Bernd
On 03/14/2016 02:20 PM, Bernd Schmidt wrote:
On 03/11/2016 11:09 PM, David Malcolm wrote:
+ cpp_error (pfile, CPP_DL_ERROR,
+ "file \"%s\" left but not entered", new_file);
Al
On 03/21/2016 02:37 AM, Alan Modra wrote:
This series tidies some of the early ira code, in the process making a
tiny improvement to register pressure. Patches 1 to 3 are fairly
simple tidies, with zero impact on generated code. Patch 4 also is
mainly a tidy, but could see some extra REG_EQUIV
On 03/17/2016 08:17 PM, Richard Henderson wrote:
With -g, and a code section that ends unaligned, the assembler complains of
"unaligned opcodes detected". Except there are no such unaligned opcodes, nor
dwarf2 code ranges covering the end of the section, which arguably makes this
an assembler bu
On 03/17/2016 04:06 PM, H.J. Lu wrote:
This is the patch I am going to check in.
That still mentions darwin which I imagine might not be an exhaustive test.
Bernd
This fixes an oversight in my previous patch here. I used biggest_mode
in the assumption that if the reg was used in the function, it would be
set to something other than VOIDmode, but that fails if we have a
multiword access - only the first hard reg gets its biggest_mode
assigned in that case
On 03/18/2016 08:14 PM, Jeff Law wrote:
I also added a blurb to the dump file when we create these equivalences
and included a test to verify the code fires. I verified it fired on
x86 and x86-64. It may or may not fire on other targets, so I left the
test in the i386 specific subdirectory.
T
On 03/17/2016 02:59 PM, H.J. Lu wrote:
On Fri, Mar 11, 2016 at 9:09 AM, H.J. Lu wrote:
We can't set flag_pie to the default when flag_pic == 0, which may be
set by -fno-pic or -fno-PIC, since the default value of flag_pie is
non-zero when GCC is configured with --enable-default-pie. We need
to
On 03/17/2016 04:13 PM, H.J. Lu wrote:
On Thu, Mar 17, 2016 at 8:09 AM, Bernd Schmidt wrote:
On 03/17/2016 04:06 PM, H.J. Lu wrote:
This is the patch I am going to check in.
That still mentions darwin which I imagine might not be an exhaustive test.
We can add an effective target
On 03/17/2016 04:26 PM, H.J. Lu wrote:
On Thu, Mar 17, 2016 at 8:23 AM, Bernd Schmidt wrote:
On 03/17/2016 04:13 PM, H.J. Lu wrote:
We can add an effective target, something like ignore_pic_pie, and
use it instead of *-*-darwin*.
That should have been done _before_ committing the patch in
On 03/16/2016 07:45 PM, Jason Merrill wrote:
Discussion of empty class parameter passing ABI led me to notice that
r162402 broke sibcalls with arguments of size 0 in some cases. Before
that commit, the code read
else if ((partial == 0 || args[i].pass_on_stack)
&& size != 0)
{
[...]
On 03/17/2016 12:16 PM, Jakub Jelinek wrote:
Thus, I've reverted the patch (kept the testcase), and after some
discussions on IRC bootstrapped/regtested on x86_64-linux and i686-linux
following version, which right now should change behavior just for the i?86
case and nothing else, so shouldn't
On 03/16/2016 01:22 PM, Jakub Jelinek wrote:
So, this is what we've converged to on IRC and passed bootstrap/regtest
on x86_64-linux and i686-linux. Is this ok for trunk?
The explanation was a bit confusing at first, but I think this looks
reasonable. The assert worries me, but triggering it
On 03/17/2016 06:37 PM, Jeff Law wrote:
+ bitmap seen_insns;
+ seen_insns = BITMAP_ALLOC (NULL);
You could save an allocation here by making this a bitmap_head and using
bitmap_initialize.
+ bitmap_set_bit (seen_insns, INSN_UID (insn));
+
if (! INSN_P (insn))
continue
On 03/17/2016 06:23 AM, David Wohlferd wrote:
2016-03-16 David Wohlferd
Bernd Schmidt
* doc/extend.texi: Doc basic asm behavior re clobbers.
Any objections from the release managers if I install this for David at
this stage?
Bernd
On 03/17/2016 06:23 AM, David Wohlferd wrote:
On 3/14/2016 8:28 AM, Bernd Schmidt wrote:
The example is not good, as discussed previously, and IMO the best
option is to remove it. Otherwise I have no objections to the latest
variant.
Despite the problems I have with the existing sample
On 03/15/2016 03:27 AM, Alan Modra wrote:
On Mon, Mar 14, 2016 at 01:00:39PM -0600, Jeff Law wrote:
Right. Tolerant as in not crash.
So can someone please approve my ira.c:indirect_jump_optimize patch?
I'm not quite audacious enough to claim it is obvious.
Looks good to me.
Bernd
On 03/15/2016 12:14 PM, Jakub Jelinek wrote:
- if (orig_code == LSHIFTRT && result_mode != shift_mode)
+ turn off all the bits that the shift would have turned off.
+ Similarly do this if we've optimized varop so that we don't perform
+ any shift. */
+ if (orig_code == LSHIFTRT
+
On 03/14/2016 09:00 PM, Segher Boessenkool wrote:
There is just the single caller, and pred is set right before the call
there. How about this patch, then?
Looks alright.
Bernd
On 03/14/2016 04:38 PM, Segher Boessenkool wrote:
If your machine description refers to a non-existent predicate genrecog
crashes. This fixes it.
Might be better to fix the caller?
Bernd
On 03/14/2016 05:23 PM, Alexander Monakov wrote:
On Mon, 14 Mar 2016, Andrey Belevantsev wrote:
In this case, we get an inconsistency between the sched-deps interface, saying
we can't move an insn writing the si register through a vector insn, and the
liveness analysis, saying we can. The latte
On 03/11/2016 01:55 AM, David Wohlferd wrote:
So, we have been discussing this issue for 4 months now. Over that
time, I have tried to incorporate everyone's feedback.
As a result we have gone from a tiny doc patch (just describe the
current semantics), to a big doc patch (completely deprecate
On 03/11/2016 11:09 PM, David Malcolm wrote:
+ cpp_error (pfile, CPP_DL_ERROR,
+"file \"%s\" left but not entered", new_file);
Although it looks like you're preserving the existing behavior from
when t
On 03/11/2016 04:32 PM, Kyrill Tkachov wrote:
PR driver/70132
* config/arm/driver-arm.c (host_detect_local_cpu): Set file pointer
to NULL after closing file.
Doesn't match the patch. Either variant is fine but please use the right
combination :)
Bernd
When I submitted my previous lra-remat patch, I mentioned I had some
concerns about the way we dealt with register number comparisons, but I
didn't want to change things blindly without a testcase. PR70123 has now
provided such a testcase where we are trying to rematerialize a hard
register (r6
On 03/10/2016 10:18 AM, Alan Modra wrote:
Doing the indirect jump optimization turned out to be quite easy.
Bootstrapped and regression tested powerpc64le-linux, gcc-6, gcc-5 and
gcc-4.9. Bootstrap and regression test x86_64-linux still running.
OK to apply?
So much nicer. Ok, and thanks.
B
This is a case where bogus #line directives can confuse libcpp into
producing nonsensical line numbers, even leading to a crash later on in LTO.
The following patch moves the test earlier to a point where we can more
easily recover from the error condition. I should note that I changed
the raw
This crash happens because LRA tries to save an AVX hard reg in a large
mode, and it only appears in the function in smaller modes. Stack
alignment isn't set up to support the larger mode.
Currently, biggest_mode for hard registers is set up from regno_reg_rtx,
set up to a large mode for argum
On 03/05/2016 06:27 AM, Jeff Law wrote:
PR rtl-optimization/69941
* postreload.c (reload_combine_recognize_pattern): Ensure all uses of
the reg share its mode.
testsuite/
PR rtl-optimization/69941
* gcc.dg/torture/pr69941.c: New test.
OK.
For branches as well?
Bernd
601 - 700 of 2198 matches
Mail list logo