Hi,
This is a ping for: https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00772.html
Regtested with aarch64-linux-gnu on QEMU.
This patch has no regressions for aarch64_be-linux-gnu big-endian target too.
OK for the trunk?
Thanks.
Jiang jiji
--
Re: [PING^2] [PATCH] [AArch64, NEON]
On 08/04/15 20:11 +0100, Jonathan Wakely wrote:
diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index 5871716..39d6866 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -2,7 +2,8 @@
* include/std/shared_mutex (shared_timed_mutex): Add comments to
ex
On 27/03/15 12:45 +, Jonathan Wakely wrote:
This is a tiny tweak to add a missing piece of C++14 support, the
duration literals should be usable via "using namespace std::chrono".
It doesn't affect anything in C++03 or C++11 mode so safe for trunk
now.
Tested x86_64-linux, committed to trunk
On 26/03/15 19:59 +, Jonathan Wakely wrote:
We have a couple of bugs where durations with unsigned representations
result in negative or huge time_t values, which result in not sleeping
at all or sleeping for billions of years (or merely for decades if you
have a 32-bit time_t).
This change
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the French team of translators. The file is available at:
http://translationproject.org/latest/gcc/fr.po
(This file, 'gcc-5.1-b20150208.fr.po', h
Hi Benno,
I tested your fixes on i386-unknown-freebsd10.1 -- you never
know, after some of these could have been reflected in some
test case for example -- and committed them on your behalf.
Sorry for none of us looking into this for so long. If you
find further typos or phrases that need improv
OK, here is a new version.
There is now an option for setting a maximum on the array size,
which takes its default from the BLAS limit (if specified).
Currently, only setting the maximum size to zero as a way of
disabling the unrolling is supported. I have done this in a
few test cases.
The bug
On Fri, 10 Apr 2015, Caroline Tice wrote:
> I would appreciate it if you would do it.
Okay. Here is the (somewhat shortened) patch I just committed.
Index: news.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/news.html,v
retrieving revis
>> The following links are broken at gcc.gnu.org/onlinedocs/4.9.2. The
>> corresponding 4.9.2-related links at gcc.gnu.org/onlinedocs are also broken:
>>GCC 4.9.2 GNAT User's Guide (/onlinedocs/gcc-4.9.2/gnat_ugn_unw/)
>>also in PDF (/onlinedocs/gcc-4.9.2/gnat_ugn_unw.pdf)
>>or Posts
Hello, I haven't looked at the patch in detail yet, but...
Le 11/04/2015 14:24, Thomas Koenig a écrit :
> Still to do: Bounds checking (a rather big one),
... as you do a front-end to front-end transformation, you get bounds
checking for free, don't you?
Mikael
On Sat, 11 Apr 2015, Arnaud Charlet wrote:
> Your patch looks good to me.
Thanks for the quick response, Arnaud.
It turns out we also had the same problem with mainline, just
that gnat_ugn_unw/ still existed there in it's old version from
summer 2014.
I have removed that stale copy on gcc.gnu
On Thu, Apr 09, 2015 at 06:37:01PM +0400, Kirill Yukhin wrote:
> gcc/
> * config/i386/sse.md: Generate vextract32x4 if AVX-512DQ
> is disabled.
>
> gcc/testsuite/
> * gcc.target/i386/pr65671.c: New.
The testcase fails if gas doesn't have AVX512VL support (my only has
AVX512F).
Hi!
The following patch fixes a bunch of issues in
cxx_eval_pointer_plus_expression:
1) as it does STRIP_NOPS, the pointed type can change, and thus the
op01 constant in p+ might not be divisible by the other type size
2) we should restore the original type, rather than returning expression
...as I had suggested and discussed with here in, umm, 2012.
Luckily my backlog really is going down now...
Committed.
Gerald
2015-04-11 Gerald Pfeifer
* doc/contrib.texi (Contributors): Add Ira Rosen.
Index: doc/contrib.texi
===
Hi!
On the following testcase, starting with r221675 aka PR65177 fix
we get ICE, because FSM discovery finds a path that includes the same blocks
multiple times, like:
Registering FSM jump thread: (9, 4) incoming edge; (4, 5) (5, 12) (12, 14)
(14, 5) (5, 12) nocopy; (5, 12)
All these bbs b
Hi Mikael,
>> Still to do: Bounds checking (a rather big one),
> ... as you do a front-end to front-end transformation, you get bounds
> checking for free, don't you?
Only partially.
What the patch does is
integer i,j,k
c = 0
do j=0, size(b,2)-1
do k=0, size(a, 2)-1
> > 2015-04-10 Martin Liska
> >
> > * g++.dg/ipa/pr65722.C: New test.
> >
> > gcc/ChangeLog:
> >
> > 2015-04-10 Martin Liska
> >
> > PR ipa/65722
> > * ipa-icf.c (sem_variable::equals_wpa): Consider comparsion just
> > for references coming from cgraph nodes.
>
> Please a
On Sat, 11 Apr 2015, Jakub Jelinek wrote:
@@ -1391,13 +1391,13 @@ thread_through_normal_block (edge e,
vec *bb_path;
vec_alloc (bb_path, n_basic_blocks_for_fn (cfun));
vec_safe_push (bb_path, e->dest);
- hash_set *visited_phis = new hash_set;
+ hash_set *visited_bbs =
On April 11, 2015 6:34:43 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>On the following testcase, starting with r221675 aka PR65177 fix
>we get ICE, because FSM discovery finds a path that includes the same
>blocks
>multiple times, like:
>Registering FSM jump thread: (9, 4) incoming edge; (4, 5) (
On Sat, Apr 11, 2015 at 07:19:00PM +0200, Marc Glisse wrote:
> On Sat, 11 Apr 2015, Jakub Jelinek wrote:
>
> >@@ -1391,13 +1391,13 @@ thread_through_normal_block (edge e,
> > vec *bb_path;
> > vec_alloc (bb_path, n_basic_blocks_for_fn (cfun));
> > vec_safe_push (bb_path, e->dest);
>
Hi Tobias,
On Fri, 6 Feb 2015, Tobias Burnus wrote:
> I think it is useful to know that one can build libcc1.so - also as
> advertisement. Thus, I propose to include something like the quip in
> the attachment.
Index: htdocs/gcc-5/changes.html
=
gcc/config/openbsd.h:143:18: error: ‘OBSD_LIB_SPEC’ was not declared in
this scope
#define LIB_SPEC OBSD_LIB_SPEC
^
gcc/gcc.c:879:31: note:
in expansion of macro ‘LIB_SPEC’
static const char *lib_spec = LIB_SPEC;
^
make[2]: *** [gcc.o] Error 1
Is
Hi,
I'd like to ask an RM or global reviewer to kindly consider the
following patches preventing one or the other target in config-list.mk
to build:
[PATCH, bfin] handle BFIN_CPU_UNKNOWN in TARGET_CPU_CPP_BUILTINS
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00034.html
[PATCH, c6x] handle unk_i
This is a patch by Martin Uecker, which I just committed.
Gerald
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
retrieving revision 1.102
diff -u -r1.102 changes.html
--- changes.html10 Apr 2015
Hi,
this is version of patch I comitted after testing at x86_64-linux firefox build
and bootstrapped/regtested ppc64-linux.
Honza
Jan Hubicka
Martin Liska
PR ipa/65722
* g++.dg/ipa/pr65722.C: New testcase.
* ipa-icf.c (sem_item::compare_cgraph_referen
On Wed, 8 Apr 2015 21:13:10 +0200 (CEST), Gerald Pfeifer wrote:
> On Wed, 27 Apr 2011, Michael Witten wrote:
>> ---
>> trunk/gcc/doc/extend.texi |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/trunk/gcc/doc/extend.texi b/trunk/gcc/doc/extend.texi
>> index eddff9
Hi,
this patch fixes two issues that reproduce with firefox build configured for
LTO&FDO
with -O3 -march=native on bdver2 (but probably elsewhere too).
The first is an ICE on out of bound accesss of jump functions. This is becuase
inline_call uses speculation_useful_p which in turn evaulates pred
27 matches
Mail list logo
