Pinski, Andrew andrew.pin...@caviumnetworks.com writes:
+ /* If TARGET_64BIT, the destination of a 32-bit extz or extzv will
+ be a DImode, create a new temp and emit a zero extend at the end. */
emit an extend, since it can be signed or unsigned. OK with that change.
Nice optimisation,
Hi,
The problem here is that adjust_address returns the same rtl as we
already have a BLKmode; mips_block_move_straight pass a BLKmode MEM to
mips_expand_ext_as_unaligned_load.
The following patch fixes the problem by copying the MEM after calling
adjust_address. This does increase garbage
Pinski, Andrew andrew.pin...@caviumnetworks.com writes:
+;; The POP instruction is special as it does not take into account the upper
+;; 32bits and is documented that way.
+(define_insn *popcountdi2_trunc
+ [(set (match_operand:SI 0 register_operand =d)
+ (popcount:SI (truncate:SI
TS 29113 adds (a bit hidden in 9.9 Edits to clause 15) a new
ISO_C_Binding parameter: C_PTRDIFF_T.
Build, tested, and currently regtesting on x86-64-gnu-linux.
OK for the trunk?
Tobias
2012-07-21 Tobias Burnus bur...@net-b.de
* iso-c-binding.def (C_PTRDIFF_T): New TS29113 parameter.
*
Andrew Pinski pins...@gmail.com writes:
The problem here is that adjust_address returns the same rtl as we
already have a BLKmode; mips_block_move_straight pass a BLKmode MEM to
mips_expand_ext_as_unaligned_load.
The following patch fixes the problem by copying the MEM after calling
Passing TREE_TYPE() to a Boolean work in C++, but fails in C. Besides,
passing a true makes more sense.
Committed (Rev. ) as obvious.
Tobias
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c (Revision 189738)
+++
I build the Fortran-dev branch with C, and it failed because of the
previous Boolean issue, but also because decl-ordering issue, addressed
by the attachment. I initially thought that the latter is a merge issue,
but as it isn't, I have now fixed it first on the trunk – and then
backported the
Hi!
I currently see
warning: implicit declaration of function ‘frv_ifcvt_machdep_init’
while gcc/ifcvt.c and
warning: no previous prototype for ‘frv_ifcvt_machdep_init’
while gcc/config/frv/frv.c are built. The following patch fixes it.
MfG, JBG
gcc/
2012-07-21
On 20/07/2012 22:03, Mikael Morin wrote:
On 20/07/2012 20:16, Mikael Morin wrote:
I have started a regression test.
OK for trunk if it passes?
Unfortunately, it fails with errors like:
/home/mik/gcc4x/src/gcc/testsuite/gfortran.dg/char_pack_1.f90:55.10:
do i = i + 1, nv
1
On Jul 17, 2012, Richard Henderson r...@redhat.com wrote:
On 07/17/2012 02:36 PM, Alexandre Oliva wrote:
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00300.html
... except that post has patch 1 repeated as patch 3.
The actual patch 3 is missing.
That said, the first two patches are ok.
On 20/07/2012 12:19, Tobias Burnus wrote:
Mikael: I wouldn't mind if you could have a look at the scalarizer - you
seem to have an idea how one can implement it with minimal effort/code
cluttering.
This is exaggerated. I just said that the scalarizer can't generate a
variable number of loops.
I
Mikael Morin wrote:
On 20/07/2012 12:19, Tobias Burnus wrote:
Build and regtested on x86-64-linux.
OK for the trunk?
OK.
Thanks! Committed as Rev. 189743.
Mikael: I wouldn't mind if you could have a look at the scalarizer - you
seem to have an idea how one can implement it with minimal
On Fri, Jul 20, 2012 at 12:41 AM, Richard Henderson r...@redhat.com wrote:
Notes for future cleanups:
+ /* If the targer has no lshift in word_mode, the operation will most
+ probably not be cheap. ??? Does GCC even work for such targets? */
Yes, it does. We're perfectly happy to let
On Sat, 2012-07-21 at 14:41 +0200, Steven Bosscher wrote:
On Fri, Jul 20, 2012 at 12:41 AM, Richard Henderson r...@redhat.com wrote:
Notes for future cleanups:
+ /* If the targer has no lshift in word_mode, the operation will most
+ probably not be cheap. ??? Does GCC even work for
On Sat, Jul 21, 2012 at 3:10 PM, Oleg Endo oleg.e...@t-online.de wrote:
to handle the const reg case. Or would it be better to make the
lshift_cheap_p try out more shifty things?
The simpler lshift_cheap stays, the better. It's already warty to have
to look at rtx_cost in a GIMPLE pass.
Jakub,
this patch adds propagation of anti-ranges to switches.
The test-case is this:
...
void
f3 (int s)
{
if (s 3 == -2)
/* s in range [ -16, -9]. */
;
else
{
/* s in range ~[-16, -9], so none of the case labels can be taken. */
switch (s)
{
case
On Fri, 20 Jul 2012 22:24:57 -0400 (EDT), Hans-Peter wrote:
Sounds like a good idea, but I think you shouldn't limit that to
{} but rather introduce \ to escape and cause any next
character to be emitted as-is, in particular |.
I had dropped the change to escape | thinking it wasn't needed --
Hi,
The PPC port can handle -mcpu=native.
The patch below enables its use at config time,
OK for trunk?
thanks,
Iain
gcc:
* config.gcc (powerpc*-*-* | rs6000-*-*): Allow 'native' as a
valid configured CPU choice.
Index: gcc/config.gcc
Hi,
The following patch was been in use internally, for some time, to handle two
further cases where the processor does not have lwsync. Verified on a cross
from i686-linux-gnu to powerpc-linux-gnu.
OK for trunk?
thanks,
Iain
gcc/
* config/rs6000/rs6000.h (TARGET_NO_LWSYNC):
Hi,
At present, if a G5 or 970 processor is selected (-mcpu=), we can (and do)
generate 64 bit register usage for m32 code. This appears to be a
long-standing bug.
OK for trunk all open branches?
Iain
gcc/
* config/rs6000/darwin.h (OS_MISSING_POWERPC64): New.
Index:
On Sat, Jul 21, 2012 at 9:12 AM, Iain Sandoe i...@codesourcery.com wrote:
Hi,
The following patch was been in use internally, for some time, to handle two
further cases where the processor does not have lwsync. Verified on a cross
from i686-linux-gnu to powerpc-linux-gnu.
OK for trunk?
Hi Andrew,
On 21 Jul 2012, at 17:43, Andrew Pinski wrote:
On Sat, Jul 21, 2012 at 9:12 AM, Iain Sandoe i...@codesourcery.com wrote:
Hi,
The following patch was been in use internally, for some time, to handle two
further cases where the processor does not have lwsync. Verified on a cross
On Jul 21, 2012, at 9:12 AM, Iain Sandoe wrote:
At present, if a G5 or 970 processor is selected (-mcpu=), we can (and do)
generate 64 bit register usage for m32 code. This appears to be a
long-standing bug.
Hum, do you have an example of something that fails? I ask, cause I think the
if
On Sat, Jul 21, 2012 at 10:27 AM, Mike Stump mikest...@comcast.net wrote:
On Jul 21, 2012, at 9:12 AM, Iain Sandoe wrote:
At present, if a G5 or 970 processor is selected (-mcpu=), we can (and do)
generate 64 bit register usage for m32 code. This appears to be a
long-standing bug.
Hum,
Hi Mike,
On 21 Jul 2012, at 18:27, Mike Stump wrote:
On Jul 21, 2012, at 9:12 AM, Iain Sandoe wrote:
At present, if a G5 or 970 processor is selected (-mcpu=), we can (and do)
generate 64 bit register usage for m32 code. This appears to be a
long-standing bug.
Hum, do you have an
On Sat, Jul 21, 2012 at 10:56 AM, Iain Sandoe i...@codesourcery.com wrote:
Hi Mike,
On 21 Jul 2012, at 18:27, Mike Stump wrote:
On Jul 21, 2012, at 9:12 AM, Iain Sandoe wrote:
At present, if a G5 or 970 processor is selected (-mcpu=), we can (and do)
generate 64 bit register usage for m32
On 21 Jul 2012, at 19:02, Andrew Pinski wrote:
If there's a different mechanism for enforcing what's implied above, then we
could use
Yes HARD_REGNO_CALL_PART_CLOBBERED should work. If that is not
working there is a bug somewhere else in the compiler.
thanks, that looks solid enough,
Hello,
I have just committed the attached patch as obvious as rev 189747.
Cheers,
Oleg
ChangeLog:
* config/sh/sh.md: Correct comment regarding clrt and sett
insns.
Index: gcc/config/sh/sh.md
===
---
On Thu, Jul 19, 2012 at 8:45 PM, Alan Modra amo...@gmail.com wrote:
This on the other hand works. Please consider the patch amended to
remove mem_operand_fpr, the 'wY' constraint, and uses thereof replaced
with m.
What, exactly, is the current proposed patch? Remove offsettable
address
Hi,
MIPS does not currently implement a mips_delegitimize_address target hook and
for n64, a RTL is produced which the standard delegitimize cannot handle:
(const:DI (plus:DI (unspec:DI [
(symbol_ref:DI (s) var_decl 0x7fe08a5a3140 s)
] 229)
Hello,
The attached patch folds the negc expander and *negc insn.
Tested with 'make all'. CSiBE result-size (-m4-single -ml
-mpretend-cmove) also doesn't show any change.
OK?
Cheers,
Oleg
ChangeLog:
* config/sh/sh.md (negc): Delete expander.
(*negc): Rename insn to negc.
Hello,
This patch cleans up some interesting things in GCC's profiling
support. The most significant changes are the removal of
BB_TO_GCOV_INDEX and after_tree_profile. Another visible cleanup is
that -profile-generate no longer sets
flag_value_profile_transformations.
The rest is mostly just
Committed as obvious.
Index: ChangeLog
===
--- ChangeLog (revision 189747)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2012-07-21 Steven Bosscher steven at gcc dot gnu dot org
+
+ PR gcov-profile/32543
+ *
Hello,
Currently the check for availability of dynamic shift instructions on a
particular SH target is repeated in several places. The attached patch
adds a new macro for that.
Tested with 'make all'. CSiBE result-size (-m4-single -ml
-mpretend-cmove) also doesn't show any change.
OK?
Hi,
I thought I would add these two aliasing testcases which I have in
Cavium's private tree for a while now. They both pass since the
addition of MEM_REF.
Committed as obvious after a bootstrap and test on x86_64-linux-gnu
with no regressions.
Thanks,
Andrew Pinski
2012-07-21 Andrew
Hi,
We (Cavium) has had these VRP testcases in our testsuite for a while
and I found they pass without any patches.
Committed as obvious after a test on x86_64-linux-gnu with no regressions.
Thanks,
Andrew Pinski
2012-07-21 Andrew Pinski apin...@cavium.com
*
36 matches
Mail list logo
