On 11/06/2014 08:44 AM, Zhenqiang Chen wrote:
> Hi,
>
> The patch add runtime check to fix s390 build fail
> (https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00050.html).
>
> And there is additional code to workaround s390 cstorecc4 issue.
>
> Bootstrap and no make check regression on X86-64.
> Bu
> + /* Generate insn to match ccmp_and/ccmp_ior. */
> + target = gen_rtx_REG (mode, CC_REGNUM);
> + emit_insn (gen_rtx_SET (VOIDmode, target,
> + gen_rtx_fmt_ee (COMPARE, VOIDmode,
> + bit_op, const0_rtx)));
Invalid mode for the
On 11/06/2014 01:48 PM, Alan Modra wrote:
> On Thu, Nov 06, 2014 at 07:59:16AM +0100, Richard Henderson wrote:
>> I haven't done powerpc yet. If you'd like to help, I'd be delighted.
>
> I was going to say that it doesn't look too difficult, but then I
> no
On 11/06/2014 02:10 PM, Lynn A. Boger wrote:
> Aren't there cases where the static chain register is needed? How does that
> work if it could be trashed on a plt call?
No. At the moment the static chain is only used for nested functions, which
are local to the translation unit, and are therefore
On 11/06/2014 06:45 PM, Ian Taylor wrote:
> On Thu, Nov 6, 2014 at 5:04 AM, Richard Henderson wrote:
>>
>> That said, this *may* not actually be a problem. It's not the direct
>> (possibly
>> lazy bound) call into libffi that needs a static chain, it's
On 11/06/2014 05:10 PM, Ulrich Weigand wrote:
>>> +/* For s390, CC REG is general_operand. But cstorecc4
>>> only
>>> + handles CCZ1, which can not handle others like CCU.
>>> */
>>> + || GET_MODE_CLASS (GET_MODE (XEXP (cond, 0))) == MODE_CC);
>>>
>>
On 11/06/2014 09:24 PM, Andrew Waterman wrote:
> 2014-10-23 Andrew Waterman
>
> * cas_n.c (libat_compare_exchange): Add missing cast.
Ok.
r~
On 11/07/2014 01:02 PM, Ramana Radhakrishnan wrote:
> + *cost = COSTS_N_INSNS (aarch64_internal_mov_immediate
> + (gen_rtx_REG (mode, 0), x, false));
> }
Can't you pass NULL for the register when generate is false?
r~
On 11/12/2014 11:01 AM, Yangfei (Felix) wrote:
> +(define_expand "doloop_end"
>> + [(use (match_operand 0 "" "")) ; loop pseudo
>> + (use (match_operand 1 "" ""))] ; label
>> + ""
>> + "
>> +{
Drop the "" surrounding the { }.
r~
LGTM.
On 8/30/19 2:31 AM, Stafford Horne wrote:
> Hello, any comments on this?
>
> If nothing I will commit in a few days.
>
> On Thu, Aug 22, 2019 at 08:44:04PM +0900, Stafford Horne wrote:
>> When compiling glibc we found that the GOT register was being allocated
>> r9 when the instruction was
On 9/5/19 3:00 AM, Kyrill Tkachov wrote:
>> +/* Define the symbol gating the LSE implementations. */
>> +extern _Bool __aa64_have_atomics
>> + __attribute__((visibility("hidden"), nocommon));
>> +
>
> Bootstrapping this patch series on an Armv8-A system with OOL atomics enabled
> by default ga
On 9/5/19 2:56 AM, Kyrill Tkachov wrote:
> On 11/1/18 9:46 PM, Richard Henderson wrote:
>> + else if (TARGET_ATOMIC_OOL)
>> + {
>> + /* Oldval must satisfy compare afterward. */
>> + if (!aarch64_plus_operand (oldval, mode))
>> +
On 9/5/19 10:35 AM, Wilco Dijkstra wrote:
> Agreed. I've got a couple of general comments:
>
> * The option name -matomic-ool sounds too abbreviated. I think eg.
> -moutline-atomics is more descriptive and user friendlier.
Changed.
> * Similarly the exported __aa64_have_atomics variable could be
On 9/17/19 6:55 AM, Wilco Dijkstra wrote:
> Hi Kyrill,
>
>>> When you select a CPU the goal is that we optimize and schedule for that
>>> specific microarchitecture. That implies using atomics that work best for
>>> that core rather than outlining them.
>>
>> I think we want to go ahead with this
-linux on a thunder x1.
I have not run tests on any platform supporting LSE, even qemu.
r~
Richard Henderson (6):
aarch64: Extend %R for integer registers
aarch64: Implement TImode compare-and-swap
aarch64: Tidy aarch64_split_compare_and_swap
aarch64: Add out-of-line functions for LSE
* config/aarch64/aarch64.c (aarch64_print_operand): Allow integer
registers with %R.
---
gcc/config/aarch64/aarch64.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 232317d4a5a..9
With aarch64_track_speculation, we had extra code to do exactly what the
!strong_zero_p path already did. The rest is reducing code duplication.
* config/aarch64/aarch64 (aarch64_split_compare_and_swap): Disable
strong_zero_p for aarch64_track_speculation; unify some code paths;
This is the libgcc part of the interface -- providing the functions.
Rationale is provided at the top of libgcc/config/aarch64/lse.S.
* config/aarch64/lse-init.c: New file.
* config/aarch64/lse.S: New file.
* config/aarch64/t-lse: New file.
* config.host: Add t-lse
---
gcc/common/config/aarch64/aarch64-common.c | 6 --
gcc/config/aarch64/aarch64.c | 6 --
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/gcc/common/config/aarch64/aarch64-common.c
b/gcc/common/config/aarch64/aarch64-common.c
index 07c03253951..2bbf454eea9 1
This pattern will only be used with the __sync functions, because
we do not yet have a bare TImode atomic load.
* config/aarch64/aarch64.c (aarch64_gen_compare_reg): Add support
for NE comparison of TImode values.
(aarch64_emit_load_exclusive): Add support for TImode.
* config/aarch64/aarch64.opt (-moutline-atomics): New.
* config/aarch64/aarch64.c (aarch64_atomic_ool_func): New.
(aarch64_ool_cas_names, aarch64_ool_swp_names): New.
(aarch64_ool_ldadd_names, aarch64_ool_ldset_names): New.
(aarch64_ool_ldclr_names, aarch64_o
On 9/18/19 5:58 AM, Kyrill Tkachov wrote:
> Thanks for this.
>
> I've bootstrapped and tested this patch series on systems with and without LSE
> support, both with and without patch [6/6], so 4 setups in total.
>
> It all looks clean for me.
>
> I'm favour of this series going in (modulo patch
As diagnosed in the PR.
* config/aarch64/lse.S (LDNM): Ensure STXR output does not
overlap the inputs.
---
libgcc/config/aarch64/lse.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libgcc/config/aarch64/lse.S b/libgcc/config/aarch64/lse.S
index a5f6673596
Tested on aarch64-linux (glibc) and aarch64-elf (installed newlib).
The existing configure claims to be generated by 2.69, but there
are changes wrt the autoconf distributed with Ubuntu 18. Nothing
that seems untoward though.
r~
* config/aarch64/lse-init.c: Include auto-target.h. Dis
Ping.
On 10/2/18 9:19 AM, Richard Henderson wrote:
> Changes since v1:
> * Use config/t-slibgcc-libgcc instead of gcc.c changes.
> * Some style fixes.
> * Ifdefs to work with old glibc.
>
> * Force TImode registers into even regnos.
> Required by CASP, allowed by
Ping 2.
On 10/11/18 6:33 PM, Richard Henderson wrote:
> Ping.
>
> On 10/2/18 9:19 AM, Richard Henderson wrote:
>> Changes since v1:
>> * Use config/t-slibgcc-libgcc instead of gcc.c changes.
>> * Some style fixes.
>> * Ifdefs to work with old glibc.
>
On 10/27/18 5:37 AM, Stafford Horne wrote:
> +/* Here _init and _fini are empty because .init_array/.fini_array are used
> + exclusively. However, the functions are still needed as required when
> + linking. */
> + .align 4
> + .global _init
> + .type _init,@function
> +_init:
>
On 10/27/18 5:37 AM, Stafford Horne wrote:
> -mm-dd Stafford Horne
> Richard Henderson
>
> gcc/testsuite/ChangeLog:
>
> * gcc.c-torture/execute/20101011-1.c: Adjust for OpenRISC.
> * gcc.dg/20020312-2.c: Likewise.
> * gcc.dg/attr-a
On 10/27/18 5:36 AM, Stafford Horne wrote:
> Changes Since v2:
> - Add RTEMS patches from Joel Sherrill
> - Disable t-softfp-excl as suggsted by Joseph Myers
> - Add new architecture flags needed to run on real FPGA's found in testing
>* -mror - enable l.ror (rotate right)
>* -mshftimm -
On 10/27/18 5:37 AM, Stafford Horne wrote:
> +(define_insn "zero_extendhisi2"
> + [(set (match_operand:SI 0 "register_operand""=r,r")
> + (zero_extend:SI (match_operand:HI 1 "nonimmediate_operand" "r,m")))]
> + ""
> + "@
> + l.exthz\t%0, %1
> + l.lhz\t%0, %1"
> + [(s
On 10/28/18 2:57 AM, Segher Boessenkool wrote:
>> +(define_insn "xorsi3"
>> + [(set (match_operand:SI 0 "register_operand" "=r,r")
>> + (xor:SI
>> + (match_operand:SI 1 "register_operand" "%r,r")
>> + (match_operand:SI 2 "reg_or_s16_operand" " r,I")))]
>> + ""
>> + "@
>> + l.
On 10/29/18 10:31 AM, Sam Tebbs wrote:
> On 10/23/2018 02:50 PM, Richard Earnshaw (lists) wrote:
>
>> On 22/10/2018 10:02, Sam Tebbs wrote:
>>> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
>>> index
>>> d7473418a8eb62b2757017cd1675493f86e41ef4..77e6f75cc15f06733df7b4
On 10/29/18 4:34 PM, Segher Boessenkool wrote:
> Is there some better documentation available? This is what google found
> for me. I would have like better docs (more compact, etc.) Links to
> such would be great to have in readings.html :-)
https://openrisc.io/architecture
and especially the
On 10/30/18 12:18 PM, Stafford Horne wrote:
> OK, I was just being lazy allowing the spill. Do you think the split/expand
> would be an RTL using left shift / right shift? Can you think of something
> more clever? Since "real" hardware does not usually support shifts with an
> immediate we will
On 10/30/18 7:48 PM, James Greenhalgh wrote:
> On Tue, Oct 02, 2018 at 11:19:05AM -0500, Richard Henderson wrote:
>> The cas insn is a single insn, and if expanded properly need not
>> be split after reload. Use the proper inputs for the insn.
>
> OK.
Thanks. Committed 1-4 & 9.
r~
On 10/30/18 8:32 PM, James Greenhalgh wrote:
> On Tue, Oct 02, 2018 at 11:19:09AM -0500, Richard Henderson wrote:
>> When the result of an operation is not used, we can ignore the
>> result by storing to XZR. For two of the memory models, using
>> XZR with LD has a preferre
On 10/30/18 8:32 PM, James Greenhalgh wrote:
> On Tue, Oct 02, 2018 at 11:19:09AM -0500, Richard Henderson wrote:
>> When the result of an operation is not used, we can ignore the
>> result by storing to XZR. For two of the memory models, using
>> XZR with LD has a preferre
Ping for rtl, middle-end, or global reviewers.
r~
On 10/2/18 5:19 PM, Richard Henderson wrote:
> * optabs-libfuncs.c (build_libfunc_function_visibility):
> New, split out from...
> (build_libfunc_function): ... here.
> (init_one_libfunc_visibility): New, sp
On 10/31/18 3:04 PM, Will Deacon wrote:
> The example test above uses relaxed atomics in conjunction with an acquire
> fence, so I don't think we can actually use ST at all without a change
> to the language specification. I previouslyyallocated P0861 for this purpose
> but never got a chance to wr
On 10/31/18 5:32 PM, Eric Botcazou wrote:
>> * optabs-libfuncs.c (build_libfunc_function_visibility):
>> New, split out from...
>> (build_libfunc_function): ... here.
>> (init_one_libfunc_visibility): New, split out from ...
>> (init_one_libfunc): ... here.
>
> Either that
it does, thanks. Lest this come up again, let's document this.
r~
>From 804f690fc8ebaa436b97ea4c9fef830f9cd2b873 Mon Sep 17 00:00:00 2001
From: Richard Henderson
Date: Wed, 19 Sep 2018 22:18:09 +
Subject: [PATCH] aarch64: Remove early clobber from ATOMIC_LDOP scratch
* config/aa
On 10/31/18 10:02 AM, Richard Henderson wrote:
> On 10/30/18 7:48 PM, James Greenhalgh wrote:
>> On Tue, Oct 02, 2018 at 11:19:05AM -0500, Richard Henderson wrote:
>>> The cas insn is a single insn, and if expanded properly need not
>>> be split after reload. Use the
From: Richard Henderson
With aarch64_track_speculation, we had extra code to do exactly what the
!strong_zero_p path already did. The rest is reducing code duplication.
* config/aarch64/aarch64 (aarch64_split_compare_and_swap): Disable
strong_zero_p for
From: Richard Henderson
This pattern will only be used with the __sync functions, because
we do not yet have a bare TImode atomic load.
* config/aarch64/aarch64.c (aarch64_gen_compare_reg): Add support
for NE comparison of TImode values.
(aarch64_emit_load_exclusive
From: Richard Henderson
* config/aarch64/aarch64.c (aarch64_print_operand): Allow integer
registers with %R.
---
gcc/config/aarch64/aarch64.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64
From: Richard Henderson
Changes since v2:
* Committed half of the patch set.
* Split inline TImode support from out-of-line patches.
* Removed the ST out-of-line functions, to match inline.
* Moved the out-of-line functions to assembly.
What I have not done, but is now a possibility, is
Do Not Merge Upstream.
This is for agraf and his testing within SLES.
---
gcc/common/config/aarch64/aarch64-common.c | 6 --
gcc/config/aarch64/aarch64.c | 6 --
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/gcc/common/config/aarch64/aarch64-common.c
b/gcc/c
This is the libgcc part of the interface -- providing the functions.
Rationale is provided at the top of libgcc/config/aarch64/lse.S.
* config/aarch64/lse-init.c: New file.
* config/aarch64/lse.S: New file.
* config/aarch64/t-lse: New file.
* config.host: Add t-lse
* config/aarch64/aarch64.opt (-matomic-ool): New.
* config/aarch64/aarch64.c (aarch64_atomic_ool_func): New.
(aarch64_ool_cas_names, aarch64_ool_swp_names): New.
(aarch64_ool_ldadd_names, aarch64_ool_ldset_names): New.
(aarch64_ool_ldclr_names, aarch64_ool_ld
On 11/4/18 9:05 AM, Stafford Horne wrote:
> I have had some inqueries into helping
> bootstrap some linux nommu machines.
For nommu, we'd need to implement an FDPIC ABI.
Otherwise, code segments cannot be mapped separately
from data segments. I believe that the arm (32bit)
port has recently adde
On 11/6/18 9:21 PM, Stafford Horne wrote:
> As you can see this is v4 of the OpenRISC port patch series, I just want to
> mention that there are a few things pointed out during the v3 review that I
> have
> not fixed, and do not plan before pushing upstream. These are either because
> I
> didn't
Ping.
On 11/1/18 10:46 PM, Richard Henderson wrote:
> From: Richard Henderson
>
> Changes since v2:
> * Committed half of the patch set.
> * Split inline TImode support from out-of-line patches.
> * Removed the ST out-of-line functions, to match inline.
> *
On 11/13/18 5:38 PM, Peter Bergner wrote:
> On 11/13/18 2:53 AM, Eric Botcazou wrote:
>>> +static rtx
>>> +simple_move_operator (rtx x)
>>> +{
>>> + /* A word sized rotate of a register pair is equivalent to swapping
>>> + the registers in the register pair. */
>>> + if (GET_CODE (x) == ROTA
On 11/13/18 10:28 AM, Jakub Jelinek wrote:
> - [(match_operand:GPI 2 "aarch64_plus_operand" "rn") ;; expect
> + [(match_operand:GPI 2 "aarch64_plus_operand" "rIJ");; expect
Ah, yes. That's my bug. There is a similar one just above wrt
aarch64_compare_and_swap, and that one need
On 7/3/19 5:43 PM, Segher Boessenkool wrote:
>> @@ -212,6 +214,7 @@ enum reg_class
>> #define REG_CLASS_CONTENTS \
>> { { 0x, 0x }, \
>>{ SIBCALL_REGS_MASK, 0 }, \
>> + { 0x7efe, 0x }, \
>
> Above you said r0, r30, r31 are excluded, but t
> +#define ASM_LONG "\t.long\t"
Do not replicate targetm.asm_out.aligned_op.si, or integer_asm_op, really.
> +aarch64_file_end_indicate_exec_stack ()
> +{
> + file_end_indicate_exec_stack ();
> +
> + if (!aarch64_bti_enabled ()
> + && aarch64_ra_sign_scope == AARCH64_FUNCTION_NONE)
> +
On 4/1/19 8:53 PM, Sudakshina Das wrote:
>> This could stand to use a comment, a moment's thinking about the sizes, and
>> to
>> use the existing asm output functions.
>>
>> /* PT_NOTE header: namesz, descsz, type.
>> namesz = 4 ("GNU\0")
>> descsz = 12 (see below)
> I was try
On 4/3/19 5:19 PM, Sudakshina Das wrote:
> + /* PT_NOTE header: namesz, descsz, type.
> + namesz = 4 ("GNU\0")
> + descsz = 16 (Size of the program property array)
> + type = 5 (NT_GNU_PROPERTY_TYPE_0). */
> + assemble_align (POINTER_SIZE);
> + assemble_integer (GEN
On 09/02/2016 02:35 AM, Uros Bizjak wrote:
> --q--
> /* Pass float and _Complex float variable arguments by reference.
> This avoids 64-bit store from a FP register to a pretend args save area
> and subsequent 32-bit load from the saved location to a FP register.
>
> Note that 32-
On 06/02/2016 03:23 PM, cheng...@emindsoft.com.cn wrote:
fprintf (file,
+ "\t{\n"
+ "\taddi\tsp, sp, -8\n"
+ "\tst\tsp, r10\n"
+ "\t}\n"
"\t{\n"
You need only do this if cfun->static_chain_decl is set.
r~
Shawcroft
aarch64 port Richard Earnshaw
-alpha port Richard Henderson
+alpha port Richard Henderson
arc port Joern Rennecke
arm port Nick Clifton
arm port Richar
Thanks to Alexey Neyman for reminding me that I've had this patch
outstanding in my tree for two months.
Re-tested and committed.
r~
* config/alpha/t-alpha (CRTSTUFF_T_CFLAGS): New.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@248522
138bc75d-0d04-0410-961f-82ee72b054a4
---
libgc
On 01/11/2017 06:30 PM, Palmer Dabbelt wrote:
+/* The largest number of operations needed to load an integer constant.
+ The worst case is LUI, ADDI, SLLI, ADDI, SLLI, ADDI, SLLI, ADDI,
+ but we may attempt and reject even worse sequences. */
+#define RISCV_MAX_INTEGER_OPS 32
Why would you
On 01/11/2017 06:30 PM, Palmer Dabbelt wrote:
+(define_register_constraint "f" "TARGET_HARD_FLOAT ? FP_REGS : NO_REGS"
+ "A floating-point register (if available).")
+
I know this is the Traditional Way, but I do wonder if using the new enable
attribute on the alternatives would be better. N
On 01/17/2017 01:16 PM, Andrew Waterman wrote:
We went with the /libXX/YY/ approach because, on a multilib system,
the system libraries also need to be distinguished by ABI. It seemed
most natural to us to handle ld.so and e.g. libc.so in a consistent
manner. However, something along the lines
On 01/11/2017 06:30 PM, Palmer Dabbelt wrote:
+__riscv_save_12:
+ addi sp, sp, -112
+ li t1, 0
+ sd s11, 8(sp)
+ j .Ls10
+
+__riscv_save_11:
+__riscv_save_10:
+ addi sp, sp, -112
+ li t1, -16
No unwind info?
r~
On 03/21/2017 07:15 AM, Jakub Jelinek wrote:
Not really sure what we should do if both i1 and i2 are frame related, shall
we check for each of the CFA reg notes if they are available and equal?
Or punt if either of the insns is frame related?
I would punt if either is frame related.
As an asid
On 01/30/2017 04:53 PM, Andrew Waterman wrote:
> The ISA spec references an out-of-date calling convention, and will be
> removed in the next revision to orthogonalize the ABI from the ISA.
> We are in the process of drafting a RISC-V ELF psABI spec, which the
> GCC port targets.
> https://github.c
On 01/30/2017 05:10 PM, Andrew Waterman wrote:
>>> +(define_expand "clear_cache"
>>> + [(match_operand 0 "pmode_register_operand")
>>> + (match_operand 1 "pmode_register_operand")]
>>> + ""
>>> + "
>>> +{
>>> + emit_insn (gen_fence_i ());
>>> + DONE;
>>> +}")
>>
>>
>> Do you need a FENCE bef
On 02/02/2017 01:05 AM, Palmer Dabbelt wrote:
Thanks to everyone who reviewed our original patch set. I've tried to CC
everyone who provided a review, sorry if I missed anyone!
Andrew, Kito and I believe that we've addressed almost all of the feedback from
the reviews of our v1 patch set. Sinc
On 02/03/2017 05:44 AM, Ramana Radhakrishnan wrote:
On 02/02/17 15:21, Torvald Riegel wrote:
On Thu, 2017-02-02 at 14:48 +, Ramana Radhakrishnan wrote:
On 30/01/17 18:54, Torvald Riegel wrote:
This patch fixes the __atomic builtins to not implement supposedly
lock-free atomic loads based o
On 03/06/2016 07:24 PM, Matthias Klose wrote:
On 05.03.2016 19:28, Richard Henderson wrote:
When I went to apply my symbol versioning patch to upstream,
I discovered that upstream had already bumped their soname to
6.4.0, beyond the bump that I'd applied to gcc to 5.0.0.
So I bumped ups
On 03/02/2016 01:31 AM, Richard Biener wrote:
As a general remark I think handling of this simplification is
better done in the reassoc pass (see Jakubs comment #4) given
|| and && associate. So I'd rather go down that route if possible.
This seems to do the trick.
r~
diff --git a/gcc/tests
The problem here is that
void* labels[] = {
&&l0, &&l1, &&l2
};
gets gimplified to
labels = *.LC0;
but .LC0 is not in the set of local decls, so that when copy_forbidden is
called during sra versioning we fail to forbid the copy. We could set a
different flag, but I think it's eas
On 03/15/2016 02:26 AM, Andreas Schwab wrote:
Richard Henderson writes:
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr68714.c
b/gcc/testsuite/gcc.dg/tree-ssa/pr68714.c
new file mode 100644
index 000..741d311
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr68714.c
@@ -0,0 +1,9
On 03/15/2016 07:13 AM, Richard Biener wrote:
On Tue, Mar 15, 2016 at 4:44 AM, Richard Henderson wrote:
The problem here is that
void* labels[] = {
&&l0, &&l1, &&l2
};
gets gimplified to
labels = *.LC0;
but .LC0 is not in the set of local decls, so tha
On 03/10/2016 08:20 PM, DJ Delorie wrote:
I'm moving on to Plan C but I put a copy of the file on
.../dj/foo.c.gz (195Mb) if anyone wants to find out
why there's a 16Gb limit compiling it...
With just the following, we successfully compile your file.
It takes about 25 minutes and memory use to
As discussed in the PR, the fix for 68215 was a bit too aggressive and caused
this one. There's a simple alternate fix, first suggested by Richi in 68714,
that cures both.
Thus I apply one patch and revert another, in order, so that nothing breaks in
between yet keeps the two commits separate
On 03/16/2016 02:40 AM, Richard Biener wrote:
I like patch 2 more - btw, you need to add has_forced_label_in_static streaming
to lto-streamer-{in,out}.c, just look for has_nonlocal_label streaming. Also
has_label_address_in_static_1 is now unused and should be removed.
I'd already found the la
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 bug. However, it's reasonably easy to work around in
This fixes only the regression described in the PR.
There was quite a bit of follow-up that points to new work that ought to be
done during the gcc7 cycle, but isn't really appropriate now.
Tested on aarch64-linux; committed as reviewed in the PR.
r~
PR target/70048
* config/
On 02/29/2016 07:50 AM, Jose E. Marchesi wrote:
> The backtrace(3) implementation for sparc contains a simple unwinder
> that works well in most cases, but that unwinder is not used if
> libgcc_s.so can be dlopened and it provides _Unwind_Backtrace.
There's no reason that simple unwinder can't be
On 03/21/2016 06:40 AM, Jiong Wang wrote:
On 17/03/16 19:17, Richard Henderson wrote:
PR target/70120
* varasm.c (for_each_section): New.
* varasm.h (for_each_section): Declare.
* config/aarch64/aarch64.c (aarch64_align_code_section): New.
(aarch64_asm_file_end): New
I'm not sure why the decl must be left on the local_decl list -- the same decl
ought to also be in the BIND_EXPR for the function. But it's a fact that the
DECL_INITIAL doesn't get processed during clone_body without the local_decl
list processing.
So in the meantime, set the has_forced_label
In PR68142 you added a check for overflow + __INT_MIN__.
I can't figure out why the check for __INT_MIN__, except
that it seems specific to the test case you examined.
And indeed, this test case shows how things go wrong
with other distributed folding leading to overflow.
I added two tests, one s
On 03/23/2016 09:10 PM, Alan Modra wrote:
On Wed, Mar 23, 2016 at 05:04:39PM +0100, Olivier Hainque wrote:
The reason why 894 is not accounted in the base ref computation is because it
is part of the epilogue sequence, and init_alias_analysis has:
/* Walk the insns adding values to the n
The ICE comes fixing up a debug_insn, and the debug info incoming to the pass
seems reasonable. Just recognizing that this situation is possible and not
asserting appears to work.
Ok?
r~
* lower-subreg.c (simplify_subreg_concatn): Reject paradoxical subregs.
diff --git a/gcc/lower-
These two related PRs are all about remembering where a macro is expanded.
Worse, we've got two competing goals -- the real location of the expansion, for
__LINE__, and the virtual location of the expansion, for diagnostics.
There seems to be no way to unify the two competing goals. If we simp
On 04/05/2016 11:03 AM, Manuel López-Ibáñez wrote:
> Why use -ftrack-macro-expansion=0?
That's the point of the PR -- we were producing totally bogus results.
r~
e build.
For aarch64 and alpha, I simply assumed there would be no loss,
since the basic search algorithm is unchanged for each.
Comments? Especially on the shared header?
r~
Cc: David Edelsohn
Cc: Marcus Shawcroft
Cc: Richard Earnshaw
Richard Henderson (15):
rs6000: Split out rs6
This allows testing for a mask without having to call GEN_INT.
Cc: David Edelsohn
---
* config/rs6000/rs6000.c (rs6000_is_valid_mask_wide): Split out from...
(rs6000_is_valid_mask): ... here.
(rs6000_is_valid_and_mask_wide): Split out from...
(rs6000_is_valid_and_m
Cc: David Edelsohn
---
* config/rs6000/rs6000-protos.h (num_insns_constant_wide): Move...
* config/rs6000/rs6000.c: ... prototype here. Make static.
---
gcc/config/rs6000/rs6000-protos.h | 1 -
gcc/config/rs6000/rs6000.c| 3 ++-
2 files changed, 2 insertions(+), 2 deletio
After the fact I noticed this does temporarily remove the
rs6000_is_valid_and_mask test from the DFmode path, but that
will be fixed shortly. And it was missing from the SFmode
path the whole time.
Cc: David Edelsohn
---
* config/rs6000/rs6000.c (num_insns_constant): Share code between
No need to special-case this in several places anymore.
Cc: David Edelsohn
---
* config/rs6000/rs6000.c (num_insns_constant): Remove test
for rs6000_is_valid_and_mask.
(genimm_ppc::exam_mask): New.
(genimm_ppc::exam_search): Use it.
(genimm_ppc::generate):
Save 2 insns for constants like 0x where
the low 32-bits can be replicated to the high 32-bits.
Cc: David Edelsohn
---
* config/rs6000/rs6000.c (genimm_ppc::exam_search): Check for
two equal 32-bit pieces.
(genimm_ppc::generate): Handle VEC_DUPLICATE.
---
Rather than always shift by 32, shift by the total number of zeros required.
The improvement to also look to shift out ones comes from Kenner via alpha.
Cc: David Edelsohn
---
* config/rs6000/rs6000.c (genimm_ppc::exam_search): Use ctz to
compute the shift. Also attempt to shift
Helps for constants like 0xf70008000ul, 0xul,
0x550ful.
There doesn't appear to be any benefit to using xori; every test that
I expected to use it found an alternate solution of the same cost.
Cc: David Edelsohn
---
* config/rs6000/rs6000.c (genimm_ppc::ex
Rather than only consider -1 as a base, consider any negative number.
Cc: David Edelsohn
---
* config/rs6000/rs6000.c (genimm_ppc::exam_search): Attempt to
mask negative numbers.
---
gcc/config/rs6000/rs6000.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/gcc/config/r
Implements basic hashing and minimal cost search, but no real
new optimizations on the constants. That said, there is one
code generation change implied by the searching: we'll find
equal or more efficient alternatives to zero-extending a
32-bit unsigned constant with bit 31 set. E.g.
Helps for constants like 0x3333ul and 0xfffful.
Cc: David Edelsohn
---
* config/rs6000/rs6000.c (genimm_ppc::exam_rotl): New.
(genimm_ppc::exam_search): Use it.
(genimm_ppc::generate): Handle ROTATE.
---
gcc/config/rs6000/rs6000.c | 51
601 - 700 of 2706 matches
Mail list logo
