This is a set of patches to convert m68k so that it no longer uses cc0.
The approach is to combine cc0 setter/user pairs into cbranch and cstore
patterns. It does not expose the flag register directly. Since m68k is a
target that is not under active development, and probably receives very
limited t
This tidies up a few spots in the m68k backend in preparation for the
large patch to follow. This is purely for review purposes: this patch
has not been tested independently, and will be committed together with
the following one.
Noteworthy changes:
Some patterns and peepholes were unified throu
This achieves the conversion by using combined cbranch/cstore patterns,
and using a mechanism similar to the cc_status tracking to elide certain
comparisons. Unlike cc_status, this is opt-in and requires a
flags_valid attribute to be set for suitable instructions. Due to lack
of test hardware, th
The combiner is somewhat strange about how it uses costs. If any of the
insns involved in a comparison have a cost of 0, it does not verify that
the substitution is cheaper. Also, it does not compute costs for jump
insns, so they are always set to zero. As a consequence, any possible
substitution i
After the m68k cc0 conversion, there is one code quality regression that
I can see: we no longer generate autoinc addressing modes in
comparisons. This is because the parts of the compiler that generate
autoinc are unwilling to substitute into jumps.
If you look at the code in reload, you'll see t
On 11/13/19 7:16 PM, Segher Boessenkool wrote:
> I tried this out with a kernel build (just the defconfig).
> during RTL pass: jump2
> /home/segher/src/kernel/fs/binfmt_elf.c: In function 'elf_core_dump':
> /home/segher/src/kernel/fs/binfmt_elf.c:2409:1: internal compiler error: in
> patch_jump_i
On 08/19/2013 11:05 PM, Jeff Law wrote:
> On 07/20/2013 03:02 AM, Alexey Makhalov wrote:
>> Hello!
>>
>> If delete_unmarked_insns deletes some insn, DF state might be
>> out of date, and, regs_ever_live might contain unused registers till
>> the end.
(I can't find the original mail either in my ma
On 09/04/2013 06:04 PM, Jan Hubicka wrote:
> this is third fallout of my change to remove DECL_ARGUMENTS/DECL_RESULT for
> functions w/o
> bodies I did not really anticipate.
[...]
> I would like to basically ask if it seems to make sense to go this route and
> try to get rid of those declarations
On 09/04/2013 07:09 PM, Jan Hubicka wrote:
> How do you support K&R functions here? My basic idea was that TYPE_ARG_TYPES
> should give enough information about external function calling convention
> anyone will ever need. I would hope that this will be sufficient for your
> use, too, despite the
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 191837)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2012-09-20 Bernd Schmidt
+
+ PR bootstrap/54688
+ * sched-deps.c (parse_add_or_inc): Remove MINUS handling. Take
+ STACK_GROWS_DOWNWARD into ac
On 10/01/2012 12:14 PM, Jakub Jelinek wrote:
> On Mon, Oct 01, 2012 at 12:01:36PM +0200, Steven Bosscher wrote:
>> I would also agree if it were not for the fact that IRA is already a
>> scalability bottle-neck and that has been known for a long time, too.
>> I have no confidence at all that if LRA
On 09/28/2012 12:59 AM, Vladimir Makarov wrote:
> + We keep RTL code at most time in such state that the virtual
> + registers can be changed by just the corresponding hard registers
> + (with zero offsets) and we have the right RTL code. To achieve this
> + we should add initial offs
On 10/03/2012 12:29 AM, Vladimir Makarov wrote:
> On 12-10-02 7:30 AM, Bernd Schmidt wrote:
>> On 09/28/2012 12:59 AM, Vladimir Makarov wrote:
>>> + We keep RTL code at most time in such state that the virtual
>>> + registers can be changed by just the c
On 08/13/2012 05:42 PM, Vladimir Makarov wrote:
> On 08/13/2012 06:32 AM, Bernd Schmidt wrote:
>> This is a small patch for sched-rgn that attempts to save DFA state at
>> the end of a basic block and re-use it in successor blocks. This was a
>> customer-requested optimizat
On 10/15/2012 06:41 AM, Joern Rennecke wrote:
> The following patch is still awaiting review:
>
> 2011-09-19 J"orn Rennecke
>
> * genoutput.c (process_template): Process '*' in '@' alternatives.
> * doc/md.texi (node Output Statement): Provide example for the
> above.
>
> http
On 10/16/2012 04:30 AM, Vladimir Makarov wrote:
> In insn:
>
> (define_insn_and_split "*lea_general_1"
> [(set (match_operand 0 "register_operand" "=r")
> (plus (plus (match_operand 1 "index_register_operand" "l")
> (match_operand 2 "register_operand" "r"))
> (match_ope
e using a
patched gcc-4.3.
I'm thinking this probably ought to go into 4.8 as well.
Bernd
commit 6a77b1fca11e2fe9ac20aba2a241ead5a8ebd701
Author: Bernd Schmidt
Date: Tue Oct 15 12:16:07 2013 +0200
Fix a miscompilation where a reload reg is reused after it has been cl
The sequence of events here can be summarized as "shrink-wrapping causes
the i386 backend to do something that confuses alias analysis". The
miscompilation is that two instructions are swapped by the scheduler
when they shouldn't be, due to an incorrect reg_base_value.
The miscompiled function has
On 07/14/2013 09:54 AM, Chung-Lin Tang wrote:
> Hi, the last ping of the Nios II patches was:
> http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01416.html
>
> After assessing the state, we feel it would be better to post a
> re-submission of the newest patches.
Since this hasn't attracted attention
On 07/14/2013 09:54 AM, Chung-Lin Tang wrote:
> These are nios2 patches for the gcc testsuite. Some new testcases were
> added since the last posting.
> Index: gcc/testsuite/gcc.c-torture/execute/builtins/lib/chk.c
> ===
> --- gcc/tes
On 10/18/2013 01:18 PM, Richard Biener wrote:
> Index: gcc/fold-const.c
> ===
> --- gcc/fold-const.c (revision 203267)
> +++ gcc/fold-const.c (working copy)
> @@ -7270,8 +7270,8 @@ fold_plusminus_mult_expr (location_t loc, enum tre
>
On 10/18/2013 02:10 PM, Richard Biener wrote:
> On Fri, Oct 18, 2013 at 2:02 PM, Bernd Schmidt
> wrote:
>> On 10/18/2013 01:18 PM, Richard Biener wrote:
>>
>>> Index: gcc/fold-const.c
>>> ==
On 01/05/2016 02:15 PM, Chung-Lin Tang wrote:
* omp-low.c (scan_sharing_clauses): Call add_local_decl() for
use_device/use_device_ptr variables.
It looks vaguely plausible, but if everything is part of the host
function, why make a copy of the decl at all? I.e. what happens if
PR66178 has some testcases where we construct expressions involving
additions and subtractions of label addresses, and we crash when trying
to expand these. There are two different issues here, shown by various
testcases in the PR:
* expand_expr_real_2 can drop EXPAND_INITIALIZER and then go
On 01/20/2016 10:49 PM, Kelvin Nilsen wrote:
* toplev.c (do_compile): remove invocation of process_options ()
from within do_compile ()
(toplev::main): insert invocation of process_options () before
invocation of handle_common_deferred_options ().
The ChangeLog se
Thomas, I've mentioned this issue before - there is sometimes just too
much irrelevant stuff to wade through in your patch submissions, and it
discourages review. The discussion of the actual problem begins more
than halfway through your multi-page mail. Please try to be more concise.
On 12/16
On 01/21/2016 03:22 PM, Chung-Lin Tang wrote:
On 2016/1/20 09:17 PM, Bernd Schmidt wrote:
On 01/05/2016 02:15 PM, Chung-Lin Tang wrote:
* omp-low.c (scan_sharing_clauses): Call add_local_decl() for
use_device/use_device_ptr variables.
It looks vaguely plausible, but if everything
On 01/21/2016 05:34 PM, Eric Botcazou wrote:
Tested on x86_64-suse-linux, OK for the mainline?
2016-01-21 Eric Botcazou
* doc/extend.texi (scalar_storage_order type attribute): Document
restriction on type punning and aliasing.
Isn't this kind of implied by the already doc
On 01/18/2016 08:30 PM, David Edelsohn wrote:
Bootstrapped on powerpc-ibm-aix7.1.2.0 with and without the corrected assembler.
Okay?
The changes seem to be in *-*-aix blocks, so as far as I'm concerned you
are the maintainer and can check this in. One question though:
;;
esac
I've bootstrapped and tested the following on 4.9-branch. It's a
backport of a patch that avoids unnecessary assertion failures, both by
tuning down an assert, and restricting an optimization for the case
where the assert would validly trigger.
Ok to commit on the branch?
Bernd
PR target/6
On 01/22/2016 09:36 AM, Jakub Jelinek wrote:
I think it is a bad idea to go against what the user wrote. Warning that
some code might not be efficient? Perhaps (if properly guarded with some
warning option one can turn off, either on a per-source file or using
pragmas even more fine grained).
On 01/22/2016 02:25 PM, Jakub Jelinek wrote:
What about #pragma oacc parallel? That would never do that?
It shouldn't, no (IMO).
Bernd
On 01/22/2016 10:52 AM, Kyrill Tkachov wrote:
AFAICT the new sequence is better than the old one even for
-mtune=cortex-a9 since it contains two fewer instructions.
Just curious (I think this patch series is good but will leave it to the
arm folks) - are these instructions equally expensive?
On 01/22/2016 02:37 PM, Andrew MacLeod wrote:
/* If the initializer is non-void, then it's a normal expression
that will be assigned to the slot. */
(*) if (!VOID_TYPE_P (t))
(*) return RECURSE (t);
I suspect this should also be
if (!VOID_TYPE_P(TREE_TYPE
On 01/22/2016 08:03 PM, Ian Lance Taylor wrote:
Updated patch.
I've verified that I'm changing the only relevant place in
tree-ssa-loop-ivopts.c that creates a POINTER_PLUS_EXPR, so I do think
that this is the only changed to fix the problem for ivopts.
I don't think so. One of the problems wi
On 01/23/2016 12:52 AM, Ian Lance Taylor wrote:
2016-01-22 Ian Lance Taylor
* common.opt (fkeep-gc-roots-live): New option.
* tree-ssa-loop-ivopts.c (add_candidate_1): If
-fkeep-gc-roots-live, skip pointers.
(add_iv_candidate_for_biv): Handle add_candidate_1 returning
NULL.
* doc/invoke.texi
On 01/24/2016 11:23 PM, David Wohlferd wrote:
+Wonly-top-basic-asm
+C ObjC ObjC++ C++ Var(warn_only_top_basic_asm) Warning
+Warn on unsafe uses of basic asm.
Maybe just -Wbasic-asm?
+/* Warn on basic asm used inside of functions,
+ EXCEPT when in naked functions. Also allow asm("").
On 01/25/2016 04:36 PM, tbsaunde+...@tbsaunde.org wrote:
$subject. To avoid regressions I kept the checks when generating rtl, but I
believe its impossible for those to trigger now and we can remove the checks.
bootstrapped + regtested on x86_64-linux-gnu, ok?
Is this still an issue? I commit
On 01/26/2016 09:39 AM, Jakub Jelinek wrote:
PR target/69442
* combine.c (combine_instructions): For REG_EQUAL note with
SET_DEST being ZERO_EXTRACT, also temporarily set SET_DEST
to the underlying register.
* doc/rtl.texi (REG_EQUAL): Document the behavio
On 01/25/2016 09:13 PM, David Malcolm wrote:
Here's an updated version of the patch.
Thanks!
Instead of testing one particular kind of output via a plugin,
this version of the patch adds code to gcc-dg-prune to issue a
FAIL for any testcase containing blank lines, with a new
dg-allow-blank
On 01/25/2016 11:13 PM, Martin Sebor wrote:
The attached patch adjusts the documentation of attribute aligned
and attribute pack so as to prevent misreading the text of the
former attribute as if it had read:
Specifying attribute aligned for struct and union types is
equivalent to specifyi
On 01/25/2016 05:03 PM, Ian Lance Taylor wrote:
On Mon, Jan 25, 2016 at 3:39 AM, Bernd Schmidt wrote:
On 01/23/2016 12:52 AM, Ian Lance Taylor wrote:
2016-01-22 Ian Lance Taylor
* common.opt (fkeep-gc-roots-live): New option.
* tree-ssa-loop-ivopts.c (add_candidate_1): If
-fkeep-gc-roots
On 01/26/2016 01:29 AM, Segher Boessenkool wrote:
In my opinion we should not warn for any asm that means the same both
as basic and as extended asm. The problem then becomes, what *is* the
meaning of a basic asm, what does it clobber.
I think this may be too hard to figure out in general wit
On 01/25/2016 09:30 PM, Jakub Jelinek wrote:
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
I've been staring at it for a while, and on the whole I think I can make
sense of this. However - it does not have test coverage. Can this be
added? Also, is this a regression?
On 01/26/2016 02:24 PM, Jakub Jelinek wrote:
just designed to enable DEF_SANITIZER_BUILTIN (IIUC). Also, why use shift
and not just sanitize=undefined?
Because -fsanitize=undefined is a large collection of individual sanitizers,
and at least some of them affect also post-IPA code (e.g.
-fsani
+This option is disabled by default for most languages, enabled by
+default for languages that use garbage collection.
This is not true as of this patch.
Index: tree-ssa-loop-ivopts.c
===
--- tree-ssa-loop-ivopts.c (revision
On 01/27/2016 02:59 PM, Ian Lance Taylor wrote:
+This option is disabled by default for most languages, enabled by
+default for languages that use garbage collection.
This is not true as of this patch.
Yes. As I said elsewhere, my intent is to do that as a separate patch.
Then the followu
On 01/27/2016 04:18 PM, Ian Lance Taylor wrote:
On Wed, Jan 27, 2016 at 7:16 AM, Bernd Schmidt wrote:
Still, I feel uncomfortable about making a promise we don't really expect to
fully keep yet, so I would prefer this option to be undocumented for now. I
won't object if someone els
On 01/08/2016 02:00 PM, Bernd Schmidt wrote:
On 01/08/2016 10:41 AM, Richard Biener wrote:
On Tue, Dec 22, 2015 at 10:55 AM, Nick Clifton wrote:
Richard Biener wrote:
I think the option should be simply removed...
Tempting - but we are in stage 3... My patch at least fixes the ICE for
now
On 01/28/2016 12:36 AM, Eric Botcazou wrote:
[cc-ing Eric as RTL maintainer]
Sorry for the delay, the message apparently bounced]
IMO the problem is that rtx_addr_can_trap_p_1 duplicates a large
bit of LRA/reload logic:
[...]
Under the current interface macros like INITIAL_ELIMINATION_OFFSE
Let's say we have
struct a {
int x[1];
int y[1];
} x = { 0, { 0 } };
^
When we reach the marked brace, we call into push_init_level, where we
notice that we have implicit initializers (for x[]) lying around that we
should deal with now that we've seen another open brace. The probl
This patch corrects some tests that can fail with -frename-registers.
The problems typically are of the form "xmm[0-7]+", disallowing
registers 8 and 9, and "xmm[0-9]". disallowing numbers higher than 9.
Most the patch was automatically generated, but there were some other
cases as well.
Enab
On 01/29/2016 04:41 PM, Jakub Jelinek wrote:
On Fri, Jan 29, 2016 at 02:09:25AM +0100, Bernd Schmidt wrote:
I think a better approach might be to just mark accesses at known locations
in the frame, or arg pushes, as MEM_NOTRAP_P, and consider accesses with
non-constant or calculated offsets
So PR57193 has an example of sub-optimal code generation, with some
unnecessary register moves left after LRA. These seem to be difficult to
prevent, but last year Robert Suchanek made some modifications to
regrename that allow it to clean up such cases. Enabling
-frename-registers removes one
On 01/29/2016 08:42 PM, Bernd Edlinger wrote:
On 29.01.2016 16:47 Bernd Schmidt wrote:
Yes. What is the problem with that? If we have (plus sfp const_int) at
any point before reload, we can check whether that offset is inside
frame_size. If it isn't or if the offset isn't known, it
On 02/01/2016 01:49 PM, Richard Biener wrote:
What prevents motion of those across a stack adjustment (thus a place
they are _not_ valid?)
If the address is SP-based, dependencies on the address register. If
you're thinking prologue stack adjustments, ports where this could be an
issue emit
On 02/01/2016 09:34 PM, Jakub Jelinek wrote:
On the following testcase we completely uselessly consume about 5.5GB
of RAM and lots of compile time. The problem is the code to avoid
exponential behavior of nonzero_bits/num_sign_bit_copies on binary
arithmetics rtxes, which causes us to recurse ev
On 02/02/2016 09:59 AM, Jakub Jelinek wrote:
I wonder if it wouldn't be better to pass around some structure, containing
for the common case fixed size cache and perhaps fall back to hash_map if
there are more calls to cache than that. Plus perhaps a recursion depth, so
that we avoid other path
On 02/03/2016 05:35 PM, Wilco Dijkstra wrote:
- tmp2 = targetm.gen_ccmp_first (&prep_seq_2, &gen_seq_2, rcode1,
-gimple_assign_rhs1 (gs1),
-gimple_assign_rhs2 (gs1));
-
It looks like after this patch tmp2 co
On 02/01/2016 08:13 AM, Mike Frysinger wrote:
We don't document the -mno-xxx variants for other flags here, and the
paragraph here specifically says "Each has a corresponding -mno- option
to disable use of these instructions". Drop the -mno-fma4 line.
2016-01-31 Mike Frysinger
* doc
In this PR, we have, at an intermediate stage during LRA (before
create_cands):
(insn 420 (set (reg:HI 276 [orig:132 g.2_118 ] [132])
(reg:HI 132 [ g.2_118 ])) 88 {*movhi_internal}
(nil))
[]
(insn 436 (set (reg/v:HI 290 [orig:87 g ] [87])
(reg/v:HI 87 [ g ]))
(insn 14 (
On 02/05/2016 01:10 PM, Richard Biener wrote:
It fails
FAIL: gcc.target/i386/addr-sel-1.c scan-assembler b+1
on i?86 (or x86_64 -m32) though, generating
f:
.LFB0:
.cfi_startproc
movl4(%esp), %eax
leal1(%eax), %edx
movsbl a+1(%eax), %eax
On 02/05/2016 01:42 PM, Richard Biener wrote:
so indeed the issue is not dx dieing in insn 10 but ax dieing in insn 8...
Maybe LRA can prefer to not do that if enough free registers are
available (that is, never re-use a register)?
Maybe, but at this stage that will probably also have some unp
Ping.
On 01/29/2016 12:40 PM, Bernd Schmidt wrote:
Let's say we have
struct a {
int x[1];
int y[1];
} x = { 0, { 0 } };
^
When we reach the marked brace, we call into push_init_level, where we
notice that we have implicit initializers (for x[]) lying around that we
should
On 02/03/2016 09:05 PM, Jakub Jelinek wrote:
2016-02-03 Jakub Jelinek
PR c++/69628
* charset.c (cpp_interpret_charconst): Clear *PCHARS_SEEN
and *UNSIGNEDP if bailing out early due to errors.
* g++.dg/parse/pr69628.C: New test.
Ok.
Bernd
This patch fixes PR60410 by removing -fshort-double. Nick earlier
propsed a fix for the crash, but Richard B suggested removing the option
entirely, and I'd agree with that. It's a pointless ABI-changing option
on most targets, and if a port really needs it, it should be a -m option
that tweaks
On 01/27/2016 07:12 PM, Kelvin Nilsen wrote:
+/* During execution of handle_common_deferred_options (), the Pmode
+ variable cannot be used because it has not yet been initialized.
+ For this reason, handling of the OPT_fstack_limit_register_ and
+ OPT_fstack_limit_symbol_ options is deferr
On 02/08/2016 10:09 AM, Richard Biener wrote:
The gcc.target/i386/addr-sel-1.c (for PR28940) seems to just started
working at some point past in time and thus it was added and the
bug closed. You could say RA does a better job after the patch
as it uses 1 less register but that restricts the fol
On 12/21/2015 08:39 PM, Jeff Law wrote:
On 12/18/2015 11:38 AM, Bernd Schmidt wrote:
In an earlier fix, the following change was made in varasm.c for invalid
register variables:
--- trunk/gcc/varasm.c2014/08/26 14:59:59214525
+++ trunk/gcc/varasm.c2014/08/26 17:06:31214526
On 02/10/2016 12:34 PM, Alexander Fomin wrote:
This patch still causes bootrstrap failure on AIX when applied
on top of r219827.
I tried to bisect first commit eliminating AIX problem - it may
be useful anyway - but my current results seem misleading.
Therefore, I'll to continue the investigatio
On 02/10/2016 12:49 PM, Thomas Schwinge wrote:
Hi!
Ping.
I think this has to be considered after gcc-6. In general, what's the
state of OpenACC these days?
I'm slightly confused by the interface between offloaded code and
libgomp. It looks like you're collecting avoid-offloading flags
per
On 02/10/2016 02:04 PM, Richard Biener wrote:
where noce_try_store_flag_constants identifies
(plus:SI (reg/v:SI 160 [ mod_tlen ])
(reg/v:SI 224 [ ]))
as "common" and then tries to detect the case where setting the
result would clobber that value. It doesn't seem to expect
anything e
On 02/10/2016 02:33 PM, Richard Biener wrote:
But if you prefer I can instead test the following
Index: gcc/ifcvt.c
===
--- gcc/ifcvt.c (revision 233262)
+++ gcc/ifcvt.c (working copy)
@@ -1274,7 +1274,7 @@ noce_try_store_flag_cons
On 02/10/2016 02:35 PM, Richard Biener wrote:
Index: gcc/ifcvt.c
===
--- gcc/ifcvt.c (revision 233262)
+++ gcc/ifcvt.c (working copy)
@@ -1274,7 +1274,8 @@ noce_try_store_flag_constants (struct no
&& CONST_INT_P (XEXP (a, 1)
On 02/10/2016 02:50 PM, Richard Biener wrote:
On Wed, 10 Feb 2016, Bernd Schmidt wrote:
On 02/10/2016 02:35 PM, Richard Biener wrote:
Index: gcc/ifcvt.c
===
--- gcc/ifcvt.c (revision 233262)
+++ gcc/ifcvt.c (working copy
On 02/10/2016 03:39 PM, Thomas Schwinge wrote:
Yes, we need a hammer that big: we have to ensure consistency between
data regions on the device and code offloading to the device, as
otherwise we'll very easily run into inconsistencies, because of the
non-shared memory. In the general case, it's
On 02/09/2016 09:44 PM, David Malcolm wrote:
This is a bug in a new feature, so it isn't a regression as such, but
it's fairly visible, and I believe the fix is relatively low-risk
(error-handling of typos of command-line options).
This also now covers PR driver/69453 (and its duplicate PR
drive
On 02/10/2016 05:23 PM, Thomas Schwinge wrote:
Why? A user of GCC has no intrinsic interest in getting OpenACC kernels
constructs' code offloaded; the user wants his code to execute as fast as
possible.
If you consider the whole of OpenACC kernels code offloading as a
compiler optimization, the
This PR notes that in this warning:
const.ii:5:25: warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
const double value() const {return val;}
^
we are pointing at the wrong qualifier. Below I'm attaching a patch that
makes it point
I've noticed that build_null_declspecs fails to clear out all location
information since it's missing a multiplication with the type size. The
simplest fix seems to be to just clear the entire structure.
Bootstrapping & testing now on x86_64-linux, ok if that succeeds?
Depending on what we do
On 02/10/2016 06:37 PM, Thomas Schwinge wrote:
On Wed, 10 Feb 2016 17:37:30 +0100, Bernd Schmidt wrote:
IIUC it's also disabling offloading for parallels rather than just
kernels, which we previously said shouldn't happen.
Ah, you're talking about mixed OpenACC parallel/ker
On 02/11/2016 04:29 AM, David Malcolm wrote:
gcc/ChangeLog:
PR plugins/69758
* Makefile.in (PLUGIN_HEADERS): Add params.list.
Ok.
Bernd
On 02/11/2016 10:45 AM, Alan Modra wrote:
Due to uses elsewhere in vsx instructions, reload chooses to put
psuedo 185 in fr31, which can't be used as a base register in the
following:
What code exactly makes the choice of fr31? I assume this is in
reg_renumber, so it's IRA and not reload that
On 02/10/2016 03:03 PM, Richard Biener wrote:
Ok, the following is in testing now.
Ok?
Thanks,
Richard.
2016-02-10 Richard Biener
PR rtl-optimization/69291
* ifcvt.c (noce_try_store_flag_constants): Do not allow
subexpressions affected by changing the result.
Ok
On 02/11/2016 12:49 AM, David Wohlferd wrote:
I believe the attached patch addresses all the other outstanding comments.
Bernd Edlinger made some thorough comments; I'll just add a few more. I
don't think this is a patch we're considering for gcc-6, at least not
for the initial release - I im
On 02/11/2016 04:12 PM, 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: Add extern declarations of the two new g
On 02/11/2016 11:01 AM, Thomas Schwinge wrote:
The "avoid offloading" mechanism. Owed to the non-shared-memory
offloading architecture, if the compiler/runtime decides to "avoid
offloading", then this has to apply to *all* code offloading, for data
consistency reasons. Do we agree on that?
N
On 02/12/2016 12:26 AM, Jakub Jelinek wrote:
When expanding shifts with invalid shift counts (negative or too large),
the shift count on the GIMPLE level is typically an int mode INTEGER_CST,
but when it is passed down through various layers up to
expand_binop_directly, we only have one known mod
This seems fairly straightforward:
(insn 213 455 216 6 (set (reg:SI 266)
(mem/u/c:SI (post_inc:SI (reg/f:SI 267)) [4 S4 A32])) 748
{*thumb1_movsi_insn}
(expr_list:REG_EQUAL (const_int -1044200508 [0xc1c2c3c4])
(expr_list:REG_INC (reg/f:SI 267)
(nil
On 02/12/2016 04:27 AM, Alan Modra wrote:
I don't understand this comment. If we're pushing a reload of the
inner reg, then the SECONDARY_MEMORY_NEEDED code in push_reload will
fire. Why then should there be any need to do anything special in
find_reloads_address_1 regarding secondary memory?
On 02/12/2016 11:46 AM, Richard Biener wrote:
On Fri, 12 Feb 2016, Jakub Jelinek wrote:
On Fri, Feb 12, 2016 at 11:23:26AM +0100, Richard Biener wrote:
I am testing the following patch which fixes PR69771 where the code
doesn't match the comment before it. We get to expand a QImode << QImo
On 02/12/2016 08:05 AM, David Wohlferd wrote:
Actually, it was my intent that this apply to v6. It's not like there
is a significant change here. We're documenting long-time behavior, and
adding a (disabled) warning.
The doc patch (minus mentioning the warning) could go in now, but for
gcc-6
On 02/12/2016 02:26 PM, Marek Polacek wrote:
On Fri, Feb 12, 2016 at 02:17:19PM +0100, Andreas Schwab wrote:
FAIL: gcc.dg/pr69522.c (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20160212/gcc/testsuite/gcc.dg/pr69522.c:2:8: error:
struct has no members [-Wpedantic]
/daten/aranym/
On 02/12/2016 02:18 PM, Jiong Wang wrote:
PR rtl-optimization/69752
* ira.c (update_equiv_regs): When looking for more than a single
SET,
also take other side effects into account.
Will it be better that we don't remove the insn if it has side-effect
instead of don't record the equ
On 02/12/2016 02:47 PM, Richard Biener wrote:
Another possibility, only do the convert_modes from VOIDmode for
shift_optab_p's xop1, and keep doing what we've done before otherwise.
That looks like a very targeted and safe fix indeed.
You two can obviously go ahead and sort this out, I'll jus
On 02/12/2016 03:08 PM, Marek Polacek wrote:
We've got a report that GCC is crashing when building a package on i686;
there was an ICE in assemble_integer. Turned out this ICE was already fixed
by r233216, so I reduced it and would like to add it to the testsuite.
Tested on x86_64-linux and i68
PR69714 is an issue where the bswap pass makes an incorrect
transformation on big-endian targets. The source has a 32-bit bswap, but
PA doesn't have a pattern for that. Still, we recognize that there is a
16-bit bswap involved, and generate code for that - loading the halfword
at offset 2 from
So do you prefer e.g. following? Bootstrapped/regtested on x86_64-linux and
i686-linux.
- mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode;
+ mode1 = (GET_MODE (xop1) != VOIDmode || canonicalize_op1)
+ ? GET_MODE (xop1) : mode;
Placement of parentheses is wrong for format
This is a PR where LRA creates a read from an uninitialized stack slot.
That stack slot is supposed to hold the value of the PIC register.
What seems to happen is that we have two passes making different choices:
Choosing alt 0 in insn 143: (0) =x (1) 0 (2) r {sse2_pinsrw}
[...]
On 02/13/2016 03:36 AM, John David Anglin wrote:
As far as the avcrc.c reduced testcase, it didn't trigger the original bug on
hppa-unknown-linux-gnu.
Odd, I see the same transformation in the dumps. Do you think you could
investigate a bit so we get a useful testcase to add?
Bernd
1 - 100 of 2198 matches
Mail list logo
