+# XXX We should probably accept /dev/stdin or maybe magic autodetection of
+# being supposed to get the patch from stdin.
+#
Can we just set $diff to '-' if @ARGV is empty?
+# In any case if we got the diff on stdin then write the ChangeLog to stdout.
Hm, this is breaks semantics: you only
On 28 April 2014 18:16, Marcus Shawcroft wrote:
> On 22 April 2014 10:36, Zhenqiang Chen wrote:
>
>>> +float f1 (float a, float b, float c, float d)
>>> +{
>>> + if (a > 0.0)
>>> +return c;
>>> + else
>>> +return 2.0;
>>> +}
>>> +
>>> +double f2 (double a, double b, double c, double d)
Hi Trevor,
I think this looks rather useful.
> +if (-d .git) {
What about moving default name/addr (with finger, etc.) to else branch?
> + chomp($gitname);
> + chomp($gitaddr);
Missing whites before (.
-Y
Hi,
Function output_move_neon now generates vld1.64 for memory ref like "dx <-
[r1:SI]", this is bogus because it requires at least 64-bit alignment for
32-bit aligned memory ref. It works now because GCC doesn't generate such
insns in the first place, but things are going to change if memset/memc
On 28/04/14 21:01, Ramana Radhakrishnan wrote:
> On 04/26/14 11:57, Kugan wrote:
>> Attached patch implements TARGET_ATOMIC_ASSIGN_EXPAND_FENV for AARCH64.
>> With this, atomic test-case gcc.dg/atomic/c11-atomic-exec-5.c now PASS.
>>
>> This implementation is based on SPARC and i386 implementation
Hi,
The following patch adds details of support for generic functions and
the explicit template parameter extension for generic lambdas present in
GCC 4.9.
OK to commit?
Cheers,
Adam
Index: htdocs/gcc-4.9/changes.html
===
RCS f
From: Trevor Saunders
Hi,
I'd like to be able to suggest a git prepare-committ-msg hook, that uses this
at some point to populate the commit message at some point. This doesn't do
that, but its a step in that direction, what would remain is just writing a
shell script to pipe git diff to mklog
From: Trevor Saunders
Hi,
finger gives the wrong data on my machines, and while I could fix it it seems
nicer to use what's configured for the git repo we're in if any, that way you
can use different defaults from the rest of the machine.
Trev
contrib/ChangeLog:
2014-04-28 Trevor Saunders
Hi,
These patches make it a little nicer to use mklog, but there not particularly
pretty.
Trev
On Thu, 2014-04-24 at 15:46 -0600, Jeff Law wrote:
> On 03/10/14 13:22, David Malcolm wrote:
> > Gimple function dumps contain the types of parameters, but not of the
> > return type.
> >
> > The attached patch fixes this omission; here's an example of the
> > before/after diff:
> > $ diff -up /tmp
On Mon, Apr 28, 2014 at 4:18 PM, Jonathan Wakely wrote:
> I thought I'd make a 5x speedup to the run-time of the regex matching,
> but I was comparing the wrong version and the improvement actually
> came from one of your patches yesterday - maybe this one:
> http://gcc.gnu.org/ml/gcc-patches/2014
On 04/28/2014 01:43 PM, Evgeny Stupachenko wrote:
> Agree on checks:
>
> /* PALIGNR of 2 128-bits registers takes only 1 instrucion.
> Requires SSSE3. */
> if (GET_MODE_SIZE (d->vmode) == 16)
> {
> if(!TARGET_SSSE3)
> return false;
> }
> /* PALIGNR of 2 256-bits r
On Sat, 2014-04-26 at 22:22 +0200, Gerald Pfeifer wrote:
> On Fri, 25 Apr 2014, David Malcolm wrote:
> > Successfully generates HTML, info and pdf via appropriate make
> > invocations; example of resulting HTML can be seen at the bottom of:
> >
> > http://dmalcolm.fedorapeople.org/gcc/2014-04-25/T
On 04/09/2014 02:56 PM, David Edelsohn wrote:
I have reverted this on trunk and asked Bill to revert this on the 4.8
branch. This patch is too risky to apply this close to a freeze for
4.9.
I received approval off list for an updated variant of the patch for
4.8, so this patch has now been (re)c
Agree on checks:
/* PALIGNR of 2 128-bits registers takes only 1 instrucion.
Requires SSSE3. */
if (GET_MODE_SIZE (d->vmode) == 16)
{
if(!TARGET_SSSE3)
return false;
}
/* PALIGNR of 2 256-bits registers on AVX2 costs only 2 instructions:
PERM and PALIGNR. It
On Mon, Apr 28, 2014 at 9:08 PM, H.J. Lu wrote:
> On Mon, Apr 28, 2014 at 9:48 AM, Evgeny Stupachenko
> wrote:
>> Hi,
>>
>> The patch enables use of "palignr with perm" instead of "2 pshufb, or
>> and perm" at AVX2 for some cases.
>>
>> Bootstrapped and passes make check on x86.
>>
>> Is it ok?
I've backported the following patch from trunk at r209812. Committed
on the google/gcc-4_9 branch at r209875.
Google ref: 14230806.
-cary
gcc/
* dwarf2out.c (should_move_die_to_comdat): A type definition
can contain a subprogram definition, but don't move it to a
comdat u
I thought I'd make a 5x speedup to the run-time of the regex matching,
but I was comparing the wrong version and the improvement actually
came from one of your patches yesterday - maybe this one:
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01725.html
Nice work!
My changes don't seem to make any
On Mon, 28 Apr 2014, Marek Polacek wrote:
This patch implements -fsanitize=float-divide-by-zero option that can
be used to detect division by zero even when using floating types.
Most of the code in ubsan_instrument_division was ready for this
so this was mainly about handling REAL_TYPE there.
On Mon, Apr 28, 2014 at 3:29 PM, Jonathan Wakely wrote:
> I'm testing the attached patch now. It compiles slightly faster
> (-ftime-report shows, as expected, that less time is spent in template
> instantiation).
>
> I'd also like to change __match_mode from a bool to an enum like:
>
> enum _Mat
On 04/17/2014 06:09 AM, Yuri Rumyantsev wrote:
> + /* Build cond expression using COND and constant operand
> + of reduction rhs. */
> + c = fold_build_cond_expr (TREE_TYPE (rhs1),
> + unshare_expr (cond),
> + swap? zero: op1,
> +
On 04/28/2014 08:00 AM, Eric Botcazou wrote:
> You can re-apply the gcc-interface/Makefile.in hunk
> (I reverted it as well) but you first need to adjust it to the mainline.
Done, after re-bootstrapping on aarch64 Just to Be Sure.
r~
On Mon, Apr 28, 2014 at 3:33 PM, Pat Haugen wrote:
> On 04/16/2014 10:27 PM, David Edelsohn wrote:
>>>
>>> >Updated patch with above comments incorporated. Bootstrap/regtest on
>>> > BE/LE
>>> >with no new regressions. Ok for trunk?
>>
>> 2014-04-08 Pat Haugen
>>
>> * config/rs6000/rs600
On 28/04/14 15:24 -0400, Tim Shen wrote:
Worth a try. Will you make the change or will I? It seems to be
simpler doing than talking.
Yes :-)
I'm testing the attached patch now. It compiles slightly faster
(-ftime-report shows, as expected, that less time is spent in template
instantiation).
I
On 04/16/2014 10:27 PM, David Edelsohn wrote:
>Updated patch with above comments incorporated. Bootstrap/regtest on BE/LE
>with no new regressions. Ok for trunk?
2014-04-08 Pat Haugen
* config/rs6000/rs6000.md (addti3, subti3): New.
gcc/testsuite:
* gcc.target/powerpc/ti_mat
On Mon, Apr 28, 2014 at 3:10 PM, Jonathan Wakely wrote:
> Data members are accessed through the 'this' pointer, which can
> require an indirection and be harder to optimise than a function
> parameter.
It doesn't matter if this variable is not frequently checked. But
let's just use the function p
On 28/04/14 15:02 -0400, Tim Shen wrote:
If we want to change it to a runtime flag, it should be a class
member. Otherwise we have to pass it as a function parameter all the
time, and it may waste an instruction and one byte per recursive call.
It surely make the code cleaner.
Data members are
This patch implements -fsanitize=float-divide-by-zero option that can
be used to detect division by zero even when using floating types.
Most of the code in ubsan_instrument_division was ready for this
so this was mainly about handling REAL_TYPE there.
Since division by a floating point zero can
On Mon, Apr 28, 2014 at 12:51 PM, Jonathan Wakely wrote:
> The next thing I plan to look at, which I haven't done yet, is to see
> if passing the __match_mode template parameter as a runtime function
> parameter makes any difference to the way the code is structuted. Do
> you have any thoughts in
Thanks. I will change
> + if (a != operand_a
> + && (LRA_SPLIT_FREQ_RATIO * freq >= a->freq))
to
> + if (a != operand_a
> + && (!ira_use_lra_p || LRA_SPLIT_FREQ_RATIO * freq >= a->freq))
Regards,
Wei.
On Mon, Apr 28, 2014 at 12:57 AM, Steven Bosscher wr
Applied, thanks. Sorry for the delay.
Jason
FYI:
Begin forwarded message:
> From: Kenneth Zadeck
> Subject: status of wide-int patch.
> Date: April 28, 2014 at 10:03:36 AM PDT
> To: gcc , Richard Sandiford ,
> Richard Biener , Mike Stump
>
> At this point we have believe that we have addressed all of the concerns that
> the community
On 04/28/2014 09:48 AM, Evgeny Stupachenko wrote:
> - /* Even with AVX, palignr only operates on 128-bit vectors. */
> - if (!TARGET_SSSE3 || GET_MODE_SIZE (d->vmode) != 16)
> + /* PALIGNR of 2 256-bits registers on AVX2 costs only 2 instructions:
> + PERM and PALIGNR. It is more profitabl
What are the rules for backporting to 4.9.1? Should I backport this patch?
-cary
> 2014-04-25 Cary Coutant
>
> gcc/
> PR debug/60929
> * dwarf2out.c (should_move_die_to_comdat): A type definition
> can contain a subprogram definition, but don't move it to a
> c
On Mon, Apr 28, 2014 at 9:48 AM, Evgeny Stupachenko wrote:
> Hi,
>
> The patch enables use of "palignr with perm" instead of "2 pshufb, or
> and perm" at AVX2 for some cases.
>
> Bootstrapped and passes make check on x86.
>
> Is it ok?
>
> 2014-04-28 Evgeny Stupachenko
>
> * config/i386
On 28/04/14 11:40 -0400, Tim Shen wrote:
On Mon, Apr 28, 2014 at 10:46 AM, Jonathan Wakely wrote:
This change splits _Executor::_M_main() into two overloaded
_M_main_dispatch() functions, choosing which to run based on the
__dfs_mode template parameter.
I think this gives a (very) small improv
Hi,
The patch enables use of "palignr with perm" instead of "2 pshufb, or
and perm" at AVX2 for some cases.
Bootstrapped and passes make check on x86.
Is it ok?
2014-04-28 Evgeny Stupachenko
* config/i386/i386.c (expand_vec_perm_1): Try AVX2 vpshufb.
* config/i386/i386.c (ex
On 04/28/2014 12:25 PM, Mike Stump wrote:
On Apr 28, 2014, at 2:36 AM, Richard Sandiford
wrote:
Ping. FWIW this is the last patch I have lined up before the merge.
I repeated the asm comparison test I did a few months ago on one target
per config/ architecture and there were no unexpected cha
On Apr 28, 2014, at 2:36 AM, Richard Sandiford
wrote:
> Ping. FWIW this is the last patch I have lined up before the merge.
> I repeated the asm comparison test I did a few months ago on one target
> per config/ architecture and there were no unexpected changes.
Nice, thanks.
On Apr 28, 2014, at 12:32 AM, Sebastian Huber
wrote:
> On 2014-04-28 04:23, Mike Stump wrote:
>> On Apr 27, 2014, at 10:45 AM, Sebastian Huber
>> wrote:
>>> 2014-04-27 Sebastian Huber
>>>
>>> * testsuite/lib/libffi.exp (load_gcc_lib): Register loaded libs.
>>
>> So, I didn’t see anythi
ok to commit.
kenny
On 04/28/2014 11:42 AM, Richard Sandiford wrote:
Kyrill Tkachov writes:
With that patch bootstrap now still fails at dwarf2out.c with the same
message. I'm attaching a gzipped dwarf2out.ii
Thanks. This is a nice proof of why clz_zero and ctz_zero were as bogus
as claimed.
Kyrill Tkachov writes:
> With that patch bootstrap now still fails at dwarf2out.c with the same
> message. I'm attaching a gzipped dwarf2out.ii
Thanks. This is a nice proof of why clz_zero and ctz_zero were as bogus
as claimed. It meant that the behaviour of floor_log2 depended on the
target an
On Mon, Apr 28, 2014 at 10:46 AM, Jonathan Wakely wrote:
> This change splits _Executor::_M_main() into two overloaded
> _M_main_dispatch() functions, choosing which to run based on the
> __dfs_mode template parameter.
>
> I think this gives a (very) small improvement in compilation time when
> us
On Mon, Apr 28, 2014 at 11:05 AM, Jonathan Wakely wrote:
> There is a well-defined mapping from every unsigned char in the range
> [0,255] to char and back, so conversions between char and unsigned
> char are fine. If we used a larger type then we would get the wrong result
> when char is signed,
> On Wed, 23 Apr 2014, Richard Biener wrote:
>
> >
> > This avoids all the complex work on simple things like
> > clear_last_verified. It also makes eventually inlining all
> > calls (for example the one with the small IPA pass hack)
> > less code-duplicating.
> >
> > I had to remove the assert
On 28/04/14 10:15 -0400, Tim Shen wrote:
On Mon, Apr 28, 2014 at 8:40 AM, Jonathan Wakely wrote:
I've been looking through the regex code and have a few ideas for
simplifications or optimisations that I'd like to share.
Thanks :)
This first patch is for _BracketMatcher. We only use std::bit
> On Mon, Apr 28, 2014 at 11:10:41AM +0200, Jakub Jelinek wrote:
> > On Mon, Apr 28, 2014 at 11:05:06AM +0200, Richard Biener wrote:
> > > On Fri, Apr 25, 2014 at 5:35 PM, Martin Jambor wrote:
> > > > Hi,
> > > >
> > > > the patch below might be useful for testcase preparation and debugging
> > >
On Mon, Apr 28, 2014 at 10:55 AM, Jonathan Wakely wrote:
> Ah yes, I didn't think of that. But the size of _Executor is fixed,
> isn't it? If it has a huge number of states or matches those will be
> on the heap anyway, in vectors/arrays.
>
> It could be huge if instantiated with a huge iterator
> Bootstrap and test succeeded, thanks.
Thanks, applied as such. You can re-apply the gcc-interface/Makefile.in hunk
(I reverted it as well) but you first need to adjust it to the mainline.
* exp_dbug.ads (Get_External_Name): Add 'False' default to Has_Suffix,
add 'Suffix' para
Tom de Vries writes:
>> If so,
>> should -fuse-caller-save imply -fcaller-saves?
>
> I don't think it's strictly necessary, but I can make a patch if required.
Implying -fcaller-saves seems better to me, since "-O -fuse-caller-save"
looks like it should enable the new optimisation. It's not my c
On 28/04/14 10:18 -0400, Tim Shen wrote:
On Mon, Apr 28, 2014 at 8:45 AM, Jonathan Wakely wrote:
Is there any reason this object is created on the heap?
Say, _Executor's size is so huge and a uncommon user gets a stack
overflow by keep invoking this function?
Ah yes, I didn't think of that.
Tom de Vries writes:
> On 28-04-14 12:26, Richard Sandiford wrote:
>> Tom de Vries writes:
>>> On 27-04-14 12:27, Richard Sandiford wrote:
Tom de Vries writes:
>mips_emit_call_insn (rtx pattern, rtx orig_addr, rtx addr, bool lazy_p)
>{
> rtx insn, reg;
>
> -
This change splits _Executor::_M_main() into two overloaded
_M_main_dispatch() functions, choosing which to run based on the
__dfs_mode template parameter.
I think this gives a (very) small improvement in compilation time when
using regexes.
Splitting _M_main() allows the _M_match_queue and _M_v
On Mon, Apr 28, 2014 at 11:10:41AM +0200, Jakub Jelinek wrote:
> On Mon, Apr 28, 2014 at 11:05:06AM +0200, Richard Biener wrote:
> > On Fri, Apr 25, 2014 at 5:35 PM, Martin Jambor wrote:
> > > Hi,
> > >
> > > the patch below might be useful for testcase preparation and debugging
> > > compiler bug
On Mon, Apr 28, 2014 at 8:45 AM, Jonathan Wakely wrote:
> Is there any reason this object is created on the heap?
Say, _Executor's size is so huge and a uncommon user gets a stack
overflow by keep invoking this function?
--
Regards,
Tim Shen
On Mon, Apr 28, 2014 at 8:40 AM, Jonathan Wakely wrote:
> I've been looking through the regex code and have a few ideas for
> simplifications or optimisations that I'd like to share.
Thanks :)
> This first patch is for _BracketMatcher. We only use std::bitset when
> is_same<_CharT, char> so 8 *
On Mon, Apr 28, 2014 at 03:47:17PM +0200, Richard Biener wrote:
> On Tue, Mar 18, 2014 at 2:51 PM, Richard Biener wrote:
> >
> > This is another patch (well, I've polished it a bit) that was sitting
> > in my local tree for some time. I've not enabled the ggc-common.c
> > code (I merely want to g
On Tue, Mar 18, 2014 at 2:51 PM, Richard Biener wrote:
>
> This is another patch (well, I've polished it a bit) that was sitting
> in my local tree for some time. I've not enabled the ggc-common.c
> code (I merely want to get rid of the false possitives).
>
> Queued for 4.10 unless I'm told other
Per Richi's request, don't iterate over virtual outputs when invaliding
outputs of statements which do not produce useful outputs for jump
threading. Related to 60902.
Bootstrapped and regression tested on x86_64-unknown-linux-gnu.
Installed on the trunk.
diff --git a/gcc/ChangeLog b/gc
Sorry, ping for maintainer.
We'd do need this for 4.8.3.
Thanks,
Daniel.
On Tue, Apr 22, 2014 at 9:15 AM, Daniel Gutson
wrote:
> Ping for maintainer please.
>
> Thanks,
>
>Daniel.
>
> On Tue, Apr 15, 2014 at 7:05 PM, Daniel Gutson
> wrote:
>> On Tue, Apr 15, 2014 at 6:12 PM, Richard S
Hi,
I've been looking through the regex code and have a few ideas for
simplifications or optimisations that I'd like to share.
This first patch is for _BracketMatcher. We only use std::bitset when
is_same<_CharT, char> so 8 * sizeof(_CharT) should be __CHAR_BIT__
instead. We also only user _Unsi
On Mon, Apr 28, 2014 at 12:44 PM, Julian Brown
wrote:
> On Mon, 28 Apr 2014 11:44:01 +0100
> Ramana Radhakrishnan wrote:
>
>> I've special cased the ffast-math case for the _f32 intrinsics to
>> prevent the auto-vectorizer from coming along and vectorizing addv2sf
>> and addv4sf type operatio
Hi,
On Fri, 25 Apr 2014, Richard Biener wrote:
> Btw, I agree we should stick to one style throughout the code-base.
> The advantage of the cast variant is that it can be made work with
> NULL pointers (in the dyn_cast <> case).
NULL pointers shouldn't even be casted at all, there should be sens
Is there any reason this object is created on the heap?
diff --git a/libstdc++-v3/include/bits/regex_executor.tcc b/libstdc++-v3/include/bits/regex_executor.tcc
index 7f89933..92ca590 100644
--- a/libstdc++-v3/include/bits/regex_executor.tcc
+++ b/libstdc++-v3/include/bits/regex_executor.tcc
@@
On Mon, Apr 28, 2014 at 4:57 AM, Richard Biener
wrote:
> On Fri, Apr 25, 2014 at 5:03 PM, Patrick Palka wrote:
>> I forgot the ChangeLog entry:
>
> Ok.
>
> Thanks,
> Richard.
Thanks for reviewing. May someone please commit this for me? Thanks
in advance.
On Mon, 2014-04-28 at 14:23 +0200, Jakub Jelinek wrote:
> On Mon, Apr 28, 2014 at 01:17:32PM +0200, Mark Wielaard wrote:
> > Ping2. Please let me know if I should ping/cc other people to get this
> > reviewed.
>
> Do you want to add DW_AT_type to DW_TAG_enumeration only if it has explicit
> underl
On Mon, Apr 28, 2014 at 01:17:32PM +0200, Mark Wielaard wrote:
> On Tue, 2014-04-22 at 12:31 +0200, Mark Wielaard wrote:
> > On Mon, 2014-04-14 at 23:19 +0200, Mark Wielaard wrote:
> > > On Fri, 2014-04-11 at 11:03 -0700, Cary Coutant wrote:
> > > > >> The DWARF bits are fine with me.
> > > > >
> >
In this PR graphite scop detection ends up doing make_forwarder_block
on a block with incoming abnormal edges but doesn't want those
"stay" on the forwarder. In the end it is an implementation detail
of make_forwarder_block that fails (because what graphite wants
would be possible - just not usin
On Thu, Apr 17, 2014 at 3:09 PM, Yuri Rumyantsev wrote:
> Hi All,
>
> We implemented enhancement for if-convert phase to recognize the
> simplest conditional reduction and to transform it vectorizable form,
> e.g. statement
> if (A[i] != 0) num+= 1; will be recognized.
> A new test-case is als
On Mon, Apr 28, 2014 at 01:52:08PM +0200, Richard Biener wrote:
> On Thu, Feb 6, 2014 at 2:26 PM, Richard Biener wrote:
> >
> > This adds a builtin for C11 aligned_alloc and support for it
> > in the alias and alignment tracking machinery.
> >
> > Bootstrap and regtest in progress on x86_64-unknow
On 28-04-14 12:47, Tom de Vries wrote:
Hmm, is that just because -fcaller-saves is -O2 and above?
For -O1, after adding -fcaller-saves the optimization triggers, and the
test-cases passes.
For -O0, adding -fcaller-saves doesn't make a difference, the optimization
doesn't trigger.
If so,
On Mon, Apr 28, 2014 at 12:18:05PM +0100, Kyrill Tkachov wrote:
> Hi all,
>
> I noticed this test is failing on aarch64:
>
> FAIL: gcc.dg/pr60114.c (test for warnings, line 7)
> FAIL: gcc.dg/pr60114.c (test for warnings, line 8)
> FAIL: gcc.dg/pr60114.c (test for warnings, line 21)
> FAIL: gcc
On Thu, Feb 6, 2014 at 2:26 PM, Richard Biener wrote:
>
> This adds a builtin for C11 aligned_alloc and support for it
> in the alias and alignment tracking machinery.
>
> Bootstrap and regtest in progress on x86_64-unknown-linux-gnu.
>
> Ok for trunk?
Ping.
> Thanks,
> Richard.
>
> 2014-02-06
On Mon, 28 Apr 2014 11:44:01 +0100
Ramana Radhakrishnan wrote:
> I've special cased the ffast-math case for the _f32 intrinsics to
> prevent the auto-vectorizer from coming along and vectorizing addv2sf
> and addv4sf type operations which we don't want to happen by default.
> Patch 1/3 causes a
Ping
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00590.html
(note that ARM seems to be doing the same thing for their neon
intrinsics, see Ramana's patch series posted today)
On Fri, 11 Apr 2014, Marc Glisse wrote:
Hello,
the previous discussion on the topic was before we added all those #
On Mon, Apr 21, 2014 at 8:28 PM, Christophe Lyon
wrote:
> Hi Ramana,
>
> Here is an updated patch, which adds a README file, some improved
> comments and a few more tests.
> The ChangeLog entry would list the following as new files:
> arm-neon-ref.h
> binary_op.inc
> compute-ref-data.h
> neon-intr
On Wed, 23 Apr 2014, Richard Biener wrote:
>
> This avoids all the complex work on simple things like
> clear_last_verified. It also makes eventually inlining all
> calls (for example the one with the small IPA pass hack)
> less code-duplicating.
>
> I had to remove the asserts in favor of free
This improves VRP of induction variables tested against zero
and handles overflow detection in a less awkward way. It does
that by, instead of dropping to +-INF on iteration, drop to
+INF-1 or -INF+1 and letting the next iteration figure that out.
Bootstrapped and tested on x86_64-unknown-linux-
Hi all,
I noticed this test is failing on aarch64:
FAIL: gcc.dg/pr60114.c (test for warnings, line 7)
FAIL: gcc.dg/pr60114.c (test for warnings, line 8)
FAIL: gcc.dg/pr60114.c (test for warnings, line 21)
FAIL: gcc.dg/pr60114.c (test for warnings, line 22)
FAIL: gcc.dg/pr60114.c (test for w
On Tue, 2014-04-22 at 12:31 +0200, Mark Wielaard wrote:
> On Mon, 2014-04-14 at 23:19 +0200, Mark Wielaard wrote:
> > On Fri, 2014-04-11 at 11:03 -0700, Cary Coutant wrote:
> > > >> The DWARF bits are fine with me.
> > > >
> > > > Thanks. Who can approve the other bits?
> > >
> > > You should prob
On Thu, 24 Apr 2014, Cong Hou wrote:
> Given the following loop:
>
> int a[N];
> short b[N*2];
>
> for (int i = 0; i < N; ++i)
> a[i] = b[i*2];
>
>
> After being vectorized, the access to b[i*2] will be compiled into
> several packing statements, while the type promotion from short to int
>
On 04/26/14 11:57, Kugan wrote:
Attached patch implements TARGET_ATOMIC_ASSIGN_EXPAND_FENV for AARCH64.
With this, atomic test-case gcc.dg/atomic/c11-atomic-exec-5.c now PASS.
This implementation is based on SPARC and i386 implementations.
Regression tested on qemu-aarch64 for aarch64-none-linu
On 04/28/14 11:48, Ramana Radhakrishnan wrote:
Patch 3/3 removes the ML to generate Neon intrinsics and the
documentation and updates the comments in the files to show that these
are now hand crafted rather than auto-generated. We've had these for
many years now and I think it's time we got rid o
Patch 3/3 removes the ML to generate Neon intrinsics and the
documentation and updates the comments in the files to show that these
are now hand crafted rather than auto-generated. We've had these for
many years now and I think it's time we got rid of this. Not everyone
groks ML and it doesn't hel
On 28-04-14 12:26, Richard Sandiford wrote:
Tom de Vries writes:
On 27-04-14 12:27, Richard Sandiford wrote:
Tom de Vries writes:
mips_emit_call_insn (rtx pattern, rtx orig_addr, rtx addr, bool lazy_p)
{
rtx insn, reg;
- insn = emit_call_insn (pattern);
+ emit_call_insn (patter
This then left us in the happy position of being able to delete code
but I was worried about LTO streaming as these "builtins" are
essentially streamed out in LTO object code format. However since we
make no promises about LTO compatibility across releases, that's safe
but I structured the dead co
On Fri, 25 Apr 2014, Martin Jambor wrote:
> Hi,
>
> the patch below is inspired by PR 57297 (the most relevant comments
> are #4 and #5). The problem is that currently SRA creates memory
> loads and stores with alias type of whatever happens to be in
> access->base. However, at least when using
I've special cased the ffast-math case for the _f32 intrinsics to
prevent the auto-vectorizer from coming along and vectorizing addv2sf
and addv4sf type operations which we don't want to happen by default.
Patch 1/3 causes apparent "regressions" in the rather ineffective neon
intrinsics tests th
Hi,
I was investigating a performance issue with Neon intrinsics and
realized this needed to happen.
Patch 1/3 does this. I've special cased the ffast-math case for the
_f32 intrinsics to prevent the auto-vectorizer from coming along and
vectorizing addv2sf and addv4sf type operations whic
After Solaris 9/x86 support is gone from mainline, the Solaris 2
configuration can be massively simplified:
* All Solaris 10+ configurations are bi-arch now.
* The sol2-bi.h configs can be merged into the base configs. For x86,
i386/x86-64.h can be included before i386/sol2.h, which then overr
On 04/25/2014 07:50 PM, Mike Stump wrote:
On Apr 25, 2014, at 9:34 AM, Dimitris Papavasiliou wrote:
--Wreturn-type -Wsequence-point -Wshadow @gol
+-Wreturn-type -Wsequence-point -Wshadow -Wshadow-ivar @gol
This has to be -Wno-shadow-ivar, we document the non-default…
+@item -Wshadow-i
On 04/26/14 11:26, Kugan wrote:
Hi,
Attached patch implements TARGET_ATOMIC_ASSIGN_EXPAND_FENV for ARM. With
this, atomic test-case gcc.dg/atomic/c11-atomic-exec-5.c now PASS.
This implementation is based on SPARC and i386 implementations.
Regression tested on qemu-arm for arm-none-linux-gnuea
Tom de Vries writes:
> On 27-04-14 12:27, Richard Sandiford wrote:
>> Tom de Vries writes:
>>> mips_emit_call_insn (rtx pattern, rtx orig_addr, rtx addr, bool lazy_p)
>>> {
>>> rtx insn, reg;
>>>
>>> - insn = emit_call_insn (pattern);
>>> + emit_call_insn (pattern);
>>> + insn = last_c
On 22 April 2014 10:36, Zhenqiang Chen wrote:
>> +float f1 (float a, float b, float c, float d)
>> +{
>> + if (a > 0.0)
>> +return c;
>> + else
>> +return 2.0;
>> +}
>> +
>> +double f2 (double a, double b, double c, double d)
>> +{
>> + if (a > b)
>> +return c;
>> + else
>> +r
As discussed at http://gcc.gnu.org/ml/gcc/2014-04/msg00241.html, this changes
the compiler to directly emit a 'casa' instruction with an appropriate ASI on
LEON3 and adds the -muser-mode switch.
Tested on SPARC/Solaris and LEON3, applied on mainline, 4.9 and 4.8 branches.
2014-04-28 Eric Botc
Hi Kugan, Thanks for this, couple of comments inline:
On 26 April 2014 11:57, Kugan wrote:
> gcc/
> +2014-04-27 Kugan Vivekanandarajah
> +
> + * config/aarch64/aarch64.c (TARGET_ATOMIC_ASSIGN_EXPAND_FENV): New
> + define.
> + * config/aarch64/aarch64-builtins.c (arm_builtins
Kyrill Tkachov writes:
> The attached patch allowed the build to proceed for me, but in stage 2 I
> encountered an ICE:
>
> $TOP/gcc/dwarf2out.c: In function 'long unsigned int
> _ZL11size_of_dieP10die_struct.isra.209(vec**, long
> unsigned int)':
> $TOP/gcc/dwarf2out.c:7820:1: internal compile
Ping. FWIW this is the last patch I have lined up before the merge.
I repeated the asm comparison test I did a few months ago on one target
per config/ architecture and there were no unexpected changes.
Richard Sandiford writes:
> At the moment we prohibit "widest_int = wide_int" and "offset_int
On Mon, Apr 28, 2014 at 11:05:06AM +0200, Richard Biener wrote:
> On Fri, Apr 25, 2014 at 5:35 PM, Martin Jambor wrote:
> > Hi,
> >
> > the patch below might be useful for testcase preparation and debugging
> > compiler bugs such as PR 60965. When
> > -ftrap-on-impossible-devirtualization is supp
On Fri, Apr 25, 2014 at 5:28 PM, David Malcolm wrote:
> On Fri, 2014-04-25 at 10:37 +0200, Richard Biener wrote:
>> On Thu, Apr 24, 2014 at 4:59 PM, David Malcolm wrote:
>> > On Thu, 2014-04-24 at 09:09 -0400, Andrew MacLeod wrote:
>> >> On 04/24/2014 04:33 AM, Richard Biener wrote:
>> >> > On We
1 - 100 of 107 matches
Mail list logo
