On Wed, 2 Apr 2014, Thomas Preud'homme wrote:
Note that as it stands the patch does not work for arrays indexed with
variable (such a tab[a] || (tab[a+1] 8)) because fold_const does not
fold (a + 1) - a.
Uh? It does fold a+1-a for me. What it doesn't do is look through the
definition of b
On Wed, Apr 2, 2014 at 12:27 AM, Joseph S. Myers
jos...@codesourcery.com wrote:
When I fixed various tests in
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01662.html for failures
with --with-arch=bdver3, I missed that a so-configured compiler still
defaults to -mtune=generic. If you override
From: Marc Glisse [mailto:marc.gli...@inria.fr]
Uh? It does fold a+1-a for me. What it doesn't do is look through the
definition of b in b-a. Richard+GSoC will supposedly soon provide a
function that does that.
Oh right, it's a bit more complex here since the array index is converted
to an
Hi DJ,
The patch below is to fix a snafu I made whilst fixing some problems
with the RL78 port a while ago. GCC was generating
(SUBREG (SYMBOL_REF) n) which made no sense to me, so I had the
movqi expander just fail when it encountered them. Now that I have
more idea about why they
Hi!
On Thu, 20 Mar 2014 17:50:13 +0100, Bernd Schmidt ber...@codesourcery.com
wrote:
This is based on Michael Zolotukhin's patch 2/3 from a while ago. It
adds functionality to build function/variable tables that will allow
libgomp to look up offload target code based on the address of the
On Tue, 1 Apr 2014, Mike Stump wrote:
On Mar 31, 2014, at 4:50 AM, Richard Biener rguent...@suse.de wrote:
-$(INSTALL_PROGRAM) xgcc$(exeext)
$(DESTDIR)$(bindir)/$(GCC_INSTALL_NAME)$(exeext)
! -rm -f
$(DESTDIR)$(bindir)/$(target_noncanonical)-gcc-$(version)$(exeext)
! -( cd
On Wed, Apr 2, 2014 at 12:27 AM, Joseph S. Myers
jos...@codesourcery.com wrote:
There are other failures this patch does not resolve in a
--with-arch=bdver3 --with-cpu=bdver3 configuration. Some of these are
AVX tests whose failures are not resolved by adding -mno-prefer-avx128
(and so this
On Wed, 19 Mar 2014, Bill Schmidt wrote:
Hi,
This patch (diff-abi-calls) backports fixes to common code to support
the new ELFv2 ABI. Copying Richard and Jakub for these bits.
Ok.
Thanks,
Richard.
Thanks,
Bill
2014-03-29 Bill Schmidt wschm...@linux.vnet.ibm.com
Backport
On Wed, 19 Mar 2014, Bill Schmidt wrote:
Hi,
This patch (diff-pr54537) backports a fix for PR54537 which is unrelated
but necessary. Copying Richard and Jakub for the common code.
Ok.
Thanks,
Richard.
Thanks,
Bill
[libstdc++-v3]
2014-03-29 Bill Schmidt
On Wed, Apr 2, 2014 at 2:54 AM, Thomas Preud'homme
thomas.preudho...@arm.com wrote:
I took the lack of answer for this patch as an indication that the patch is
too
big. This is the first patch in a series of three. Its purpose is to create
some new
effective target for architecture having
On Wed, Apr 2, 2014 at 9:04 AM, Thomas Preud'homme
thomas.preudho...@arm.com wrote:
From: Marc Glisse [mailto:marc.gli...@inria.fr]
Uh? It does fold a+1-a for me. What it doesn't do is look through the
definition of b in b-a. Richard+GSoC will supposedly soon provide a
function that does
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sorry, I simply queued it in my review queue for stage1 ... it's definitely
something that was high on my wish-list (including of also using
general vector shuffles if available to support even more patterns).
Oh great. Anyway, having
Hi!
On Thu, 20 Mar 2014 17:50:13 +0100, Bernd Schmidt ber...@codesourcery.com
wrote:
This is based on Michael Zolotukhin's patch 2/3 from a while ago. It
adds functionality to build function/variable tables that will allow
libgomp to look up offload target code based on the address of the
Hi!
On Wed, 02 Apr 2014 09:34:29 +0200, I wrote:
On Thu, 20 Mar 2014 17:50:13 +0100, Bernd Schmidt ber...@codesourcery.com
wrote:
This is based on Michael Zolotukhin's patch 2/3 from a while ago. It
adds functionality to build function/variable tables that will allow
libgomp to look up
On Tue, 1 Apr 2014, Jan Hubicka wrote:
This reworks the option to use the Enum support we have now and
adds a =one case (to eventually get rid of one LTO operation mode,
=none ...). I was tempted to support -flto-partition=number
and get rid of --param lto-partitions (thereby also
I noticed that we declare this function, but its definition was
removed in 2009 by P. Bonzini, thus the decl serves no purpose.
Regtested/bootstrapped on x86_64-linux, ok for trunk?
2014-04-02 Marek Polacek pola...@redhat.com
* c-common.h (c_expand_expr): Remove declaration.
diff
On Wed, Apr 2, 2014 at 12:36 PM, Marek Polacek pola...@redhat.com wrote:
I noticed that we declare this function, but its definition was
removed in 2009 by P. Bonzini, thus the decl serves no purpose.
Regtested/bootstrapped on x86_64-linux, ok for trunk?
Ok.
Thanks,
Richard.
2014-04-02
domi...@lps.ens.fr (Dominique Dhumieres) writes:
r...@cebitec.uni-bielefeld.de (Rainer Orth) wrote:
Sure, patch preapproved.
Commited as r208983:
2014-04-01 Dominique d'Humieres domi...@lps.ens.fr
Rainer Orth r...@cebitec.uni-bielefeld.de
PR libgcj/55637
On 25/03/14 15:44, Richard Earnshaw wrote:
On 24/03/14 11:26, Jiong Wang wrote:
This patch enables tail call optimization for long call on arm.
Previously we have too strict check on arm_function_ok_for_sibcall and
be lack of the support on sibcall/sibcall_value expand that long call tail
^Ping...
Regards,
Jiong
On 18/03/14 14:13, Jiong Wang wrote:
Current, indirect function call prevents tail-call optimization on AArch64.
This patch adapt the fix for PR arm/19599 to AArch64.
Is it ok for next stage 1?
Thanks.
-- Jiong
gcc/
* config/aarch64/predicates.md
It is a common mistake to enable both -flto and -fprofile-generate when
building projects. This is not a good idea, because memory use will
skyrocket due to instrumentation. So just warn the user.
OK for next stage1?
2014-04-02 Markus Trippelsdorf mar...@trippelsdorf.de
* common.opt
On Wed, Apr 02, 2014 at 01:50:31PM +0200, Markus Trippelsdorf wrote:
+ if (opts-x_flag_generate_lto opts-x_flag_profile_generate)
+warning_at (loc, 0, Enabling both -fprofile-generate and -flto is a bad
idea.);
s/Enabling/enabling/ + no dot at the end.
Marek
It is a common mistake to enable both -flto and -fprofile-generate when
building projects. This is not a good idea, because memory use will
skyrocket due to instrumentation. So just warn the user.
OK for next stage1?
2014-04-02 Markus Trippelsdorf mar...@trippelsdorf.de
* common.opt
On Wed, Apr 2, 2014 at 1:50 PM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
It is a common mistake to enable both -flto and -fprofile-generate when
building projects. This is not a good idea, because memory use will
skyrocket due to instrumentation. So just warn the user.
OK for next
On Wed, Apr 2, 2014 at 2:07 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Wed, Apr 2, 2014 at 1:50 PM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
It is a common mistake to enable both -flto and -fprofile-generate when
building projects. This is not a good idea, because memory
Markus Trippelsdorf mar...@trippelsdorf.de writes:
diff --git a/gcc/opts.c b/gcc/opts.c
index fdc903f9271a..581d2e948483 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -833,6 +833,9 @@ finish_options (struct gcc_options *opts, struct
gcc_options *opts_set,
error_at (loc, only one
Hi,
recently I've been looking into a number of bugs involving
symtab_remove_unreachable_nodes in one way or another and I have
always started by applying the hunk below. I did this because
distinguishing different symbol nodes only according to their names is
just so inconvenient, especially
Hi,
when dealing with a PR yesterday I have noticed that IPA-SRA was
modifying an always_inline function which is useless work since the
function must then be inlined anyway. Thus I'd like to propose the
following simple change disabling it in such cases.
Included in a bootstrap and testing on
On Wed, 2 Apr 2014, Martin Jambor wrote:
Hi,
recently I've been looking into a number of bugs involving
symtab_remove_unreachable_nodes in one way or another and I have
always started by applying the hunk below. I did this because
distinguishing different symbol nodes only according to
On Wed, 2 Apr 2014, Martin Jambor wrote:
Hi,
when dealing with a PR yesterday I have noticed that IPA-SRA was
modifying an always_inline function which is useless work since the
function must then be inlined anyway. Thus I'd like to propose the
following simple change disabling it in such
Pinging this for stage1, otherwise I'll forget about it and it'll fall through
the cracks...
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01276.html
Thanks,
Kyrill
On 24/03/14 17:21, Kyrill Tkachov wrote:
Hi all,
I noticed that we don't handle simple reg-to-reg arithmetic operations in the
Hi
This patch fixes the push_minipool_fix ICE, which occurs when the ARM
backend encounters a zero/sign extending load from a constant pool.
I don't have a current test case for trunk, lp1296601 has a test case
which affects the linaro-4.8 branch. As far as I know, there has been
no fix for this
Richard Henderson wrote:
On 02/21/2014 08:30 AM, Tejas Belagod wrote:
+ /* If two vectors, we end up with a wierd mixed-endian mode on NEON. */
+ if (BYTES_BIG_ENDIAN)
+ {
+ if (!d-one_vector_p d-perm[i] nunits)
+ {
+ /* Extract the offset. */
+
On 04/01/2014 03:41 PM, Andrew Pinski wrote:
On Tue, Apr 1, 2014 at 3:24 PM, Richard Henderson r...@redhat.com wrote:
Comments? If approved, should this go in for 4.9, or wait for stage1?
Certainly it's self-contained...
On Cavium's thunder processor the cache line size is going to be
On Wed, 2 Apr 2014, Thomas Preud'homme wrote:
+ if { [is-effective-target bswap]
+ ![istarget x86_64-*-*] } {
That x86_64-*-* test is wrong. x86_64-*-* and i?86-*-* should always be
handled the same (if you then want to distinguish 32-bit and 64-bit
multilibs, you check
Hi,
This patch (diff-aix) adds to the 4.8 PowerPC backport patch series with
a few backported fixes from trunk that repair test failures on AIX.
Thanks,
Bill
[gcc]
2014-04-02 Bill Schmidt wschm...@linux.vnet.ibm.com
Backport from mainline r205308
2013-11-23 David Edelsohn
Hi,
Following change fixes gimple production for lambda function, in the
patch I assumed that constructing COMPOUND_EXPR for the return value
of auto type function resoluted to CLASS_TYPE_P is wrong. Tested
x86_64-pc-linux-gnu by applying to trunk with no new regressions.
Thanks, Dinar.
On Apr 2, 2014, at 7:37 AM, Richard Henderson r...@redhat.com wrote:
On 04/01/2014 03:41 PM, Andrew Pinski wrote:
On Tue, Apr 1, 2014 at 3:24 PM, Richard Henderson r...@redhat.com wrote:
Comments? If approved, should this go in for 4.9, or wait for stage1?
Certainly it's
On 28 March 2014 10:20, Eric Botcazou ebotca...@adacore.com wrote:
However, the first call is for blocks with incoming abnormal edges.
If these are empty, the change as I wrote it yesterday is fine, but not
when they are non-empty; in that case, we should indeed insert before the
first
On Wed, 2 Apr 2014, Martin Jambor wrote:
Hi,
recently I've been looking into a number of bugs involving
symtab_remove_unreachable_nodes in one way or another and I have
always started by applying the hunk below. I did this because
distinguishing different symbol nodes only
Hi,
On Wed, Apr 02, 2014 at 06:08:27PM +0200, Jan Hubicka wrote:
On Wed, 2 Apr 2014, Martin Jambor wrote:
Hi,
recently I've been looking into a number of bugs involving
symtab_remove_unreachable_nodes in one way or another and I have
always started by applying the hunk below.
Hmm, the sanity check in new_seginfo caused a boostrap failure
building libjava on x86.
There was a block with CODE_LABEL as basic block head, otherwise empty.
If you test an x86_64 toolchain with -march=bdver3 in the multilib
options, as noted in
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01662.html various test
failures arise from tests whose own -march= in dg-options is
overridden. This patch adds dg-skip-if to those tests to skip them
for
On 2 April 2014 14:29, Charles Baylis charles.bay...@linaro.org wrote:
Tested on arm-unknown-linux-gnueabihf (qemu), bootstrap in progress.
bootstrapped successfully on a Chromebook arm-unknown-linux-gnueabihf.
On 2 April 2014 17:34, Joern Rennecke joern.renne...@embecosm.com wrote:
Hmm, the sanity check in new_seginfo caused a boostrap failure
building libjava on x86.
There was a block with CODE_LABEL as basic block head, otherwise empty.
I've added the testcase - and a bit more detail on this issue
As recently pointed out in a thread porting libitm to aarch64, the PAGE_SIZE
and FIXED_PAGE_SIZE macros are unused. Indeed, not all of the ports actually
defined them at all.
Removed, lest they cause further confusion.
r~
* config/alpha/target.h (PAGE_SIZE, FIXED_PAGE_SIZE): Remove.
Hello,
this fixes the following testsuite regression on spu-elf:
FAIL: g++.dg/torture/pr57499.C -O1 (internal compiler error)
which was caused by a code path in pad_bb that would simply crash
if the very last active insn in a function happened to be a
blockage.
Tested on spu-elf, committed to
Hello,
this fixes the following regressions on spu-elf:
FAIL: gcc.dg/pr48335-2.c (internal compiler error)
FAIL: gcc.dg/pr48335-3.c (internal compiler error)
which are caused by common code calling the insv pattern with a
combination of bitoffset/bitsize that lies partially outside the
*PING*
Tobias Burnus wrote:
H.J. Lu wrote:
On Fri, Mar 28, 2014 at 12:41 PM, Mike Stump mikest...@comcast.net
wrote:
Since we are nearing release, I thought I'd mention I see:
../../gcc/gcc/doc/invoke.texi:1114: warning: node next `Overall
Options' in menu `C Dialect Options' and in
Use of STB_GNU_UNIQUE to avoid problems with variable symbols shared
between two RTLD_LOCAL plugins and a common library dependency causes
problems with libraries that depend on dlclose/dlopen to reinitialize
state. This patch adds a -fno-gnu-unique flag that such libraries can use.
Tested
On Wed, Apr 2, 2014 at 6:36 PM, Joseph S. Myers jos...@codesourcery.com wrote:
If you test an x86_64 toolchain with -march=bdver3 in the multilib
options, as noted in
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01662.html various test
failures arise from tests whose own -march= in dg-options
Two of the tests I noted in
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00036.html did not get
fixed for --with-arch=bdver3 --with-cpu=bdver3 by adding
-mno-prefer-avx128 in fact also show failures for --with-arch=btver2
--with-tune=btver2, and in that case *are* fixed by adding
On Wed, Apr 2, 2014 at 10:09 PM, Joseph S. Myers
jos...@codesourcery.com wrote:
Two of the tests I noted in
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00036.html did not get
fixed for --with-arch=bdver3 --with-cpu=bdver3 by adding
-mno-prefer-avx128 in fact also show failures for
This is OK. Thanks!
2014-03-31 23:48 GMT+02:00 Jason Merrill ja...@redhat.com:
[...]
if (permerror (input_location,
default argument given for parameter
%d of %q#D, i, newdecl))
permerror (DECL_SOURCE_LOCATION (olddecl),
previous
I would like to ping the following two patches of Jakub. As he wrote in
PR60667:
The http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01370.html fix is still
waiting for review, you need that for both
--with-build-config=bootstrap-ubsan and --with-build-config=bootstrap-asan.
For
Dear All,
This fix, of itself, is quite obvious. The offset was being set to
zero for array segments, rather than that required for unity valued
lvalues.
I think that the fix could be used to clean up:
trans-expr.c(gfc_trans_alloc_subarray_assign)
trans-expr.c(gfc_trans_pointer_assign)
On 04/02/2014 04:21 PM, Fabien Chêne wrote:
* cp/decl.c (duplicate_decls): Check for the return of
permerror before emitting a note.
You don't need cp/ within cp/ChangeLog. OK with that change.
Jason
The following patch fixes the PR for new set of options.
The details of the problem can be found on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60650
The patch affects a sensitive part for LRA. Therefore I bootstrapped
and tested it on x86-64, aarch64, arm, s390, and Ppc64. The results
PR60733 identifies a case where straight-line strength reduction
produces code that doesn't satisfy SSA verification. For a PHI
candidate, the insertion of an initializer for a stride calculation
along an incoming arc was specified to be at the point of the feeding
definition of the PHI along
Hi,
when dealing with a PR yesterday I have noticed that IPA-SRA was
modifying an always_inline function which is useless work since the
function must then be inlined anyway. Thus I'd like to propose the
following simple change disabling it in such cases.
Included in a bootstrap and
On Wed, Apr 2, 2014 at 2:07 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Wed, Apr 2, 2014 at 1:50 PM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
It is a common mistake to enable both -flto and -fprofile-generate when
building projects. This is not a good idea, because
Hi,
I just merged trunk r209020 into the gimple-front-end branch, please
tell me if you see anything busted ;)
I successfully bootstrapped the merge including building the gimple front
end and its few tests passed.
Trev
signature.asc
Description: Digital signature
This patch does three related things for the moxie port...
1. Changes char to be unsigned by default
2. Changes WCHAR_TYPE from long int to unsigned int
3. Zero- and sign-extends values properly, sometimes using the new
sign-extension instructions.
I am committing this change even at this
Hi,
this patch fixes ICE on type inconsistent code. The ICE happens because of
gcc_unreachable I forgot in code during development. I added way to mark calls
as inconsistent that is useful to redirect them to UNREACHABLE.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
*
From: Richard Biener [mailto:richard.guent...@gmail.com]
More like isn't enough to answer this - do you have a testcase? (usually
these end up in undefined-overflow and/or conversion-to-sizetype issues)
I do. See attachment. This testcase needs to be compiled with patch 2/3
applied. As you
From: Joseph Myers [mailto:jos...@codesourcery.com]
+ if { [is-effective-target bswap]
+ ![istarget x86_64-*-*] } {
That x86_64-*-* test is wrong. x86_64-*-* and i?86-*-* should always be
handled the same (if you then want to distinguish 32-bit and 64-bit
multilibs,
67 matches
Mail list logo
