"Pinski, Andrew" 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, thanks.
Richard
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 sligh
"Pinski, Andrew" 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 (match_operand:DI 1 "re
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
* iso-c-binding.def (C_PTRDIFF_T): New TS29113 parameter.
* intrinsic.texi (I
Andrew Pinski 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
> adjust_address. Thi
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)
+++ g
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 Jan-Benedict
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
>
On Jul 17, 2012, Richard Henderson 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.
Thanks.
> P
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.
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 eff
On Fri, Jul 20, 2012 at 12:41 AM, Richard Henderson 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 this ex
On Sat, 2012-07-21 at 14:41 +0200, Steven Bosscher wrote:
> On Fri, Jul 20, 2012 at 12:41 AM, Richard Henderson 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
On Sat, Jul 21, 2012 at 3:10 PM, Oleg Endo 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.
Ciao!
Steven
On Sat, 2012-07-21 at 15:12 +0200, Steven Bosscher wrote:
> On Sat, Jul 21, 2012 at 3:10 PM, Oleg Endo 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
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 ne
On Sat, Jul 21, 2012 at 10:53 AM, Tobias Burnus wrote:
> 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?
Ok. Thanks for the patch.
--
Janne Blomqvist
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): E
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: gcc/c
On Sat, Jul 21, 2012 at 9:12 AM, Iain Sandoe 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?
This was only d
Hi Andrew,
On 21 Jul 2012, at 17:43, Andrew Pinski wrote:
> On Sat, Jul 21, 2012 at 9:12 AM, Iain Sandoe 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 i68
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
On Sat, Jul 21, 2012 at 10:27 AM, 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
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
On Sat, Jul 21, 2012 at 10:56 AM, Iain Sandoe 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 code. Th
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 enoug
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
===
--- gcc/config/sh/s
On Thu, Jul 19, 2012 at 8:45 PM, Alan Modra 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 constraint from m
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") )
] 229)
(cons
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.
Index
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 c
Committed as obvious.
Index: ChangeLog
===
--- ChangeLog (revision 189747)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2012-07-21 Steven Bosscher
+
+ PR gcov-profile/32543
+ * profile.c (branch_prob): Update total_
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?
Cheers,
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 Pinski
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
* gcc.dg/tree-ssa/vrp72.c: New test.
38 matches
Mail list logo
