From: Diego Novillo dnovi...@google.com
Date: Thu, 16 Aug 2012 21:12:56 +0200
On 12-08-16 15:00 , Diego Novillo wrote:
This is the patch I'm currently testing. I need someone with a very old
toolchain (4.1 or earlier) to also give this a try (the original problem
does not occur in g++
Hello,
This reduces peak memory usage for the small test case of PR54146 by
2GB. 24hrs ago peak memory was 9.4 GB in top, but with Richi's patches
from yesterday and with this one, peak memory is now only 5.2GB.
About 40% of that is in IRA and reload so there is still room for
improvement, but
Hi Diego,
Thanks Nick. I made the wrong fix here, sorry about that. I will be
making more changes to VEC_ shortly. What's a good way for me to test
them?
All I was doing was building a variety of targets, just to make sure
that a local, generic patch of my own did not break anything. If
On Thu, 16 Aug 2012, Ian Lance Taylor wrote:
On Thu, Aug 16, 2012 at 12:12 PM, Diego Novillo dnovi...@google.com wrote:
This is the patch I'm currently testing. I need someone with a very old
toolchain (4.1 or earlier) to also give this a try (the original problem
does not occur in g++
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-08-16 Richard Guenther rguent...@suse.de
* tree-sra.c (modify_function): Free redirect_callers vector.
* ipa-split.c (split_function): Free args_to_pass vector.
* tree-vect-data-refs.c
On Thu, 16 Aug 2012, Jakub Jelinek wrote:
On Thu, Aug 16, 2012 at 04:44:03PM +0200, Richard Guenther wrote:
On Thu, 16 Aug 2012, Paolo Carlini wrote:
On 08/16/2012 03:39 PM, Richard Guenther wrote:
This decreases the integer-share-limit to make sure the TREE_VEC we
allocate for the
On Fri, Aug 17, 2012 at 09:46:35AM +0200, Richard Guenther wrote:
--- gcc/tree-vect-slp.c (revision 190447)
+++ gcc/tree-vect-slp.c (working copy)
@@ -1858,8 +1862,11 @@ new_bb_vec_info (basic_block bb)
static void
destroy_bb_vec_info (bb_vec_info bb_vinfo)
{
+ VEC
On Thu, Aug 16, 2012 at 4:40 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Aug 16, 2012 at 3:09 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Thu, Aug 16, 2012 at 1:50 AM, H.J. Lu hongjiu...@intel.com wrote:
Hi,
This patch replaces MEMBER_TYPE_FORCES_BLK with a target hook. I
On Fri, 17 Aug 2012, Jakub Jelinek wrote:
On Fri, Aug 17, 2012 at 09:46:35AM +0200, Richard Guenther wrote:
--- gcc/tree-vect-slp.c (revision 190447)
+++ gcc/tree-vect-slp.c (working copy)
@@ -1858,8 +1862,11 @@ new_bb_vec_info (basic_block bb)
static void
destroy_bb_vec_info
On Fri, Aug 17, 2012 at 9:03 AM, Steven Bosscher stevenb@gmail.com wrote:
Hello,
This reduces peak memory usage for the small test case of PR54146 by
2GB. 24hrs ago peak memory was 9.4 GB in top, but with Richi's patches
from yesterday and with this one, peak memory is now only 5.2GB.
Thumb2 add instructions of the form
add Rd, Rm
Are already 16-bit instructions, so turning them into
addsRd, Rm
is pointless.
This patch adds support for this in the compiler and ensures that the
conversion to ADDS is skipped in this case.
The additional variant in
http://gcc.gnu.org/viewcvs?view=revisionrevision=190473
Committed this to compile gen-avr-mmcu-texi.c with the C compiler.
Johann
--
* config/avr/t-avr (gen-avr-mmcu-texi): Use $(CC) to compile
gen-avr-mmcu-texi.c.
Hi DJ,
I am applying the following patch as an obvious patch fix for building
the MEP targeted port of gcc. It fixes the build rule for
mep-pragma.o so that is uses the C++ compiler instead of the C
compiler.
Cheers
Nick
gcc/ChangeLog
2012-08-17 Nick Clifton ni...@redhat.com
On 16 August 2012 21:28, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Aug 16, 2012 at 06:59:09PM +0200, Simon Baldwin wrote:
On 16 August 2012 16:40, Michael Matz m...@suse.de wrote:
,,,
Do you have considered to use a new option flag (usable in the .opt files)
instead of a
I am Kayleigh.
I am 26 years and I really like spending nice time with my buddies.
Yeah, it always brings me delight to go party, going to disco clubs, pubs and
other places like these. It is always fun and interesting with me.
And... I am so sexual! I even won the sexiest woman in our
Hi Guys,
I am applying the patch below to fix some problems building an
iq2000-elf toolchain. The main problem is that the conditional branch
patterns were specifying a mode for the comparison operator, which then
fails to match the rtl generated by the compiler.
The other problem is
Hi Guys,
I am applying the patch below to fix a problem building libgcc for the
mcore-elf target. The cbranchsi4 pattern was applying a mode to the
comparison operator which was preventing it from matching rtl
generated by the middle end.
Cheers
Nick
gcc/ChangeLog
2012-08-17 Nick
Hi Guys,
I am applying the patch below to fix building libgcc for the fr30-elf
target. The problem was that the comparison patterns were applying a
mode to the operator which prevents them from matching rtl generated
by the middle-end.
Cheers
Nick
gcc/ChangeLog
2012-08-17 Nick
Hi Sebastien,
Currently the lm32-elf target fails to configure libgcc because of a
seg-fault whilst running the configuration checks:
configure:3794: lm32-elf/gcc/xgcc [...] conftest.c
xgcc: internal compiler error: Segmentation fault (program cc1)
GCC goes into an infinite loop
Ping
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00205.html
(Cc: the nice reviewer of the previous patch)
On Fri, 3 Aug 2012, Marc Glisse wrote:
Hello,
this is a follow up to the patch applied after this discussion:
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00504.html
It handles the
This marks GTY bitmaps properly for most efficient marking.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2012-08-17 Richard Guenther rguent...@suse.de
* bitmap.h (struct bitmap_element_def): GTY annotate next/prev.
(struct bitmap_head_def):
On Fri, Aug 03, 2012 at 10:47:25PM +0200, Marc Glisse wrote:
Hello,
this is a follow up to the patch applied after this discussion:
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00504.html
It handles the -mavx __builtin_shuffle case mentioned there.
It passes bootstrap (languages=c,c++)
This reduces the number of re-allocations and the amount of memory
wasted by store_binding. Previously, on a cut-down testcase from
PR54146 we can see (--enable-gather-detailed-mem-stats -fmem-report
output):
cp/name-lookup.c:5874 (store_binding) 12033504: 1.6%
8564032: 2.4%
Ping one more time.
2012/8/10 Anna Tikhonova anna.m.tikhon...@gmail.com:
Ping.
2012/8/8 Anna Tikhonova anna.m.tikhon...@gmail.com:
Hi,
while running check for Android NDK compiler (I've used
contrib/test_installed for it) I've noticed that gcov name is
hardcoded in g++.dg/gcov/gcov.exp.
This gets rid of this field, pushing it into a short int in tree_base
(hopefully 2^16 non-defaulted template args are enough ...). The
existing code is a bit confusing because of the differences with
respect to ENABLE_CHECKING, it has very little testcase coverage as
well (a single testcase,
On Fri, Aug 17, 2012 at 6:17 AM, Richard Guenther rguent...@suse.de wrote:
This reduces the number of re-allocations and the amount of memory
wasted by store_binding. Previously, on a cut-down testcase from
PR54146 we can see (--enable-gather-detailed-mem-stats -fmem-report
output):
On Fri, Aug 17, 2012 at 6:17 AM, Richard Guenther rguent...@suse.de wrote:
which means only 19516 reallocations and 350kb wasted memory. The
compile-time effects are neutral (name-lookup is 1.0+-0.05s on
the reduced testcase) - a slightly different version which omitted
the temporary vector
Hello,
On a 64-bits host we leave 32 bits of each bitmap_element unused. And
actually, on a 32-bits host we do that too for GGC-allocated bitmaps
(due to alignment).
With this patch, we use those 32 bits by making BITMAP_WORD an
unsigned int (instead of unsigned long) and having 5 elts per
On Fri, Aug 17, 2012 at 1:46 PM, Steven Bosscher stevenb@gmail.com wrote:
Hello,
On a 64-bits host we leave 32 bits of each bitmap_element unused. And
actually, on a 32-bits host we do that too for GGC-allocated bitmaps
(due to alignment).
With this patch, we use those 32 bits by making
On Fri, 17 Aug 2012, Gabriel Dos Reis wrote:
On Fri, Aug 17, 2012 at 6:17 AM, Richard Guenther rguent...@suse.de wrote:
This reduces the number of re-allocations and the amount of memory
wasted by store_binding. Previously, on a cut-down testcase from
PR54146 we can see
On Fri, Aug 17, 2012 at 06:41:37AM -0500, Gabriel Dos Reis wrote:
I am however concerned with:
static void
store_bindings (tree names, VEC(cxx_saved_binding,gc) **old_bindings)
{
! static VEC(tree,heap) *bindings_need_stored = NULL;
I would be more comfortable to see the
On Fri, Aug 17, 2012 at 2:04 PM, Steven Bosscher stevenb@gmail.com wrote:
On Fri, Aug 17, 2012 at 1:54 PM, Richard Guenther
richard.guent...@gmail.com wrote:
Well, another effect of reducing the size of BITMAP_WORD is that
operations are not performed in a mode optimally using CPU regs
On Fri, Aug 17, 2012 at 02:04:50PM +0200, Steven Bosscher wrote:
On Fri, Aug 17, 2012 at 1:54 PM, Richard Guenther
richard.guent...@gmail.com wrote:
Well, another effect of reducing the size of BITMAP_WORD is that
operations are not performed in a mode optimally using CPU regs
(did you
On Fri, Aug 17, 2012 at 2:12 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Fri, Aug 17, 2012 at 2:04 PM, Steven Bosscher stevenb@gmail.com
wrote:
On Fri, Aug 17, 2012 at 1:54 PM, Richard Guenther
richard.guent...@gmail.com wrote:
Well, another effect of reducing the size of
On 12-08-16 20:29 , Ian Lance Taylor wrote:
I recommend that you add libintl.h to the AC_CHECK_HEADERS list in
gcc/configure.ac
Thanks. The attached patch implements the approach.
Tested with --disable-nls and --enable-nls. Folks with 4.1 compilers,
could you test it there?
OK for trunk
On Fri, Aug 17, 2012 at 02:16:12PM +0200, Richard Guenther wrote:
Or figure out if or why not the vectorizer does catch this (of course we do
not enable that with -O2 which we eventually should in a very conservative
mode).
It might be helpful if we for the BITMAP_ELEMENT_WORDS == 5 case
Hi!
On Fri, Aug 17, 2012 at 08:23:02AM -0400, Diego Novillo wrote:
--- a/gcc/intl.h
+++ b/gcc/intl.h
@@ -27,8 +27,16 @@
# define setlocale(category, locale) (locale)
#endif
+/* If libintl.h is available, include it before testing for NLS. If we
+ are building with --disable-nls and
This fixes a warning about the definition not matching the builtin.
Since the type is not actually used for accessing the data, this doesn't
affect the generated code.
Tested on m68k-linux and committed.
Andreas.
* config/m68k/linux-atomic.c (__sync_lock_test_and_set_1): Fix
On 12-08-17 03:10 , nick clifton wrote:
Hi Diego,
Thanks Nick. I made the wrong fix here, sorry about that. I will be
making more changes to VEC_ shortly. What's a good way for me to test
them?
All I was doing was building a variety of targets, just to make sure
that a local, generic patch
On Fri, Aug 17, 2012 at 6:55 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Aug 17, 2012 at 06:41:37AM -0500, Gabriel Dos Reis wrote:
I am however concerned with:
static void
store_bindings (tree names, VEC(cxx_saved_binding,gc) **old_bindings)
{
! static VEC(tree,heap)
On 08/16/2012 09:10 PM, Jakub Jelinek wrote:
+ switch (DECL_FUNCTION_CODE (callee))
+{
+case BUILT_IN_STRNCMP:
+case BUILT_IN_STRNCASECMP:
+case BUILT_IN_STRNCPY:
+case BUILT_IN_STRNCAT:
+ strop = true;
+ /* FALLTHRU */
+case BUILT_IN_MEMCPY:
+case
Hi Diego,
Would it be too much imposition for you to put this on the wiki?
I would be happy to. Where do you think would be appropriate ? I would
guess that somewhere off the Getting Started page
(http://gcc.gnu.org/wiki/GettingStarted) would be best. Maybe a new
item in the Tutorials
On Fri, Aug 17, 2012 at 2:21 PM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Aug 17, 2012 at 02:16:12PM +0200, Richard Guenther wrote:
Or figure out if or why not the vectorizer does catch this (of course we do
not enable that with -O2 which we eventually should in a very conservative
mode).
On Fri, Aug 17, 2012 at 02:52:34PM +0200, Florian Weimer wrote:
+{
+case BUILT_IN_STRNCMP:
+case BUILT_IN_STRNCASECMP:
+case BUILT_IN_STRNCPY:
+case BUILT_IN_STRNCAT:
+ strop = true;
+ /* FALLTHRU */
+case BUILT_IN_MEMCPY:
+case BUILT_IN_MEMMOVE:
+
On 08/17/2012 03:09 PM, Jakub Jelinek wrote:
s/stpncopy/stpncpy/, yeah, I guess, we could do that for those too,
but 1) I'd prefer to wait for the C++ FE change to go in first
2) {,v}snprintf would be much harder than the rest, as the size
argument then isn't the last argument to the function,
On Fri, Aug 17, 2012 at 03:26:34PM +0200, Florian Weimer wrote:
On 08/17/2012 03:09 PM, Jakub Jelinek wrote:
s/stpncopy/stpncpy/, yeah, I guess, we could do that for those too,
but 1) I'd prefer to wait for the C++ FE change to go in first
2) {,v}snprintf would be much harder than the rest,
On Fri, Aug 17, 2012 at 1:02 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Thu, Aug 16, 2012 at 4:40 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Aug 16, 2012 at 3:09 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Thu, Aug 16, 2012 at 1:50 AM, H.J. Lu
On Fri, Aug 17, 2012 at 9:39 AM, H.J. Lu hjl.to...@gmail.com wrote:
Here is the updated patch. Steve, David, Sterling, can you take a look
at ia64, rs6000 and xtensa changes?
* config/rs6000/rs6000.c (TARGET_MEMBER_TYPE_FORCES_BLK): New
macro.
multiply operation.
PR tree-ssa/54295
* tree-ssa-math-opts.c (is_widening_mult_p): Short-circuit when
the stmt is already a widening multiply.
Testsuite
PR tree-ssa/54295
* gcc.c-torture/execute/20120817-1.c: New test.
OK to commit once testing has completed
On 17/08/12 15:04, Richard Earnshaw wrote:
The fix is to make is_widening_mult_p note that it has been called with
a WIDEN_MULT_EXPR and rather than decompose the operands again, to
simply extract the existing operands, which have already been formulated
correctly for a widening multiply
On 17/08/12 15:22, Andrew Stubbs wrote:
On 17/08/12 15:04, Richard Earnshaw wrote:
The fix is to make is_widening_mult_p note that it has been called with
a WIDEN_MULT_EXPR and rather than decompose the operands again, to
simply extract the existing operands, which have already been formulated
On 17/08/12 15:31, Richard Earnshaw wrote:
On 17/08/12 15:22, Andrew Stubbs wrote:
On 17/08/12 15:04, Richard Earnshaw wrote:
The fix is to make is_widening_mult_p note that it has been called with
a WIDEN_MULT_EXPR and rather than decompose the operands again, to
simply extract the existing
On Fri, Aug 17, 2012 at 5:32 AM, Jakub Jelinek ja...@redhat.com wrote:
Will that handle even the case where without --disable-nls intl/
creates its own libintl.h? Dunno which targets need that, but
I'd guess configury wouldn't find it in that case. So perhaps
it should be #if
On 17/08/12 15:39, Andrew Stubbs wrote:
On 17/08/12 15:31, Richard Earnshaw wrote:
On 17/08/12 15:22, Andrew Stubbs wrote:
On 17/08/12 15:04, Richard Earnshaw wrote:
The fix is to make is_widening_mult_p note that it has been called with
a WIDEN_MULT_EXPR and rather than decompose the
On Fri, 17 Aug 2012, Diego Novillo wrote:
On 12-08-17 03:10 , nick clifton wrote:
Hi Diego,
Thanks Nick. I made the wrong fix here, sorry about that. I will be
making more changes to VEC_ shortly. What's a good way for me to test
them?
All I was doing was building a variety of
On Fri, 17 Aug 2012, Simon Baldwin wrote:
You could have just added
case OPT_cpp_:
to the switch in gen_producer_string, instead of all this.
Thanks. I was under the impression, apparently mistaken, that
OPT_cpp_ exists only if fortran is enabled.
OPT_* for Fortran options only
On 12-08-17 08:32 , Jakub Jelinek wrote:
Hi!
On Fri, Aug 17, 2012 at 08:23:02AM -0400, Diego Novillo wrote:
--- a/gcc/intl.h
+++ b/gcc/intl.h
@@ -27,8 +27,16 @@
# define setlocale(category, locale) (locale)
#endif
+/* If libintl.h is available, include it before testing for NLS. If we
+
On 12-08-17 10:52 , Joseph S. Myers wrote:
On Fri, 17 Aug 2012, Diego Novillo wrote:
On 12-08-17 03:10 , nick clifton wrote:
Hi Diego,
Thanks Nick. I made the wrong fix here, sorry about that. I will be
making more changes to VEC_ shortly. What's a good way for me to test
them?
All I
Hi,
I've just committed the attached patch on the AArch64 branch to use
effective-target keyword to test for endianness.
Thanks
Sofiane
-
r190482 | sofiane | 2012-08-17 16:02:20 +0100 (Fri, 17 Aug 2012) | 9 lines
[AArch64] Use effective-target to check for big endian
On 17/08/12 15:47, Richard Earnshaw wrote:
If we don't have a 16x16-64 mult operation then after step 1 we'll
still have a MULT_EXPR, not a WIDEN_MULT_EXPR, so when we reach step2
there's nothing to short circuit.
Unless, of course, you're expecting us to get
step1 - 16x16-32 widen mult
step2
On Fri, Aug 17, 2012 at 10:58:25AM -0400, Diego Novillo wrote:
Sounds reasonable. Amended patch attached.
OK for trunk?
Yes, except for:
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index c9a81d1..43b0af7 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -213,7 +222,7 @@
*
Hi,
I've just committed the attached patch on the AArch64 branch to implement
vmlsq_laneq_*.
Thanks
Sofiane
-
r190484 | sofiane | 2012-08-17 16:15:49 +0100 (Fri, 17 Aug 2012) | 11 lines
Tejas Belagod tejas.bela...@arm.com
[AArch64] Implement vmlsq_laneq_*.
gcc/
On 17/08/12 16:06, Andrew Stubbs wrote:
On 17/08/12 15:47, Richard Earnshaw wrote:
If we don't have a 16x16-64 mult operation then after step 1 we'll
still have a MULT_EXPR, not a WIDEN_MULT_EXPR, so when we reach step2
there's nothing to short circuit.
Unless, of course, you're expecting us
Hi,
I've just committed the attached patch on the AArch64 branch to implement
FSQRT in RTL.
Thanks
Sofiane
-
r190485 | sofiane | 2012-08-17 16:22:28 +0100 (Fri, 17 Aug 2012) | 12 lines
2012-08-17 Tejas Belagod tejas.bela...@arm.com
[AArch64] Implement FSQRT in RTL.
*
Hi,
I've just committed the attached patch on the AArch64 branch to fix a style
issue related to mixing statements with declarations.
Thanks
Sofiane
-
r190486 | sofiane | 2012-08-17 16:26:47 +0100 (Fri, 17 Aug 2012) | 7 lines
2012-08-17 Marcus Shawcroft marcus.shawcr...@arm.com
On Fri, Aug 17, 2012 at 11:05 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Aug 17, 2012 at 10:58:25AM -0400, Diego Novillo wrote:
Sounds reasonable. Amended patch attached.
OK for trunk?
Yes, except for:
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index c9a81d1..43b0af7 100644
---
Here is the updated patch. Steve, David, Sterling, can you take a look
at ia64, rs6000 and xtensa changes?
Thanks.
The ia64 part looks OK.
Steve Ellcey
sell...@mips.com
On 2012-08-10 20:38, Dehao Chen wrote:
+ // { dg-final { scan-assembler 1 28 0 } }
This test case isn't going to work except with dwarf2, and with gas.
You can use -dA so that you can scan for file.c:line. There are
other examples in the testsuite.
This doesn't belong in guality. It belongs
On Fri, Aug 17, 2012 at 6:59 AM, David Edelsohn dje@gmail.com wrote:
On Fri, Aug 17, 2012 at 9:39 AM, H.J. Lu hjl.to...@gmail.com wrote:
Here is the updated patch. Steve, David, Sterling, can you take a
look
at ia64, rs6000 and xtensa changes?
* config/rs6000/rs6000.c
In some real-world code, I noticed a curious pattern: using the unsafe
string functions on function parameter arguments. This leads to
gets()-style unsafe APIs.
I've looked at how to implement a warning for this, and came up with the
attached patch. Do you think this makes sense?
1
Hello!
Attached patch fixes one of the critical problems in combine.c:
combine pass blindly propagates hard registers into insn patterns and
this way creates partially invalid instructions. Most of the times,
reload is able to fix these inconsistencies, but operands with invalid
hard registers
On 17/08/12 16:20, Richard Earnshaw wrote:
Ok, in which case we have to give is_widening_mult_rhs_p enough smarts
to not strip
(s32)u32
and return u32.
I'll have another think about it.
Take two.
This version should address your concerns about handling
(u32)u16 *
Hi Rong,
Could you take a look at the patch I mailed to gcc-patches when you get
a chance?
It reduces the gcda size bloat issue by replacing gcov_pmu data with a
filetag field that holds the position of the correct filename inside of
the newly added string table.
Thanks,
Chris
On Fri, Aug 17, 2012 at 8:26 AM, Sofiane Naci sofiane.n...@arm.com wrote:
Hi,
I've just committed the attached patch on the AArch64 branch to implement
FSQRT in RTL.
Maybe add a testcase which tests that sqrt gets vectorized?
Thanks,
Andrew
Thanks
Sofiane
-
r190485 | sofiane |
On 08/15/2012 11:25 AM, Gabriel Dos Reis wrote:
On Wed, Aug 15, 2012 at 1:21 PM, Tom Tromey tro...@redhat.com wrote:
Gaby == Gabriel Dos Reis g...@integrable-solutions.net writes:
Tom I asked Keith to resurrect his patch for this.
[snip]
I hope this will be acceptable all around.
OK, that
On Fri, Aug 17, 2012 at 10:45 AM, Keith Seitz kei...@redhat.com wrote:
On 08/15/2012 11:25 AM, Gabriel Dos Reis wrote:
On Wed, Aug 15, 2012 at 1:21 PM, Tom Tromey tro...@redhat.com wrote:
Gaby == Gabriel Dos Reis g...@integrable-solutions.net writes:
Tom I asked Keith to resurrect his
On Aug 17, 2012, at 6:58 AM, Paolo Carlini wrote:
On 08/17/2012 01:26 PM, Richard Guenther wrote:
This gets rid of this field, pushing it into a short int in tree_base
(hopefully 2^16 non-defaulted template args are enough ...).
Honestly, I don't think it's a trivial issue.
Love to hear from
On Fri, Aug 17, 2012 at 6:36 PM, Uros Bizjak ubiz...@gmail.com wrote:
2012-08-17 Uros Bizjak ubiz...@gmail.com
PR rtl-optimization/46829
* combine.c (recog_for_combine): Check operand constraints
in case hard registers were propagater into insn pattern.
On 17/08/12 16:20, Richard Earnshaw wrote:
No, given a u16xu16-u64 operation in the code, and that the arch
doesn't have such an opcode, I'd expect to get
step1 - (u32)u16 x (u32)u16 - u64
Hmm, I would have thought that would be more costly than
(u64)(u16 x u16 - u32)
You might be
On Fri, Aug 17, 2012 at 1:03 PM, Mike Stump mikest...@comcast.net wrote:
On Aug 17, 2012, at 6:58 AM, Paolo Carlini wrote:
On 08/17/2012 01:26 PM, Richard Guenther wrote:
This gets rid of this field, pushing it into a short int in tree_base
(hopefully 2^16 non-defaulted template args are
On Fri, Aug 17, 2012 at 11:22 AM, Florian Weimer fwei...@redhat.com wrote:
In some real-world code, I noticed a curious pattern: using the unsafe
string functions on function parameter arguments. This leads to
gets()-style unsafe APIs.
I've looked at how to implement a warning for this, and
On 17/08/12 18:05, Richard Earnshaw wrote:
Take two.
This version should address your concerns about handling
(u32)u16 * (u32)u16 - u64
We now look at each operand directly, but when doing so we check whether
the operand is the same size as the result or not. When it is, we can
strip
On Thu, Aug 16, 2012 at 7:41 PM, H.J. Lu hongjiu...@intel.com wrote:
My email sent to gcc-patches@gcc.gnu.org was bounced as spam. I am
resending it. This patch defines both MAX_FIXED_MODE_SIZE and
MEMBER_TYPE_FORCES_BLK for i386. MEMBER_TYPE_FORCES_BLK is needed so
that we always put
On Fri, Aug 17, 2012 at 12:35 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Thu, Aug 16, 2012 at 7:41 PM, H.J. Lu hongjiu...@intel.com wrote:
My email sent to gcc-patches@gcc.gnu.org was bounced as spam. I am
resending it. This patch defines both MAX_FIXED_MODE_SIZE and
MEMBER_TYPE_FORCES_BLK
On 08/17/2012 09:15 PM, Gabriel Dos Reis wrote:
Hmm, I think it help a little bit if you could expand on where exactly
the danger the patch is trying to prevent is, and where what
does unbound parameter refer to or mean? (I don't know what
an unbound parameter is)
Sorry for being unclear. I
Hi,
On Fri, 2012-08-17 at 20:34 +0200, Uros Bizjak wrote:
On Fri, Aug 17, 2012 at 6:36 PM, Uros Bizjak ubiz...@gmail.com wrote:
2012-08-17 Uros Bizjak ubiz...@gmail.com
PR rtl-optimization/46829
* combine.c (recog_for_combine): Check operand constraints
in
Hi!
As discussed in the PR, this patch, originally posted for PR42728,
makes sure the shortcut in all_uses_available_at is used on the same insns
in between -g and -g0, it is the second time a -fcompare-debug failure
resulted from NEXT_INSN being something different with -g, so IMHO it is
On Fri, Aug 17, 2012 at 9:58 PM, Oleg Endo oleg.e...@t-online.de wrote:
2012-08-17 Uros Bizjak ubiz...@gmail.com
PR rtl-optimization/46829
* combine.c (recog_for_combine): Check operand constraints
in case hard registers were propagater into insn pattern.
Hi!
I see these warnings/errors right now:
g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings
On Thu, Aug 16, 2012 at 9:20 AM, Andreas Schwab sch...@linux-m68k.org wrote:
* floatformat.c (floatformat_to_double): Correctly handle numbers
between 1 and 2. Simplify handling of denormal number.
(main): Test with 1.1.
This is OK.
Thanks.
Ian
On Fri, 2012-08-17 at 22:32 +0200, Uros Bizjak wrote:
Yes, x86_64 also has register passing convention. So, i.e.:
--cut here--
int foo (int a, int b, int c)
{
return a + b + c;
}
--cut here--
expands to:
(note 6 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 6 3 2 (set
Following up on myself:
On 2012-08-16 14:59, Tobias Schlüter wrote:
A place where C++ inheritance is a trivial improvement is the red-black
tree used for storing various objects (gfc_symtree, gfc_gsymbol,
gfc_st_label, I think). This is currently implemented with macro-based
inheritance. It
Hi, Richard,
Thanks for the review. I've addressed most of the issues except the
java unittest (see comments below). The new patch is attached in the
end of this email.
Thanks,
Dehao
On Fri, Aug 17, 2012 at 8:47 AM, Richard Henderson r...@redhat.com wrote:
On 2012-08-10 20:38, Dehao Chen
This patch is for the google/gcc-4_7 branch. I'll submit it for trunk
after the Fission patches have gone in.
When adding names to the pubnames table (-gsplit-dwarf or -gpubnames),
a method within a union may not get handled properly, sometimes resulting
in an internal compiler error in
Bootstrapping cross toolchains using glibc is an unduly complicated
process involving multiple GCC builds and sometimes multiple glibc
builds or glibc header installs.
Something like the ideal bootstrap process is described at
http://sourceware.org/ml/libc-alpha/2012-03/msg00960.html. I put
some
On Fri, Aug 17, 2012 at 3:09 PM, Cary Coutant ccout...@google.com wrote:
This patch is for the google/gcc-4_7 branch. I'll submit it for trunk
after the Fission patches have gone in.
When adding names to the pubnames table (-gsplit-dwarf or -gpubnames),
a method within a union may not get
OK for Google 4.7
Thanks, committed at r190494.
-cary
On Fri, Aug 17, 2012 at 3:14 PM, Joseph S. Myers
jos...@codesourcery.com wrote:
Bootstrapping cross toolchains using glibc is an unduly complicated
process involving multiple GCC builds and sometimes multiple glibc
builds or glibc header installs.
Something like the ideal bootstrap process is
Paul Hargrove noted the following build failure on
an older x86-32 Linux (Redhat 8.0) system.
g++ -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -W -Wall
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -fno-common
-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild
On Fri, 17 Aug 2012, Gary Funck wrote:
Paul Hargrove noted the following build failure on
an older x86-32 Linux (Redhat 8.0) system.
wow. old.
The g++ version is: g++ (GCC) 3.4.0
Currently, install.texi states:
@heading Tools/packages necessary for building GCC
@table @asis
1 - 100 of 103 matches
Mail list logo
