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
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 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
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,
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
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 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
=
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);
>
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, 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 =
> > 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
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
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
...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!
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
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).
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
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
>> 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
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
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
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
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
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
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 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
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]
27 matches
Mail list logo
