Ping.
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
On
Behalf Of Bin Cheng
Sent: Tuesday, September 25, 2012 4:00 PM
To: 'Richard Sandiford'
Cc: Ramana Radhakrishnan; Richard Earnshaw; gcc-patches@gcc.gnu.org
Subject: RE: [Updated]:
On Sun, Oct 7, 2012 at 7:22 PM, Jan Hubicka hubi...@ucw.cz wrote:
On Sun, Oct 7, 2012 at 5:15 PM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
I added a santy check that after fixup all types that lost in the merging
are
really dead. And it turns out we have some zombies around.
On Mon, Oct 8, 2012 at 3:16 AM, Jonathan Wakely jwakely@gmail.com wrote:
On 7 October 2012 21:31, Manuel López-Ibáñez wrote:
On 7 October 2012 22:13, Jonathan Wakely jwakely@gmail.com wrote:
On Oct 7, 2012 12:00 AM, NightStrike nightstr...@gmail.com wrote:
On Sat, Oct 6, 2012 at 7:30
On Sun, Oct 7, 2012 at 11:27 PM, Steven Bosscher stevenb@gmail.com wrote:
On Sun, Oct 7, 2012 at 5:59 PM, Vladimir Makarov wrote:
The following patch speeds LRA up more on PR54146. Below times for
compilation of the test on gcc17.fsffrance.org (an AMD machine):
Before:
real=1214.71
On Mon, Oct 8, 2012 at 4:50 AM, Dehao Chen de...@google.com wrote:
Attached is the updated patch. Yes, if we add a VRP pass before
profile pass, this patch would be unnecessary. Should we add a VRP
pass?
No, we don't want VRP in early optimizations.
Richard.
Thanks,
Dehao
On Sat, Oct 6,
Hi,
When running libstdc++ regression test on Cortex-M0, the case 49445.cc fails
with error message:
/tmp/ccMqZdgc.o: In function `std::atomicfloat::load(std::memory_order)
const':^M
/home/build/work/GCC-4-7-build/build-native/gcc-final/arm-none-eabi/armv6-m/
libstdc++-v3/include/atomic:202:
On 8 October 2012 09:18, Richard Guenther richard.guent...@gmail.com wrote:
On Mon, Oct 8, 2012 at 3:16 AM, Jonathan Wakely jwakely@gmail.com wrote:
On 7 October 2012 21:31, Manuel López-Ibáñez wrote:
On 7 October 2012 22:13, Jonathan Wakely jwakely@gmail.com wrote:
On Oct 7, 2012
Recent tests added to gcc.dg/tree-ssa don't clean up after themselves.
Tested on x86_64-suse-linux, applied on the mainline as obvious.
2012-10-08 Eric Botcazou ebotca...@adacore.com
* gcc.dg/tree-ssa/slsr-30.c: Use correct cleanup directive.
*
On Mon, Oct 08, 2012 at 09:20:47AM +0200, Richard Guenther wrote:
On Sun, Oct 7, 2012 at 11:27 PM, Steven Bosscher stevenb@gmail.com
wrote:
The next bottle-neck in my timings is in
lra-eliminate.c:lra_eliminate(), in this loop:
FOR_EACH_BB (bb)
FOR_BB_INSNS_SAFE (bb, insn,
On Fri, 5 Oct 2012, Steven Bosscher wrote:
On Fri, Sep 14, 2012 at 2:26 PM, Richard Guenther rguent...@suse.de wrote:
If you can figure out a better name for the function we should
probably move it to cfganal.c
It looks like my previous e-mail about this appears to have gone got
somehow,
On Fri, Oct 5, 2012 at 5:01 PM, Marc Glisse marc.gli...@inria.fr wrote:
[I am still a little confused, sorry for the long email...]
On Tue, 2 Oct 2012, Richard Guenther wrote:
+ if (TREE_CODE (op0) == VECTOR_CST TREE_CODE (op1) == VECTOR_CST)
+{
+ int count = VECTOR_CST_NELTS
On Mon, Oct 8, 2012 at 4:50 AM, Dehao Chen de...@google.com wrote:
Attached is the updated patch. Yes, if we add a VRP pass before
profile pass, this patch would be unnecessary. Should we add a VRP
pass?
No, we don't want VRP in early optimizations.
I am not quite sure about that. VRP
On Sat, Oct 6, 2012 at 12:48 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
This patch adds machinery to genmodes.c so that largest possible sizes of
various data structures can be determined at gcc build time. These
functions create 3 symbols that are available in insn-modes.h:
On Sat, Oct 6, 2012 at 5:55 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
This is the third patch in the series of patches to fix constant math.
this one changes some predicates at the rtl level to use the new predicate
CONST_SCALAR_INT_P.
I did not include a few that were tightly
On Sun, Oct 7, 2012 at 7:22 PM, Jan Hubicka hubi...@ucw.cz wrote:
On Sun, Oct 7, 2012 at 5:15 PM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
I added a santy check that after fixup all types that lost in the
merging are
really dead. And it turns out we have some zombies around.
On Sun, Oct 7, 2012 at 12:44 PM, Tom de Vries tom_devr...@mentor.com wrote:
Richard,
attached patch checks that unlinked uses do not contain ssa-names when
renaming.
This assert triggers when compiling (without the fix) the PR54735 example.
AFAIU, it was due to chance that we caught the
On Sun, Oct 7, 2012 at 4:58 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
On 10/07/2012 09:19 AM, Richard Guenther wrote:
In fact, you could argue that the tree level did it wrong (not that i am
suggesting to change this). But it makes me think what was going on
when
the decision to
On Mon, 8 Oct 2012, Richard Guenther wrote:
VEC_COND_EXPR is more complicated. We could for instance require that it
takes as first argument a vector of -1 and 0 (thus 0, !=0 and the neon
thing are equivalent). Which would leave to decide what the expansion of
vec_cond_expr passes to the
On Mon, Oct 8, 2012 at 11:18 AM, Jan Hubicka hubi...@ucw.cz wrote:
On Sun, Oct 7, 2012 at 7:22 PM, Jan Hubicka hubi...@ucw.cz wrote:
On Sun, Oct 7, 2012 at 5:15 PM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
I added a santy check that after fixup all types that lost in the
merging are
On Mon, Oct 8, 2012 at 11:34 AM, Marc Glisse marc.gli...@inria.fr wrote:
On Mon, 8 Oct 2012, Richard Guenther wrote:
VEC_COND_EXPR is more complicated. We could for instance require that it
takes as first argument a vector of -1 and 0 (thus 0, !=0 and the neon
thing are equivalent). Which
2) As we query the type_hash while we are rewritting the types,
we run into instability of the hashtable. This manifests itself
as an ICE when one adds sanity check that while merging function
types their arg types are equivalent, too.
This ICEs compiling i.e.
On Mon, Oct 8, 2012 at 11:04 AM, Jan Hubicka hubi...@ucw.cz wrote:
On Mon, Oct 8, 2012 at 4:50 AM, Dehao Chen de...@google.com wrote:
Attached is the updated patch. Yes, if we add a VRP pass before
profile pass, this patch would be unnecessary. Should we add a VRP
pass?
No, we
Hi Richard,
I have incorporated your comments.
Yes, call dump_mem_ref then, instead of repeating parts of its body.
Reference object is not yet created at the place we check for invariance. It
is still a tree expression. I created a common function and used at all places
to dump the step,
On Sat, Oct 6, 2012 at 11:34 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
I benchmarked the patch moving loop header copying and it is quite noticeable
win.
Some testsuite updating is needed. In many cases it is just because the
optimizations are now happening earlier.
There are however few
Hi,
in this PR submitter points out that in the -Wparentheses warning, for, eg,
char in[4]={0}, out[6];
out[1] = in[1] 0x0F | ((in[3] 0x3C) 2);
warning: suggest parentheses around arithmetic in operand of ‘|’
[-Wparentheses]
the caret points to end of the expression, ie the final closing
Applied the following changes to 4.7/4.8 release notes caveats.
Index: htdocs/gcc-4.7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.127
retrieving revision 1.128
diff -u -p -r1.127
On Mon, Oct 8, 2012 at 12:01 PM, Jan Hubicka hubi...@ucw.cz wrote:
On Mon, Oct 8, 2012 at 11:04 AM, Jan Hubicka hubi...@ucw.cz wrote:
On Mon, Oct 8, 2012 at 4:50 AM, Dehao Chen de...@google.com wrote:
Attached is the updated patch. Yes, if we add a VRP pass before
profile pass, this patch
On Mon, Oct 8, 2012 at 12:01 PM, Kumar, Venkataramanan
venkataramanan.ku...@amd.com wrote:
Hi Richard,
I have incorporated your comments.
Yes, call dump_mem_ref then, instead of repeating parts of its body.
Reference object is not yet created at the place we check for invariance. It
is
On Mon, Oct 8, 2012 at 10:18 AM, Jakub Jelinek ja...@redhat.com wrote:
I'm playing with a patch to expand the insns_with_changed_offsets
bitmap to an sbitmap, and will send a patch if this works better.
Or make insns_with_changed_offsets a VEC of insns (or a pointer-set).
Or use
On Sun, Oct 7, 2012 at 5:59 PM, Vladimir Makarov wrote:
* lra-lives.c (lra_start_point_ranges, lra_finish_point_ranges):
Remove.
(process_bb_lives): Change start regno in
EXECUTE_IF_SET_IN_BITMAP. Iterate on DF_LR_IN (bb) instead of
Hi,
we recently noticed that, even at -O3, the compiler doesn't figure out that
the following loop is dumb:
#define SIZE 64
int foo (int v[])
{
int r;
for (i = 0; i SIZE; i++)
r = v[i];
return r;
}
which was a bit of a surprise. On second thoughts, this isn't entirely
On Sat, Oct 6, 2012 at 11:34 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
I benchmarked the patch moving loop header copying and it is quite
noticeable win.
Some testsuite updating is needed. In many cases it is just because the
optimizations are now happening earlier.
There are
On 08/13/2012 05:42 PM, Vladimir Makarov wrote:
On 08/13/2012 06:32 AM, Bernd Schmidt wrote:
This is a small patch for sched-rgn that attempts to save DFA state at
the end of a basic block and re-use it in successor blocks. This was a
customer-requested optimization; I've not seen it make much
yes, my bad. here it is with the patches.
On 10/06/2012 11:55 AM, Kenneth Zadeck wrote:
This is the third patch in the series of patches to fix constant math.
this one changes some predicates at the rtl level to use the new
predicate CONST_SCALAR_INT_P.
I did not include a few that were
This replaces my_rev_post_order_compute in PRE by the already
existing inverted_post_order_compute, with the necessary adjustments.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-10-08 Richard Guenther rguent...@suse.de
* tree-ssa-pre.c (postorder_num):
This fixes PR54825, properly FRE/PRE vector BIT_FIELD_REFs.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-10-08 Richard Guenther rguent...@suse.de
PR tree-optimization/54825
* tree-ssa-sccvn.c (vn_nary_length_from_stmt): Handle BIT_FIELD_REF.
On Mon, Oct 8, 2012 at 1:36 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
yes, my bad. here it is with the patches.
Just for the record, ok!
Thanks,
Richard.
On 10/06/2012 11:55 AM, Kenneth Zadeck wrote:
This is the third patch in the series of patches to fix constant math.
this one
Jason Merrill ja...@redhat.com writes:
OK.
Thanks. Committed to trunk at revision r192199.
--
Dodji
It appears that the patch should also special case the scan-assembler
.internal.*Foo.methodEv
tests in g++.dg/ext/visibility/pragma-override1.C and
g++.dg/ext/visibility/pragma-override2.C
on darwin as well...
Done, thanks.
Jason,
These tests are still failing on darwin. I
On Mon, Oct 8, 2012 at 12:38 PM, Eric Botcazou ebotca...@adacore.com wrote:
Hi,
we recently noticed that, even at -O3, the compiler doesn't figure out that
the following loop is dumb:
#define SIZE 64
int foo (int v[])
{
int r;
for (i = 0; i SIZE; i++)
r = v[i];
return r;
On Mon, Oct 8, 2012 at 2:32 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Mon, Oct 8, 2012 at 12:38 PM, Eric Botcazou ebotca...@adacore.com wrote:
Hi,
we recently noticed that, even at -O3, the compiler doesn't figure out that
the following loop is dumb:
#define SIZE 64
int
lto_obj_file_open allocates:
lo = XCNEW (struct lto_simple_object);
However, the data is never freed - neither explicitly nor in
lto_obj_file_close.
In the attached patch, I free the memory now after the call to
lto_obj_file_close.
Build and regtested on x86-64-gnu-linux.
OK for the
On Mon, Oct 8, 2012 at 2:39 PM, Tobias Burnus bur...@net-b.de wrote:
lto_obj_file_open allocates:
lo = XCNEW (struct lto_simple_object);
However, the data is never freed - neither explicitly nor in
lto_obj_file_close.
In the attached patch, I free the memory now after the call to
On Mon, Oct 8, 2012 at 1:00 AM, Steven Bosscher stevenb@gmail.com wrote:
Hello,
This patch changes the worklist-like bitmap in lra_eliminate() to an
sbitmap. Effect on compile time:
I have another patch to also make lra_constraint_insn_stack_bitmap.
Without patch:
log.0: LRA
Il 07/10/2012 19:18, Steven Bosscher ha scritto:
Hello,
The attached patch adds a DF changeable flag to compute a subset of
reaching definitions that are also live at the program points they
reach. This is an idea I discussed with Paolo many years ago already,
but until today it hadn't
The following patch fixes PR52945 on Darwin. It as beem approved
by Jan Hubicka in PR52945#c5. Since I don't have write permission,
could someone commit it for me?
TIA
Dominique
2012-10-08 Dominique d'Humieres domi...@lps.ens.fr
PR gcc/52945
*
On Android NDK libstdc++ is configured, built and packaged separately.
The problem is not dependency on libgcc sources but rather dependency
on the symlink which is generated during libgcc build and cannot be
found if libstdc++ is configured and built separately.
It was working fine for 4.4 and
On Fri, Oct 5, 2012 at 7:19 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Oct 05, 2012 at 03:59:55PM +0200, Richard Guenther wrote:
I don't think we want to rely on that ... so just keep the push/pop_cfun.
Ok, so this is what I'm retesting (basically just comments added and the two
lines
On 10/08/2012 03:57 PM, Jason Merrill wrote:
This is definitely an improvement, though for warnings about issues
with the left or right argument, we could use the EXPR_LOCATION of the
problematic argument rather than the location of the new operand.
I agree. Let me see if I can figure out
On 10/08/2012 03:43 PM, Pavel Chupin wrote:
This issue has been introduced in 4.7.
Irrespective of what we are eventually going to do from a practical
point of view, I think it would be important to understand when/what
introduced the issue: did you analyze that in any detail?
Thanks,
Paolo.
On Mon, Oct 8, 2012 at 3:27 PM, Paolo Bonzini wrote:
I wonder if we actually need the non-pruned version anywhere...
I don't think so, but I'm not sure. Only ddg.c and loop-iv.c access
the DF_RD results directly (i.e. not via DU/UD chains). For loop-iv
the pruned version is fine. For ddg I
2) As we query the type_hash while we are rewritting the types,
we run into instability of the hashtable. This manifests itself
as an ICE when one adds sanity check that while merging function
types their arg types are equivalent, too.
This ICEs compiling i.e.
On Fri, 28 Sep 2012, Uros Bizjak wrote:
2) {v[0]-v[1], v[0]-v[1]} is not recognized as a hsubpd because
vec_duplicate doesn't match vec_concat. Do we really need to duplicate (no
pun intended) the pattern?
You can add this transformation to simplify-rtx.c. Probably vec_concat
with two equal
On 10/04/2012 11:40 AM, Jason Merrill wrote:
Recent versions of binutils seem to have started putting ' around the
version number in bfd/configure.in, which was confusing gcc configure.
When this change was made to binutils, the other directories changed to
using bfd/configure --version to
Ping. This patch
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01907.html (non-C parts) is
pending review.
--
Joseph S. Myers
jos...@codesourcery.com
Hi,
Pavel Chupin pavel.v.chu...@gmail.com ha scritto:
It has been changed here:
http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=630d52ca0a88d173f89634a5d7dd8aee07d04d80
subj:Move gthr to toplevel libgcc
I see, thanks. Let's add Rainer in CC, see if he expected this to happen or not.
Paolo
- Original Message -
Btw, as for Richards idea of conditionally placing the length field
in
rtx_def looks like overkill to me. These days we'd merely want to
optimize for 64bit hosts, thus unconditionally adding a 32 bit
field to rtx_def looks ok to me (you can wrap that inside a
gcc.target/i386/pr54445-1.c FAILs to execute on Solaris 9 with native TLS:
ld.so.1: pr54445-1.exe: fatal: pr54445-1.exe: object requires TLS, but TLS faile
d to initialize
The following patch fixes this by both requiring TLS runtime support and
adding the necessary options.
Tested with the
On 10/8/2012 11:01 AM, Nathan Froyd wrote:
- Original Message -
Btw, as for Richards idea of conditionally placing the length field
in
rtx_def looks like overkill to me. These days we'd merely want to
optimize for 64bit hosts, thus unconditionally adding a 32 bit
field to rtx_def looks
On 10/06/12 01:50, Paolo Carlini wrote:
On 10/06/2012 02:33 AM, Joe Seymour wrote:
I'm seeing tr2/headers/all.cc fail in the libstdc++ testsuite:
In file included from
src/gcc-mainline/libstdc++-v3/testsuite/tr2/headers/all.cc:22:0:
Ping, again.
On 1 October 2012 16:56, Simon Baldwin sim...@google.com wrote:
Ping, again.
On 21 September 2012 12:45, Simon Baldwin sim...@google.com wrote:
Ping.
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00459.html
Full text of previous message and context at URL above. No
If the size of the inner array elements is 1 and we do not need a
cookie, we do not need to insert an overflow check. This applies to the
relatively frequent new char[n] case.
Built and regression-tested on x86_64-redhat-linux-gnu. Okay for trunk?
--
Florian Weimer / Red Hat Product
On Fri, 5 Oct 2012, Jason Merrill wrote:
+ error_at (loc, conversion of scalar to vector
+ involves truncation);
These errors should print the types involved. They also need to be
suppressed when !(complain tf_error).
Hello,
here is a new
As the testcase shows, we ICEd when generating the debug info for C++
and not splitting types into multiple registers.
The issue is in vt_add_function_parameter that we assumed that the
DECL_RTL expression was a pseudo register. But in that case it is
better to just give up than to ICE.
On Mon, Oct 8, 2012 at 4:40 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Fri, 28 Sep 2012, Uros Bizjak wrote:
2) {v[0]-v[1], v[0]-v[1]} is not recognized as a hsubpd because
vec_duplicate doesn't match vec_concat. Do we really need to duplicate
(no
pun intended) the pattern?
You can add
On Mon, Oct 08, 2012 at 05:58:15PM +0200, Marek Polacek wrote:
2012-10-08 Marek Polacek pola...@redhat.com
PR debug/54831
* var-tracking.c (vt_add_function_parameter): Use condition in place
of gcc_assert.
Perhaps s/in place/instead/ ?
--- gcc/var-tracking.c.mp
On Mon, Oct 8, 2012 at 6:08 PM, Uros Bizjak ubiz...@gmail.com wrote:
+(define_insn *sse3_haddv2df3
[(set (match_operand:V2DF 0 register_operand =x,x)
(vec_concat:V2DF
- (plusminus:DF
+ (plus:DF
+ (vec_select:DF
+ (match_operand:V2DF 1
The gcc.target/mips/ext_ins.c was failing in little endian mode on MIPS because
the compiler is smart enough now to see that 'c' is uninitialized and it can
insert the field 'a' into 'c' with a shift and a full store instead of an
insert because the store just overwrites unintialized data. I
On Mon, Oct 8, 2012 at 5:01 PM, Nathan Froyd froy...@mozilla.com wrote:
- Original Message -
Btw, as for Richards idea of conditionally placing the length field
in
rtx_def looks like overkill to me. These days we'd merely want to
optimize for 64bit hosts, thus unconditionally adding
The gcc.target/octeon-bbit-2.c is failing with -Os because that optimization
level does not do whichever optimization it is that results in a bbit instead
of a bbit[01]l. I would like to skip this test for -Os the way it already gets
skipped for -O0.
Tested on mips-mti-elf. Ok for checkin?
Hello,
This patch makes lra_constraint_insn_stack_bitmap an sbitmap. This
reduces compile time by another minute or so on gcc17 for the test
case of PR54146, and I think it's a general improvement also for less
extreme code. For cc1-i files the compile time change tends to be a
little less but
On Mon, Oct 08, 2012 at 06:09:41PM +0200, Jakub Jelinek wrote:
Ok with those changes.
Thanks, this is what I've checked in:
2012-10-08 Marek Polacek pola...@redhat.com
PR debug/54831
* var-tracking.c (vt_add_function_parameter): Use condition instead
of gcc_assert.
OK.
Jason
On 10/08/2012 08:28 AM, Dominique Dhumieres wrote:
These tests are still failing on darwin. I think that
target { ! *-*-solaris2* } { ! *-*-darwin* }
sould be replaced with
target { ! { *-*-solaris2* *-*-darwin* } }
Could someone with a darwin box handy make the appropriate change?
Thanks.
On Oct 8, 2012, at 9:21 AM, Steve Ellcey sell...@mips.com wrote:
The gcc.target/octeon-bbit-2.c is failing with -Os because that optimization
level does not do whichever optimization it is that results in a bbit instead
of a bbit[01]l. I would like to skip this test for -Os the way it already
On Oct 8, 2012, at 8:53 AM, Marc Glisse marc.gli...@inria.fr wrote:
On Fri, 5 Oct 2012, Jason Merrill wrote:
+ error_at (loc, conversion of scalar to vector
+ involves truncation);
These errors should print the types involved. They also need to be
On Oct 8, 2012, at 9:16 AM, Steve Ellcey sell...@mips.com wrote:
The gcc.target/mips/ext_ins.c was failing in little endian mode on MIPS
because
the compiler is smart enough now to see that 'c' is uninitialized and it can
insert the field 'a' into 'c' with a shift and a full store instead of
On Mon, 2012-10-08 at 11:09 -0700, Mike Stump wrote:
On Oct 8, 2012, at 9:21 AM, Steve Ellcey sell...@mips.com wrote:
The gcc.target/octeon-bbit-2.c is failing with -Os because that optimization
level does not do whichever optimization it is that results in a bbit
instead
of a bbit[01]l.
On 10/08/2012 11:15 AM, Mike Stump wrote:
On Oct 8, 2012, at 9:16 AM, Steve Ellcey sell...@mips.com wrote:
The gcc.target/mips/ext_ins.c was failing in little endian mode on MIPS because
the compiler is smart enough now to see that 'c' is uninitialized and it can
insert the field 'a' into 'c'
I have backported r192215 from trunk to google-4_7:
2012-10-08 Dehao Chen de...@google.com
* predict.c (predict_extra_loop_exits): Use
predict_paths_leading_to_edge to replace predict_edge_def.
Bootstrapped and passed crosstool test.
Dehao
Let's move the alias template case from primary_template_instantiation_p
into alias_template_specialization_p and call the latter from the
former. And also call it from tsubst.
Jason
Really I meant this in reply to the 'Fix
gcc.target/mips/octeon-bbit-2.c for -Os' thread. Sorry for confusing
the issue here.
I don't really have an objection to this one.
David Daney
On 10/08/2012 11:28 AM, David Daney wrote:
On 10/08/2012 11:15 AM, Mike Stump wrote:
On Oct 8, 2012, at
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Spanish team of translators. The file is available at:
http://translationproject.org/latest/gcc/es.po
(This file, 'gcc-4.7.2.es.po', has
Hi!
The following testcase ICEs because cp_tree_equal doesn't handle
FIELD_DECLs (in 4.4 it was enough to have c0/d0 and c1/d1 in the testcase,
now 12 lines are needed due to introduction of a hash table).
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk/4.7?
is this ok to commit with this change?
kenny
On 10/05/2012 08:14 PM, Joseph S. Myers wrote:
On Fri, 5 Oct 2012, Kenneth Zadeck wrote:
+# define HOST_HALF_WIDE_INT_PRINT h
This may cause problems on hosts not supporting %hd (MinGW?), and there's
no real need for using h here given the
OK.
Jason
On Oct 5, 2012, at 3:19 PM, Diego Novillo dnovi...@google.com wrote:
On Fri, Oct 5, 2012 at 6:08 PM, Lawrence Crowl cr...@googlers.com wrote:
For many people the time to compile (almost) empty file is very
important, we are already bad about that right now, initializing
too much stuff
On Mon, 8 Oct 2012, Uros Bizjak wrote:
You missed the most important sseadd1 addition, the one that prevents
checking of operand2 when calculating memory attribute:
(and (eq_attr type
!alu1,negnot,ishift1,
imov,imovx,icmp,test,bitmanip,
Kenneth Zadeck zad...@naturalbridge.com writes:
diff --git a/gcc/combine.c b/gcc/combine.c
index 4e0a579..b531305 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -2617,16 +2617,19 @@ try_combine (rtx i3, rtx i2, rtx i1, rtx i0, int
*new_direct_jump_p,
constant. */
if (i1 == 0
Jonathan,
Any further thoughts about this? I've attached a diff that combines
my origional diff with the change to use the newlib locale model on
OpenBSD since they probably should be committed together.
On 10 September 2012 07:34, Mark Kettenis wrote:
Date: Sun, 9 Sep 2012 21:07:39 +0100
I have backported the following patches from trunk to google-4_7:
191931, 192049, 192120, 192165
gcc:
2012-10-08 Dehao Chen de...@google.com
Backport 191931, 192049, 192120, 192165 from trunk.
* tree-vect-loop-manip.c (slpeel_make_loop_iterate_ntimes): Use
On 8 October 2012 20:45, Mark Kettenis wrote:
Jonathan,
Any further thoughts about this? I've attached a diff that combines
my origional diff with the change to use the newlib locale model on
OpenBSD since they probably should be committed together.
Hi,
Sorry for the delay, I realised over
Robert Dewar de...@adacore.com writes:
On 10/8/2012 11:01 AM, Nathan Froyd wrote:
- Original Message -
Btw, as for Richards idea of conditionally placing the length field
in
rtx_def looks like overkill to me. These days we'd merely want to
optimize for 64bit hosts, thus
On Mon, Oct 8, 2012 at 9:36 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Mon, 8 Oct 2012, Uros Bizjak wrote:
You missed the most important sseadd1 addition, the one that prevents
checking of operand2 when calculating memory attribute:
(and (eq_attr type
Some more issues found by Coverity scanner.
lto-cgraph.c: The code seems to be unused, besides, it's a zero-trip
loop as parm_num is set to 0 and then checked non nonzeroness.
lto-opts: The check whether first_p is non NULL is always false: All
calls have a variable ref as argument - and
On 10/07/2012 02:52 PM, Steven Bosscher wrote:
On Sat, Oct 6, 2012 at 4:52 AM, Vladimir Makarov wrote:
Without this patch:
Compressing live ranges: from 700458 to 391665 - 55%, pre_count
40730653, post_count 34363983
max per-reg pre_count 12978 (228090, 2 defs, 2 uses) (reg/f:DI 228090
[
On 07/25/2012 07:54 PM, Sterling Augustine wrote:
On Wed, Jul 25, 2012 at 4:00 PM, Cary Coutant ccout...@google.com wrote:
Perhaps instead of having a val_index field in each attribute you should
have the attribute point to something like an indirect_string_node for
addresses as well.
The
On Mon, Oct 8, 2012 at 10:25 PM, Vladimir Makarov vmaka...@redhat.com wrote:
Actually I have a simpler and better patch:
Ah, lra_insn_recog_data, I couldn't find out how to get the insn itself :-)
The OOM you're seeing on gcc17 is probably because we're both working
on that machine. If we're
Hello!
2012-10-08 Uros Bizjak ubiz...@gmail.com
* config/i386/atom.md (atom_sse_4): Merge atom_sse_attr attibutes.
(atom_sse_5): Ditto.
Tested on x86_64-pc-linux-gnu {,-m32}, committed to mainline SVN.
Uros.
Index: config/i386/atom.md
From: Dodji Seketeli do...@redhat.com
Date: Mon, 8 Oct 2012 14:12:04 +0200
Jason Merrill ja...@redhat.com writes:
OK.
Thanks. Committed to trunk at revision r192199.
This caused a build failure, see PR54860.
brgds, H-P
1 - 100 of 117 matches
Mail list logo
