On Thu, Jun 16, 2016 at 6:18 PM, James Greenhalgh
wrote:
>
> Hi,
>
> As subject, config/arm/arm_neon.h currently uses __FAST_MATH, but:
>
> $ gcc -E -dM - -ffast-math < /dev/null | grep FAST_MATH
> #define __FAST_MATH__ 1
>
> It should be spelled as __FAST_MATH__.
>
> I've made that change, an
Cesar Philippidis wrote:
> On 06/16/2016 08:30 PM, Cesar Philippidis wrote:
> > This patch introduces a match_acc function to the fortran FE. It's
> > almost identical to match_omp, but it passes openacc = true to
> > gfc_match_omp_clauses. I supposed I could have consolidated those two
> > functio
Basic ARC cpus are having only simple shift operations. Here they are.
OK to apply?
Claudiu
gcc/
2016-06-09 Claudiu Zissulescu
* config/arc/arc.md (*rotrsi3_cnt1): New pattern,
(*ashlsi2_cnt1, *lshrsi3_cnt1, *ashrsi3_cnt1): Likewise.
---
gcc/config/arc/arc.md | 40 +++
On 16/06/16 21:29 +0200, François Dumont wrote:
Here is a new version compiling all your feedbacks.
PR libstdc++/71181
* include/tr1/hashtable_policy.h
(_Prime_rehash_policy::_M_next_bkt): Make past-the-end iterator
dereferenceable to avoid check on lower_bound result.
(_Prime_reh
This is another step to flesh out -mmitigate-rop for i386 a little more.
The basic idea was (I think) Richard Henderson's: if we could arrange to
have every return preceded by a leave instruction, it would make it
harder to construct an attack since it takes away a certain amount of
control ove
On Fri, Jun 17, 2016 at 12:06:48PM +0200, Bernd Schmidt wrote:
> This is another step to flesh out -mmitigate-rop for i386 a little more. The
> basic idea was (I think) Richard Henderson's: if we could arrange to have
> every return preceded by a leave instruction, it would make it harder to
> cons
2016-06-16 8:06 GMT+03:00 Jeff Law :
> On 05/20/2016 05:40 AM, Ilya Enkovich wrote:
>>
>> 2016-05-20 14:17 GMT+03:00 Richard Biener :
>>>
>>> On Fri, May 20, 2016 at 11:50 AM, Ilya Enkovich
>>> wrote:
2016-05-20 12:26 GMT+03:00 Richard Biener :
>
> On Thu, May 19, 2016 at 9:36 PM
Hi,
As discussed some time ago with Kyrylo (on IRC IIRC), the attached
patch makes sure that arm_neon_fp16_ok and arm_neonv2_ok effective
targets imply that arm_neon_ok passes, and use the corresponding
flags.
Without this patch, the 3 effective targets have different, possibly
inconsistent condi
On 06/17/2016 12:37 PM, Jakub Jelinek wrote:
Do you really need to require frame pointer for this?
I mean, couldn't you instead use what you do if a function needs frame
pointer and otherwise just replace the original ret with
pushq %rbp
movq%rsp, %rbp
jmp __rop
Hi,
one more I missed. Tested x86_64-linux. Should be obvious too...
Thanks,
Paolo.
PS: I still have pending:
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01116.html
//
/cp
2016-06-17 Paolo Carlini
* decl.c (grokfndecl): Change pair of errors to error + infor
Senthil Kumar Selvaraj schrieb:
Hi,
This patch fixes PR 71151 by eliminating the
TARGET_ASM_FUNCTION_RODATA_SECTION hook and setting
JUMP_TABLES_IN_TEXT_SECTION to 1.
As described in the bugzilla entry, this hook assumed it will get
called only for jumptable rodata for functions. This
On 16 June 2016 at 14:56, Jan Hubicka wrote:
> Hi,
> tree_estimate_loop_size contains one extra else that prevents it from
> determining
> that the induction variable comparsion is going to be eliminated in both the
> peeled
> copies as well as the last copy. This patch fixes it
> (it really re
> So at least in the immediate term let's get you write privileges so you can
> commit approved changes and on the path towards maintaining the Phoenix-RTOS
> configurations.
Do I have to apply for this permission somewhere? Provided page states
only, that it has to be granted by an existing maint
Hi.
Following simple patch fixes a newly introduced memory leak.
Patch survives regression tests and bootstraps on x86_64-linux.
Ready from trunk?
Thanks,
Martin
>From a2e6be16d7079b744db4d383b8317226ab53ff58 Mon Sep 17 00:00:00 2001
From: marxin
Date: Fri, 17 Jun 2016 12:26:58 +0200
Subject: [
Hi,
On Fri, 17 Jun 2016, Bernd Schmidt wrote:
> This is another step to flesh out -mmitigate-rop for i386 a little more.
> The basic idea was (I think) Richard Henderson's: if we could arrange to
> have every return preceded by a leave instruction, it would make it
> harder to construct an att
On Thu, Jun 16, 2016 at 09:05:40PM +0200, Jakub Jelinek wrote:
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, and
> tested with x86_64-intelmicemul-linux offloading on x86_64-linux, committed
> to trunk.
And the following testcase shows similar issues in the array section
h
On Fri, Jun 17, 2016 at 10:40:40AM +0200, Tobias Burnus wrote:
> Cesar Philippidis wrote:
> > On 06/16/2016 08:30 PM, Cesar Philippidis wrote:
> > > This patch introduces a match_acc function to the fortran FE. It's
> > > almost identical to match_omp, but it passes openacc = true to
> > > gfc_matc
2016-06-16 8:22 GMT+03:00 Jeff Law :
> On 06/15/2016 05:03 AM, Richard Biener wrote:
>>
>> On Thu, May 19, 2016 at 9:39 PM, Ilya Enkovich
>> wrote:
>>>
>>> Hi,
>>>
>>> This patch introduces changes required to run vectorizer on loop
>>> epilogue. This also enables epilogue vectorization using a ve
On 06/17/2016 04:03 PM, Michael Matz wrote:
But does this really improve something? Essentially you're replacing
0xc9 0xc3
(the end of a function containing "leave;ret") with
0xe9
where the four random bytes are different for each rewritten function
return (but correlated as they di
Hello,
An initial patch has been integrated into gnu-config to translate triplets like
e500v2-*- into powerpc-*-spe.
The spe extension to the os is expected for targets such as e500v[12]-*-linux
(translated as powerpc-*-linux-gnuspe) or eabi targets.
This patch integrates the patch of gnu-config
On 14 June 2016 at 18:31, Prathamesh Kulkarni
wrote:
> On 13 June 2016 at 16:13, Jan Hubicka wrote:
>>> diff --git a/gcc/cgraph.h b/gcc/cgraph.h
>>> index ecafe63..41ac408 100644
>>> --- a/gcc/cgraph.h
>>> +++ b/gcc/cgraph.h
>>> @@ -1874,6 +1874,9 @@ public:
>>> if we did not do any inter-p
On 10 June 2016 at 14:29, James Greenhalgh wrote:
>
> Hi,
>
> My autotester picked up some issues with the vcvt{ds}_n_* intrinsics
> added in r237200.
>
Hi,
What tests does your autotester perform? I haven't noticed these
problems when running the GCC testsuite on the usual aarch64
targets. I'm i
Hi Christophe,
On 17/06/16 11:47, Christophe Lyon wrote:
Hi,
As discussed some time ago with Kyrylo (on IRC IIRC), the attached
patch makes sure that arm_neon_fp16_ok and arm_neonv2_ok effective
targets imply that arm_neon_ok passes, and use the corresponding
flags.
Without this patch, the 3 e
Hello.
After we've recently applied various changes (fixes) to predict.c, SPEC2006
shows that PRED_LOOP_EXIT value should be amended.
Survives regression tests & bootstrap on x86_64-linux.
Pre-approved by Honza, installed as r237556.
Thanks,
Martin
>From 849c2e064bcadc269f82656d15722f28d1b1fe73
Hi,
On Fri, 17 Jun 2016, Bernd Schmidt wrote:
> On 06/17/2016 04:03 PM, Michael Matz wrote:
> > But does this really improve something? Essentially you're replacing
> >
> >0xc9 0xc3
> >
> > (the end of a function containing "leave;ret") with
> >
> >0xe9
> >
> > where the four rand
2016-06-16 9:00 GMT+03:00 Jeff Law :
> On 05/19/2016 01:39 PM, Ilya Enkovich wrote:
>>
>> Hi,
>>
>> This patch introduces changes required to run vectorizer on loop epilogue.
>> This also enables epilogue vectorization using a vector of smaller size.
>>
>> Thanks,
>> Ilya
>> --
>> gcc/
>>
>> 2016-0
On 06/17/2016 04:29 PM, Michael Matz wrote:
On Fri, 17 Jun 2016, Bernd Schmidt wrote:
On 06/17/2016 04:03 PM, Michael Matz wrote:
But does this really improve something? Essentially you're replacing
0xc9 0xc3
(the end of a function containing "leave;ret") with
0xe9
where the four
On Thu, Jun 16, 2016 at 08:22:29PM -0700, Cesar Philippidis wrote:
> --- a/gcc/fortran/openmp.c
> +++ b/gcc/fortran/openmp.c
> @@ -677,7 +677,6 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, uint64_t
> mask,
> && gfc_match ("async") == MATCH_YES)
> {
> c->async =
Ping.
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00821.html
Thanks,
Kyrill
On 10/06/16 15:55, Kyrill Tkachov wrote:
Hi all,
This function just ICEs and isn't actually called from anywhere.
It was introduced back in 2000 as part of a large merge introducing Thumb
support
and was aborting eve
On Wed, Jun 15, 2016 at 08:12:15PM -0700, Cesar Philippidis wrote:
> The second set of changes involves teaching the gimplifier to error when
> it detects a function call to an non-acc routines inside an OpenACC
> offloaded region. Actually, I relaxed non-acc routines by excluding
> calls to builti
On Fri, Jun 17, 2016 at 04:25:31PM +0200, Christophe Lyon wrote:
> On 10 June 2016 at 14:29, James Greenhalgh wrote:
> >
> > Hi,
> >
> > My autotester picked up some issues with the vcvt{ds}_n_* intrinsics
> > added in r237200.
> >
> Hi,
>
> What tests does your autotester perform? I haven't noti
On Fri, Jun 17, 2016 at 3:33 PM, Ilya Enkovich wrote:
> 2016-06-16 9:00 GMT+03:00 Jeff Law :
>> On 05/19/2016 01:39 PM, Ilya Enkovich wrote:
>>>
>>> Hi,
>>>
>>> This patch introduces changes required to run vectorizer on loop epilogue.
>>> This also enables epilogue vectorization using a vector of
On 17 June 2016 at 16:44, James Greenhalgh wrote:
> On Fri, Jun 17, 2016 at 04:25:31PM +0200, Christophe Lyon wrote:
>> On 10 June 2016 at 14:29, James Greenhalgh wrote:
>> >
>> > Hi,
>> >
>> > My autotester picked up some issues with the vcvt{ds}_n_* intrinsics
>> > added in r237200.
>> >
>> Hi,
2016-06-17 17:48 GMT+03:00 Bin.Cheng :
> On Fri, Jun 17, 2016 at 3:33 PM, Ilya Enkovich wrote:
>> 2016-06-16 9:00 GMT+03:00 Jeff Law :
>>> On 05/19/2016 01:39 PM, Ilya Enkovich wrote:
Hi,
This patch introduces changes required to run vectorizer on loop epilogue.
This also
On 04/04/14 20:48, dw wrote:
> I do not have write permissions to check this patch in.
We must fix that.
Andrew.
On 06/17/2016 08:48 AM, Bin.Cheng wrote:
+ /* FORNOW: Currently alias checks are not inherited for epilogues.
+ Don't try to vectorize epilogue because it will require
+ additional alias checks. */
Are the alias checks here redundant with the ones done for the original
loop? If so
On 06/17/2016 08:16 AM, Ilya Enkovich wrote:
I do think you've got a legitimate question though. Ilya, can you give any
insights here based on your KNL and Haswell testing or data/insights from
the LLVM and/or ICC teams?
I have no information about LLVM. As I said in other thread ICC uses a
On 06/17/2016 04:06 AM, Bernd Schmidt wrote:
This is another step to flesh out -mmitigate-rop for i386 a little more.
The basic idea was (I think) Richard Henderson's: if we could arrange to
have every return preceded by a leave instruction, it would make it
harder to construct an attack since it
On Fri, Jun 17, 2016 at 4:37 PM, Jeff Law wrote:
> On 06/17/2016 08:48 AM, Bin.Cheng wrote:
> + /* FORNOW: Currently alias checks are not inherited for epilogues.
> + Don't try to vectorize epilogue because it will require
> + additional alias checks. */
>
On 06/17/2016 08:29 AM, Michael Matz wrote:
Hi,
On Fri, 17 Jun 2016, Bernd Schmidt wrote:
On 06/17/2016 04:03 PM, Michael Matz wrote:
But does this really improve something? Essentially you're replacing
0xc9 0xc3
(the end of a function containing "leave;ret") with
0xe9
where the
On 06/16/2016 02:32 AM, Aldy Hernandez wrote:
Hi folks!
I've been working on a plugin to warn on unbounded uses of alloca() to
help find questionable uses in glibc and other libraries. It occurred
to me that the broader community could benefit from it, as it has found
quite a few interesting ca
Now that we have stopped treating *this as a dependent scope, we need
to avoid giving errors for not finding things when we have dependent
bases.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit d553bc7ff104a8d973c3f48c005457038422db26
Author: Jason Merrill
Date: Fri Jun 17 12:16:00 2016 -
On 06/17/2016 08:33 AM, Ilya Enkovich wrote:
Hmm, there seems to be a level of indirection I'm missing here. We're
smuggling LOOP_VINFO_ORIG_LOOP_INFO around in loop->aux. Ewww. I thought
the whole point of LOOP_VINFO_ORIG_LOOP_INFO was to smuggle the VINFO from
the original loop to the vecto
On 06/17/2016 07:14 AM, Martin Liška wrote:
Hi.
Following simple patch fixes a newly introduced memory leak.
Patch survives regression tests and bootstraps on x86_64-linux.
Ready from trunk?
Thanks,
Martin
0001-Fix-memory-leak-in-tree-ssa-reassoc.c.patch
From a2e6be16d7079b744db4d383b83172
On 06/17/2016 07:07 AM, Jakub Sejdak wrote:
So at least in the immediate term let's get you write privileges so you can
commit approved changes and on the path towards maintaining the Phoenix-RTOS
configurations.
Do I have to apply for this permission somewhere? Provided page states
only, that
On Wednesday 01 June 2016 10:00:52 Ramana Radhakrishnan wrote:
> Please fix up the macros, post back and redo the test. Otherwise this
> is ok from a quick read.
What about the updated patch in attachment? As for the original patch, I've
checked that code generation does not change for a number o
OK.
Jason
On Wed, Jun 15, 2016 at 5:15 AM, Paolo Carlini wrote:
> + /* Likewise for the constexpr specifier, in case t is a specialization
> + and we are emitting an error about an incompatible redeclaration. */
It doesn't need to be in an error about a redeclaration; in general a
specialization can
OK.
Jason
PR libstdc++/71545
* include/bits/stl_algobase.h (lower_bound, lexicographical_compare):
Remove irreflexive checks.
* include/bits/stl_algo.h (lower_bound, upper_bound, equal_range,
binary_search): Likewise.
* testsuite/25_algorithms/equal_range/part
We can use rich_location and the new diagnostic_show_locus to print
both locations when complaining about a bogus string concatenation
in the C++ FE, giving e.g.:
test.C:3:24: error: unsupported non-standard concatenation of string literals
const void *s = u8"a" u"b";
~ ^~~
Hi,
Please find the patch for introducing vulcan as a cpu name for the
AArch64 port of GCC.
Broadcom's vulcan is an armv8.1-a aarch64 server processor.
Since vulcan is the first armv8.1-a processor to be introduced in
aarch64-cores.def,
I have created a new section in the file for the armv8.1 bas
This patch adds explicit testing of lexing a source file,
generalizing this (and the test of ordinary line maps) over
a 2-dimensional test matrix covering:
(1) line_table->default_range_bits: some frontends use a non-zero value
and others use zero
(2) the fallback modes within line-map.c: t
Reverts https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01538.html - G10
supports MULU but not other multiplication methods. Committed.
PR target/71338
* config/rl78/rl78-expand.c (umulqihi3): Enable for G10.
* config/rl78/rl78-virtual.c (umulhi3_shift_virt): Likewise.
On Fri, Jun 17, 2016 at 7:29 AM, Martin Liška wrote:
> Hello.
>
> After we've recently applied various changes (fixes) to predict.c, SPEC2006
> shows that PRED_LOOP_EXIT value should be amended.
This caused a 1% decrease of performance on coremarks on
aarch64-linux-gnu on ThunderX.
Thanks,
Andr
55 matches
Mail list logo
