On 2011/3/30 上午 12:23, Richard Earnshaw wrote:
>
> On Tue, 2011-03-29 at 22:53 +0800, Chung-Lin Tang wrote:
>> On 2011/3/29 下午 10:26, Richard Earnshaw wrote:
>>> On Tue, 2011-03-29 at 18:25 +0800, Chung-Lin Tang wrote:
On 2011/3/24 06:51 PM, Richard Earnshaw wrote:
>
> On Thu, 2011-03
Richard Henderson writes:
> On 03/29/2011 06:21 AM, Richard Sandiford wrote:
>> - enum machine_mode mode0 = insn_data[(int) icode].operand[1].mode;
>> - enum machine_mode mode1 = insn_data[(int) icode].operand[2].mode;
>> - enum machine_mode tmp_mode;
>> + enum machine_mode xmode0 = insn_data[
Richard Sandiford writes:
> The ??? is saying that the V8QI-derived MEM is really a 3-byte access,
> not a 4-byte (SI) access, and so on. The comment makes the mode sound
> like a representational niceity, but really, there's no such thing as
> a "conservatively wrong" memory size here.
Hi,
With this patch a data-ref is marked as unconditionally read or
written also if its adjacent field is read or written unconditionally
in the loop.
My concern is that this is not safe enough, even though the fields
have to be non-pointers and non-aggregates, and this optimization is
applied onl
On Wed, 2011-03-30 at 15:35 +0800, Chung-Lin Tang wrote:
> On 2011/3/30 上午 12:23, Richard Earnshaw wrote:
> >
> > On Tue, 2011-03-29 at 22:53 +0800, Chung-Lin Tang wrote:
> >> On 2011/3/29 下午 10:26, Richard Earnshaw wrote:
> >>> On Tue, 2011-03-29 at 18:25 +0800, Chung-Lin Tang wrote:
> On 2
On Tue, Mar 29, 2011 at 5:53 PM, Jakub Jelinek wrote:
> Hi!
>
> I've left these 4 out because I thought they should be fine given
> that the other operands are equal. But the testcase shows I was wrong.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
> for trunk?
Ok.
On Tue, Mar 29, 2011 at 7:00 PM, Aldy Hernandez wrote:
> [Language lawyers, please correct me if I have mis-interpreted the upcoming
> standard in any way.]
>
> In the C++ memory model, contiguous bitfields comprise a single memory
> location, so it's fair game to bit twiddle them when setting the
Hi Vlad,
First, I want to echo H-P's thanks for tackling this area. I just wondered:
Vladimir Makarov writes:
> The following patch is to solve PR48336, PR48342, PR48345. The
> profitable hard regs exclude hard regs which are prohibited for the
> corresponding allocno mode. It is true for pr
Hi,
I checked this pre-approved patch into trunk/4.6/4.5/4.4.
H.J.
---
Index: ChangeLog
===
--- ChangeLog (revision 171717)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2011-03-30 H.J. Lu
+
+ PR target/48349
+ *
On Wed, Mar 30, 2011 at 11:13 AM, Ira Rosen wrote:
> Hi,
>
> With this patch a data-ref is marked as unconditionally read or
> written also if its adjacent field is read or written unconditionally
> in the loop.
> My concern is that this is not safe enough, even though the fields
> have to be non-
Hi,
with GCC 4.4 compiling a testcase like "%:%:" on s390x triggers the
stack smashing protector.
Uli fixed this for GCC 4.5 with:
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00755.html
Ok to apply that patch on 4.4 branch?
Bye,
-Andreas-
On Tue, 29 Mar 2011 11:45:58 +0100
Richard Sandiford wrote:
> Julian Brown writes:
> > On Thu, 24 Mar 2011 10:57:06 +
> > Richard Sandiford wrote:
> >
> >> Chung-Lin Tang writes:
> >> > PR48183 is a case where ARM NEON instrinsics, under -O -g,
> >> > produce debug insns that tries to expa
On Tue, 29 Mar 2011, Hans-Peter Nilsson wrote:
> FWIW, I have a five regressions for cris-elf too appearing at
> that RA change, but as they're wrong-code and noticed only at
> execution, I'm going to wait analyzing further until this is
> committed and caught by my autotester. Just a heads-up.
L
On Wed, 2011-03-30 at 12:38 +0800, Chung-Lin Tang wrote:
> On 2011/3/30 06:35 AM, Ramana Radhakrishnan wrote:
> > Hi Carrot,
> >
> > On 26/03/11 15:14, Carrot Wei wrote:
> >> Index: arm.md
> >> ===
> >> --- arm.md(revision 171337
On 30 March 2011 12:59, Richard Guenther wrote:
> On Wed, Mar 30, 2011 at 11:13 AM, Ira Rosen wrote:
>> Hi,
>>
>> With this patch a data-ref is marked as unconditionally read or
>> written also if its adjacent field is read or written unconditionally
>> in the loop.
>> My concern is that this is
On Wed, Mar 30, 2011 at 2:22 PM, Ira Rosen wrote:
> On 30 March 2011 12:59, Richard Guenther wrote:
>> On Wed, Mar 30, 2011 at 11:13 AM, Ira Rosen wrote:
>>> Hi,
>>>
>>> With this patch a data-ref is marked as unconditionally read or
>>> written also if its adjacent field is read or written unco
Ok so I needed to install dejagnu from macports.
The comparison of the test results turned out empty except one output
that made no sense:
--
Tests that now fail, but worked before:
g++.dg/warn/Wstrict-aliasing-float-ref-int-obj.C (test for warnings,
line 7)
Tests that now work, bu
This patch adds a NegativeAlias .opt facility, for one option to be
marked as an alias for the negative form of another option. There are
quite a lot of options like that, and this is of particular use where
it allows option handler code to be removed because the aliases can
now be handled purely
On 30 March 2011 14:41, Richard Guenther wrote:
> On Wed, Mar 30, 2011 at 2:22 PM, Ira Rosen wrote:
>> On 30 March 2011 12:59, Richard Guenther wrote:
>>> On Wed, Mar 30, 2011 at 11:13 AM, Ira Rosen wrote:
Hi,
With this patch a data-ref is marked as unconditionally read or
w
> "Paolo" == Paolo Bonzini writes:
I saw this thread due to Joseph's recent post about top-level configury
changes...
Paolo> * May in principle be in use (or be put to some use for libelf):
Paolo> fastjar libelf
I think fastjar is dead.
Paolo> * Probably present only for historical reasons
The attached patch prevents P2 getting clobbered by stack check code.
2011-03-30 Stuart Henderson
From Jie Zhang
* config/bfin/bfin.c (bfin_expand_prologue): Don't clobber P2.
Thanks,
Stu
upstream.patch
Description: upstream.patch
Hi Guys,
I am applying the patch below to sync the RX backend with the 4.6
branch. In practice this means bringing in the peepholes to combine
extending loads and simple arithmetic expressions, and adjusting the
memory move cost cost for stores. (The insn length attribute is
needed for
The memory model is not implementable on strict-alignment targets
that do not have a byte store operation. But we previously said that ;)
Yes. I think we should issue an error when we have such a target and
the user tries -fmemory-model=c++0x. However, how many strict-alignment
targets ar
On Wed, Mar 30, 2011 at 4:11 PM, Aldy Hernandez wrote:
>
>> The memory model is not implementable on strict-alignment targets
>> that do not have a byte store operation. But we previously said that ;)
>
> Yes. I think we should issue an error when we have such a target and the
> user tries -fmem
Hi,
On Wed, 30 Mar 2011, Aldy Hernandez wrote:
>
> > The memory model is not implementable on strict-alignment targets
> > that do not have a byte store operation. But we previously said that ;)
>
> Yes. I think we should issue an error when we have such a target and the user
> tries -fmemory
So... do you have any important targets in mind, because I don't see this
being a problem for most targets? As can be expected, I am only interested
in x86*, powerpc*, and s390, especially since a cursory glance on other
important targets didn't exhibit any problems. However, given my target
b
On Tue, 2011-03-29 at 20:55 +, Joseph S. Myers wrote:
> This patch continues cleaning up the toplevel configure.ac, in particular
> as regards cases handling GCC libraries for targets where GCC is no longer
> (or never was) supported.
>
> The principle there, as discussed for the original d
On Wed, Mar 30, 2011 at 4:26 PM, Aldy Hernandez wrote:
>
>>> So... do you have any important targets in mind, because I don't see this
>>> being a problem for most targets? As can be expected, I am only
>>> interested
>>> in x86*, powerpc*, and s390, especially since a cursory glance on other
>>>
On Tue, 2011-01-18 at 16:56 +, Yufeng Zhang wrote:
> This patch replaces define_constants in the ARM backend with
> define_c_enum for defining the available indexes for the
> unspecs/unspecvs expressions. This improves the readability of the
> intermediate dumps for machine-specific operations
The attached patch allows long jumps to __mcount, defines
PROFILE_BEFORE_PROLOGUE and ensures ASM_OUTPUT_REG_PUSH pre-decrements the
stack pointer.
2011-03-30 Stuart Henderson
From Bernd Schmidt
* config/bfin/bfin.h (FUNCTION_PROFILER): Take TARGET_LONG_CALLS into
account and sa
While working on the dragonegg plugin I noticed that the Fortran front-end
declares frexp with the parameters the wrong way round. Instead of
double frexp(double x, int *exp);
it is declared as
double frexp(int *exp, double x);
This is fairly harmless but might as well be fixed, so here is a
On Tue, 2011-03-29 at 15:38 +0100, Richard Sandiford wrote:
> This ARM patch allows *UNSPEC_* constants to be printed in dump files.
> It's very much a target decision whether this is worth doing, but just
> in case...
>
> ...tested on arm-linux-gnueabi. OK to install?
>
> Richard
>
>
> gcc/
On Mar 30, 2011, at 5:41 AM, gcchelp.5.ad...@0sg.net wrote:
> Tests that now fail, but worked before:
>
> g++.dg/warn/Wstrict-aliasing-float-ref-int-obj.C (test for warnings, line 7)
>
> Tests that now work, but didn't before:
>
> g++.dg/warn/Wstrict-aliasing-float-ref-int-obj.C (test for warn
On Wed, Mar 30, 2011 at 4:23 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> As originally discussed here:
>
> http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00987.html
>
> Changes since the original submission:
>
> Per Richi's suggestion I changed the patch to use a GC'd V
Richard Earnshaw writes:
> On Tue, 2011-03-29 at 15:38 +0100, Richard Sandiford wrote:
>> This ARM patch allows *UNSPEC_* constants to be printed in dump files.
>> It's very much a target decision whether this is worth doing, but just
>> in case...
>>
>> ...tested on arm-linux-gnueabi. OK to ins
Hi,
Currently, we limit XVECEXP to 26 elements in machine description
since we use letters 'a' to 'z' to encode them. I don't see any
reason why we can't go beyond 'z'. This patch removes this restriction.
Any comments?
Thanks.
H.J.
---
2011-03-30 H.J. Lu
* genextract.c (gen_insn)
On Fri, 2011-02-18 at 10:56 +, Ian Bolton wrote:
> > Is the following patch OK for trunk?
> >
> >
> > 2011-01-26 Ian Bolton
> >
> > * testsuite/gcc.dg/20100906-1.c: Use -fno-short-enums
> > option for "target arm_eabi".
> >
> >
> > Index: gcc/testsuite/gcc.dg/20100906-1.c
> > =
On Mar 30, 2011, at 7:40 AM, Richard Guenther wrote:
>> Is forcing word-alignment too big of a hammer, or will the users for these
>> architectures be content with having no support for the C++0x memory model?
>
> I think a memory model that cannot be reasonably (read: also fast) implemented
> on
On 03/30/2011 01:53 AM, Richard Sandiford wrote:
> This comes back to the point that we really should know up-front what
> modes op0 and op1 actually have. (The thing I left as a future clean-up.)
> Until then, the process implemented by yesterday's patch was supposed to be:
>
>- work out wha
On Mon, 2011-02-14 at 14:20 +, Andrew Stubbs wrote:
> This patch is a rework of an old one:
>
> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01080.html
>
> The ARM parts of that patch were approved, but the target independent
> parts were never reviewed (AFAICT), and the patch no longer app
On Thu, 2011-02-10 at 15:29 +, Andrew Stubbs wrote:
> I'm posting this patch on behalf of Jie.
>
> The patch simply prevents a test failure on non-thumb2 targets.
>
> OK?
>
> Andrew
2010-09-30 Jie Zhang
gcc/testsuite/
* gcc.target/arm/neon-thumb2-move.c: Add
dg
On Wed, 30 Mar 2011, Richard Earnshaw wrote:
> > 2011-03-29 Joseph Myers
> >
>
> > (arm-*-coff): Don't disable libgcj.
> > (arm*-*-linux-gnueabi): Remove useless assignment.
> > (arm-*-riscix*): Don't disable libgcj.
>
>
> RISC iX support was removed from GCC years ago. Looks l
I have updated libgo to the current master Go library. The main reason
for this is to bring in some new code which uses nonblocking connect.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
foo.patch.bz2
Description: patch
As people noted one computes UIDs for PHIs and one doesn't. Now I'm
working on sth that needs it for PHIs, thus the following fix.
We have to exclude LTO as it re-builds PHIs and gets confused with
inconsistent numbering.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2
Hi!
MEM_REFs which can represent type punning on lhs don't force
non-gimple types to be addressable. This causes various problems
in the expander, which wasn't prepared to handle that.
This patch tries to fix what I've found and adds a bunch of
testcases. The original report was with just -O2 o
The following patch is to fix an arm bootstrap failure described in
http://gcc.gnu.org/ml/gcc/2011-03/msg00499.html
when variable mode is set but not used because it is used when macro
HONOR_REG_ALLOC_ORDER is defined.
I found that 2 variables mode in different scopes is defined in function
Hello,
I noticed this some time ago already, but it went away. Now it reoccured
and made me suspicious. "It" being random ICEs in fold_convert_loc, or
segfaults, sometimes reproducable, sometimes not, on the
realloc_on_assign_2.f03 testcase.
The issue is that the frontend leaks the address o
On Mon, Mar 28, 2011 at 6:11 PM, Vladimir Makarov wrote:
> On 03/27/2011 07:25 PM, Vladimir Makarov wrote:
>>
>> I submitted the following patch. The patch contains original
>> patches from ira-improv branch, changes addressing all Keneth Zadeck's
>> comments in http://gcc.gnu.org/ml/gcc-patches
On 03/30/2011 06:19 AM, Richard Sandiford wrote:
Hi Vlad,
First, I want to echo H-P's thanks for tackling this area. I just wondered:
Vladimir Makarov writes:
The following patch is to solve PR48336, PR48342, PR48345. The
profitable hard regs exclude hard regs which are prohibited for the
c
Nice cleanup thanks. Just noticed a couple of things:
Jeff Law writes:
> *** struct reload
> *** 100,106
> int inc;
> /* A reg for which reload_in is the equivalent.
>If reload_in is a symbol_ref which came from
> ! reg_equiv_constant, then this is the pseud
On 03/30/2011 06:21 PM, Michael Matz wrote:
Okay for trunk? (regstrapping on x86_64-linux in progress)
OK. Thanks for tracing the bug. I think the issue could be the reason
for the elusive PR 47516 - thus, you might consider adding that PR to
the ChangeLog and close the PR afterwards.
Tobi
On 03/29/2011 08:49 AM, Henderson, Stuart wrote:
>(match_operand:SI 2 "immediate_operand" "")))]
>""
> {
> - if (INTVAL (operands[2]) != 16)
> + if (GET_CODE (operands[2]) != CONST_INT || INTVAL (operands[2]) != 16)
> FAIL;
Perhaps use const_int_operand instead of i
On 03/29/2011 05:57 AM, Henderson, Stuart wrote:
> - operands[1] = bfin_gen_compare (operands[1], SImode);
> + operands[1] = bfin_gen_compare (operands[1], GET_MODE (operands[0]));
FWIW, you can use "mode" to get the proper value
without having to read it from the operand.
r~
On 03/29/2011 03:20 AM, Mark Wielaard wrote:
> 2011-03-29 Mark Wielaard
>
> * common.opt (fdebug-types-section): New flag.
> * doc/invoke.texi: Document new -fno-debug-types-section flag.
> * dwarf2out.c (use_debug_types): New define.
> (struct die_struct): Mark die_id with GTY
Hi,
On Wed, 30 Mar 2011, Tobias Burnus wrote:
> On 03/30/2011 06:21 PM, Michael Matz wrote:
> > Okay for trunk? (regstrapping on x86_64-linux in progress)
>
> OK. Thanks for tracing the bug. I think the issue could be the reason for the
> elusive PR 47516 - thus, you might consider adding that
On 03/30/2011 07:33 PM, Michael Matz wrote:
Hi,
On Wed, 30 Mar 2011, Tobias Burnus wrote:
On 03/30/2011 06:21 PM, Michael Matz wrote:
Okay for trunk? (regstrapping on x86_64-linux in progress)
OK. Thanks for tracing the bug. I think the issue could be the reason for the
elusive PR 47516 - t
I committed this patch to libgo to add some missing Makefile
dependencies. Bootstrapped on x86_64-unknown-linux-gnu. Committed to
mainline.
Ian
diff -r 58ba48318471 libgo/Makefile.am
--- a/libgo/Makefile.am Wed Mar 30 08:17:36 2011 -0700
+++ b/libgo/Makefile.am Wed Mar 30 10:35:55 2011 -0700
@@
The testcase in 48281 started breaking in 4.6.0 because of my change to
finish_compound_literal to stop putting constant compound literals into
static variables, because it was interfering with constexpr.
First I noticed that the crash was due to non-constant CONSTRUCTORs with
TREE_CONSTANT se
On Wed, Mar 30, 2011 at 08:02:38AM -0700, H.J. Lu wrote:
> Hi,
>
> Currently, we limit XVECEXP to 26 elements in machine description
> since we use letters 'a' to 'z' to encode them. I don't see any
> reason why we can't go beyond 'z'. This patch removes this restriction.
> Any comments?
>
Tha
Hello,
This is about the line program emitted by the compiler into the
.debug_line section, without optimization. In the example
accompanying the patch below, at the beginning of the function f, the
compiler emits two .loc asm directives that are identical. The first
one is right before the .cfi
I merged mainline revision 171737 onto the gccgo branch.
Ian
On Wed, Mar 30, 2011 at 7:23 AM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> As originally discussed here:
>
> http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00987.html
>
> Changes since the original submission:
>
> Per Richi's suggestion I changed the patch to use a GC'd V
A couple of missed cases.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.6.
commit cea17025eb232f3931ce34e16dedff7fd42d2478
Author: Jason Merrill
Date: Wed Mar 30 15:17:27 2011 -0400
PR c++/48369
* semantics.c (potential_constant_expression_1): Handle
UNORDERED_EX
Hi!
We ICE on the attached testcase, because combiner changes mode of
a pseudo (which was set just once and used once plus in debug insns)
from SImode to QImode, but the uses in debug insns aren't adjusted.
Combiner has code to adjust this too (propagate_for_debug), but only updates
debug insns b
Hello!
Attached ports go to ALPHA architecture.
There are however several problems with the build:
a) Bootstrap compare failure in the gcc/go directory due to binutils
bug [1], fixed in latest binutils SVN, use --disable-bootstrap
b) alpha doesn't define "struct user_regs_struct" from which "ty
On Wed, 2 Mar 2011, Richard Earnshaw wrote:
> Could you remove the documentation entries for the hard/soft-float
> aliases please? They're really only there for legacy reasons.
Is this the change you want here?
2011-03-30 Joseph Myers
* config/arm/arm.opt (mhard-float, msoft-float):
On Wed, Mar 30, 2011 at 9:58 PM, Uros Bizjak wrote:
> Hello!
>
> Attached ports go to ALPHA architecture.
>
> There are however several problems with the build:
>
> a) Bootstrap compare failure in the gcc/go directory due to binutils
> bug [1], fixed in latest binutils SVN, use --disable-bootstrap
non_const_var_error wasn't considering the possibility that the variable
is unsuitable for a constant expression because its initializer is
erroneous.
Tested x86_64-pc-linux-gnu, applied to trunk and 4.6.
commit 95a1f4128e0d9fb5480f0ae83240a6d339cf012e
Author: Jason Merrill
Date: Wed Mar 30
On 30 Mar 2011, at 21:11, "Joseph S. Myers" wrote:
> On Wed, 2 Mar 2011, Richard Earnshaw wrote:
>
>> Could you remove the documentation entries for the hard/soft-float
>> aliases please? They're really only there for legacy reasons.
>
> Is this the change you want here?
>
> 2011-03-30 Jose
Rainer Orth writes:
> 2011-03-24 Rainer Orth
>
> go:
> * go.test/go-test.exp (go-set-goarch): Use sparc64 for 64-bit SPARC.
> diff -r de1b3baf021b gcc/testsuite/go.test/go-test.exp
> --- a/gcc/testsuite/go.test/go-test.exp Thu Mar 24 13:19:30 2011 +0100
> +++ b/gcc/testsuite
Hi,
for some reasons the FAIL of pass49-frag now annoyed me enough to look
into it, where it didn't do so for the last 50 years it's failing (give or
take a few). mudflap has a mean to mark some expressions as not
interesting to generate checks for, which is used to disable this for the
indir
I brought over this patch to the Go testsuite from the master
repository. This avoids an explicit list of supported architectures, so
that we don't have to add each gcc architecture to the list. Ran Go
testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
Index: gcc/testsuite/go.te
This patch implements the writing of DECL_LANG_SPECIFIC fields. It's
needed to write global_namespace. The reading part is still
incomplete, but I wanted to flush this out before it got too big.
The main changes:
- We can now write out references to TEMPLATE_DECLs. They are stored
in the sa
The guality tests are failing/passing intermittently. This confuses
our builders which expect 0 failures and 0 xpasses. When they "work",
it's not that they are working but dejagnu failed to launch gdb:
-
spawn [open ..
Rainer Orth writes:
> * go-test.exp wasn't updated for the change from sparcv9 to sparc64.
> While I still don't agree with the new name, at least the two should
> be consistent.
I committed this earlier today.
> * env.go needs to accept sparc and sparc64.
I fixed this in a different way.
Rainer Orth writes:
> Apart from the lack of wait4, libgo on IRIX 6.5 contained an undefined
> reference to strerror_r. This patch provides a replacement, based on
> gnulib/lib/strerror_r.c, but massively simplified.
I addressed this in a different way, with a new variant of
syscall.Errstr writ
Hi,
This is the first cleanup for cprop.c. These cleanups are only
possible now, thanks to splitting the CPROP code out from gcse.c
The first change is to not treat unfolded conditions as constant in
gcse_constant_p(). This never happens because:
- during hash table building any such condition sh
Rainer Orth writes:
> Currently, libgo uses wait4 unconditionally, which is missing on IRIX
> 6.5. Fortunately, the rusage * arg is used nowhere, so I've decide to
> replace wait4 by waitpid, which seems to be considerably more portable.
Thanks for the patch, but I wasn't entirely happy with th
Hi,
this is a regression present for x86-64 on mainline and 4.6 branch with the
options -Os -mpreferred-stack-boundary=5 -fstack-check -fno-omit-frame-pointer.
This improbable combination of options is necessary because you need to have
stack checking + stack realignment + !ACCUMULATE_OUTGOING_A
I had misnamed the functions to convert output_block to pph_stream.
cp/ChangeLog.pph
2011-03-30 Diego Novillo
* pph-streamer.h (pph_get_pph_stream): Rename from
pph_get_ob_stream. Update all users.
(pph_set_pph_stream): Rename from pph_set_pph_stream. Update
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sigh. I changed a reg_equiv_address to reg_equiv_mem when I changed
from explicit VEC_index references to macros. That caused all kinds of
interesting problems for ia32 :-)
I'm also fixing a comment typo that was introduced around the same time.
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/30/11 10:51, Richard Sandiford wrote:
> Nice cleanup thanks. Just noticed a couple of things:
>
> Jeff Law writes:
>> *** struct reload
>> *** 100,106
>> int inc;
>> /* A reg for which reload_in is the equivalent.
>>
On Tue, 29 Mar 2011, Joseph S. Myers wrote:
> Other cleanups here:
> cris*-*-none acts just like cris*-*-elf in
> config.gcc so it's appropriate to make the "*" subcase of cris*-*-* act
> like the -elf case;
'k.
> mmix-*-* disabled "libgloss", i.e. libgloss for the
> host, which is never built a
The following patch solves the problem. The reason for the problem is
described on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48367
The patch has been committed as obvious.
2011-03-30 Vladimir Makarov
PR middle-end/48367
* ira-costs.c (find_costs_and_classes): Fix a typo i
Hi,
in order to reduce the size of my LTO early-merging patch I'll post some
cleanups separately. This one removes two functions that are not called
from anywhere and makes not allocate priority structs for all decls that
set them only to the DEFAULT_INIT_PRIORITY.
Regstrapped on x86_64-linux
Hi,
this came up when looking into why the static ctors contain useless trees
(like casts). We can simply canonicalize them while varpool analyzes
pending decls. It'll look at initialzers once, where we can "gimplify"
them. This requires making canonicalize_constructor_val be able to be
cal
On Wed, Mar 30, 2011 at 21:16, Michael Matz wrote:
> * tree.c (decl_init_priority_insert): Don't create entry for
> default priority.
> (decl_fini_priority_insert): Ditto.
> (fields_compatible_p, find_compatible_field): Remove.
> * tree.h (fields_compatible_p, f
Hi,
I noticed this while working on early-merging LTO. The DECL_VINDEX slot
of FUNCTION_DECLs is supposed to hold the numeric index of the vtable
slot if it's a virtual function. During parsing the C++ frontend uses it
to hold a reference to itself, which then later is supposed to be
transfo
On Wed, Mar 30, 2011 at 21:32, Michael Matz wrote:
> * tree.c (free_lang_data_in_decl): Zero DECL_VINDEX if it's not
> an integer.
> * tree.h (tree_decl_non_common.vindex): Adjust comment.
OK.
Diego.
No functional changes. Just some refactoring to stop mixing up
reading and writing routines in the same file.
Tested on x86_64.
cp/ChangeLog.pph
2011-03-30 Diego Novillo
* Make-lang.in (CXX_AND_OBJCXX_OBJS): Add cp/pph-streamer-out.o
and cp/pph-streamer-in.o.
(cp/pph
Hi,
I fear I wasn't as thorough in also splitting this one into several
patches, but the different cleanups are at least mostly in different
files. They are:
* lto-lang remembers all builtin decls in a local list, to be returned
by the getdecls langhook. But as we have our own write_globals
Hi Ramana
On Wed, Mar 30, 2011 at 6:35 AM, Ramana Radhakrishnan
wrote:
> Hi Carrot,
>
>
> How about adding an alternative only enabled for T2 that uses the `l'
> constraint and inventing new constraints for some of the constant values
> that are valid for 16 bit instructions since the `I'
On 03/30/2011 11:19 AM, Dodji Seketeli wrote:
> First, it avoids emitting two consecutive .loc that are identical.
> Strictly speaking that should fix this issue in this particular case.
What's the compatibility strategy? I.e. how does gdb tell that we're
not using the double-loc mechanism? Does
On 2011/3/30 05:28 PM, Richard Earnshaw wrote:
>
> On Wed, 2011-03-30 at 15:35 +0800, Chung-Lin Tang wrote:
>> On 2011/3/30 上午 12:23, Richard Earnshaw wrote:
>>>
>>> On Tue, 2011-03-29 at 22:53 +0800, Chung-Lin Tang wrote:
On 2011/3/29 下午 10:26, Richard Earnshaw wrote:
> On Tue, 2011-03-2
Hello.
This patch removes obsolete GO_IF_MODE_DEPENDENT_ADDRESS macros from H8300
back end in the GCC and introduces equivalent TARGET_MODE_DEPENDENT_ADDRESS_P
target hook.
Regression tested on h8300-unknown-elf with no new failure.
OK to install?
* config/h8300/h8300.h (GO_IF
Hello,
Is this ok to apply?
2011-03-31 Andreas Tobler
* config/rs6000/rs6000.c (rs6000_handle_option): Remove unused isel
var.
Index: config/rs6000/rs6000.c
===
--- config/rs6000/rs6000.c (revision 171769)
On Thu, Mar 31, 2011 at 08:30:42AM +0200, Andreas Tobler wrote:
> Hello,
>
> Is this ok to apply?
That patch is obvious, just commit it.
> 2011-03-31 Andreas Tobler
>
> * config/rs6000/rs6000.c (rs6000_handle_option): Remove unused isel
> var.
>
> --- config/rs6000/rs6000.c(
97 matches
Mail list logo
