[committed] TILE-Gx: Fix tilegx_fixup_pcrel_references
This patch fixes a bug in tilegx_fixup_pcrel_references, to properly
match and fixup the second instruction of the instruction sequence to
generate a pc relative address.
Walter
* config/tilegx/tilegx.c (match_pcrel_step2): Fix instruction
pattern.
(replace_mov_pcrel_step2): Ditto.
Index: gcc/config/tilegx/tilegx.c
===
--- gcc/config/tilegx/tilegx.c (revision 184581)
+++ gcc/config/tilegx/tilegx.c (working copy)
@@ -4420,7 +4420,9 @@ replace_mov_pcrel_step1 (rtx insn)
static bool
match_pcrel_step2 (rtx insn)
{
- rtx src;
+ rtx unspec;
+ rtx addr;
+
if (TARGET_32BIT)
{
if (recog_memoized (insn) != CODE_FOR_insn_addr_shl16insli_32bit)
@@ -4432,11 +4434,12 @@ match_pcrel_step2 (rtx insn)
return false;
}
- src = SET_SRC (PATTERN (insn));
+ unspec = SET_SRC (PATTERN (insn));
+ addr = XVECEXP (unspec, 0, 1);
- return (GET_CODE (src) == CONST
- && GET_CODE (XEXP (src, 0)) == UNSPEC
- && XINT (XEXP (src, 0), 1) == UNSPEC_HW0_PCREL);
+ return (GET_CODE (addr) == CONST
+ && GET_CODE (XEXP (addr, 0)) == UNSPEC
+ && XINT (XEXP (addr, 0), 1) == UNSPEC_HW0_PCREL);
}
@@ -4446,6 +4449,7 @@ replace_mov_pcrel_step2 (rtx insn)
{
rtx pattern = PATTERN (insn);
rtx unspec;
+ rtx addr;
rtx opnds[3];
rtx new_insns;
rtx got_rtx = tilegx_got_rtx ();
@@ -4453,10 +4457,18 @@ replace_mov_pcrel_step2 (rtx insn)
gcc_assert (GET_CODE (pattern) == SET);
opnds[0] = SET_DEST (pattern);
- unspec = XEXP (SET_SRC (pattern), 0);
+ unspec = SET_SRC (pattern);
+ gcc_assert (GET_CODE (unspec) == UNSPEC);
+ gcc_assert (XINT (unspec, 1) == UNSPEC_INSN_ADDR_SHL16INSLI);
+
+ opnds[1] = XVECEXP (unspec, 0, 0);
+
+ addr = XVECEXP (unspec, 0, 1);
+ gcc_assert (GET_CODE (addr) == CONST);
+
+ unspec = XEXP (addr, 0);
gcc_assert (GET_CODE (unspec) == UNSPEC);
gcc_assert (XINT (unspec, 1) == UNSPEC_HW0_PCREL);
- opnds[1] = XEXP (XEXP (SET_SRC (pattern), 0), 0);
opnds[2] = XVECEXP (unspec, 0, 0);
/* We only need to replace SYMBOL_REFs, not LABEL_REFs. */
[google/gcc-4_7] update BASE-VER to 4.7.x-google (issue5696077)
commit d00e10980dde6c19ec3d8035a80769d54288 Author: Ollie Wild Date: Sun Feb 26 00:30:42 2012 -0600 Update BASE-VER to 4.7.x (for consistency across minor releases). This is what we do with the existing google/gcc-4_6 branch. gcc/ChangeLog.google-4_7 2012-02-26 Ollie Wild * BASE-VER: Change to 4.7.x-google. diff --git a/gcc/BASE-VER b/gcc/BASE-VER index cfb495d..b256a44 100644 --- a/gcc/BASE-VER +++ b/gcc/BASE-VER @@ -1 +1 @@ -4.7.0-google +4.7.x-google diff --git a/gcc/ChangeLog.google-4_7 b/gcc/ChangeLog.google-4_7 index 9d40c1b..38802b2 100644 --- a/gcc/ChangeLog.google-4_7 +++ b/gcc/ChangeLog.google-4_7 @@ -1,3 +1,7 @@ +2012-02-26 Ollie Wild + + * BASE-VER: Change to 4.7.x-google. + 2012-02-23 Diego Novillo * BASE-VER: Change to 4.7.0-google. -- This patch is available for review at http://codereview.appspot.com/5696077
Re: [google][4.6]Bug fix to function reordering plugin to check presence of elf.h
Committed now, thanks. -Sri. On Fri, Feb 24, 2012 at 11:18 PM, Xinliang David Li wrote: > ok. > > David > > On Fri, Feb 24, 2012 at 4:19 PM, Sriraman Tallam wrote: >> function_reordering_plugin.c includes which is not available >> on non-ELF platforms building a cross-compiler. This patch checks for >> before including it. Otherwise, it redefines the macros used. >> This is safe becaue the macros will not change. >> >> For context, this linker plugin itself is only available in the google >> 4_6 branch and I will port it to other branches and make it available >> for review for trunk soon. >> >> >> 2012-02-24 Sriraman Tallam >> >> * function_reordering_plugin.c: Check for presence of elf.h. >> Otherwise, redefine the elf macros used. >> >> Ok to commit? >> >> Thanks, >> -Sri.
[committed] Fix PR testsuite/52201
Tested on hppa2.0w-hp-hpux11.11. Committed to trunk.
Dave
--
J. David Anglin dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
2012-02-25 John David Anglin
PR testsuite/52201
* testsuite/29_atomics/atomic/operators/pointer_partial_void.cc:
Requireatomic builtins.
* testsuite/29_atomics/atomic/operators/51811.cc: Likewise.
Index: testsuite/29_atomics/atomic/operators/pointer_partial_void.cc
===
--- testsuite/29_atomics/atomic/operators/pointer_partial_void.cc
(revision 184496)
+++ testsuite/29_atomics/atomic/operators/pointer_partial_void.cc
(working copy)
@@ -1,3 +1,4 @@
+// { dg-require-atomic-builtins "" }
// { dg-options "-std=gnu++0x" }
// Copyright (C) 2012 Free Software Foundation, Inc.
Index: testsuite/29_atomics/atomic/operators/51811.cc
===
--- testsuite/29_atomics/atomic/operators/51811.cc (revision 184496)
+++ testsuite/29_atomics/atomic/operators/51811.cc (working copy)
@@ -1,3 +1,4 @@
+// { dg-require-atomic-builtins "" }
// { dg-options "-std=gnu++0x" }
// Copyright (C) 2012 Free Software Foundation, Inc.
Re: [Patch,AVR]: Make flash size a device property (was: core property)
Georg-Johann Lay schrieb:
This patch addresses several issues related to device flash size:
* cores avrxmega4/5 have ELPM* instruction
* flash sizes for xmega were wrong because atxmegaXX
has some extra bootloader flash and thus a flash size
of XX + epsilon.
* There are devices with different flash sizes, i.e. with
different sets of reasonable address spaces within the same
core architecture. Thus, turn flash size from a core property
to a device property
* No more try to fix silly (too big) address spaces by means
of modulo computation. Just emit an error if a nonsensical
address space is used
As this patch is mainly about the new xmega architecture support:
I updated the avrtest core simulator hosted in the WinAVR project at
sourceforge. The avrtest simulator can now be used to reg-test avr-gcc
testsuite against xmega core.
The regression tests on xmega revealed two typos in avr BE that are
already fixed:
http://gcc.gnu.org/viewcvs?view=revision&revision=184522
http://gcc.gnu.org/viewcvs?view=revision&revision=184559
As target I used atxmega128a3 and the test results are exactly the same
as for atmega128, except for some functions that use builtin return or
instrument-functions that trigger builtin return.
This is because the testsuite was run with this patch applied and the
flash size of atxmega128a3 is > 64Ki words then, thus a warning from avr.c
rtx
avr_return_addr_rtx (int count, rtx tem)
{
...
if (AVR_3_BYTE_PC)
{
r = gen_rtx_SYMBOL_REF (Pmode, ".L__stack_usage+2");
warning (0, "'builtin_return_address' contains only
2 bytes of address");
}
I did not try to use PSImode as potential fix; but even with PSImode
there would be a warning from
static bool
avr_assemble_integer (rtx x, unsigned int size, int aligned_p)
{
...
if (GET_MODE (x) == PSImode)
{
default_assemble_integer (avr_const_address_lo16 (x),
GET_MODE_SIZE (HImode), aligned_p);
fputs ("\t.warning\t\"assembling 24-bit address needs binutils"
" extension for hh8(", asm_out_file);
output_addr_const (asm_out_file, x);
fputs (")\"\n", asm_out_file);
fputs ("\t.byte\t0\t" ASM_COMMENT_START " hh8(", asm_out_file);
output_addr_const (asm_out_file, x);
fputs (")\n", asm_out_file);
return true;
}
The simulator does not test I/O and the new operand modifier %i, of
course, but I heard that guys using 4.7 snapshots could compile and run
xmega programs without problems.
Johann
Passes without regression.
Ok for trunk?
Johann
PR target/49868
* doc/extend.texi (AVR Named Address Spaces): No more try to fix
address spaces located outside of device flash.
PR target/49868
PR target/52261
* config/avr/avr.h (base_arch_s): Remove field n_segments.
(mcu_type_s): Add field n_flash.
* config/avr/avr-devices.c (avr_arch_types): Remove .n_segments.
Set .have_elpm and .have_elpmx to 1 for avrxmega4 and avrxmega5.
(AVR_MCU): Add N_FLASH argument.
* config/avr/avr-mcus.def (AVR_MCU): Add initializer for .n_flash.
* config/avr/avr-c.c (avr_cpu_cpp_builtins): Only define built-in
macro __FLASH if that address space makes sense for the device.
* config/avr/avr.c (avr_out_lpm): Don't try to fix address spaces
outside of target flash.
(avr_asm_named_section): Ditto.
(avr_asm_select_section): Ditto.
(avr_addr_space_convert): Ditto.
(avr_emit_movmemhi): Ditto.
(avr_nonconst_pointer_addrspace, avr_pgm_check_var_decl): Error if
address space is outside of device flash.
(avr_insert_attributes): Ditto.
(avr_xload_libgcc_p): Use avr_current_device->n_flash instead of
avr_current_arch->n_segments.
Re: Ping #1: [Patch,AVR] Fix/hack around spill fail ICE PR52148
2012/2/25 Georg-Johann Lay : [...] > The pattern for the address spaces is now as simple as > > ;; $0 : Address Space > ;; $1 : RAMPZ RAM address > ;; R24 : #bytes and loop register > ;; R23:Z : 24-bit source address > ;; R26 : 16-bit destination address > > ;; "movmemx_qi" > ;; "movmemx_hi" > (define_insn "movmemx_" > [(set (mem:BLK (reg:HI REG_X)) > (mem:BLK (lo_sum:PSI (reg:QI 23) > (reg:HI REG_Z > (unspec [(match_operand:QI 0 "const_int_operand" "n")] > UNSPEC_MOVMEM) > (use (reg:QIHI 24)) > (clobber (reg:HI REG_X)) > (clobber (reg:HI REG_Z)) > (clobber (reg:QI LPM_REGNO)) > (clobber (reg:HI 24)) > (clobber (reg:QI 23)) > (clobber (mem:QI (match_operand:QI 1 "io_address_operand" "n")))] > "" > "%~call __movmemx_" > [(set_attr "type" "xcall") Thanks for explanation. This technique similar to mulhi3, mulhi3_call ... IMHO this is a better solution then very strict constraint 'x' or 'y' or 'z'. I.e. better to have (at least from reload's point of view): mov r26, "r" mov r27, "r" r30,r31 = do-something-with r26, r27 mov "r", r30 mov "r", r31 Than: "z" = do-something-with "x" Denis.
Re: Ping #1: [Patch,AVR] Fix/hack around spill fail ICE PR52148
Denis Chertykov schrieb:
2012/2/24 Georg-Johann Lay:
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00956.html
Georg-Johann Lay wrote:
Spill failure PR52148 occurs for movmem insn that allocates 2 of AVR's 3
pointer registers. Register allocator is at it's limits and the patch tries to
cure the situation by replacing
(match_operand:HI 0 "register_operand" "x")
with explicit
(reg:HI REG_X)
and similar for Z Register classes "x" and "z" contain only one HI register.
This PR and PR50925 show that register allocator has some problems.
Even though this patch is not a fix of the root cause, it allows the PR's test
case to compile.
Anyways, the patch simplifies the backend and replaces an insn with 11(!)
operands with an insn with only 2 operands so that the patch is improvement of
the backend.
The hard registers are already known at expand time so there is no need for
match_operands.
Passes without regression.
Ok for trunk?
Johann
PR target/52148
* config/avr/avr.md (movmem_): Replace match_operand that
match only one single hard register with respective hard reg rtx.
(movmemx_): Ditto.
* config/avr/avr.c (avr_emit_movmemhi): Adapt expanding to new
insn anatomy of movmem[x]_.
(avr_out_movmem): Same for printing assembler and operand usage.
Approved.
Denis.
PS: I have not understood this patch from first look
In 4.6, movmemhi expands the copy loop explicitly:
/* Move one byte into scratch and inc pointer. */
emit_move_insn (tmp_reg_rtx, gen_rtx_MEM (QImode, addr1));
emit_move_insn (addr1, gen_rtx_PLUS (Pmode, addr1, const1_rtx));
/* Move to mem and inc pointer. */
emit_move_insn (gen_rtx_MEM (QImode, addr0), tmp_reg_rtx);
emit_move_insn (addr0, gen_rtx_PLUS (Pmode, addr0, const1_rtx));
tmp_reg is fixed and used implicitly by insn templates; the
assertion is that the lifetime of tmp_reg does never
extend over one insn.
The 4.6 movmemhi violates that assertion, and in 4.7 I saw situations
where reload generates insns that use (i.e. clobber) tmp_reg so that
explicit expanding is wrong. This happend together with movmemhi on
address spaces:
/* FIXME: Register allocator does a bad job and might spill
address register(s) inside the loop leading to additional
move instruction to/from stack which could clobber tmp_reg.
Thus, do *not* emit load and store as seperate insns.
Instead, we perform the copy by means of one
monolithic insn. */
To fix it, I put all the movmemhi stuff into an unspec insn, but that
insn is not nice: The address-space version has 11 operands to
describe the insns action and the ordinary version 7 operands:
;; $0, $4 : & dest (REG_X)
;; $1, $5 : & src (REG_Z)
;; $2 : Address Space
;; $3, $7 : Loop register
;; $6 : Scratch register
;; "movmem_qi"
;; "movmem_hi"
(define_insn "movmem_"
[(set (mem:BLK (match_operand:HI 0 "register_operand" "x"))
(mem:BLK (match_operand:HI 1 "register_operand" "z")))
(unspec [(match_operand:QI 2 "const_int_operand" "n")]
UNSPEC_MOVMEM)
(use (match_operand:QIHI 3 "register_operand" ""))
(clobber (match_operand:HI 4 "register_operand" "=0"))
(clobber (match_operand:HI 5 "register_operand" "=1"))
(clobber (match_operand:QI 6 "register_operand" "=&r"))
(clobber (match_operand:QIHI 7 "register_operand" "=3"))]
""
{
return avr_out_movmem (insn, operands, NULL);
}
[(set_attr "adjust_len" "movmem")
(set_attr "cc" "clobber")])
Even more issues are that the expand machinery expects a specific style
for movmem patterns (or was it clrstrhi?) and that with "free" register
assignments, i.e. with constrints "b" for the addresses,
I saw spill fails.
Outcome was the pattern above, that only allows one specific allocation
of the pointer registers involved; similar for the address space version:
;; Ditto and
;; $3, $7 : Loop register = R24
;; $8, $9 : hh8 (& src) = R23
;; $10: RAMPZ_ADDR
;; "movmemx_qi"
;; "movmemx_hi"
(define_insn "movmemx_"
[(set (mem:BLK (match_operand:HI 0 "register_operand" "x"))
(mem:BLK (lo_sum:PSI (match_operand:QI 8 "register_operand" "r")
(match_operand:HI 1 "register_operand" "z"
(unspec [(match_operand:QI 2 "const_int_operand""n")]
UNSPEC_MOVMEM)
(use (match_operand:QIHI 3 "register_operand" "w"))
(clobber (match_operand:HI 4 "register_operand" "=0"))
(clobber (match_operand:HI 5 "register_operand" "=1"))
(clobber (match_operand:QI 6 "register_operand" "=&r"))
(clobber (match_operand:HI 7 "register_operand" "=3"))
(clobber (match_operand:QI 9 "register_operand" "=8"))
(clobber (mem:QI (match_operand:QI 10 "io_address_operand" "n")))]
""
"%~call __movmemx_"
[(set_attr "type" "xcall")
(set_attr "cc" "clobber")])
With these patterns the test suite passed but are were more FIXMEs
in the source:
/* FIXME: Register allo
Re: [PR52001] too many cse reverse equiv exprs (take2)
On Feb 19, 2012, Richard Sandiford wrote: > I have to admit I still don't like these changes > I'd much rather we kept to the original dag. I'm not sure I mentioned before, but it remains a DAG unless cselib_add_permanent_equiv is called. Only var-tracking calls it, and even then, only when VTA is enabled, so if anyone ever runs into a problem, it's easy enough to disable VTA, var-tracking or even -g altogether to work around the problem. Now, I confess I didn't expect problems in the first place, for I'd missed this use of alias.c by var-tracking. The other use, in find_base_term, had been properly adjusted already. There aren't any other uses of CSELIB_VAL_PTR, so I'm now pretty confident we won't run into any other problems like this. (famous last words ;-) > and it still isn't obvious to me when canonical_cselib_val is supposed > to be used. For comparison of VALUEs, it avoids the need for recursive or combinatorial compares, for all equivalent VALUEs map directly to the single canonical value. For recursive searches and other the like, it's just an optimization to avoid an additional recursion (avoiding recursing into *any* VALUEs is recommended along with it). Other algorithms that iterate over loc lists and recurse should take care to avoid infinite recursion, by marking already-visited nodes (cselib and var-tracking do some of this), temporarily zeroing out their loc lists (like find_base_term), or using other mechanisms to break recursion cycles (like get_addr). Algorithms that didn't expect naked VALUEs in loc lists (like get_addr) may need adjusting to iterate over the loc lists of the canonical value (for non-canonical values have a single loc, the canonical value), and to disregard values in canonical value's lists (unless e.g. we happen to be looking for VALUEs that turn out to be noncanonical). In other cases, the use of canonical values instead of noncanonical ones when filling in data structures (say, building expressions to record in cselib) may save memory by avoiding duplication, but since it causes cselib to compute different hashes, we'd better use whatever is most likely to be searched for by hashing. (We could tweak lookups to use canonical values and to recompute hashes when adding equivalences between values already used in expressions, but this hasn't been done yet). I hope this makes some sense ;-) -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [PATCH] Ignore CLOBBER stmts in ipa-split (PR tree-optimization/52019)
On 2012.02.23 at 15:31 +0100, Richard Guenther wrote: > On Thu, 23 Feb 2012, Jakub Jelinek wrote: > > > Hi! > > > > IMHO we should treat CLOBBER stmts in various places like debug stmts, > > they shouldn't affect the decisions of the optimization phases, but > > if the pass does some transformation that somehow invalidates them or > > moves them (not in this pass), it needs to be adjusted. Otherwise we end > > up with the CLOBBERs inhibiting optimizations. > > > > This seems to work for ipa-split, the actual transformations DTRT > > apparently. Bootstrapped/regtested on x86_64-linux and i686-linux, > > ok for trunk? > > Ok. This patch causes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52376 -- Markus
Re: Ping #1: [Patch,AVR]: Add builtins.def and fix some ICE, add tests
2012/2/24 Georg-Johann Lay : > http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00843.html > > Georg-Johann Lay wrote: >> This patch introduces a new file builtins.def that is used as central >> registry >> to hold built-ins' information. >> >> The file is used by defining DEF_BUILTIN macre and then including the file as >> described in the head comment of builtins.def. >> >> Up to here it's all code clean-up and no functional change. >> >> Moreover there are some minor changes and ICE fixes: >> >> * Fold __builtin_avr_swap to rotate <<< 4 >> * Don't fold __builtin_avr_insert_bits if first arg is non-const (was ICE) >> * Don't expand __builtin_avr_delay_cycles if arg is not-const (was ICE) >> >> Ok for trunk? >> >> Johann >> >> gcc/testsuite/ >> * gcc.target/avr/torture/builtins-1.c: New test. >> * gcc.target/avr/torture/builtins-error.c: New test. >> gcc/ >> * config/avr/builtins.def: New file. >> * config/avr/t-avr (avr.o, avr-c.o): Depend on it. >> * config/avr/avr.c (enum avr_builtin_id): Use it. >> (avr_init_builtins): Use it. And use avr_bdesc. >> (bdesc_1arg): Remove. >> (bdesc_2arg): Remove. >> (bdesc_3arg): Remove. >> (struct avr_builtin_description): Add field n_args. >> (avr_bdesc): New static variable using builtins.def. >> (avr_expand_builtin): Use it. >> Don't call avr_expand_delay_cycles if op0 is not CONST_INT. >> (avr_fold_builtin): Fold AVR_BUILTIN_SWAP. >> Don't fold AVR_BUILTIN_INSERT_BITS if arg0 is not INTEGER_CST. > > Approved. Denis.
Re: Ping #1: [Patch,AVR] Fix/hack around spill fail ICE PR52148
2012/2/24 Georg-Johann Lay : > http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00956.html > > Georg-Johann Lay wrote: >> Spill failure PR52148 occurs for movmem insn that allocates 2 of AVR's 3 >> pointer registers. Register allocator is at it's limits and the patch tries >> to >> cure the situation by replacing >> >> (match_operand:HI 0 "register_operand" "x") >> >> with explicit >> >> (reg:HI REG_X) >> >> and similar for Z Register classes "x" and "z" contain only one HI register. >> >> This PR and PR50925 show that register allocator has some problems. >> Even though this patch is not a fix of the root cause, it allows the PR's >> test >> case to compile. >> >> Anyways, the patch simplifies the backend and replaces an insn with 11(!) >> operands with an insn with only 2 operands so that the patch is improvement >> of >> the backend. >> >> The hard registers are already known at expand time so there is no need for >> match_operands. >> >> Passes without regression. >> >> Ok for trunk? >> >> Johann >> >> PR target/52148 >> * config/avr/avr.md (movmem_): Replace match_operand that >> match only one single hard register with respective hard reg rtx. >> (movmemx_): Ditto. >> * config/avr/avr.c (avr_emit_movmemhi): Adapt expanding to new >> insn anatomy of movmem[x]_. >> (avr_out_movmem): Same for printing assembler and operand usage. Approved. Denis. PS: I have not understood this patch from first look
Re: PATCH: PR target/52352: [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
On Fri, Feb 24, 2012 at 9:19 PM, H.J. Lu wrote: > This patches enables *movabs_1 and *movabs_2 only for > TARGET_LP64 since x32 doesn't need 64bit address. OK for trunk? > > Thanks. > > H.J. > --- > 2012-02-24 H.J. Lu > > PR target/52352 > * config/i386/i386.md (*movabs_1): Enable only for > TARGET_LP64. > (*movabs_2): Likewise. OK. Thanks, Uros.
Re: [PATCH 1/2] mips: Add R4600 scheduling support for imul and idiv
Matt Turner writes: > The r4600_imul and r4600_idiv reservations were correct for si, but > there were no *_di reservations. > > See page 4 of > http://www.sgistuff.net/hardware/other/documents/R4600_Prod_OV.pdf > > 2012-02-24 Matt Turner > > * config/mips/4600.md (r4600_imul_si): Rename from r4600_imul. > (r4600_imul_di): New. > (r4600_idiv_si): Rename from r4600_idiv. > (r4600_idiv_di): New. Both patches look good, thanks. Will commit once 4.8 is open and the copyright assignment is sorted. Richard
