On Mon, Nov 17, 2014 at 11:39:47PM -0800, Alexey Samsonov wrote:
> > That is not what I think we've agreed on and what is implemented in GCC.
> > -fsanitize-recover only enables recovery of the undefined plus
> > undefined-like sanitizers, in particular it doesn't enable recover from
> > kernel-add
On Mon, Nov 17, 2014 at 10:47 PM, Jakub Jelinek wrote:
>
> On Mon, Nov 17, 2014 at 06:40:00PM -0800, Alexey Samsonov wrote:
> > I've just prepared a patch implementing -fsanitize-recover= in
> > Clang (http://reviews.llvm.org/D6302), writing here to make sure we're
> > on
> > the same page w.r.t.
On 17 Nov 13:32, Richard Biener wrote:
> On Mon, Nov 10, 2014 at 4:48 PM, Ilya Enkovich wrote:
> > Hi,
> >
> > Here is a fix for PR63766. Currently all functions are transformed into
> > SSA before local optimizations and it allows function to be inlined and
> > removed before it goes through l
On Sat, Nov 15, 2014 at 07:46:40AM -0800, Ian Taylor wrote:
> On Thu, Nov 13, 2014 at 2:58 AM, Dominik Vogt wrote:
> > What do you think about the attached patches? They work for me, but I'm
> > not sure whether the patch to go-test.exp is good because I know
> > nothing about tcl.
>
> Looks pla
As for the generated code, I'm at the stage where I can implement the
following: if a single UBSan hander is used to report multiple error
kinds (__ubsan_handle_type_mismatch is used for
-fsanitize=null,alignment,object-size), and these kinds have different
recoverability, then we emit two handler
On Mon, Nov 17, 2014 at 06:40:00PM -0800, Alexey Samsonov wrote:
> I've just prepared a patch implementing -fsanitize-recover= in
> Clang (http://reviews.llvm.org/D6302), writing here to make sure we're
> on
> the same page w.r.t. flag semantics:
>
> * -fsanitize-recover: Enable recovery for all c
On Mon, Nov 17, 2014 at 4:15 PM, Vladimir Makarov wrote:
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63906
>
> LRA rematerialization checks SP offsets at origin and rematerialization
> places when trying to rematerialize an insn. But the offsets are not valid
> if
When I was fixing attribute deprecated for C++ templates, I found it odd
that the source location for the deprecated decl was embedded in the
warning rather than in a separate inform. This patch moves it out.
Tested x86_64-pc-linux-gnu. OK for trunk?
commit 8d6b87fadf0799ec863e2d538fcce713a65
On 11/17/14 08:56, David Edelsohn wrote:
Olivier,
The patch is okay with me, but I cannot approve it.
Maybe Jason, Richard or Jeff can take a look.
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01369.html
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02625.html
Best for Jason, Richard or Jaku
On 11/17/14 19:48, Terry Guo wrote:
Hi there,
This patch documents recent Thumb-1 UAL feature in trunk. Is it OK?
OK.
jeff
On 11/17/14 13:05, Ilya Enkovich wrote:
How comes you emit debug info for functions that do not exist and thus
are never used? Is problem caused by builtins going after
END_CHKP_BUILTINS? Or some info generated for all builtins ignoring
its existence?
IIRC, stabs aren't pruned based on whether
On 11/17/14 13:43, Ilya Enkovich wrote:
I don't fully understand how this problem appears. Is it fully AIX
specific and doesn't affect any other target? May we put all _CHKP
codes to the end of enum and ignore them by AIX? Limiting number of
codes in enum due to restrictions of specific debug
On 11/17/14 18:18, David Edelsohn wrote:
I'll try to make a patch reducing amound of builtin codes to a
required minimum in case it appears to be the best option we have.
I am not a stabstring expert, but the output that I am seeing in
almost every assembler file and the output that is overflo
Hi there,
This patch documents recent Thumb-1 UAL feature in trunk. Is it OK?
BR,
TerryIndex: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
retrieving revision 1.27
diff -u -r1.27 changes.html
--- changes.ht
On 11/17/14 19:06, David Edelsohn wrote:
The following patch seems to allow me to at least build stage1 GCC.
We'll see how far it get through bootstrap and testing. Hopefully it
is a work-around until we find a complete solution.
Thanks, David
Index: tree-core.h
===
Hi Jakub,
I've just prepared a patch implementing -fsanitize-recover= in
Clang (http://reviews.llvm.org/D6302), writing here to make sure we're
on
the same page w.r.t. flag semantics:
* -fsanitize-recover: Enable recovery for all checks enabled by
-fsanitize= which support it.
* -fno-sanitize-rec
On 10/15/2014 11:07 AM, Olivier Hainque wrote:
for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
{
+ enum machine_mode save_mode = targetm.dwarf_frame_reg_mode (i);
+ rtx span;
+ span = targetm.dwarf_register_span (gen_rtx_REG (save_mode, i));
+ if (!span)
+ init_one_
The following patch seems to allow me to at least build stage1 GCC.
We'll see how far it get through bootstrap and testing. Hopefully it
is a work-around until we find a complete solution.
Thanks, David
Index: tree-core.h
===
--- tr
On Mon, 2014-11-17 at 11:06 +0100, Richard Biener wrote:
> On Sat, Nov 15, 2014 at 12:00 PM, David Malcolm wrote:
> > On Thu, 2014-11-13 at 11:45 +0100, Richard Biener wrote:
> >> On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm wrote:
> >> > On Tue, 2014-11-11 at 11:43 +0100, Richard Biener wrote:
On Mon, Nov 17, 2014 at 12:36 PM, Jeff Law wrote:
> On 11/17/14 02:26, Jiong Wang wrote:
>>
>> as Pinski reported at
>>
>>https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01967.html
>>
>> the previosu LR free patch on AArch64 cause one gcc_assert in
>> lra-elimination.c
>>
>> one of the problem i
On Mon, Nov 17, 2014 at 3:43 PM, Ilya Enkovich wrote:
> 2014-11-17 21:41 GMT+03:00 Jeff Law :
>> On 11/17/14 11:22, David Edelsohn wrote:
>>>
>>> However, the patch causes another problem that breaks bootstrap on
>>> AIX. All of the builtins are emitted as an enum in debug information
>>> and the
There are actually two patches needed to port to mainline. I'll send
out the patch tomorrow.
Dehao
On Mon, Nov 17, 2014 at 4:58 PM, Andi Kleen wrote:
> Xinliang David Li writes:
>
>> Ok for now as a workraround, but this is probably not a long term fix.
>
> Is the workaround needed for the main
Xinliang David Li writes:
> Ok for now as a workraround, but this is probably not a long term fix.
Is the workaround needed for the mainline autofdo version too?
-Andi
>
> David
>
>
> On Mon, Nov 17, 2014 at 12:47 PM, Dehao Chen wrote:
>> The patch was updated to ignore comdat einline tuning f
Hello,
Ping for https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00519.html
> Patches posted early enough during Stage 1 and not yet fully reviewed
> may still get in early in Stage 3. Please make sure to ping them
> soon enough.
This patch was initially posted before stage 1 opened... for 4.9. So
Hi,
This patch implements the use phase of indirect-call-topn-profile that
promotes multiple targets of indirect-calls. It addresses pr/45631.
The main idea is to use current speculation framework, with a vector
of direct edges (sorted by the probability). The trick part is the we
have multiple
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63906
LRA rematerialization checks SP offsets at origin and rematerialization
places when trying to rematerialize an insn. But the offsets are not
valid if sp elimination is prohibited (e.g. when alloca is used). Value
o
On Mon, 17 Nov 2014, Ilya Enkovich wrote:
> I don't fully understand how this problem appears. Is it fully AIX
> specific and doesn't affect any other target? May we put all _CHKP
> codes to the end of enum and ignore them by AIX? Limiting number of
It sounds to me like this is actually an AIX
On 11/14/14 10:52, Marek Polacek wrote:
We ICEd when dumping the IPA symbol table when -fsanitize=undefined
and -fdump-ipa-* options were enabled on every testcase where we
sanitized something and thus internal ubsan data have been created.
The problem was that the C++ printer expects a decl as a
On 11/14/14 10:29, Zamyatin, Igor wrote:
On Fri, Nov 14, 2014 at 05:05:57PM +, Zamyatin, Igor wrote:
It is not that easy, -fsanitize=address is not supported everywhere.
Better if you stick it into testsuite/gcc.dg/asan/ No point adding effective-
target ia32/fpic, there is nothing i?86 sp
> New optimization flags and new params need documentation in
> gcc/doc/invoke.texi.
>
Thanks. Added description in invoke.texi. The patch is in trunk.
> The description of the --params suggest they provide fixed values - is
> there no way to autodetect sensible values with a cost-model? I
> ha
On 11/12/14 09:45, Alexander Ivchenko wrote:
Hi,
This patch adds bind_pic_locally to a certain tests that depend on the
availability of functions, declared in them. Those tests fail on
Android (or on any other pic target);
As for gcc/testsuite/g++.dg/fstack-protector-strong.[cC] - this is a
rela
On 11/12/14 08:48, Marat Zakirov wrote:
Hi!
I have a patch which disables -faggressive-loop-optimizations and
-fstrict-overflow when -fsanitize=undefined is switched on. Compiler
with aggressive optimizations may decrease quality of sanitization by
optimistically proposing something it actually
On 11/05/14 09:03, Ilya Tocar wrote:
Ping.
On 20 Oct 19:25, Ilya Tocar wrote:
Same in collect2.
On 09 Oct 15:40, Ilya Tocar wrote:
Ping.
On 29 Sep 18:02, Ilya Tocar wrote:
Hi,
Currently if call to atexit (lto_wrapper_cleanup) fails we
won't report error as we haven't initialized error-repo
On Mon, Nov 17, 2014 at 12:04 PM, Sebastian Pop wrote:
> Andrew Pinski wrote:
>> diff --git a/gcc/config/aarch64/thunderx.md b/gcc/config/aarch64/thunderx.md
>> new file mode 100644
>> index 000..30e4395
>> --- /dev/null
>> +++ b/gcc/config/aarch64/thunderx.md
>> @@ -0,0 +1,260 @@
>> +;; Caviu
Ok for now as a workraround, but this is probably not a long term fix.
David
On Mon, Nov 17, 2014 at 12:47 PM, Dehao Chen wrote:
> The patch was updated to ignore comdat einline tuning for AutoFDO.
> Performance testing is green.
>
> OK for google-4_9?
>
> Thanks,
> Dehao
>
> Index: gcc/auto-pr
On 11/14/14 10:43, Jeff Law wrote:
On 11/14/14 04:09, Bernd Schmidt wrote:
Hi Jakub,
I have some questions about nvptx:
1) you've said that alloca isn't supported, but it seems
Yes, it's unimplemented. There's an internal declaration for it but that
seems to be as far as it goes, and that d
On 11/14/14 11:04, Jeff Law wrote:
On 11/14/14 05:36, Jakub Jelinek wrote:
So, for a warp, if some threads perform one branch of an if and other
threads another one, all threads perform the first one first (with some
maybe not doing anything), then all the threads the others (again, other
threa
We weren't warning properly about deprecated class templates because we
were treating the deprecated attribute as a late template attribute, to
be applied at instantiation time. But it applies to the template
itself, and we should warn about uses of the template as a template
template argument
On 11/15/14 11:34, H.J. Lu wrote:
Hi,
GCC uses xstrndup/xstrdup throughout the source tree and those memory
may not be freed explicitly before exut. LeakSanitizer isn't very
useful here. This patch suppresses LeakSanitizer in bootstrap. OK
for trunk?
This patch isn't sufficient. I got
conf
On 11/16/14 23:31, Zhouyi Zhou wrote:
From: Zhouyi Zhou
In function build_conflict_bit_table, id is set in objects_live before
traversing that sparseset, so the obj is unnessary compared with itself
during the traversing.
The comparing of obj with itself can be avoided by means of moving
sparse
Hi,
this patch makes ipa-cp to handle creation of speculative edges. This is done
same way as in inliner's updating code. ipa-cp culd do more - use speculative
edges instead of paying all the cost to produce a full clone, but I will leave
this to Martin.
I made no attempt to tune the metrics. In
Hi,
this patch fixes the scan patterns for test-cases pr43864-{2,3,4].c.
The patterns matched over several lines, this is fixed in the patch by using
(?n).
Committed as obvious.
Thanks,
- Tom
2014-11-17 Tom de Vries
* gcc.dg/pr43864-2.c: Fix scan-tree-dump-times scan pattern.
* gcc.dg/p
Hi,
this patch adds -ftree-tail-merge to tail-merge testcases.
There is no separate dump for tail-merge, instead the test-cases use
-fdump-tree-pre, so it's not easy to spot that they're tail-merge test-cases.
This patch fixes that by adding an explicit -ftree-tail-merge.
Committed as obviou
2014-11-17 20:36 GMT+00:00 Jeff Law :
> On 11/17/14 02:26, Jiong Wang wrote:
>>
>> as Pinski reported at
>>
>>https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01967.html
>>
>> the previosu LR free patch on AArch64 cause one gcc_assert in
>> lra-elimination.c
>>
>> one of the problem is that gcc_as
On 11/14/14 10:10, Radovan Obradovic wrote:
Thank you for the quick reply.
Please repost after updating to test HAVE_prologue and
HAVE_epilogue and adding a testcase.
I have managed to reproduce the problem on the small test case on
mips32, but the test is architecture independent and should
On 11/14/14 11:25, Bernd Schmidt wrote:
On 11/05/2014 12:17 AM, Jeff Law wrote:
On 11/04/14 14:08, Bernd Schmidt wrote:
On 11/04/2014 10:01 PM, Jeff Law wrote:
Communication between host and GPU is all done via some form of
memcpy,
so I wouldn't expect this to be a problem.
They still need to
On 11/14/14 12:19, Segher Boessenkool wrote:
If the result of combining some insns is a PARALLEL of two SETs, and that
is not a recognised insn, and one of the SETs is dead, combine tries to
use the remaining SET as insn.
This patch changes things around so that the one SET is preferably used,
n
On 13 November 2014 15:32, David Sherwood wrote:
> Hi,
>
> I think that's because Alan Hayward's original patch had a bug in it, which he
> has fixed and should be submitting to gcc patches fairly soon. So it's
> probably
> best waiting until he gets a new patch up I think.
>
I've applied both A
The patch was updated to ignore comdat einline tuning for AutoFDO.
Performance testing is green.
OK for google-4_9?
Thanks,
Dehao
Index: gcc/auto-profile.c
===
--- gcc/auto-profile.c (revision 217523)
+++ gcc/auto-profile.c (working
2014-11-17 21:41 GMT+03:00 Jeff Law :
> On 11/17/14 11:22, David Edelsohn wrote:
>>
>> However, the patch causes another problem that breaks bootstrap on
>> AIX. All of the builtins are emitted as an enum in debug information
>> and the CHKP enums now cause an overflow in the debug data on AIX.
>>
On Mon, Nov 17, 2014 at 12:36 PM, Andi Kleen wrote:
> "H.J. Lu" writes:
>
>> On Wed, Oct 29, 2014 at 11:07 PM, Andi Kleen wrote:
Hmm, can't the insns themselves properly clobber/use memory?
>>>
>>> The transactions don't really use the memory. They just guard it,
>>> like a lock.
>>>
>
On 11/17/14 02:26, Jiong Wang wrote:
as Pinski reported at
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01967.html
the previosu LR free patch on AArch64 cause one gcc_assert in
lra-elimination.c
one of the problem is that gcc_assert is too strict and overkilled some
valid cases.
the purpo
"H.J. Lu" writes:
> On Wed, Oct 29, 2014 at 11:07 PM, Andi Kleen wrote:
>>>
>>> Hmm, can't the insns themselves properly clobber/use memory?
>>
>> The transactions don't really use the memory. They just guard it,
>> like a lock.
>>
>> So the intrinsic doesn't know what memory is used inside the
Jan Hubicka writes:
> the C and C++ languages to support data and task parallelism.
> +New attribute no_reorder prevents reordering of
> selected symbols.
> + This enables to link-time optimize Linux kernel without need to use
> + -fno-toplevel-reorder that disable several
> opt
Trying to establish a constant value for an uninstantiated constexpr
reference is complicated because of temporary binding semantics. Best
to just treat it as value-dependent.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 23fbd2ea665ffbc88722f918d8acc44c70614fc0
Author: Jason Merrill
On 11/17/14 11:55, David Edelsohn wrote:
Recent versions of AIX now have support for DWARF. I don't know if it
has arbitrary length limits like this as well. Adacore has an
implementation and I hope that they will contribute the patch
eventually.
Ah. Good. Though we probably shouldn't depend
2014-11-17 21:22 GMT+03:00 David Edelsohn :
> Ilya,
>
> Thanks for fixing the reference to BNDmode.
>
> However, the patch causes another problem that breaks bootstrap on
> AIX. All of the builtins are emitted as an enum in debug information
> and the CHKP enums now cause an overflow in the debug
Andrew Pinski wrote:
> diff --git a/gcc/config/aarch64/thunderx.md b/gcc/config/aarch64/thunderx.md
> new file mode 100644
> index 000..30e4395
> --- /dev/null
> +++ b/gcc/config/aarch64/thunderx.md
> @@ -0,0 +1,260 @@
> +;; Cavium ThunderX pipeline description
> +;; Copyright (C) 2014 Free Sof
On Nov 17, 2014, at 10:55 AM, David Edelsohn wrote:
>
>> It's unfortunately AIX continues to use stabs rather than an embedded dwarf
>> format. Sigh.
> The other complexity is IBM backported the feature to earlier versions
> of AIX, but there is no major or minor AIX version number that
> defin
On 11/17/14 12:52, Jan Hubicka wrote:
On 11/16/14 13:02, Andi Kleen wrote:
This patch describes some user visible changes that were
added to gcc 5.
Ok to commit?
Yes, this is fine. Thanks,
... which remind me that I also wrote some update that apparently was never
approved
Looks good to m
Hi Maciej,
> -Original Message-
> From: Rozycki, Maciej
> Sent: Monday, November 17, 2014 2:39 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Moore, Catherine; Eric Christopher; Matthew Fortune
> Subject: [PATCH] microMIPS/GCC: Correct 64-bit instruction sizes
>
> Hi,
>
> Noticed in an attempt
> On 11/16/14 13:02, Andi Kleen wrote:
> >
> >This patch describes some user visible changes that were
> >added to gcc 5.
> >
> >Ok to commit?
> Yes, this is fine. Thanks,
... which remind me that I also wrote some update that apparently was never
approved
Index: changes.html
===
On 11/14/14 14:39, Andrew Pinski wrote:
I thought I would mention the addition of the ThunderX AARCH64
processor support to the changes web page.
OK? Tested by looking at the web page with Chrome.
Ok.
jeff
On 11/16/14 13:02, Andi Kleen wrote:
This patch describes some user visible changes that were
added to gcc 5.
Ok to commit?
Yes, this is fine. Thanks,
Jeff
Hi,
Noticed in an attempt to build a 64-bit microMIPS Linux kernel.
None of the 64-bit operations have a short instruction encoding in the
microMIPS instruction set. Despite that our code has been written such
that the presence of a short encoding is assumed for both 32-bit and
64-bit opera
On 11/17/14 03:06, Richard Biener wrote:
Also, presumably if this were merged, it would require a followup with
the gimple to gimple * fixup you wanted? (which we talked about doing as
an early stage3 thing IIRC [1]).
Yeah, that would be nice (to remind people - this is about getting rid
of
On 11/14/14 08:27, David Malcolm wrote:
I just don't like all the as_a/is_a stuff enforced everywhere,
it means more typing, more temporaries, more indentation.
So, as I view it, instead of the checks being done cheaply (yes, I think
the gimple checking as we have right now is very cheap) under
On November 17, 2014 7:38:24 PM CET, Jan Hubicka wrote:
>Hi,
>this patch makes us to store default optimization node same way as we
>stream
>target node. This means that command line options given at compile
>time
>prevail those given at linktime. Previously we sort of combined both.
>
>We still
On Wed, Oct 29, 2014 at 11:07 PM, Andi Kleen wrote:
>>
>> Hmm, can't the insns themselves properly clobber/use memory?
>
> The transactions don't really use the memory. They just guard it,
> like a lock.
>
> So the intrinsic doesn't know what memory is used inside the transaction,
> but the access
Andi Kleen writes:
Ping^2!
> Andi Kleen writes:
>
> Ping!
>
>> From: Andi Kleen
>>
>> xbegin/xend/xabort were missing memory barriers. This can
>> lead to memory operations being moved out of transactions, which would
>> cause unexpected races.
>>
>> Always generate implicit memory barriers fo
On Mon, Nov 17, 2014 at 1:41 PM, Jeff Law wrote:
> On 11/17/14 11:22, David Edelsohn wrote:
>>
>> However, the patch causes another problem that breaks bootstrap on
>> AIX. All of the builtins are emitted as an enum in debug information
>> and the CHKP enums now cause an overflow in the debug dat
On 11/17/14 11:22, David Edelsohn wrote:
However, the patch causes another problem that breaks bootstrap on
AIX. All of the builtins are emitted as an enum in debug information
and the CHKP enums now cause an overflow in the debug data on AIX.
AIX continues to use stabstrings debugging and does
Hi,
this patch makes us to store default optimization node same way as we stream
target node. This means that command line options given at compile time
prevail those given at linktime. Previously we sort of combined both.
We still have a lot of flags that are global (i.e. not marked as Optimiza
On Mon, 17 Nov 2014, Jakub Jelinek wrote:
> > The question, for both _Alignas and ubsan, is the alignment guaranteed *in
> > valid programs*.
> >
> > malloc only provides sufficient alignment for types with fundamental
> > alignment requirements (although there are various problems with the C11
Ilya,
Thanks for fixing the reference to BNDmode.
However, the patch causes another problem that breaks bootstrap on
AIX. All of the builtins are emitted as an enum in debug information
and the CHKP enums now cause an overflow in the debug data on AIX.
AIX continues to use stabstrings debugging
On 11/17/2014 10:27 AM, Richard Biener wrote:
The generated code for g++.dg/torture/pr37922.C is pretty different at -O2,
but it's hard for me to tell whether the changes are good, bad, or neutral.
There is always the possibility of running the C++ portion of SPEC CPU 2006...
I ran the tramp3
On 11/17/2014 05:29 AM, Richard Biener wrote:
can you rename it to copy_fn please? It really copies parameter and
result and then the body.
Ok with that change.
Done. Here's what I'm checking in, along with a second patch to enable
the new code for C++11 as well:
commit 71b7bdd54c7bf07343
On Mon, Nov 17, 2014 at 05:46:55PM +, Joseph Myers wrote:
> On Mon, 17 Nov 2014, Jakub Jelinek wrote:
>
> > > If it is true that a type satisfying TYPE_USER_ALIGN will never be
> > > allocated at an address less-aligned than its TYPE_ALIGN, even if that's
> > > greater than BIGGEST_ALIGNMENT
On Mon, 17 Nov 2014, Jakub Jelinek wrote:
> > If it is true that a type satisfying TYPE_USER_ALIGN will never be
> > allocated at an address less-aligned than its TYPE_ALIGN, even if that's
> > greater than BIGGEST_ALIGNMENT, then the change seems correct for C11
> > _Alignof.
>
> I think it d
On 14 November 2014 12:01, Christophe Lyon wrote:
> On 14 November 2014 12:17, Marcus Shawcroft
> wrote:
>> On 12 November 2014 13:11, Christophe Lyon
>> wrote:
>>> Hi,
>>>
>>> The attached patch adds a few more tests to the recently added
>>> advsimd-intrinsics series.
>>>
>>> OK for trunk?
>
On 14 November 2014 10:46, Alan Lawrence wrote:
> This patch replaces the inline asm for vld1_dup intrinsics with a vdup_n_
> and a load from the pointer. The existing *aarch64_simd_ld1r insn,
> combiner, etc., are quite capable of generating the expected single ld1r
> instruction from this. (I've
Hi all,
This patch implements the vsqrt_f64 intrinsic in arm_neon.h.
There's not much to it, we can reuse __builtin_sqrt.
It's a fairly straightforward and self-contained patch,
do we still want it at this stage?
A new execute test is added.
Tested aarch64-none-elf.
Thanks,
Kyrill
2014-11-17
Hi all,
This is a simple patch to add more conditional macros defined ACLE 2.0.
aarch64-none-elf target is tested on the model, no new issues.
Is this Okay for trunk?
gcc/ChangeLog:
2014-11-17 Renlin Li
* config/aarch64/aarch64.h (TARGET_CPU_CPP_BUILTINS): Define
__ARM_FP_FAST,
On 14 November 2014 10:46, Alan Lawrence wrote:
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-simd.md (aarch64_simd_vec_set): Add
> variant reading from memory and assembling to ld1.
>
> * config/aarch64/arm_neon.h (vld1_lane_f32, vld1_lane_f64,
> vld1_lane_p8,
> v
On 14 November 2014 10:45, Alan Lawrence wrote:
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-builtins.c (TYPES_CREATE): Remove.
> * config/aarch64/aarch64-simd-builtins.def (create): Remove.
> * config/aarch64/aarch64-simd.md (aarch64_create): Remove.
> * config/a
On 17 November 2014 14:48, Kyrill Tkachov wrote:
> Hi all,
>
> Some configurations of Cortex-A53 and Cortex-A57 don't ship with crypto,
> so enabling it by default for -mcpu=cortex-a53 and cortex-a57 is
> inappropriate.
>
> Tested aarch64-none-elf. Reminder that at the moment all the crypto
> exte
On 14 November 2014 15:06, Kyrill Tkachov wrote:
> Hi all,
>
> Considering that the erratum workaround option was backported to 4.9, I
> assume we'll need an item for that
> in the changes.html for that branch?
>
> The text is the same as in the trunk version that I committed recently.
Looks OK t
On 14 November 2014 14:35, Wilco Dijkstra wrote:
> 2014-11-14 Wilco Dijkstra
>
> * gcc/config/aarch64/aarch64.c (generic_regmove_cost):
> Increase FP move cost.
OK /Marcus
> On Nov 17, 2014, at 8:59 AM, Ramana Radhakrishnan
> wrote:
>
>> On Mon, Nov 17, 2014 at 2:48 PM, Kyrill Tkachov
>> wrote:
>> Hi all,
>>
>> Some configurations of Cortex-A53 and Cortex-A57 don't ship with crypto,
>> so enabling it by default for -mcpu=cortex-a53 and cortex-a57 is
>> inap
On Mon, Nov 17, 2014 at 2:48 PM, Kyrill Tkachov wrote:
> Hi all,
>
> Some configurations of Cortex-A53 and Cortex-A57 don't ship with crypto,
> so enabling it by default for -mcpu=cortex-a53 and cortex-a57 is
> inappropriate.
>
> Tested aarch64-none-elf. Reminder that at the moment all the crypto
I've started going through the constexpr blocker bug to try and clear up
remaining problems. For this bug, the issue wasn't really a problem
with the constexpr implementation, but with our pointer to member
function handling: a const PMF (e.g. void (A::* const)()) is a distinct
RECORD_TYPE fro
This is a pure tidyup, no new functionality. Changes are
(1) Use op[0] to store the result operand, rather than a separate variable, thus
combining the two large switch statements into one;
(2) The 'arg' and 'mode' arrays were (almost-)only ever used to store data
*within* each iteration, so tur
No new code here ;). There is a slight change of execution path, i.e. some
VEC_PERM_EXPRs (e.g. those for reductions via shifts) will be expanded using
arm_expand_vec_perm_const rather than the vec_shr pattern. This generates EXT
instructions equivalent to the original, but using the mode of the s
On Sat, 15 Nov 2014, Patrick Palka wrote:
> 1. if the top-level driver is waiting on a hanging subprocess,
> pressing ^C will kill the driver but it may not necessarily kill the
> subprocess; an unresponsive, perhaps busy-looping subprocess may be
> running in the background yet the compil
> OK to apply?
>
> 2014-11-17 Maciej W. Rozycki
>
> gcc/
> * gcc/config/mips/mips.md (*jump_absolute): Use a branch when in
> range, a jump otherwise.
OK.
I only got my head around this code last week otherwise I wouldn't have
known whether this was correct!
Thanks,
Matth
On 17/11/14 13:06 +0100, Markus Trippelsdorf wrote:
On 2014.11.14 at 15:43 +, Jonathan Wakely wrote:
Tested on x86_64-linux and powerpc64-linux, also with
--disable-libstdcxx11-abi to verify all the incompatible changes can
be disabled if needed.
On ppc64 I get:
FAIL: libstdc++-abi/abi_ch
On Mon, 2014-11-17 19:17:34 +0300, Ilya Enkovich wrote:
> On 17 Nov 16:12, Jan-Benedict Glaw wrote:
> > On Mon, 2014-11-17 15:59:41 +0100, Markus Trippelsdorf
> > wrote:
> > > On 2014.11.17 at 15:52 +0100, Jan-Benedict Glaw wrote:
> > > > On Thu, 2014-11-06 15:24:59 +0300, Ilya Enkovich
> > > >
On Sat, 15 Nov 2014, Chen Gang wrote:
> Also in c_common_read_pch(), when failure occurs, also need be sure the
> 'fd' is not '-1' for the next close operation.
Please clarify how c_common_read_pch gets called with fd == -1.
Certainly checking after an error is too late; we shouldn't call fdope
On 17 Nov 16:12, Jan-Benedict Glaw wrote:
> On Mon, 2014-11-17 15:59:41 +0100, Markus Trippelsdorf
> wrote:
> > On 2014.11.17 at 15:52 +0100, Jan-Benedict Glaw wrote:
> > > On Thu, 2014-11-06 15:24:59 +0300, Ilya Enkovich
> > > wrote:
> [...]
> > > It seems this part of the patch series causes
Hi David,
Thanks for your support :)
Note that the DWARF_REG_TO_UNWIND_COLUMN part
is essentially a noop today and is not necessary
to fix the breakage. It's just something that
ISTM should be there in principle.
Olivier
On Nov 17, 2014, at 16:56 , David Edelsohn wrote:
> Olivier,
>
> The pa
1 - 100 of 165 matches
Mail list logo
