Adhemerval Zanella writes:
> On 08/08/2016 07:58, Jiong Wang wrote:
>>
>> Adhemerval Zanella writes:
>>
>
> Below it the last iteration patch, however I now seeing some similar issue
> s390 hit when building libgo:
>
> ../../../gcc-git/libgo/go/syscall/socke
Wilco Dijkstra writes:
> Ping
>
> I noticed it would still be a good idea to add an extra barrier in the epilog
> as the
> scheduler doesn't appear to handle aliases of frame accesses properly.
>
> This patch simplifies the handling of the EH return value. We force the use
> of the
> frame poi
On 18/05/16 14:13, Jiong Wang wrote:
On 18/05/16 09:17, Christophe Lyon wrote:
gcc/
2016-05-17 Jiong Wang
* config/aarch64/aarch64-simd.md
(*aarch64_mul3_elt_to_128df): Extend
to all supported modes. Rename to...
(*aarch64_mul3_elt_from_dup): ...this.
gcc
On 27/05/16 14:42, James Greenhalgh wrote:
On Tue, May 24, 2016 at 09:24:03AM +0100, Jiong Wang wrote:
These intrinsics was implemented by inline assembly using "faddp"
instruction.
There was a pattern "aarch64_addpv4sf" which supportsV4SF mode only
while we can
extend thi
On 27/05/16 14:31, James Greenhalgh wrote:
On Tue, May 24, 2016 at 09:23:58AM +0100, Jiong Wang wrote:
These intrinsics were implemented before "fabd_3" introduces.
Meanwhile
the patterns "fabd_3" and "*fabd_scalar3" can be merged into a
single "fabd3&qu
On 27/05/16 14:25, James Greenhalgh wrote:
On Tue, May 24, 2016 at 09:23:53AM +0100, Jiong Wang wrote:
Similar as [3/6], these intrinsics were implemented before the instruction
pattern "aarch64_rsqrts" added, that these intrinsics were implemented
through inline assembly.
This mi
On 27/05/16 14:24, James Greenhalgh wrote:
On Tue, May 24, 2016 at 09:23:48AM +0100, Jiong Wang wrote:
These intrinsics were implemented before the instruction pattern
"aarch64_rsqrte" added, that these intrinsics were implemented through
inline assembly.
This mirgrate the impleme
On 27/05/16 14:03, James Greenhalgh wrote:
On Tue, May 24, 2016 at 09:23:36AM +0100, Jiong Wang wrote:
* config/aarch64/aarch64-simd-builtins.def: Rename to
aarch64-builtins.def.
Why? We already have some number of intrinsics in here that are not
strictly SIMD, but I don&#
n only deals with POP instructions, so talking about PUSH
encodings
is confusing. I suggest you drop point 2).
Thanks, all fixed.
Meanwhile I splitted the comments to keep PUSH part in
arm_attr_length_push_multi.
Patch updated.
OK for trunk?
gcc/
2016-06-02 Jiong Wang
PR target/71061
On 27/05/16 17:52, Jiong Wang wrote:
On 27/05/16 14:03, James Greenhalgh wrote:
On Tue, May 24, 2016 at 09:23:36AM +0100, Jiong Wang wrote:
* config/aarch64/aarch64-simd-builtins.def: Rename to
aarch64-builtins.def.
Why? We already have some number of intrinsics in here
Based on top of [1/6], this patch reimplement vector intrinsics for
conversion between floating-point and fixed-point.
gcc/
2016-06-06 Jiong Wang
* config/aarch64/aarch64-builtins.def (scvtf): Register vector modes.
(ucvtf): Likewise.
(fcvtzs): Likewise.
(fcvtzu
These intrinsics were implemented before the instruction pattern
"aarch64_rsqrte" added, that these intrinsics were implemented through
inline assembly.
This mirgrate the implementation to builtin.
gcc/
2016-06-06 Jiong Wang
* config/aarch64/aarch64-builtins.def (rsqrte): Ne
Similar as [3/6], these intrinsics were implemented before the instruction
pattern "aarch64_rsqrts" added, that these intrinsics were implemented
through inline assembly.
This mirgrate the implementation to builtin.
gcc/
2016-06-06 Jiong Wang
* config/aarch64/aarch64-bu
These intrinsics were implemented before "fabd_3" introduces.
Meanwhile
the patterns "fabd_3" and "*fabd_scalar3" can be merged into a
single "fabd3" using VALLF.
This patch migrate the implementation to builtins backed by this pattern.
gcc/
2016-06-0
These intrinsics was implemented by inline assembly using "faddp" instruction.
There was a pattern "aarch64_addpv4sf" which supportsV4SF mode only while we can
extend this pattern to support VDQF mode, then we can reimplement these
intrinsics through builtlins.
gcc/
20
structions are available, it is otherwise
undefined.
The feature macro __ARM_FEATURE_FP16_VECTOR_ARITHMETIC is defined to
be 1 if the vector FP16 instructions are available, it is otherwise
undefined.
OK for trunk?
Thanks.
2016-06-07 Matthew Wahab
Jiong Wang
* config/aarch
As discussed on the PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70751,
here is the patch.
For this particular failure on arm, *arm_movsi_insn has the following operand
constraints:
operand 0: "=rk,r,r,r,rk,m"
operand 1: "rk, I,K,j,mi,rk"
gcc won't explicitly refuse an unmatch CT_
On 11/05/16 12:52, Jiong Wang wrote:
On 09/05/16 16:08, Segher Boessenkool wrote:
Hi Christophe,
On Mon, May 09, 2016 at 03:54:26PM +0200, Christophe Lyon wrote:
After this patch, I've noticed that
gcc.target/arm/pr43920-2.c
now fails at:
/* { dg-final { scan-assembler-times &q
Segher Boessenkool writes:
> On Tue, Jun 14, 2016 at 03:53:59PM +0100, Jiong Wang wrote:
>> "bl to pop" into "pop" which is "jump to return" into "return", so a better
>> place to fix this issue is at try_optimize_cfg where we are doing the
On 07/06/16 09:46, Jiong Wang wrote:
2016-06-07 Matthew Wahab
Jiong Wang
* config/aarch64/aarch64-arches.def: Add "armv8.2-a".
* config/aarch64/aarch64.h (AARCH64_FL_V8_2): New.
(AARCH64_FL_F16): New.
(AARCH64_FL_FOR_ARC
On 27/06/16 17:26, Dominik Vogt wrote:
On Thu, Jun 09, 2016 at 09:52:39AM -0600, Jeff Law wrote:
On 06/08/2016 10:47 AM, Jiong Wang wrote:
As discussed on the PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70751,
here is the patch.
This commit has introduced an ICE with s390x, march=z13
On 28/06/16 10:51, Jiong Wang wrote:
On 27/06/16 17:26, Dominik Vogt wrote:
On Thu, Jun 09, 2016 at 09:52:39AM -0600, Jeff Law wrote:
On 06/08/2016 10:47 AM, Jiong Wang wrote:
As discussed on the PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70751,
here is the patch.
This commit has
On 28/06/16 11:01, Jiong Wang wrote:
On 28/06/16 10:51, Jiong Wang wrote:
On 27/06/16 17:26, Dominik Vogt wrote:
On Thu, Jun 09, 2016 at 09:52:39AM -0600, Jeff Law wrote:
On 06/08/2016 10:47 AM, Jiong Wang wrote:
As discussed on the PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id
Richard Earnshaw (lists) writes:
> On 29/06/16 09:43, James Greenhalgh wrote:
>> On Mon, Jun 27, 2016 at 03:58:00PM +0100, Jiong Wang wrote:
>>>
>>> The permissible values for @var{arch} are @samp{armv8-a},
>>> -@samp{armv8.1-a} or @var{native}.
>>>
Jiong Wang
include/
* dwarf2.def (DW_CFA_AARCH64_negate_ra_state): New DW_CFA_DUP.
* dwarf2.h (DW_CFA_DUP): New define.
libiberty/
* dwarfnames.c (DW_CFA_DUP): New define.
diff --git a/include/dwarf2.def b/include/dwarf2.def
index a91e9439cd82f3bb9fdddc14904114e5490c1af6
On 10/08/17 17:39, Jiong Wang wrote:
Hi,
A new vendor CFA DW_CFA_AARCH64_negate_ra_state was introduced for
ARMv8.3-A
return address signing, it is multiplexing DW_CFA_GNU_window_save in
CFA vendor
extension space.
This patch adds necessary code to make it available to external, the
2017-08-22 9:18 GMT+01:00 Jiong Wang :
> On 10/08/17 17:39, Jiong Wang wrote:
>>
>> Hi,
>>
>> A new vendor CFA DW_CFA_AARCH64_negate_ra_state was introduced for
>> ARMv8.3-A
>> return address signing, it is multiplexing DW_CFA_GNU_window_save in CFA
>
Jiong Wang writes:
> Jiong Wang writes:
>
>> Jiong Wang writes:
>>
>>> On 16/11/16 14:02, Jakub Jelinek wrote:
>>>> On Wed, Nov 16, 2016 at 02:54:56PM +0100, Mark Wielaard wrote:
>>>>> On Wed, 2016-11-16 at 10:00 +, Jiong Wang wrote:
On 28/12/16 19:54, Cary Coutant wrote:
OK on this proposal and to install this patch to gcc trunk?
Hi GDB, Binutils maintainer:
OK on this proposal and install this patch to binutils-gdb master?
include/
2016-11-29 Richard Earnshaw
Jiong Wang
* dwarf2.def
On 11/11/16 18:22, Jiong Wang wrote:
This patch add command line support for ARMv8.3-A through new architecture:
-march=armv8.3-a
ARMv8.3-A implies all default features of ARMv8.2-A and meanwhile it includes
the new pointer authentication extension.
gcc/
2016-11-08 Jiong Wang
On 11/11/16 18:22, Jiong Wang wrote:
As described in the cover letter, this patch implements return address signing
for AArch64, it's controlled by the new option:
-msign-return-address=[none | non-leaf | all]
"none" means don't do return address signing at all on any
On 11/11/16 18:22, Jiong Wang wrote:
This patch generate DWARF description for pointer authentication. DWARF value
expression is used to describe the authentication action.
Please see the cover letter and AArch64 DWARF specification for the semantics
of AArch64 DWARF operations.
When
On 11/11/16 18:22, Jiong Wang wrote:
This patch add AArch64 specific runtime EH unwinding support for
DW_OP_AARCH64_pauth, DW_OP_AARCH64_paciasp and DW_OP_AARCH64_paciasp_deref.
The semantics of them are described at the specification in patch [1/9].
The support includes:
* Parsing these
On 11/11/16 18:22, Jiong Wang wrote:
We need customized EH unwinder support for AArch64 DWARF operations introduced
earlier in this patchset, these changes mostly need to be done in the generic
file unwind-dw2.c.
There are two ways of introducing these AArch64 support:
* Introducing a few
On 11/11/16 18:22, Jiong Wang wrote:
This patch implements a few ARMv8.3-A new builtins for pointer sign and
authentication instructions.
Currently, these builtins are supposed to be used by libgcc EH unwinder
only. They are not public interface to external user.
OK to install?
gcc/
2016-11
On 06/01/17 11:47, Jiong Wang wrote:
This is the update on libgcc unwinder support according to new DWARF
proposal.
As Joseph commented, duplication of unwind-dw2.c is not encouraged in
libgcc,
But from this patch, you can see there are a few places we need to
modify for
AArch64 in unwind
On 13/01/17 16:04, James Greenhalgh wrote:
On Fri, Jan 06, 2017 at 11:47:07AM +, Jiong Wang wrote:
On 11/11/16 18:22, Jiong Wang wrote:
gcc/
2017-01-06 Jiong Wang
* config/aarch64/aarch64-opts.h (aarch64_function_type): New enum.
* config/aarch64/aarch64-protos.h
On 13/01/17 16:09, Richard Earnshaw (lists) wrote:
On 06/01/17 11:47, Jiong Wang wrote:
This patch is an update on DWARF generation for return address signing.
According to new proposal, we simply needs to generate REG_CFA_WINDOW_SAVE
annotation.
gcc/
2017-01-06 Jiong Wang
On 13/01/17 18:02, Jiong Wang wrote:
On 13/01/17 16:09, Richard Earnshaw (lists) wrote:
On 06/01/17 11:47, Jiong Wang wrote:
This patch is an update on DWARF generation for return address signing.
According to new proposal, we simply needs to generate
REG_CFA_WINDOW_SAVE
annotation.
gcc
On 17/01/17 13:57, Richard Earnshaw (lists) wrote:
On 16/01/17 14:29, Jiong Wang wrote:
I can see the reason for doing this is if you want to seperate the
interpretion
of GCC CFA reg-note and the final DWARF CFA operation. My
understanding is all
reg notes defined in gcc/reg-note.def
On 12/01/17 18:10, Jiong Wang wrote:
On 06/01/17 11:47, Jiong Wang wrote:
This is the update on libgcc unwinder support according to new DWARF proposal.
As Joseph commented, duplication of unwind-dw2.c is not encouraged in libgcc,
But from this patch, you can see there are a few places we need
libgcc,
otherwise
you can't utilize new pointer authentication features.
gcc/
2016-11-11 Jiong Wang
* config/aarch64/aarch64-opts.h (aarch64_stack_protector_type): New
enum.
(aarch64_layout_frame): Swap callees and locals when
-mstack-protector-dialect=
y inline it anyway, but it seems wrong for us to rely on that.
Thanks, fixed.
Does the updated patch looks OK to you know?
libgcc/
2017-01-19 Jiong Wang
* config/aarch64/aarch64-unwind.h: New file.
(DWARF_REGNUM_AARCH64_RA_STATE): Define.
(MD_POST_
On 20/01/17 08:41, Christophe Lyon wrote:
Hi Jiong,
On 19 January 2017 at 15:46, Jiong Wang wrote:
Thanks for the review.
On 19/01/17 14:18, Richard Earnshaw (lists) wrote:
diff --git a/libgcc/unwind-dw2.c b/libgcc/unwind-dw2.c
index
8085a42ace15d53f4cb0c6681717012d906a6d47
On 20/01/17 10:11, Christophe Lyon wrote:
/tmp/8132498_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgcc/unwind-dw2.c:
In function 'execute_cfa_program':
/tmp/8132498_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgcc/unwind-dw2.c:1193:17:
error: 'DWARF_REGNUM_AARCH64_RA_STATE' undeclared (
On 20/01/17 03:39, Andrew Pinski wrote:
On Fri, Jan 6, 2017 at 3:47 AM, Jiong Wang wrote:
On 11/11/16 18:22, Jiong Wang wrote:
As described in the cover letter, this patch implements return address
signing
for AArch64, it's controlled by the new option:
-msign-return-address=
the attached patch as obvious, once I finished a fresh
bootstrap, cross elf, cross linux.
Thanks.
libgcc/
2017-01-20 Jiong Wang
* config/aarch64/linux-unwind.h: Always include aarch64-unwind.h.
diff --git a/libgcc/config/aarch64/linux-unwind.h b/libgcc/config/aarch64/linux-
On 20/01/17 11:15, Jiong Wang wrote:
On 20/01/17 03:39, Andrew Pinski wrote:
On Fri, Jan 6, 2017 at 3:47 AM, Jiong Wang
wrote:
On 11/11/16 18:22, Jiong Wang wrote:
As described in the cover letter, this patch implements return address
signing
for AArch64, it's controlled by th
make sure they strictly follow the C
prototype. I also borrow the type define in ARM backend
typedef unsigned _uw64 __attribute__((mode(__DI__)));
And this is need to type cast the salt value which is always DImode.
It passed my local ILP32 cross build.
OK for trunk?
gcc/
2017-01-20 Jiong Wa
On 20/01/17 18:23, Jiong Wang wrote:
OK, the attached patch disable the building of pointer signing code in
libgcc
on ILP32 mode, except the macro bit RA_A_SIGNED_BIT is still defined as I
want to book this bit for ILP32 as LP64 in case we later enable ILP32
support.
All pauth builtins
On 24/01/17 18:05, Adhemerval Zanella wrote:
On 03/01/2017 13:13, Wilco Dijkstra wrote:
+ /* If function uses stacked arguments save the old stack value so morestack
+ can return it. */
+ reg11 = gen_rtx_REG (Pmode, R11_REGNUM);
+ if (cfun->machine->frame.saved_regs_size
+ || cfun
Hi all,
This patch adds a short entry for the -march=armv8.3-a and -msign-return-address= options
in GCC 7 to the "AArch64" section.
Eyeballed the result in Firefox.
Ok to commit?
Thanks,
Jiong
Index: gcc-7/changes.html
===
RCS f
On 02/02/17 13:31, Gerald Pfeifer wrote:
On Thu, 2 Feb 2017, Jiong Wang wrote:
This patch adds a short entry for the -march=armv8.3-a and
-msign-return-address= options in GCC 7 to the "AArch64" section.
Thanks, Jiong.
Index: gcc-7/ch
On 06/02/17 15:26, Jan Hubicka wrote:
I think it is not a regression, just the testcase if fragile and depends on
outcome
of ifcombine. It seems it was updated several time in the past. I am not quite
sure what the test is testing.
They are tring to make sure optimal stack adjustment decision
On 18/01/17 17:10, Jiong Wang wrote:
aarch64 cross check OK with the following options enabled on all testcases.
-fstack-protector-all -mstack-protector-pauth
OK for trunk?
gcc/
2017-01-18 Jiong Wang
* config
On 15/02/17 15:45, Richard Earnshaw (lists) wrote:
On 18/01/17 17:10, Jiong Wang wrote:
NOTE, this approach however requires DWARF change as the original LR
is signed,
the binary needs new libgcc to make sure c++ eh works correctly.
Given this
acceleration already needs the user specify
he issue. I don't happen to
have one that old to just test on.
I am seeing this failure on arm and aarch64 bare-metal environment where newlib
are used.
This patch also XFAIL this testcase on newlib.
OK for trunk?
Regards,
Jiong
gcc/testsuite/
2017-03-10 Jiong Wang
* g++.dg/tls
On 10/03/17 15:26, Segher Boessenkool wrote:
On Fri, Mar 10, 2017 at 01:57:31PM +0100, Rainer Orth wrote:
I just noticed that nothing has happened at all in a month, so anything
is better than the tests XPASSing on a number of targets.
So the patch is ok for mainline with sparc*-*-* added to th
On 15/03/17 15:34, Rainer Orth wrote:
Hi Jiong,
Subject: [PATCH] testsuite, 79356
As stated in the PR (and elsewhere), this test now passes on aarch64,
ia64, mips, powerpc, sparc, and s390x. This patch disables the xfails
for those targets.
gcc/testsuite/
PR testsuite/79356
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.
(TARGET_ASM_FILE_END): Redefin
Richard Henderson writes:
> 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/
On 19/04/16 03:54, Vladimir N Makarov wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70689
The patch was successfully tested and bootstrapped on x86/x86-64.
Committed to the trunk as rev. 235184.
This caused the following regression on trunk
FAIL: gcc: gcc
On 21/04/16 09:45, Jiong Wang wrote:
On 19/04/16 03:54, Vladimir N Makarov wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70689
The patch was successfully tested and bootstrapped on x86/x86-64.
Committed to the trunk as rev. 235184.
This caused the
Linux distro like
Fedora doesn't enable this, this is why we caught it.
The copy-and-clear test shows it improves by 50%.
Ran all testsuites on Linux-x64.
2016-09-13 Cong Wang
PR libstdc++/77582
* libstdc++-v3/include/bits/basic_string.h: Change inline to a declaration.
* libstdc
On Wed, Sep 14, 2016 at 4:06 AM, Jonathan Wakely wrote:
> On 13/09/16 11:02 -0700, Cong Wang wrote:
>>
>> In !_GLIBCXX_USE_CXX11_ABI implementation, string::clear() calls
>> _M_mutate(), which could allocate memory as we do COW. This hurts
>> performance when string:
On Wed, Sep 14, 2016 at 10:28 AM, Jonathan Wakely wrote:
> On 14/09/16 09:09 -0700, Cong Wang wrote:
>>
>> On Wed, Sep 14, 2016 at 4:06 AM, Jonathan Wakely
>> wrote:
>>>
>>> If I understand the purpose of the change correctly, it's similar to
&g
On Thu, Sep 15, 2016 at 2:08 AM, Jonathan Wakely wrote:
> On 14/09/16 10:41 -0700, Cong Wang wrote:
>>
>> For long term, I think gcc should have something as simple as
>> 'Signed-off-by' for Linux kernel, otherwise too much work for first-time
>> contributors
On Fri, Sep 23, 2016 at 10:25 AM, Jonathan Wakely wrote:
>
> I'm applying this patch, which is my one from 2014 with a check for
> whether the string is shared, so we just set the length to zero (and
> don't throw away reusable capacity) when it's not shared.
>
> Tested x86_64-linux, committed to
0551.
gcc/testsuite/
2016-09-27 Jiong Wang
* lib/target-supports.exp
(check_effective_target_arm_v8_2a_fp16_scalar_hw): Delete redundant
word
in function comment.
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 3d11e2
On 25/07/16 12:26, James Greenhalgh wrote:
On Thu, Jul 07, 2016 at 05:12:48PM +0100, Jiong Wang wrote:
Hello,
As a follow up of
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01240.html,
This patch set adds ARMv8.2-A FP16 scalar and vector intrinsics support,
gcc middle-end will also be aware
On 27/09/16 17:03, Jiong Wang wrote:
>
> Now as ARM patches have gone in around r240427, I have done a quick
confirmation
> on the status of these four pending testsuite patches:
>
> https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00337.html
> https://gcc.gnu.org/ml/g
Hi Adhemerval,
On 06/10/16 22:54, Adhemerval Zanella wrote:
+ bool split_stack_arg_pointer_used = split_stack_arg_pointer_used_p ();
if (flag_stack_usage_info)
current_function_static_stack_size = frame_size;
@@ -3220,6 +3264,10 @@ aarch64_expand_prologue (void)
aarch64_em
are not
changed during insn copy. Redundant code in emit-rtl.c and sel-sched-ir.c are
deleted also.
x86_64/aarch64 bootstrap OK. c/c++ regression OK.
OK for trunk?
gcc/
2016-10-20 Jiong Wang
PR middle-end/78016
* lists.c (alloc_INSN_LIST_bidirection): New function. The
The current code suppose targetm.stack_protect_fail always generate something.
But in case one target start to generate NULL_TREE, there will be ICE. This
patch adds a simple sanity check to only call expand if it's not NULL_TREE.
OK for trunk?
gcc/
2016-10-20 Jiong
2016-10-20 19:50 GMT+01:00 Jeff Law :
>
> On 10/20/2016 09:28 AM, Jiong Wang wrote:
>>
>> The current code suppose targetm.stack_protect_fail always generate
>> something.
>> But in case one target start to generate NULL_TREE, there will be ICE.
>> This
>>
elem, 0, 0));
oprnd1 = INTVAL (XVECEXP (elem, 0, 1));
oprnd2 = INTVAL (XVECEXP (elem, 0, 2));
}
else
call standard RTL parser.
Any comments on the approach?
Thanks.
gcc/
2016-10-20 Jiong Wang
* reg-notes.def (CFA_VAL_EXPRESSION): New entry.
* d
On 21/10/16 08:43, Eric Botcazou wrote:
That's also overcomplicated.
Yes, I agree that's too heavy.
rtx *ptail = ®_NOTES (to_insn);
while (*ptail != NULL_RTX)
ptail = &XEXP (*ptail, 1);
Thanks very much Bernd, yes, this is better. And through manipulating
pointer directly, those bidire
0-21 Bernd Schmidt
Jiong Wang
gcc/
PR middle-end/78016
* emit-rtl.c (emit_copy_of_insn_after): Copy REG_NOTES in order instead
of in reverse order.
* sel-sched-ir.c (create_copy_of_insn_rtx): Likewise.
diff --git a/gcc/emit-rtl.c b/g
On 24/10/16 16:22, Jeff Law wrote:
On 10/20/2016 01:46 PM, Jiong Wang wrote:
2016-10-20 19:50 GMT+01:00 Jeff Law :
On 10/20/2016 09:28 AM, Jiong Wang wrote:
The current code suppose targetm.stack_protect_fail always generate
something.
But in case one target start to generate NULL_TREE
On 21/10/16 09:30, Jiong Wang wrote:
Currently, GCC only support DW_CFA_expression in dwarf module, this patch
extend the support to DW_CFA_val_expression which share the same code
mostly the same code with DW_CFA_expression.
Meanwhile the existed dwarf expression parser only allows expressions
On 21/10/16 13:30, Bernd Schmidt wrote:
On 10/21/2016 02:04 PM, Jiong Wang wrote:
+ /* Locate the end of existing REG_NOTES in NEW_RTX. */
+ rtx *ptail = ®_NOTES (new_rtx);
+ while (*ptail != NULL_RTX)
+ptail = &XEXP (*ptail, 1);
I was thinking along the lines of something like
On 31/10/16 12:10, Kyrill Tkachov wrote:
Ping.
Thanks,
Kyrill
On 24/10/16 12:30, Kyrill Tkachov wrote:
Ping.
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00839.html
Thanks,
Kyrill
On 12/10/16 11:23, Kyrill Tkachov wrote:
Hi all,
I'm looking at the aarch64 prologue and epilogue generation
On 31/10/16 19:50, Jason Merrill wrote:
On 10/21/2016 04:30 AM, Jiong Wang wrote:
All DW_OP_* of the expression are grouped together inside the PARALLEL,
and those operations which don't have RTL mapping are wrapped by
UNSPEC. The parsing algorithm is simply something like:
foreach
On 01/11/16 15:24, Jason Merrill wrote:
On Tue, Nov 1, 2016 at 11:12 AM, Jiong Wang wrote:
On 31/10/16 19:50, Jason Merrill wrote:
On 10/21/2016 04:30 AM, Jiong Wang wrote:
All DW_OP_* of the expression are grouped together inside the PARALLEL,
and those operations which don't hav
On 01/11/16 16:48, Jason Merrill wrote:
On Tue, Nov 1, 2016 at 11:59 AM, Jiong Wang wrote:
On 01/11/16 15:24, Jason Merrill wrote:
On Tue, Nov 1, 2016 at 11:12 AM, Jiong Wang wrote:
On 31/10/16 19:50, Jason Merrill wrote:
On 10/21/2016 04:30 AM, Jiong Wang wrote:
All DW_OP_* of the
xpression note. My worry of conflict
makes no sense.
I updated the patch to put DWARF operation in to UNSPEC number field.
x86-64 bootstrap OK, no regression on gcc/g++.
Please review.
Thanks.
gcc/
2016-11-02 Jiong Wang
* reg-notes.def (CFA_VAL_EXPRESSION): New entry.
On 02/11/16 13:42, Jakub Jelinek wrote:
On Wed, Nov 02, 2016 at 01:26:48PM +, Jiong Wang wrote:
-/* A subroutine of dwarf2out_frame_debug, process a REG_CFA_EXPRESSION note. */
+/* A subroutine of dwarf2out_frame_debug, process a REG_CFA_EXPRESSION note.
*/
Too long line.
Hmm, it
On 03/11/16 12:06, Eric Botcazou wrote:
What's your decision on this?
I think that we ought to standardize on a single order for note copying in the
RTL middle-end and the best way to enforce it is to have a single primitive in
rtlanal.c, with an optional filtering. Bernd's patch is a step
On 03/11/16 13:01, Bernd Schmidt wrote:
Index: gcc/emit-rtl.c
===
--- gcc/emit-rtl.c (revision 241233)
+++ gcc/emit-rtl.c (working copy)
@@ -6169,17 +6169,18 @@ emit_copy_of_insn_after (rtx_insn *insn,
which may be
Andreas Krebbel writes:
> On 06/28/2016 04:16 PM, Jiong Wang wrote:
> ...
>> So my first impression is TARGET_LEGITIMATE_ADDRESS_P on s390 do need a
>> fix here. The following draft patch fix this, my fix may be in
>> correct as normally we will allow illegal
On 29/06/16 22:31, Jiong Wang wrote:
Andreas Krebbel writes:
On 06/28/2016 04:16 PM, Jiong Wang wrote:
...
So my first impression is TARGET_LEGITIMATE_ADDRESS_P on s390 do need a
fix here. The following draft patch fix this, my fix may be in
correct as normally we will allow illegal constant
+1,20 @@
+2016-07-04 Matthew Wahab
+ Jiong Wang
+
+ * config/aarch64/aarch64-arches.def: Add "armv8.2-a".
+ * config/aarch64/aarch64.h (AARCH64_FL_V8_2): New.
+ (AARCH64_FL_F16): New.
+ (AARCH64_FL_FOR_ARCH8_2): New.
+ (AARCH64_ISA_8_2): New.
+ (AARCH64_ISA_F16): New.
+ (TARGET_FP_F16
On 04/07/16 14:12, Bernd Schmidt wrote:
On 06/30/2016 07:24 PM, Jiong Wang wrote:
From my understanding, "offmemok" is used to represent a memory operand
who's address we want to reload, and searching of it's reference
location
seems confirmed my understanding as it&#x
As the request from
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01936.html
This patch replace all use of ARMv8.1 to ARMv8.1-A.
OK for trunk?
2016-07-04 Jiong Wang
gcc/
* config/aarch64/aarch64.h: Rename "ARMv8.1" to "ARMv8.1-A".
* config/aarch64/aarc
On 04/07/16 20:44, Vladimir Makarov wrote:
On 06/30/2016 01:22 PM, Jiong Wang wrote:
Here is the patch,
From my understanding, "offmemok" is used to represent a memory operand
who's address we want to reload, and searching of it's reference location
seems confirmed my u
m*-*-* as ARM hasn't
implemented these intrinsics.
OK for trunk?
2016-07-06 Jiong Wang
gcc/
* config/aarch64/aarch64-simd-builtins.def (smax): Remove float variants.
(smin): Likewise.
(fmax): New entry.
(fmin): Likewise.
* config/aarch64/arm_neon.h (vmaxnm_f32): Use __builtin_aarch64
On 06/07/16 16:55, Christophe Lyon wrote:
On 6 July 2016 at 17:44, Kyrill Tkachov wrote:
Hi all,
On 06/07/16 16:29, James Greenhalgh wrote:
On Wed, Jul 06, 2016 at 02:11:51PM +0100, Jiong Wang wrote:
The current vmaxnm/vminnm float intrinsics are implemented using
__builtin_aarch64_smax
On 07/07/16 12:36, Christophe Lyon wrote:
On 7 July 2016 at 11:16, Jiong Wang wrote:
I was using dg-xfail-if, (the description is still using "marked as
XFAIL"...),
but later found it's actually broken under advsimd-intrinsics, UNRESOLVEDs
are
given at the same time instead
On 07/07/16 15:13, Christophe Lyon wrote:
On 7 July 2016 at 14:54, Jiong Wang wrote:
On 07/07/16 12:36, Christophe Lyon wrote:
On 7 July 2016 at 11:16, Jiong Wang wrote:
I was using dg-xfail-if, (the description is still using "marked as
XFAIL"...),
but later found it's
FP16 intrinsics for AArch64 is superset of
intrinsics for AArch32, so all those intrinsic related testcases,
particularly those under the directory advsimd-intrinsics, are also
appliable to AArch64. This patch set has only included those testcases
that are exclusive for AArch64.
---
Jiong Wang (14
501 - 600 of 1050 matches
Mail list logo
