Hi,
There is an off by one error in neon_evpc_vrev which means it
rarely gets triggerred. The problem is that if you are looking at
d-perm [i +j] and you increment i by just diff you end up starting
looking where you looked at the end of the last place where you
checked. Given this I
To have the name of the types of the variant part and the fields therein be
unique instead of mere duplicates of those of the base type, which makes it
easier to debug type merging issues in LTO mode.
Tested on i586-suse-linux, applied on the mainline, 4.7 and 4.6 branches.
2012-05-26 Eric
There is one more goto in the .optimized dump because the latch of a loop is
now preserved.
Tested on i586-suse-linux, applied on the mainline.
2012-05-26 Eric Botcazou ebotca...@adacore.com
* gnat.dg/renaming5.adb: Adjust dg-final directive.
--
Eric Botcazou
Index:
The problem is that the new call to cleanup_cfg in gimple_expand_cfg has
short-circuited the machinery that emits nops to carry goto locus at -O0.
The machinery works in CFGLAYOUT mode, but here we're still in CFGRTL.
The attached patch makes it so that forwarder blocks are not deleted by
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 2cecf45..9d6983b 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -7131,6 +7131,8 @@ arm_rtx_costs_1 (rtx x, enum rtx_code outer, int*
total, bool speed)
*total = COSTS_N_INSNS (2);
else if
Il 25/05/2012 12:20, Dinar Temirbulatov ha scritto:
+ emit_store_flag_force (c, GT, u0, tmp, mode, 1, 1);
+ emit_store_flag_force (c1, GT, u1, tmp, mode, 1, 1);
+ result = expand_binop (mode, ior_optab, c, c1, cres, 1,
OPTAB_LIB_WIDEN);
+ if (!result)
+ return
Il 26/05/2012 14:35, Paolo Bonzini ha scritto:
/* We have to return
z2 + ((u0 + u1) GET_MODE_BITSIZE (word_mode)).
u0 + u1 are the upper two words of the three-word
intermediate result and they could have up to
2 * GET_MODE_BITSIZE
Hi,
I found the time to return to this issue, where -Wmissing-braces is
often overeager to warn, thus annoying, for example, people using -Wall
together with std::array:
std::arrayint, 3 s = { 1, 2, 3 };
I handle the issue following the letter of the suggestion given by Ian
at the
Hi,
As described in PR53447, many 64bit ALU operations with constant can be
optimized to use corresponding 32bit instructions with immediate operands.
This is the first part of the patches that deals with 64bit add. It directly
extends the patterns adddi3, arm_adddi3 and adddi3_neon to handle
I think I would rather fix stabilize_expr to handle void arguments
properly: basically just stick the whole argument in *initp and return
void_zero_node.
Jason
On Mon, May 21, 2012 at 9:33 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Apr 11, 2012 at 7:35 AM, Bernd Schmidt ber...@codesourcery.com
wrote:
On 12/23/2011 05:31 PM, Vladimir Makarov wrote:
On 12/21/2011 09:09 AM, Bernd Schmidt wrote:
This patch was an experiment to see if we can get the
On 05/26/2012 04:21 PM, Jason Merrill wrote:
I think I would rather fix stabilize_expr to handle void arguments
properly: basically just stick the whole argument in *initp and return
void_zero_node.
Ok. Like this it works, if I understand your suggestion.
Thanks,
Paolo.
On 05/26/2012 11:31 AM, Paolo Carlini wrote:
Ok. Like this it works, if I understand your suggestion.
Yep, that's what I had in mind. But let's put it after the
!TREE_SIDE_EFFECTS case. OK with that change.
Jason
On Sat, 26 May 2012, Jason Merrill wrote:
In C++, C99 a compound literal creates a temporary object, unlike C, where it
creates an automatic or static object. As a result, using an array compound
literal to initialize a pointer variable leads to undefined behavior, as the
array's lifetime
Hello,
I happened to notice these typos but I don't have commit rights.
Thanks to whoever might pick it up.
-- Oliver
2012-05-26 Oliver Kellogg okell...@users.sourceforge.net
* alloc.ads, exp_dbug.adb, gcc-interface/misc.c, lib.ads, lib-xref.adb,
lib-xref.ads, sem_ch10.adb, sem_ch12.adb,
On Fri, May 25, 2012 at 10:05 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, May 25, 2012 at 8:38 PM, Sriraman Tallam tmsri...@google.com wrote:
On May 25, 2012 7:15 PM, H.J. Lu hjl.to...@gmail.com wrote:
On May 25, 2012 6:54 PM, Sriraman Tallam tmsri...@google.com wrote:
On Fri,
... and this is the version of the patch which simply takes
-Wmissing-braces out of -Wall in C++. Bootstrapped and tested all
C-family languages x86-64-linux.
Paolo.
///
Index: doc/invoke.texi
===
---
On Sat, May 26, 2012 at 3:34 PM, Sriraman Tallam tmsri...@google.com wrote:
On Fri, May 25, 2012 at 10:05 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, May 25, 2012 at 8:38 PM, Sriraman Tallam tmsri...@google.com wrote:
On May 25, 2012 7:15 PM, H.J. Lu hjl.to...@gmail.com wrote:
On May 25,
On Sat, May 26, 2012 at 4:56 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sat, May 26, 2012 at 3:34 PM, Sriraman Tallam tmsri...@google.com wrote:
On Fri, May 25, 2012 at 10:05 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, May 25, 2012 at 8:38 PM, Sriraman Tallam tmsri...@google.com
wrote:
On
Hi,
I still had some cleanups for age-old code lying around, and thought to
bring it up to date. The whole dealing of slots for temporary stack space
in function.c was never really updated to the way we're meanwhile
expanding statements. It has facilities that aren't useful anymore. In
the
Hi,
and this is the large cleanup, removing dead code introduced by [1/3] for
real, and removing the 'keep' parameter from assign_temp and friends,
which now is always zero (in the compiler proper and in the backends).
That latter is the largest churn.
If [1/3] is approved this whole patch is
Hi,
and this is a further small cleanup. pop_temp_slots is now the same as
free_temp_slots (modulo the level-- of course), so there's no need in
calling both. (and preserve_temp_slots(NULL) is useless now).
Regstrapped on x86_64-linux together with [1/3] and [2/3], all languages
On Sat, May 26, 2012 at 5:23 PM, Sriraman Tallam tmsri...@google.com wrote:
On Sat, May 26, 2012 at 4:56 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sat, May 26, 2012 at 3:34 PM, Sriraman Tallam tmsri...@google.com wrote:
On Fri, May 25, 2012 at 10:05 PM, H.J. Lu hjl.to...@gmail.com wrote:
On
On Sat, May 26, 2012 at 7:06 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sat, May 26, 2012 at 5:23 PM, Sriraman Tallam tmsri...@google.com wrote:
On Sat, May 26, 2012 at 4:56 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sat, May 26, 2012 at 3:34 PM, Sriraman Tallam tmsri...@google.com
wrote:
On
On Sat, May 26, 2012 at 7:23 PM, Sriraman Tallam tmsri...@google.com wrote:
Ｔhat is because libgcc_s.so is preferred by g++. We can do one
of 3 things:
1. Abuse libgcc_eh.a by moving __cpu_model and __cpu_indicator_init
from libgcc.a to libgcc_eh.a.
2. Rename libgcc_eh.a to libgcc_static.a
Hi,
[for certain test cases :-) ]
the temp slot cleanups I just sent where actually motivated by PR38474.
It exposes many slownesses in the compiler, but at -O0 the only remaining
one is the expand phase. expanding variables is the one thing (on my
machine here, with -O0 -g f951): 30
Hi,
On Fri, 25 May 2012, NightStrike wrote:
This point of yours should be stressed. Using writing standards of
one language to develop in another language is a fundamentally bad
idea. C and C++ kind of look the same, but they are not:
http://www.research.att.com/~bs/bs_faq.html#C-slash
27 matches
Mail list logo
