PING? Is it OK for me to apply this patch? Thanks.
>
> > 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
> > >> + ""
> > >> + "
> > >> +{
> >
>
On Mon, Nov 17, 2014 at 08:38:19AM +0100, Jakub Jelinek wrote:
> On Mon, Nov 17, 2014 at 08:16:32AM +0100, Marek Polacek wrote:
> > On Mon, Nov 17, 2014 at 06:40:26AM +0800, Chen Gang wrote:
> > > According to the next code, 'pretty_name' may need additional bytes more
> > > than 16. For simplify t
Ping Richard. Any comments?
> > Hi Felix,
> >
> > Sorry for the delay responding, I've been out of the office recently
> > and I'm only just catching up on a backlog of GCC related emails.
> >
> > I'm in two minds about this; I can potentially see the need for
> > attributes to enable long calls
The trunk is in Stage 3 now, which means it is open for general
bugfixing.
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.
Still misleading quality data below - P3 bugs have not been
re-prioritiz
On Tue, Nov 11, 2014 at 01:14:04AM +, Sebastian Pop wrote:
> Hi Jeff,
>
> I have adapted the code generation part from James' patch to current trunk,
> and
> the resulting patch gets the 30% speedup on coremark and passes bootstrap of
> GCC.
For what it is worth, I've bootstrapped and teste
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 purpose of that assert is described here
PR 63894 was fixed by r217634, so I'm just adding the testcase.
Tested on powerpc64-unknown-linux-gnu.
Commited.
2014-11-17 Markus Trippelsdorf
PR ipa/63894
* g++.dg/ipa/pr63894.C: New test.
diff --git a/gcc/testsuite/g++.dg/ipa/pr63894.C
b/gcc/testsuite/g++.dg/ipa/pr63894.C
new file mo
Jeff Law writes:
> OK, let's go ahead and make that official. Please update MAINTAINERS ;-)
I have just added a line for myself as a maintainer for the line map sub
system in the MAINTAINERS file.
Thanks!
--
Dodji
Committed as obvious.
Richard.
2014-11-17 Richard Biener
PR middle-end/63898
* match.pd: Guard X / CST -> X * CST' transform against
zero CST.
Index: gcc/match.pd
===
--- gcc/match.pd(revision 21
PR63883 had a nice small testcase, applied.
Richard.
2014-11-17 Richard Biener
PR middle-end/63898
* gfortran.dg/pr63883.f90: New testcase.
Index: gcc/testsuite/gfortran.dg/pr63883.f90
===
--- gcc/testsuite/gfor
-mdeb ran into a null pointer, hence applied the following fix.
http://gcc.gnu.org/r217651
Johann
gcc/
* config/avr/avr-log.c (avr_log_set_avr_log) [TARGET_ALL_DEBUG]:
Set avr_log_details to "all".
Index: avr-log.c
On Fri, Nov 14, 2014 at 4:27 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 Tue, Nov 11, 2014 at 8:26 AM, Jakub Jelinek wrote:
>> >
On Fri, 14 Nov 2014, Dodji Seketeli wrote:
> Hello,
>
> Following the discussion at
> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01755.html,
> I am proposing this documentation patch to add more comments to some
> gimple accessors for properties that are meant to be undefined at patch
> bound
On Fri, Nov 14, 2014 at 8:19 PM, Segher Boessenkool
wrote:
> Output the cost calculation always, not only when the costs disallow
> a combination. Checking if your port has sane costs is much easier
> this way.
>
> Also there is no point in printing full lines at once; debug dumps
> are never tra
On Fri, Nov 14, 2014 at 10:12 PM, wrote:
> From: Trevor Saunders
>
> Hi,
>
> $subject
>
> bootstrapped + regtested x86_64-unknown-linux-gnu, ok?
>
> Trev
>
> gcc/
>
> * ipa-utils.c, lto-section-in.c, lto-streamer.h,
> tree-scalar-evolution.c: Replace htab with hash_table.
>
> lto
On Fri, Nov 14, 2014 at 10:12 PM, wrote:
> From: Trevor Saunders
>
>
> Hi,
>
> $subject, logically this really is a hash map, but it turns out that doesn't
> work. There's a bug in the way elements are inserted into the table at
> trans-mem.c:3093 which means nothing is ever actually inserted
On Nov 14, 2014, at 1:00 PM, Maciej W. Rozycki wrote:
> http://gcc.gnu.org/ml/gcc-patches/2014-09/msg00242.html
>
> is still waiting, please review.
Wait no more.
Ok.
On Fri, Nov 14, 2014 at 6:08 PM, Ilya Verbin wrote:
> On 14 Nov 09:01, H.J. Lu wrote:
>> On Fri, Nov 14, 2014 at 8:51 AM, Ilya Verbin wrote:
>> > On 14 Nov 08:46, H.J. Lu wrote:
>> >> What happens when -flto is used on command line? Will we
>> >> generate both LTO IR and offload IR?
>> >
>> > Ri
On Sat, Nov 15, 2014 at 11:57 AM, Mircea Namolaru
wrote:
> The close of stage 1 is getting close (very close). Even there is not so much
> new code (basically
> the new code computes the separation class option for AST build), I am not
> sure that the patch
> qualify for stage 2.
>
> There is ve
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 Tue, Nov 11, 2014 at 8:26 AM, Jakub Jelinek wrote:
>>
Hi,
This patch prevents optimizing libraries for space from overriding all
previous CFLAGS_FOR_TARGET settings. Add optimization flags to any
pre-existing values.
I hit this problem whilst building a Gcc cross compiler and newlib
library for ARM with crosstool-NG-1.20.0. The newlib developers
s
On Sat, 15 Nov 2014, Tom de Vries wrote:
> On 15-11-14 13:14, Tom de Vries wrote:
> > Hi,
> >
> > I'm submitting a patch series with initial support for the oacc kernels
> > directive.
> >
> > The patch series uses pass_parallelize_loops to implement parallelization of
> > loops in the oacc kern
On Sun, Nov 16, 2014 at 2:01 AM, Patrick Palka wrote:
> Currently the top-level driver handles SIGINT by immediately killing
> itself even when the driver has subprocesses (e.g. cc1, as) running. I
> don't think this is a good idea because
>
> 1. if the top-level driver is waiting on a hanging
On Sun, Nov 16, 2014 at 6:04 AM, Jason Merrill wrote:
> I've had a TODO in genericize_cp_loop for a long time suggesting that we
> should genericize to LOOP_EXPR rather than gotos, and now that I need to
> interpret the function body for constexpr evaluation, making this change
> will also simplif
On Sun, Nov 16, 2014 at 5:59 AM, Jason Merrill wrote:
> This patch implements more support for C++14 constexpr: it allows arbitrary
> modification of variables in a constexpr function, but does not currently
> handle jumping -- multiple returns, loops, switches.
>
> The approach I took for this wa
On Sun, Nov 16, 2014 at 3:40 PM, Patrick Palka wrote:
> On Sun, Nov 16, 2014 at 8:52 AM, Richard Biener
> wrote:
>> On November 16, 2014 5:22:26 AM CET, Patrick Palka
>> wrote:
>>>On Wed, Nov 12, 2014 at 3:38 AM, Richard Biener
>>> wrote:
On Wed, Nov 12, 2014 at 5:17 AM, Patrick Palka
>>>
On Sun, Nov 16, 2014 at 7:00 PM, Jan Hubicka wrote:
>> >The patch also hits a bug in i386's ix86_set_current_function. It is
>> >responsible
>> >for initializing backend and it does so lazily remembering the previous
>> >options
>> >backend was initialized for. Pragma parsing however clears the ca
Richard Biener writes:
> This means I can no longer interrupt a compile that is running too long?
The compiler will receive your interrupt as well, and die eventually,
unless it is blocked for some reason, in which case you will now notice
instead of leaving behind a lingering process.
Andreas.
On 14/11/14 15:43 +, Jonathan Wakely wrote:
This is the long-awaited ABI break for std::string, replacing our
venerable Copy-On-Write implementation with a C++11-conforming
Small-String-Optimization implementation (based on Paolo's vstring).
This patch fixes move construction and assignment
On Sun, Nov 16, 2014 at 6:53 PM, Marc Glisse wrote:
> On Sun, 16 Nov 2014, Richard Biener wrote:
>
>> I think the element_mode is the way to go.
>
>
> The following passed bootstrap+testsuite.
>
> 2014-11-16 Marc Glisse
>
> * tree.c (element_mode, integer_truep): New functions.
>
What you said sound reasonable to me.
I shall try to send patch v2 within this week (use pretty_printer).
Thanks.
On 11/17/14 16:15, Marek Polacek wrote:
> On Mon, Nov 17, 2014 at 08:38:19AM +0100, Jakub Jelinek wrote:
>> On Mon, Nov 17, 2014 at 08:16:32AM +0100, Marek Polacek wrote:
>>> On Mon
On Sat, 15 Nov 2014 00:58:56 +
Julian Brown wrote:
> On Thu, 13 Nov 2014 11:15:18 +0100
> Jakub Jelinek wrote:
>
> > > +# Turn on OpenACC.
> > > +# XXX (TEMPORARY): Remove the -flto once that's properly
> > > integrated. +lappend ALWAYS_CFLAGS "additional_flags=-fopenacc
> > > -flto"
> >
>
Ah, sorry for the duplication of effort. And thanks for the heads-up about
upcoming work! I don't think I have any plans for any of those others at the moment.
In the case of vld1_dup, however, I'm going to argue that my approach
(https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01718.html) is bet
On 14/11/14 15:31, Gerald Pfeifer wrote:
On Friday 2014-11-14 15:06, Kyrill Tkachov wrote:
Considering that the erratum workaround option was backported to 4.8,
I assume we'll need an item for that in the changes.html for that
branch?
Good point.
Yes. It will be good note note which minor re
On Wed, Nov 12, 2014 at 9:51 AM, Terry Guo wrote:
> Hi there,
>
> Attached patch intends to add pipeline description for ARM MCU Cortex-M7.
> Is it ok to trunk?
This is OK. Can you please make sure there's an entry in changes for 5.0 ?
Ramana
>
> BR,
> Terry
>
> 2014-11-12 Terry Guo
>
>
On Nov 17, 2014, at 2:23 AM, Richard Biener wrote:
> On Sun, Nov 16, 2014 at 2:01 AM, Patrick Palka wrote:
>> Currently the top-level driver handles SIGINT by immediately killing
>> itself even when the driver has subprocesses (e.g. cc1, as) running. I
>> don't think this is a good idea because
I confirm no regressions on aarch64_be-none-elf.
--Alan
Alan Lawrence wrote:
...Patch attached...
Alan Lawrence wrote:
Following recent vectorizer changes to reductions via shifts, AArch64 will now
reduce loops such as this
unsigned char in[8] = {1, 3, 5, 7, 9, 11, 13, 15};
int
main (unsig
On Sat, Nov 15, 2014 at 2:04 AM, Martin Jambor wrote:
> Hi,
>
> this patch adds very simple propagation of alignment of pointers to
> IPA-CP. Because I have not attempted to estimate profitability of
> such propagation in any way, it does not do any cloning, just
> propagation when the alignment
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_check
FAIL: 27_io/basic_ios/copyfmt/char/1.cc execut
On Mon, Nov 17, 2014 at 5:23 AM, Richard Biener
wrote:
> On Sun, Nov 16, 2014 at 2:01 AM, Patrick Palka wrote:
>> Currently the top-level driver handles SIGINT by immediately killing
>> itself even when the driver has subprocesses (e.g. cc1, as) running. I
>> don't think this is a good idea beca
On Mon, Nov 17, 2014 at 5:32 AM, Richard Biener
wrote:
> On Sun, Nov 16, 2014 at 3:40 PM, Patrick Palka wrote:
>> On Sun, Nov 16, 2014 at 8:52 AM, Richard Biener
>> wrote:
>>> On November 16, 2014 5:22:26 AM CET, Patrick Palka
>>> wrote:
On Wed, Nov 12, 2014 at 3:38 AM, Richard Biener
On Tue, Nov 11, 2014 at 2:14 AM, Sebastian Pop wrote:
> Hi Jeff,
>
> I have adapted the code generation part from James' patch to current trunk,
> and
> the resulting patch gets the 30% speedup on coremark and passes bootstrap of
> GCC.
>
> Ok for trunk?
In addition to missing documentation for
On 11/14/2014 09:11 PM, Gopalasubramanian, Ganesh wrote:
> +const char * pftype[2][10]
> + = { {"PLDL1STRM", "PLDL3KEEP", "PLDL2KEEP", "PLDL1KEEP"},
> + {"PSTL1STRM", "PSTL3KEEP", "PSTL2KEEP", "PSTL1KEEP"},
> + };
The array should be
static const char * const pftype[2][4]
I'
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 local optimzations. But this requires removal of
>
On Thu, Aug 7, 2014 at 12:55 PM, Thomas Preud'homme
wrote:
> Hi all,
>
> Currently, when an expression doing manual load or bswap is detected, the
> bswap optimization replace it by an actual load and/or bswap instruction
> without considering whether the intermediate values computed in the
> expr
On 15 Nov 00:03, Jeff Law wrote:
> On 11/14/14 01:22, Ilya Enkovich wrote:
> >
> >I don't think I'm hiding some problem here. Builtin function calls
> >may be removed during various optimizations. Therefore we may remove
> >all calls to some instrumented builtins and corresponding cgraph_node
> >
On 14 Nov 23:58, Jeff Law wrote:
> On 11/14/14 01:06, Ilya Enkovich wrote:
>
> >>>- /* Avoid instrumented builtin functions for now. Due to IPA
> >>>- it also means we have to avoid instrumentation of indirect
> >>>- calls. */
> >>>- if (fndecl && DECL_BUILT_IN_CLASS (fndecl) != NOT_BU
On Mon, Nov 17, 2014 at 1:28 AM, Markus Trippelsdorf
wrote:
> PR 63894 was fixed by r217634, so I'm just adding the testcase.
>
> Tested on powerpc64-unknown-linux-gnu.
> Commited.
>
> 2014-11-17 Markus Trippelsdorf
>
> PR ipa/63894
> * g++.dg/ipa/pr63894.C: New test.
>
> diff --git a/gcc/t
On 14 Nov 23:40, Jeff Law wrote:
> On 11/06/14 05:39, Ilya Enkovich wrote:
> >Hi,
> >
> >This patch adds support of instrumented function calls into strlen pass.
> >
> >Whole series pass bootstrap and check on linux-x86_64. OK for trunk?
> >
> >Thanks,
> >Ilya
> >--
> >gcc/
> >
> >2014-11-06 Ilya
Hello,
ping for https://gcc.gnu.org/ml/gcc-patches/2014-10/msg03264.html
TIA for your feedback,
Olivier
On Oct 31, 2014, at 11:31 , Olivier Hainque wrote:
> Hello,
>
> ping for https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01369.html
>
> a proposal to repair unwinding breakage on e500 targe
On 11/17/2014 10:20 AM, Jakub Jelinek wrote:
On Fri, Nov 14, 2014 at 06:15:16PM +, Joseph Myers wrote:
On Fri, 14 Nov 2014, Jakub Jelinek wrote:
On Fri, Nov 14, 2014 at 09:46:14AM +0300, Yury Gribov wrote:
Hi all,
This patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63802 by onl
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
extension does is enable the use of the ACLE crypto intrinsics in
On Wed, Nov 12, 2014 at 11:49 PM, Zhenqiang Chen wrote:
>
>> -Original Message-
>> From: Richard Henderson [mailto:r...@redhat.com]
>> Sent: Thursday, November 06, 2014 4:23 PM
>> To: Zhenqiang Chen; 'Jan-Benedict Glaw'; Hartmut Penner; Ulrich Weigand;
>> Andreas Krebbel
>> Cc: gcc-patches
On Mon, 17 Nov 2014, Yury Gribov wrote:
> It looks like min_align_of_type is just too C11-specific to be usable in other
> contexts. Here is a patch which does what Jakub originally proposed (use
> TYPE_ALIGN_UNIT for user-aligned types, fallback to min_align_of_type
> otherwise).
I think the re
On 11 November 2014 11:59, Kyrill Tkachov wrote:
> Hi all,
>
> This patch models the latency of moves between FP and GP registers on the
> A15 and A57 a bit more accurately by splitting the reservations for FP->GP
> and GP->FP moves and adding an appropriate bypass.
>
> Bootstrapped and tested on
On Thu, 2014-11-06 15:24:59 +0300, Ilya Enkovich wrote:
> Hi,
>
> This patch adds support of instrumented builtin calls in expand.
> Calls are mostly expanded as calls. But some of them reuse existing
> string function calls expand functions (memcpy expand was slightly
> refactored for that).
>
On 2014.11.17 at 15:52 +0100, Jan-Benedict Glaw wrote:
> On Thu, 2014-11-06 15:24:59 +0300, Ilya Enkovich
> wrote:
> > Hi,
> >
> > This patch adds support of instrumented builtin calls in expand.
> > Calls are mostly expanded as calls. But some of them reuse existing
> > string function calls e
On Tue, Sep 30, 2014 at 11:59 AM, Bin Cheng wrote:
> Hi,
> As analyzed in PR62178, IVOPT can't find the optimal iv set for that case.
> The problem with current heuristic algorithm is it only replaces candidate
> with ones not in current solution one by one, starting from small solution.
> This pa
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 some build breakage
> > right now, see eg. build
> > htt
Posted again, compared to last post on Sep 8 the patch got LTO
support and minor cleanups.
---
The following addresses PR55334 which is about us losing restrict
properties of parameters when inlining or cloning (in the case of the
PR it's cloning via IPA-CP).
It does that by introducing another
On 11/17/2014 05:26 AM, Richard Biener wrote:
Did you inspect generated code for a few testcases?
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.
Jason
On Mon, Nov 17, 2014 at 4:25 PM, Jason Merrill wrote:
> On 11/17/2014 05:26 AM, Richard Biener wrote:
>>
>> Did you inspect generated code for a few testcases?
>
>
> 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 g
...as the former is defined as returning MIN_VALUE for argument MIN_VALUE,
whereas the latter is 'undefined', and gcc can optimize "abs(x)>=0" to "true",
which is wrong for __builtin_aarch64_abs.
There has been much debate here, although not recently - I think the last was
https://gcc.gnu.org/
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
Thanks, David
Hi,
This was lost in the original microMIPS submission.
For absolute microMIPS jumps GCC always produces a branch instruction,
causing a `relocation truncated to fit: R_MICROMIPS_PC16_S1' linker
error if the branch target turns out of range. The TARGET_ABICALLS_PIC2
macro is never set in ab
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
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
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 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 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
> 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 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
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
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
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
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
> 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 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 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 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 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 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
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,
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
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
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 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 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 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 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
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 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
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 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
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
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 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
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 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 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
1 - 100 of 165 matches
Mail list logo
