2012/6/27 Richard Henderson :
> On 06/27/2012 12:47 PM, Kai Tietz wrote:
>> 2012-06-27 Kai Tietz
>>
>> * config/i386/winnt.c (i386_pe_reloc_rw_mask): New function.
>> * config/i386/i386-protos.h (i386_pe_reloc_rw_mask): Add
>> prototype.
>> * config/i386/cygming.h (TARGET_A
On 6/27/12, Martin Jambor wrote:
> On Tue, Jun 26, 2012 at 11:06:15AM -0700, Lawrence Crowl wrote:
> > On 6/26/12, Martin Jambor wrote:
> > > On Mon, Jun 25, 2012 at 03:26:01PM -0700, Lawrence Crowl wrote:
> > > > +but think twice before using it in code
> > > > +intended to last a long time.
> >
On 6/27/12, Chiheng Xu wrote:
> On Jun 19, 2012, Lawrence Crowl wrote:
> > Function prototypes for extern functions should only occur in
> > header files. Functions should be ordered within source files to
> > minimize the number of function prototypes, by defining them before
> > @@ -121,13
On 6/27/12, Gabriel Dos Reis wrote:
>
> [...]
>
> | > Two spaces for members is common practice with GNU, and it seems to be
> | > used for libstdc++.
> | >
> | > One space for protection labels is not something I have heard of before
> | > and libstdc++ uses no indentation for them.
> | >
> | > A
On Jun 27, 2012, at 1:35 PM, Andrew Pinski wrote:
> On Wed, Jun 27, 2012 at 3:33 AM, Matthew Gretton-Dann
> wrote:
>> All,
>>
>> This patch enables the dump-noaddr test to work in out-of-build-tree
>> testing.
>>
>> It does this by making sure that the dump files generated during the
>> test are
On Jun 27, 2012, at 3:36 PM, Janis Johnson wrote:
> These scans from gcc.dg/vect/vect-50.c, and others similar to them in
> other vect tests, hurt my brain:
>
> /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2
> "vect" { xfail { vect_no_align } } } } */
> /* { dg-final {
On Jun 27, 2012, at 12:21 PM, Kai Tietz wrote:
> this patch fixes a testsuite-failure for LLP64 targets.
>
> ChangeLog
>
> 2012-06-27 Kai Tietz
>
>* g++.dg/cpp0x/constexpr-52672.C (ul_ptr): Use SIZE_TYPE instead of
>hard-coded 'unsigned long'.
> Ok for apply?
Ok.
On Jun 27, 2012, at 1:13 PM, Richard Henderson wrote:
> Would it be of any use to introduce an .rdata$N section (equivalent
> to .data.ro) so that most of the runtime relocations are adjacent,
> and more of the executable image is sharable?
I can't help but think that grouping them together would
On 06/27/2012 03:53 PM, Steven Bosscher wrote:
> * system.h (IFCVT_EXTRA_FIELDS): Poison.
> (IFCVT_INIT_EXTRA_FIELDS): Poison.
> * basic-block.h (struct ce_if_block): Remove IFCVT_EXTRA_FIELDS.
> * ifcvt.c (find_if_header): Use IFCVT_MACHDEP_INIT instead of
> IFCVT_INI
Hello,
The only user of IFCVT_EXTRA_FIELDS is FR-V -- and it's not even using
the macro to define extra fields...
This patch removes IFCVT_EXTRA_FIELDS and replaces the related
IFCVT_INIT_EXTRA_FIELDS with IFCVT_MACHDEP_INIT.
Bootstrapped&tested on x86_64-unknown-linux-gnu, and build&tested with
These scans from gcc.dg/vect/vect-50.c, and others similar to them in
other vect tests, hurt my brain:
/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect"
{ xfail { vect_no_align } } } } */
/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect
On 06/27/2012 02:42 PM, Steven Bosscher wrote:
> Maybe also a bit in doc/generic.texi? Or is this not supposed to be
> exposed to the front ends?
I can't imagine it being terribly useful to front ends, but there's
certainly nothing that ought to prevent it. How's this?
r~
diff --git a/gcc/doc/g
On Wed, Jun 27, 2012 at 11:37 PM, Richard Henderson wrote:
> * tree.def (MULT_HIGHPART_EXPR): New.
> * cfgexpand.c (expand_debug_expr): Ignore it.
> * expr.c (expand_expr_real_2): Handle it.
> * fold-const.c (int_const_binop_1): Likewise.
> * optabs.c (optab_for_
* config/alpha/alpha.c (alpha_dimode_u): New.
(alpha_init_builtins): Initialize it, and use it.
(alpha_fold_builtin_cmpbge): Use alpha_dimode_u.
(alpha_fold_builtin_zapnot, alpha_fold_builtin_insxx): Likewise.
(alpha_fold_vector_minmax, alpha_fold_builtin_per
I was sitting on this patch until I got around to fixing up Jakub's
existing vector divmod code to use it. But seeing as how he's adding
more uses, I think it's better to get it in earlier.
Tested via a patch sent under separate cover that changes
__builtin_alpha_umulh to immediately fold to MUL
As noticed by Igor Zamyatin. Committed.
r~
---
PR target/53749
* config/i386/i386.c (ix86_rtx_costs): Fix typo vs UNITS_PER_WORD
in 2012-06-23 change. Adjust two other DImode tests as well.
---
gcc/ChangeLog |6 ++
gcc/config/i386/i386.c |8 +++-
2 fil
On 27 June 2012 21:27, Richard Henderson wrote:
> On 06/20/2012 05:44 AM, Ramana Radhakrishnan wrote:
>> + case NEON_DUP:
>> + if (TREE_CODE (argp[0]) == INTEGER_CST
>> + || TREE_CODE (argp[0]) == REAL_CST)
>> + return build_vector_from_val (result_type,
Hello,
This small patch moves a couple of #defines into the only files that
use them. En passant xcoff.h (gcc/xcoff.h, *not* the rs6000/xcoff.h)
becomes unused and can be removed.
Tested by building a cross cc1 from x86_64-unknown-linux-gnu to
rs6000-ibm-aix4.3, just to be sure.
OK for trunk?
C
On Wed, Jun 27, 2012 at 3:33 AM, Matthew Gretton-Dann
wrote:
> All,
>
> This patch enables the dump-noaddr test to work in out-of-build-tree
> testing.
>
> It does this by making sure that the dump files generated during the
> test are created under $tmpdir.
I created a much simpler patch which I
On 06/20/2012 05:44 AM, Ramana Radhakrishnan wrote:
> + case NEON_DUP:
> + if (TREE_CODE (argp[0]) == INTEGER_CST
> + || TREE_CODE (argp[0]) == REAL_CST)
> + return build_vector_from_val (result_type, argp[0]);
> + return NULL_TREE;
You can exp
On 06/27/2012 12:47 PM, Kai Tietz wrote:
> 2012-06-27 Kai Tietz
>
> * config/i386/winnt.c (i386_pe_reloc_rw_mask): New function.
> * config/i386/i386-protos.h (i386_pe_reloc_rw_mask): Add
> prototype.
> * config/i386/cygming.h (TARGET_ASM_RELOC_RW_MASK): Define
> as
Hello,
this patch makes sure that for pe(+)-coff targets always relocations
are allowed in readonly memory.
This fixes for x86_64-w64-mingw32 target some testcases.
ChangeLog
2012-06-27 Kai Tietz
* config/i386/winnt.c (i386_pe_reloc_rw_mask): New function.
* config/i386/i386-pr
Hi,
this patch fixes a testsuite-failure for LLP64 targets.
ChangeLog
2012-06-27 Kai Tietz
* g++.dg/cpp0x/constexpr-52672.C (ul_ptr): Use SIZE_TYPE instead of
hard-coded 'unsigned long'.
Tested for x86_64-w64-mingw32, and x86_64-unknown-linux-gnu. Ok for apply?
Regards,
Kai
On Jun 27, 2012, at 2:07 AM, Alexandre Oliva wrote:
> Why? We don't demand a working plugin. Indeed, we disable the use of
> the plugin if we find a linker that doesn't support it. We just don't
> account for the possibility of finding a linker that supports plugins,
> but that doesn't support t
Here, we were parsing s::s wrong. When we've seen a
class-key, an injected-class-name must be considered to name the class,
not the constructor, because the class-key limits lookup to finding type
names. Fixing that corrects the error message for this testcase, and
avoids the ICE.
Tested x8
On 06/26/2012 01:54 PM, Alexandre Oliva wrote:
> + track_stack_pointer (dst, src1, src2);
Why does this function return a value then?
r~
On Tue, Jun 26, 2012 at 10:56 AM, nick clifton wrote:
> Hi Matt,
>
>
>> There's also a trivial documentation fix:
>>
>> [PATCH 1/2] doc: Correct __builtin_arm_tinsr prototype documentation
>>
>> and a test to exercise the intrinsics:
>>
>> [PATCH 2/2] arm: add iwMMXt mmx-2.c test
>
>
> These have
On Wed, Jun 27, 2012 at 10:06 AM, Richard Guenther wrote:
> With this patch (ontop of the one requiring ClooG 0.17.0)
> we will require ISL 0.10 for enabling Graphite.
Thanks Richi, Micha, and Tobi for picking up this code and making this
transition happen. I owe each of you a beer ;-)
Sebastia
On Jun 27, 2012, at 3:33 AM, Matthew Gretton-Dann wrote:
> This patch enables the dump-noaddr test to work in out-of-build-tree testing.
> * gcc.c-torture/unsorted/dump-noaddr.x: Generate dump files in
> tmpdir.
> OK?
Ok.
On Jun 27, 2012, at 7:45 AM, Iain Buclaw wrote:
> I do have a question though, what is available for the transition of
> development from git to svn? Other than a lot of ready and getting
> used to the various switches and commands on my part.
Why transition? Quite a few people around here use g
Hi,
>> here is a patch related to type-bound operators, which fixes both PR
>> 49591 and parts of PR 41951 (namely comment #12). The central piece of
>> the patch is the resolve.c part. This adds all type-bound operator
>> routines also to the non-typebound operator list (i.e. ns->op). In
>> this
2012/6/7 Fabien Chêne :
[...]
> ... committed as rev 188294.
> I will backport it to 4.7 when it unfreezes.
... Eventually backported as rev 189021.
--
Fabien
On Wed, Jun 27, 2012 at 9:14 PM, Richard Henderson wrote:
> On 06/27/2012 10:08 AM, Igor Zamyatin wrote:
>> On Wed, Jun 27, 2012 at 9:00 PM, Richard Henderson wrote:
>>> > On 06/27/2012 09:07 AM, Igor Zamyatin wrote:
>> May I ask about the purpose of the following piece of change? Doesn't
>>
On 06/27/2012 10:08 AM, Igor Zamyatin wrote:
> On Wed, Jun 27, 2012 at 9:00 PM, Richard Henderson wrote:
>> > On 06/27/2012 09:07 AM, Igor Zamyatin wrote:
>>> >> May I ask about the purpose of the following piece of change? Doesn't
>>> >> it affect non-sse cases either?
>> >
>> > Err, no, it doesn
On Wed, Jun 27, 2012 at 9:00 PM, Richard Henderson wrote:
> On 06/27/2012 09:07 AM, Igor Zamyatin wrote:
>> May I ask about the purpose of the following piece of change? Doesn't
>> it affect non-sse cases either?
>
> Err, no, it doesn't affect non-sse cases. All MODE_VECTOR_INT
> cases will be im
On 06/27/2012 09:07 AM, Igor Zamyatin wrote:
> May I ask about the purpose of the following piece of change? Doesn't
> it affect non-sse cases either?
Err, no, it doesn't affect non-sse cases. All MODE_VECTOR_INT
cases will be implemented in the xmm registers (ignoring the
deprecated and largely
On Wed, 27 Jun 2012, Iain Buclaw wrote:
> OK, thanks. As the D frontend goes through a sometimes experimental
> development process between each release, I'd rather have it so that I
> merge the frontend into GDC as each release happens, instead of
> keeping in constant sync. This is how I handl
On 27 June 2012 16:47, Joseph S. Myers wrote:
> On Wed, 27 Jun 2012, Iain Buclaw wrote:
>
>> It's copied as including c-common.c / .h causes problems with a fair
>> number of references pulled in that need to be stubbed out - also,
>> some GCC function attributes that we use do not make any sense
On 28 May 2012 11:08, Carrot Wei wrote:
> Hi
>
> This is the second part of the patches that deals with 64bit and. It directly
> extends the patterns anddi3, anddi3_insn and anddi3_neon to handle 64bit
> constant operands.
>
Comments about const_di_ok_for_op still apply from my review of your add
On 28 May 2012 11:08, Carrot Wei wrote:
> Hi
>
> This is the second part of the patches that deals with 64bit and. It directly
> extends the patterns anddi3, anddi3_insn and anddi3_neon to handle 64bit
> constant operands.
>
Comments about const_di_ok_for_op still apply from earlier review.
Howe
May I ask about the purpose of the following piece of change? Doesn't
it affect non-sse cases either?
@@ -32038,7 +32042,15 @@ ix86_rtx_costs (rtx x, int code, int
outer_code_i, int opno, int *total,
case ASHIFTRT:
case LSHIFTRT:
case ROTATERT:
- if (!TARGET_64BIT && GET_MODE (XEX
On 8 June 2012 10:12, Carrot Wei wrote:
> Hi
>
> In rtl expression, substract a constant c is expressed as add a value -c, so
> it
> is alse processed by adddi3, and I extend it more to handle a subtraction of
> 64bit constant. I created an insn pattern arm_subdi3_immediate to specifically
> repr
On 27 June 2012 15:58, Dmitry Melnik wrote:
> Hi,
>
> We'd like to note about CodeSourcery's patch for ARM backend, from which GCC
> mainline can gain 4% on SPEC2K INT:
> http://cgit.openembedded.org/openembedded/plain/recipes/gcc/gcc-4.5/linaro/gcc-4.5-linaro-r99369.patch
> (also the patch is att
On 27/06/12 15:58, Dmitry Melnik wrote:
> Hi,
>
> We'd like to note about CodeSourcery's patch for ARM backend, from which
> GCC mainline can gain 4% on SPEC2K INT:
> http://cgit.openembedded.org/openembedded/plain/recipes/gcc/gcc-4.5/linaro/gcc-4.5-linaro-r99369.patch
>
> (also the patch is a
On Wed, 27 Jun 2012 18:58:36 +0400
Dmitry Melnik wrote:
> This patch can be applied to current trunk and passes regtest
> successfully on qemu-arm.
> Maybe it will be good to have it in trunk?
> If everybody agrees, we can take care of committing it.
No objection from me (as the original author
On Wed, 27 Jun 2012, Iain Buclaw wrote:
> It's copied as including c-common.c / .h causes problems with a fair
> number of references pulled in that need to be stubbed out - also,
> some GCC function attributes that we use do not make any sense to have
> in D code (eg: gnu_inline, artificial, clea
On 06/27/2012 10:45 AM, Richard Guenther wrote:
> On Wed, Jun 27, 2012 at 5:02 AM, Richard Henderson wrote:
>> sometimes not (increased code size):
>>
>> -: 41 bd 01 00 00 00 mov$0x1,%r13d
>> -: 4d 89 ecmov%r13,%r12
>> +: 41 bc 01 00 00 00 mov
On 06/27/2012 01:45 AM, Richard Guenther wrote:
>> > Of course, this fires for normal integer code as well.
>> > Some cases it's a clear win:
>> >
>> > -: 41 be 1f 00 00 00 mov$0x1f,%r14d
>> > ...
>> > -: 4c 89 f1mov%r14,%rcx
>> > +: b9 1f 00 00 00
On Wed, Jun 27, 2012 at 4:58 PM, Dmitry Melnik wrote:
> This patch can be applied to current trunk and passes regtest successfully
> on qemu-arm.
> Maybe it will be good to have it in trunk?
> If everybody agrees, we can take care of committing it.
If the patch is approved, can you please add a b
On 19 June 2012 17:08, Steven Bosscher wrote:
>
> Many functions have no leading comment, and other GNU coding standard
> requirements are not followed either. Those should IMHO be fixed also,
> before this front end can be accepted.
>
To separate this from the other listed items. I am aware of
Hi,
We'd like to note about CodeSourcery's patch for ARM backend, from which
GCC mainline can gain 4% on SPEC2K INT:
http://cgit.openembedded.org/openembedded/plain/recipes/gcc/gcc-4.5/linaro/gcc-4.5-linaro-r99369.patch
(also the patch is attached).
Originally, we noticed that GNU Go works 6
Hi!
When testing SVN valgrind AVX support, I've discovered a bug in
this testcase, which has been initializing only half of the array and
performed testing on the second half of the array with uninitialized random
stack data.
Tested on x86_64-linux and i686-linux, committed to trunk.
2012-06-27
On 19 June 2012 17:20, Joseph S. Myers wrote:
> On Mon, 18 Jun 2012, Iain Buclaw wrote:
>
>> [PATCH 1/4]:
>> The D compiler frontend
>> - gcc/d
>
> Only selectively reviewed, but here are some comments:
>
>> diff -Naur gcc-4.8-20120617/gcc/d/asmstmt.cc gcc-4.8/gcc/d/asmstmt.cc
>> --- gcc-4.8-201
Hi!
This patch makes veclower2 attempt to emit integer division/modulus of
vectors by constants using vector multiplication, shifts or masking.
It is somewhat similar to the vect_recog_divmod_pattern, but it needs
to analyze everything first, see if all divisions or modulos are doable
using the s
Hi Janus,
On 06/27/2012 02:42 PM, Janus Weil wrote:
here is a patch related to type-bound operators, which fixes both PR
49591 and parts of PR 41951 (namely comment #12). The central piece of
the patch is the resolve.c part. This adds all type-bound operator
routines also to the non-typebound op
On 25 June 2012 04:32, Jason Merrill wrote:
> On 06/18/2012 09:04 AM, Ramana Radhakrishnan wrote:
>>
>> + location_t loc = EXPR_LOC_OR_HERE (t);
>
>
> We should only use EXPR_LOC_OR_HERE for diagnostics. For a location to use
> in building other expressions, use EXPR_LOCATION.
Thanks for the re
On Fri, Jun 22, 2012 at 9:16 AM, Richard Guenther wrote:
>
> This bumps the requirement to enable Graphite to using cloog 0.17.0
> which is the last release from upstream. The patch removes the
> support for the legacy cloog versions, too.
>
> I am bootstrapping and testing this now with cloog 0.
On 06/27/2012 08:35 AM, Chiheng Xu wrote:
dynamic_cast use RTTI, while TREE_CODE are poor man's type info. RTTI
is better than TREE_CODE. But, If you decide to use RTTI, TREE_CODE
become redundant, that means all use of TREE_CODE should be removed,
sooner or later. Are you prepared for that ?
On Wed, 27 Jun 2012, Kai Tietz wrote:
> 2012-06-27 Kai Tietz
>
> PR preprocessor/37215
> * c-ppoutput.c (preprocess_file): Check for none-empty buffer.
"nonempty"
> Tested for x86_64-unknown-linux-gnu, and i688-pc-cygwin. Ok for apply?
OK with the ChangeLog typo fixed.
--
J
Hello,
this patch fixes an ICE on valid code for preprocessor as described in PR 37215
ChangeLog
2012-06-27 Kai Tietz
PR preprocessor/37215
* c-ppoutput.c (preprocess_file): Check for none-empty buffer.
Tested for x86_64-unknown-linux-gnu, and i688-pc-cygwin. Ok for apply?
Re
Hi,
On Tue, Jun 26, 2012 at 11:06:15AM -0700, Lawrence Crowl wrote:
> On 6/26/12, Martin Jambor wrote:
> > On Mon, Jun 25, 2012 at 03:26:01PM -0700, Lawrence Crowl wrote:
> > > > I have no idea. I don't use emacs. The two-space rule for
> > > > members comes from the wiki. The one-space rule f
On Tue, Jun 19, 2012 at 6:28 AM, Lawrence Crowl wrote:
> Function prototypes for extern functions should only occur in
> header files. Functions should be ordered within source files to
> minimize the number of function prototypes, by defining them before
> @@ -121,13 +208,13 @@
> necessary,
Hi Guys,
I am checking in the patch below to the mainline and 4.7 branch
sources to fix a typo in the comparesi3_extend patterns in the rx.md
file. Operand 0 is an input operand but it had an = modifier applied
to it. This confused gcc's internals and resulted in several ICEs in
the gc
On Wed, Jun 27, 2012 at 2:35 PM, Chiheng Xu wrote:
> On Wed, Jun 27, 2012 at 2:19 AM, Lawrence Crowl wrote:
>> On 6/26/12, Jason Merrill wrote:
>>> On 06/25/2012 06:26 PM, Lawrence Crowl wrote:
>>> > +orgcc_unreachable. If the checks are expensive or the
>>> > +compiler can reasonably carry on
Hi all,
here is a patch related to type-bound operators, which fixes both PR
49591 and parts of PR 41951 (namely comment #12). The central piece of
the patch is the resolve.c part. This adds all type-bound operator
routines also to the non-typebound operator list (i.e. ns->op). In
this way, duplic
On Wed, Jun 27, 2012 at 2:19 AM, Lawrence Crowl wrote:
> On 6/26/12, Jason Merrill wrote:
>> On 06/25/2012 06:26 PM, Lawrence Crowl wrote:
>> > +orgcc_unreachable. If the checks are expensive or the
>> > +compiler can reasonably carry on after the error, they may be
>> > +conditioned on--enable-
This fixes PR53695 where we recognize a loop which has only an
abnormal goto edge from its header to its tail. We already reject
loops during recognition that have at least a single abnormal
predecessor of its head so it seems reasonable to at least require
one regular CFG path from its header to
This fixes PR53774, a case where reassoc produced non-canonical
statements like a = 4 + b. The reason it did so was that it
assigned a rank of zero to things that are not constant. Fixed
by pre-computing a rank for all SSA default defs.
Bootstrapped and tested on x86_64-unknown-linux-gnu, appli
All,
This patch enables the dump-noaddr test to work in out-of-build-tree testing.
It does this by making sure that the dump files generated during the
test are created under $tmpdir.
gcc/testsuite/ChangeLog:
2012-06-27 Matthew Gretton-Dann
* gcc.c-torture/unsorted/dump-noaddr.x: Ge
On Jun 25, 2012, Alexandre Oliva wrote:
> On Jun 24, 2012, Richard Sandiford wrote:
>> gcc.c-torture/compile/vector-2.c fails on mips64-elf with RTL checking
>> enabled because dead_debug_insert_temp tries to read the REGNO of something
>> that it has already replaced with a debug temporary.
>
On Jun 21, 2012, Uros Bizjak wrote:
> Hello!
>> > During htab_delete (dropped_values), loc_exp_dep_pool
>> > allocated objects might be accessed, so it is better to free the
>> > pool afterwards.
>> >
>> > Bootstrapped/regtested on i686-linux, ok for trunk?
>>
>> Looks obvious.
> The patch does
On 26.06.2012 22:17, Alexandre Oliva wrote:
On Jun 26, 2012, Christophe Lyon wrote:
On 25.06.2012 17:24, Joseph S. Myers wrote:
On Mon, 25 Jun 2012, Christophe Lyon wrote:
Ping?
I advise CCing appropriate maintainers (in this case, build system
maintainers) on pings.
Ping again, CCing bu
[Adding gcc@]
On Jun 26, 2012, "H.J. Lu" wrote:
> On Tue, Jun 26, 2012 at 3:39 PM, Mike Stump wrote:
>> On Jun 26, 2012, at 2:04 PM, Alexandre Oliva wrote:
>>> I test i686-linux-gnu in a presumably unusual setting
>>
>> I like the setup and testing...
>>
>>> This worked fine for regression te
On Wed, Jun 27, 2012 at 10:40 AM, Zhenqiang Chen wrote:
> Hi,
>
> In general, invariant motion itself can not reduce code size. But it will
> change the liverange of the invariant, which might lead to more spilling.
This may be true for ARM but it's not true in general. Sometimes
loop-invariant a
On Wed, Jun 27, 2012 at 10:40 AM, Zhenqiang Chen wrote:
> Hi,
>
> In general, invariant motion itself can not reduce code size.
It can expose CSE opportunities across loops though.
> But it will
> change the liverange of the invariant, which might lead to more spilling.
"might" - indeed. I won
[...]
| > Two spaces for members is common practice with GNU, and it seems to be
| > used for libstdc++.
| >
| > One space for protection labels is not something I have heard of before
| > and libstdc++ uses no indentation for them.
| >
| > A freshly started emacs also doesn't indent access label
On Wed, Jun 27, 2012 at 2:35 AM, Magnus Fromreide wrote:
> On Mon, 2012-06-25 at 15:17 -0700, Lawrence Crowl wrote:
>> On 6/25/12, Joseph S. Myers wrote:
>> > On Mon, 25 Jun 2012, Diego Novillo wrote:
>> > > [ Added doc maintainers in CC ]
>> > >
>
>> I have added a bit more in the rationale, rea
On Wed, Jun 27, 2012 at 5:02 AM, Richard Henderson wrote:
> The problem I'd like to solve is stuff like
>
> pxor %xmm4, %xmm4
> ...
> movdqa %xmm4, %xmm2
> pcmpgtd %xmm0, %xmm2
>
> In that there's no point performing the copy from xmm4
> rather than just emitting a new pxo
On Tue, Jun 26, 2012 at 11:28 PM, H.J. Lu wrote:
> On Tue, Jun 26, 2012 at 2:04 PM, Alexandre Oliva wrote:
>> I test i686-linux-gnu in a presumably unusual setting: it's an
>> x86_64-linux-gnu system, and I've configured the GCC build to use as
>> builddev tools wrapper scripts for as, ld, gnatma
Hi,
In general, invariant motion itself can not reduce code size. But it will
change the liverange of the invariant, which might lead to more spilling.
The patch disables loop2_invariant when optimizing for size.
I measured the code size benefit for four targets based on CSiBE benchmark:
ARM: 0.
Hi Dodji Seketeli:
Is it possible to gcc to accept libcpp.patch and plugin.patch?
I recently rewrite my doc.txt which mainly add a new section , it's focused on pfile.context usage linking to
macro. I think it's important to use cb_macro_start/end callbacks
because most users only care about the
Hi Mike,
I plan on applying a similar patch to the mainline sources once I have
finished regression testing them.
Really, trunk should always go in first... Could you hold 4.7 until trunk goes
in?
Sorry, I had already checked the patch in. I have now checked in the
trunk patch, with o
82 matches
Mail list logo
