hi, Richard
On Mon, Sep 26, 2011 at 11:50 AM, Richard Sandiford
wrote:
> Dinar Temirbulatov writes:
>> I found typo in the patch instead of checking *set_after != 0 it was
>> set_after != 0, here is corrected version of patch. I retested the
>> patch without typo on mipsel-unknown-linux-gnu with
Hello,
> ok, so if we have an auto-inc'ing insn which defines (auto-inc's) an
> addr register and another (say, result) register, we want to allow the
> result register to have life ranges in excess of ii (by eliminating
> anti-dep edges of distance 1 from uses to def, and generating
> reg_moves i
On 26 September 2011 17:12, Richard Guenther wrote:
> On Mon, Sep 19, 2011 at 9:54 AM, Ira Rosen wrote:
>> Hi,
>>
>> This patch adds a support of widening shift left. The following
>> pattern is detected:
>>
>> type a_t;
>> TYPE a_T, res_T;
>>
>> a_t = ;
>> a_T = (TYPE) a_t;
>> res_T = a_T << CON
Backport mainline r179236 to ARM/embedded-4_6-branch.
Committed.
2011-09-27 Joey Ye
Backport r179236 from mainline
2011-09-27 Marcus Shawcroft
* libsupc++/tinfo.cc (type_info::operator==): Test __name instead
of name().
Commit to trunk an approved but forgotten patch:
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00876.html
Eric, I'm sure you have noticed this, but the Sparc target test
"combined-1.c" fails for some time on 32-bit because of how float
arguments are passed in the 32-bit SPARC ABI.
Since they are passed in integer registers, the vectorizer does
the initial logical operations using non-VIS instructions
> Think of it this way. What the IR says is there is no barrier between
> those moves. You either have an implicit barrier (which is what you
> are proposing) or you have it explicitly. I think we all rather have
> more things explicit rather than implicit in the IR. And that has
> been the ove
On Mon, Sep 26, 2011 at 7:28 PM, Jiangning Liu wrote:
>
> Sorry, for this bug, I don’t see your valuable comments previously in either
> bug zilla and the [RFC] I sent out long time ago in gcc mail list. What I see
> is a bunch of people agreed this problem should be fixed in middle end.
The on
Hi,
pretty straightforward, tested x86_64-linux, committed to mainline.
Thanks,
Paolo.
///
2011-09-26 Paolo Carlini
PR libstdc++/50529
* include/bits/vector.tcc (vector<>::erase(iterator, iterator)):
Fix to do nothing if the range is empty.
*
Fix a typo and CC x86/rs6000/arm ports maintainers.
ChangeLog:
* config/i386/i386.c (ix86_stack_using_red_zone): Change inline
to be extern.
(TARGET_STACK_USING_RED_ZONE): New.
* config/rs6000/rs6000.c (rs6000_stack_using_red_zone): New.
(TARGET_STA
> -Original Message-
> From: Andrew Pinski [mailto:pins...@gmail.com]
> Sent: Tuesday, September 27, 2011 5:31 AM
> To: Jiangning Liu
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Fix stack red zone bug (PR38644)
>
> On Mon, Sep 26, 2011 at 3:26 AM, Jiangning Liu
> wrote:
> > Thi
I wanted to adjust the types of these builtins before this hits a
release and they are set in stone. I adjusted the edge and
pixel-compare operation return value to 'long' from 'int' to minimize
the zero and sign extensions that need to happen. And this will only
get worse when I add intrinsics
When Paolo asked earlier, I thought these two were the same bug, but on
investigation they turned out to be unrelated. In 46105 we were
treating (const T)::element_type as different from T::element_type, and
in 45102 we were pulling out the constant value of RUNTIME and then
deciding it was di
On Mon, Sep 26, 2011 at 7:31 AM, Revital Eres wrote:
> Hello,
>
> This patch extends the implementation to support instructions with
> REG_INC notes.
> It addresses the comments from the previous submission:
> http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01299.html.
>
ok, so if we have an auto-in
On Tue, Sep 27, 2011 at 9:27 AM, Liang Wang wrote:
> Hi,
>
> I find that the description from line 36, gcc/vec.h is wrong. It
> should be the pointers in structure object variant are dereferenced
> and the objects copied into the vector.
>
> The following patch makes the *former* and *latter* in
Hi,
I find that the description from line 36, gcc/vec.h is wrong. It
should be the pointers in structure object variant are dereferenced
and the objects copied into the vector.
The following patch makes the *former* and *latter* in comment to
point to the right thing.
OK for trunk?
By the way,
Hi
This patch removes the XPASS of test case 20040204-1.c on arm.
Tested by
on arm: make check-gcc RUNTESTFLAGS="--target_board=arm-sim/thumb/arch=armv7-a
tree-ssa.exp=20040204-1.c"
on x86_64: make check-gcc RUNTESTFLAGS="tree-ssa.exp=20040204-1.c"
OK for google/gcc-4_6?
thanks
Carrot
2011-0
Hello,
The gcc.target/sh/mfmovd.c test was ran even for targets that can't
support it at all. While I was at it, I've also noticed that for some
reason SH4A specific tests were ran for other targets and reported a
fake pass, although the tests are actually unsupported.
Cheers,
Oleg
2011-09-27
On Tue, Sep 27, 2011 at 02:15:24AM +0200, Bernd Schmidt wrote:
> That looks perfectly reasonable, and even if it is ordered in the way
> shown above, dwarf2cfi still should be able to deal with it if the
> prologue and epilogue are annotated correctly.
Here I was thinking that it was someone else'
cxx_eval_logical_expression was assuming that a folded first operand of
&& would be either boolean_true_node or boolean_false_node, but in fact
it can be a constant with a typedef of bool, which doesn't compare equal
with ==. So we should use tree_int_cst_equal to compare them instead.
Tested
>OK for mainline?
Doh, hard to believe we never checked that an insn defines a register
before spitting out reg_moves for it ... nice catch.
This
+ /* Skip instructions that do not set a register. */
+ if (set && !REG_P (SET_DEST (set)))
+ continue;
is ok. Can you also prevent !
*Resending as plain text*
I am attaching a patch of the updated files. This patch was meant for
the google gcc-4_6 branch. Sorry for not mentioning this upfront in my
original mail.
Thanks,
-Sri.
> On Mon, Sep 26, 2011 at 9:53 AM, Sriraman Tallam wrote:
>>
>> On Mon, Sep 26, 2011 at 9:22 AM,
OK.
Jason
As noticed by Jonathan, the namespace chosen for this extension is not
in the implementation namespace and clashes with a similar name in
: the placeholders for bind.
Fixed thusly. And another name injection patchlet.
However, there's a bit of an added wrinkle in that now libstdc++ is
linked in
On 09/27/11 02:11, Alan Modra wrote:
> On Tue, Sep 27, 2011 at 12:39:36AM +0200, Bernd Schmidt wrote:
>> On 09/27/11 00:32, Alan Modra wrote:
>>> On Mon, Sep 26, 2011 at 11:22:54PM +0930, Alan Modra wrote:
Two regressions appeared due to a problem in the shrink-wrap code.
>>>
>>> These two.
>>
On Tue, Sep 27, 2011 at 12:39:36AM +0200, Bernd Schmidt wrote:
> On 09/27/11 00:32, Alan Modra wrote:
> > On Mon, Sep 26, 2011 at 11:22:54PM +0930, Alan Modra wrote:
> >> Two regressions appeared due to a problem in the shrink-wrap code.
> >
> > These two.
> > +FAIL: g++.dg/torture/pr46111.C -O1
For PR lto/47247, I updated the linker plugin API to add a new entry
point, LDPT_GET_SYMBOLS_V2, and a new symbol resolution code,
LDPR_PREVAILING_DEF_IRONLY_EXP. Ian approved the patch on the binutils
side, but it includes a change to an include file shared with gcc.
This patch to sync include/plu
On 09/27/2011 12:05 AM, cr...@google.com wrote:
The gcc source uses several constructs that GDB does not understand.
This patch corrects some of them. It affects only compilers built
with ENABLE_TREE_CHECKING, and hence release compilers are unaffected.
This is "funny". I have been using for yea
Hi,
the below implements what submitter requested - ie, separate bindings
with semicolons instead of commas, already used in many other places.
Seems a pretty straightforward change to me. Tested x86_64-linux.
Ok for mainline?
Thanks,
Paolo.
/
/cp
2011-09-26 Paolo Carl
On 09/27/11 00:32, Alan Modra wrote:
> On Mon, Sep 26, 2011 at 11:22:54PM +0930, Alan Modra wrote:
>> Two regressions appeared due to a problem in the shrink-wrap code.
>
> These two.
> +FAIL: g++.dg/torture/pr46111.C -O1 (internal compiler error)
> +FAIL: gcc.dg/autopar/pr46099.c (internal comp
Rainer Orth writes:
> Apart from the (already fixed) go.* dejagnu errors, I noticed another
> problem: the libgo net test now fails on Solaris, but only with Sun ld:
>
> Undefined first referenced
> symbol in file
> getaddrinfo
On Mon, Sep 26, 2011 at 11:22:54PM +0930, Alan Modra wrote:
> Two regressions appeared due to a problem in the shrink-wrap code.
These two.
+FAIL: g++.dg/torture/pr46111.C -O1 (internal compiler error)
+FAIL: gcc.dg/autopar/pr46099.c (internal compiler error)
Both "internal compiler error: in m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/18/11 15:59, Richard Henderson wrote:
> On 08/17/2011 12:21 AM, Richard Guenther wrote:
>> The patch itself looks sensible, though I am surprised ifcvt
>> doesn't run in cfglayout mode (so you have to use reg notes to
>> find probabilities ...)
>
The gcc source uses several constructs that GDB does not understand.
This patch corrects some of them. It affects only compilers built
with ENABLE_TREE_CHECKING, and hence release compilers are unaffected.
In particular, I change the implementation of CHECK macros using
__extension__ into macros
Rainer Orth writes:
> the problem turned out to be obvious once you ignore most of the error
> message ;-( The spurious import is in sysinfo.go, which unconditionally
> imports the package, but only uses in some cases.
And this patch should fix the Solaris problem. Bootstrapped and ran Go
test
On 09/26/2011 07:55 AM, Jakub Jelinek wrote:
> * rtl.h (const_tiny_rtx): Change into array of 4 x MAX_MACHINE_MODE
> from 3 x MAX_MACHINE_MODE.
> (CONSTM1_RTX): Define.
> * emit-rtl.c (const_tiny_rtx): Change into array of 4 x MAX_MACHINE_MODE
> from 3 x MAX_MACHINE_
On Mon, Sep 26, 2011 at 3:26 AM, Jiangning Liu wrote:
> This patch is fix PR38644, a 3-year-old bug.
>
> From the discussions in mail list and bugzilla, I think the middle end fix
> is a common view. Although there are stills some gaps on how to fix it in
> middle end, I think this patch at least
Committed to trunk.
gcc/testsuite/
* gcc.target/sparc/rdgsr.c: New test.
* gcc.target/sparc/edge.c: New test.
* gcc.target/sparc/fcmp.c: New test.
---
gcc/testsuite/ChangeLog|3 ++
gcc/testsuite/gcc.target/sparc/edge.c | 39 +++
Hi,
Here is a simple patch to add SECTION_EXCLUDE to the list of
section flag macros. Is this ok for trunk?
Thanks,
-Sri.
* output.h (SECTION_EXCLUDE): New macro.
* varasm.c (default_elf_asm_named_section): Check for
SECTION_EXCLUDE.
Index: gcc/varasm.c
=
On 09/26/2011 04:21 PM, Dodji Seketeli wrote:
Jason Merrill writes:
On 09/21/2011 02:32 PM, Dodji Seketeli wrote:
FWIW, I'd like the LRK_MACRO_PARM_REPLACEMENT name (or its
replacement. ha ha) to hint at the fact that it really has to do with
a token that is an /argument/ for a function-like
Hi,
>> >I just committed as obvious two small patches for two recently
>> >reported accepts-invalid PRs (after regtesting):
>> >
>> >http://gcc.gnu.org/viewcvs?view=revision&revision=179213
>>
>> Thanks !
>>
>> As far as the fortran/interface.c change is concerned, why isn't a full
>> TKR (Type/Ki
On Mon, Sep 26, 2011 at 10:28:14PM +0200, Toon Moene wrote:
> On 09/26/2011 10:10 PM, Janus Weil wrote:
>
> >Hi all,
> >
> >I just committed as obvious two small patches for two recently
> >reported accepts-invalid PRs (after regtesting):
> >
> >http://gcc.gnu.org/viewcvs?view=revision&revision=17
On 09/26/2011 10:10 PM, Janus Weil wrote:
Hi all,
I just committed as obvious two small patches for two recently
reported accepts-invalid PRs (after regtesting):
http://gcc.gnu.org/viewcvs?view=revision&revision=179213
Thanks !
As far as the fortran/interface.c change is concerned, why isn'
I foolishly tried to use an unspec to keep the compiler from
eliminating stores to %gsr, when the proper thing to do is to
mark it in global_regs[] instead.
Committed to trunk.
gcc/
* config/sparc/sparc.c (sparc_conditional_register_usage): When VIS
is enabled, mark %gsr as glob
Jason Merrill writes:
> On 09/21/2011 02:32 PM, Dodji Seketeli wrote:
>> FWIW, I'd like the LRK_MACRO_PARM_REPLACEMENT name (or its
>> replacement. ha ha) to hint at the fact that it really has to do with
>> a token that is an /argument/ for a function-like macro.
>
> I disagree; arguments are t
Hi all,
I just committed as obvious two small patches for two recently
reported accepts-invalid PRs (after regtesting):
http://gcc.gnu.org/viewcvs?view=revision&revision=179213
Cheers,
Janus
On Fri, Sep 17, 2010 at 5:57 AM, Martin Jambor wrote:
> Hi,
>
> this is a followup to my previous build_ref_for_offset patch. If
> build_user_friendly_ref_for_offset does not succeed when building an
> artificial SRA access, we use build_ref_for_model which produces an
> expression we cannot use
Rainer Orth writes:
> the problem turned out to be obvious once you ignore most of the error
> message ;-( The spurious import is in sysinfo.go, which unconditionally
> imports the package, but only uses in some cases.
Ah. This patch fixes the location of the error message. Bootstrapped
and r
On 09/26/2011 10:21 AM, Dodji Seketeli wrote:
> > + /* The cpp_reader the macro comes from. */
> > + cpp_reader *pfile;
>
> This seems to only be used to decide whether or not to increment
> location_ptr. Rather than base that decision on going all the way
> back to the CPP_OPTION, le
From: David Miller
Date: Sat, 24 Sep 2011 17:30:57 -0400 (EDT)
> From: Hans-Peter Nilsson
> Date: Sat, 24 Sep 2011 17:15:06 -0400 (EDT)
>
>> One more: please consider adding a
>> if (TARGET_VIS) builtin_define ("__VIS__=something") so I as a
>> user theoretically wouldn't *have* to autoconfisc
This patch from Chung-Lin Tang fixes PR50496.
I post it under his name (hope this is OK). The original patch can be
found here:
https://code.launchpad.net/~cltang/gcc-linaro/lp-748138-cfgrtl-fix-4_5/+merge/60742/+preview-diff/+files/preview.diff
https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+b
Hi,
this patch implements slim LTO. It is updated version of Andi's patch. It is
done by terminating IPA optimization after analyzing and outputting LTO and in
compile_file skipping stuff that outputs assembly.
After some consideration I neded up with -ffat-lto-objects and
-fno-fat-lto-objects.
http://codereview.appspot.com/5090041/diff/1/gcc/cp/pph-streamer-out.c
File gcc/cp/pph-streamer-out.c (right):
http://codereview.appspot.com/5090041/diff/1/gcc/cp/pph-streamer-out.c#newcode1924
gcc/cp/pph-streamer-out.c:1924: tree enclosing_namespace )
1922 void
1923 pph_write_namespace_tree (
> >>> This patch is OK, with or without the testsuite additions Jakub
> >>> mentions.
> >>
> >> Thanks, I added the new tests, and tweaked the clone suffix parsing to
> >> allow the leading "_".
> >>
> >> Committed as r179132.
> >
> > Should I backport this patch to gcc-4_6-branch?
>
> Since you of
2011/9/26 Georg-Johann Lay :
> This patchlet represents the impact of insn ashrqi3 on CC by means of
> attribute
> "cc" instead of hard-coding it in notice_update_cc.
>
> Testsuite passes fine. Moreover, tested against code like
>
> char c;
>
> void func_1 (char a)
> {
> a = a >> 7;
> if (a)
On Sep 25, 2011, at 4:01 AM, Iain Sandoe wrote:
> Following Eric's fix to the stack-check output for rs6000/Darwin, I think we
> can enable this function for the port.
>
> bootstrapped/tested (including Java, Ada), on *-darwin9, x86-64-darwin10.
>
> OK for trunk?
Ok.
My patch for DR 1328 started comparing rvaluedness_matches_p for all
reference binding conversions, not just those where the target type
differs in rvaluedness. In this testcase, the rvaluedness of the
initializer differs: when calling the first function the initializer is
a pointer constant,
On Fri, Sep 23, 2011 at 10:34 AM, Jan Hubicka wrote:
> Hi,
> this patch extends inliner's predicate infrastructure to track optimization
> oppurtunities that depends on properties of call site parameters that are
> not readilly available (and do not belong to) jump functions.
>
> For this new inli
On Mon, Sep 26, 2011 at 06:01:45PM +0200, Jakub Jelinek wrote:
> In the above function with this e.g. a[4] object is modified during
> the extecution of the foo block B, thus the 6.7.3.1/4 rules should apply.
> And within that block a[4] is accessed through lvalues whose address
> is p1 based as we
On 09/26/2011 11:50 AM, Mike Spertus wrote:
This patch consists intrinsics to properly create the bases and direct_bases of
a class
Looks pretty good. Some comments:
#define GCC_TREE_H
-
#include "hashtab.h"
I don't see any reason to remove this blank line.
+ if (TREE_CODE (par
On Mon, Sep 26, 2011 at 9:22 AM, Nathan Froyd wrote:
> On 9/23/2011 6:03 PM, Sriraman Tallam wrote:
>>
>> This patch adds a new linker plugin to re-order functions.
>
> This is great stuff. We were experimenting with using the coverage files to
> generate an ordering for --section-ordering-file,
Paolo,
> Ok with a couple of changes:
>
>> gcc:
>> * gthr-posix.h, gthr-single.h, gthr.h: Move to ../libgcc.
>
> Move gthr-posix.h to config/
I had left it in libgcc directly since the file, like gthr-single.h, is
included in a couple of others, and is pretty generic. The updated
patch
On 26 September 2011 15:24, Ulrich Weigand wrote:
> Ramana Radhakrishnan wrote:
>> On 9 September 2011 18:04, Ulrich Weigand wrote:
>> >
>> > In theory, LEGITIMIZE_RELOAD_ADDRESS could attempt to handle them by
>> > substituting the equivalent constant and then reloading the result.
>> > However,
On 9/23/2011 6:03 PM, Sriraman Tallam wrote:
This patch adds a new linker plugin to re-order functions.
This is great stuff. We were experimenting with using the coverage
files to generate an ordering for --section-ordering-file, but this
might be even better, will have to experiment with it
On Mon, Sep 26, 2011 at 05:50:40PM +0200, Jakub Jelinek wrote:
> On Mon, Sep 26, 2011 at 04:56:20PM +0200, Richard Guenther wrote:
> > Let's see what kind of fallout we get ;) For example, if the
> > following is valid C code I expect we will vectorize the second
> > loop (disambiguating p[i] and
This patchlet represents the impact of insn ashrqi3 on CC by means of attribute
"cc" instead of hard-coding it in notice_update_cc.
Testsuite passes fine. Moreover, tested against code like
char c;
void func_1 (char a)
{
a = a >> 7;
if (a)
c = a;
}
that triggered PR39633.
Ok?
On Tue, Sep 20, 2011 at 11:23 AM, Doug Evans wrote:
> Hi.
>
> Part of the abstraction of an argv is a count of the number elements.
> This patch adds countargv which I have use for in gdb.
>
> Ok to check in?
>
> 2011-09-20 Doug Evans
>
> include/
> * libiberty.h (countargv): Decl
On Mon, Sep 19, 2011 at 5:52 PM, Doug Evans wrote:
> Hi.
>
> This patch adds two functions, timeval_add and timeval_sub,
> to libiberty. GDB has use for them in a few places and since
> they're general purpose I wish to check them into libiberty.
>
> Ok to check in?
>
> 2011-09-19 Doug Evans
>
On Mon, 26 Sep 2011, Jakub Jelinek wrote:
> Hi!
>
> Adding Joseph and Jason to CC.
>
> On Mon, Sep 26, 2011 at 04:56:20PM +0200, Richard Guenther wrote:
> > Let's see what kind of fallout we get ;) For example, if the
> > following is valid C code I expect we will vectorize the second
> > loop
Hi!
Adding Joseph and Jason to CC.
On Mon, Sep 26, 2011 at 04:56:20PM +0200, Richard Guenther wrote:
> Let's see what kind of fallout we get ;) For example, if the
> following is valid C code I expect we will vectorize the second
> loop (disambiguating p[i] and q[i]) bogously:
>
> void foo (int
This patch consists intrinsics to properly create the bases and
direct_bases of a class in the correct order (including multiple nested
ambiguous virtual and non-virtual classes) for N2965
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2965.html).
This allows you to create type trait
build_user_type_conversion_1 complains about ambiguity if
LOOKUP_COMPLAIN is set, so we need to avoid setting that flag when we
call the function from reference_binding. It seems to make sense to
mask away all inappropriate lookup flags at the top of
implicit_conversion rather than doing it fu
On Mon, Sep 26, 2011 at 4:25 PM, Richard Guenther
wrote:
> On Wed, Sep 7, 2011 at 5:06 PM, Joseph S. Myers
> wrote:
>> This looks like it has the same issue with maybe needing to use
>> TYPE_MAIN_VARIANT in type comparisons as the shuffle patch.
>
> I don't think so, we move qualifiers to the ve
> > ld -r is now supported with LTO
>
> Thanks, forgot about this one. This also needs support at linker side, right?
Only if you include assembler or non LTO code.
Without that it should work with any linker.
> Do you know minimal GNU ld/Gold versions that works fine?
I believe the assembler
On Mon, 26 Sep 2011, Jakub Jelinek wrote:
> Hi!
>
> As discussed in the PR, we currently don't vectorize
> #include
>
> std::valarray
> f1 (std::valarray a, std::valarray b, std::valarray c, int z)
> {
> int i;
> for (i = 0; i < z; i++)
> {
> a[i] = b[i] + c[i];
> a[i] += b[
On Mon, Sep 26, 2011 at 10:18:43AM +0100, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > optimize all ones vectors in simplify-rtx.c (and i386 expansion):
> > http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01364.html
>
> I wonder whether we should have a CONSTM1_RTX(MODE). It seems
> incon
Ping 3 ? I'd like to get this in before stage1 ends... There's
RX-specific code that goes with it that can't go in until the core
functionality is approved.
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01889.html
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02555.html
http://gcc.gnu.org/ml/gcc-
Hi!
As discussed in the PR, we currently don't vectorize
#include
std::valarray
f1 (std::valarray a, std::valarray b, std::valarray c, int z)
{
int i;
for (i = 0; i < z; i++)
{
a[i] = b[i] + c[i];
a[i] += b[i] * c[i];
}
return a;
}
void
f2 (std::valarray &__restrict a,
On Wed, Sep 14, 2011 at 10:38 PM, Richard Henderson wrote:
> On 09/13/2011 04:27 PM, Michael Meissner wrote:
>> This patch touches a bunch of files, but most of the changes are fairly
>> mechanical. What this does is change the infrastructure of how machine
>> independent builtin functions are ha
2011/9/26 Georg-Johann Lay :
> This is a minor tweak to do eq/ne comparisons one instruction shorter in the
> case where the compare target is unused after the comparison:
>
> For 1:
> DEC R0
> OR R0,R1
> OR R0,R2
> OR R0,R3
>
> For -1:
> AND R0,R3
> AND R0,R2
> AND R0,R1
> COM R0
>
> Th
On Thu, Sep 15, 2011 at 7:00 PM, Jakub Jelinek wrote:
> Hi!
>
> Here is an updated version of the support patch for the tree-ssa-strlen.c
> optimization. The only change is the propagation of gimple_block
> to the new call from the old call, otherwise Wobjsize-1.c testcase
> fails when we optimiz
On Wed, Sep 7, 2011 at 5:06 PM, Joseph S. Myers wrote:
> This looks like it has the same issue with maybe needing to use
> TYPE_MAIN_VARIANT in type comparisons as the shuffle patch.
I don't think so, we move qualifiers to the vector type from the element type
in make_vector_type and the tests on
Ramana Radhakrishnan wrote:
> On 9 September 2011 18:04, Ulrich Weigand wrote:
> >
> > In theory, LEGITIMIZE_RELOAD_ADDRESS could attempt to handle them by
> > substituting the equivalent constant and then reloading the result.
> > However, this might need additional steps (pushing to the constant
On Mon, Sep 19, 2011 at 9:54 AM, Ira Rosen wrote:
> Hi,
>
> This patch adds a support of widening shift left. The following
> pattern is detected:
>
> type a_t;
> TYPE a_T, res_T;
>
> a_t = ;
> a_T = (TYPE) a_t;
> res_T = a_T << CONST;
>
> ('TYPE' is at least 2 times bigger than 'type', and CONST
This patch increases opportunities for shrink-wrapping. With this
applied, http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00754.html and
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01499.html plus the fix
mentioned in http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01016.html,
along with my powerpc ch
On 09/25/2011 11:57 PM, Jason Merrill wrote:
Ville pointed out that my earlier patch failed to support 'this' in
NSDMIs. So this patch implements that.
...and this one fixes 'this' in templates.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 7893474d771c6449e05f8c85b3e9e418b9c72a57
Aut
On 09/25/2011 05:06 PM, Fabien Chêne wrote:
+ else if ((using_decl = strip_using_decl (member)) != member)
+ /* If it is a using decl, use its underlying decl. */
+ type_decl = strip_using_decl (type_decl);
- if (DECL_NAME (field) == name
+ if (DECL_NAME (decl) == name
This patch fixes an issue that limit opportunities for shrink-wrapping
on PowerPC. The rs6000 REG_ALLOC_ORDER chooses r0 as the very first
gpr to use in code, with r11 also having high priority. This means it
is quite likely that r0 or r11 is live on the edge chosen for
shrink-wrapping. That's u
OK.
Jason
OK.
Jason
This is a minor tweak to do eq/ne comparisons one instruction shorter in the
case where the compare target is unused after the comparison:
For 1:
DEC R0
OR R0,R1
OR R0,R2
OR R0,R3
For -1:
AND R0,R3
AND R0,R2
AND R0,R1
COM R0
The text peephole casesi+2 used 0x where -1 is the right
On 09/25/2011 02:39 PM, Fabien Chêne wrote:
Great, I would be glad to see it applied to 4.6. If you do that, you
may also want to adjust the last paragraph in the release note of 4.6.
Done, thanks for the suggestion.
Jason
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2011-09-26 Richard Guenther
PR tree-optimization/50472
* gimple-fold.c (fold_const_aggregate_ref_1): Do not fold
volatile references.
* gcc.dg/torture/pr50472.c: New testcase.
Index: gcc/
On 09/26/2011 12:29 PM, Richard Guenther wrote:
> On Sun, 25 Sep 2011, Tom de Vries wrote:
>
>> On 09/25/2011 10:57 AM, Richard Guenther wrote:
>>> On Sat, Sep 24, 2011 at 5:29 PM, Eric Botcazou
>>> wrote:
> This is an updated version of the patch. I have 2 new patches and an
> updated t
Hi,
as analyzed in the audit trail, it's pretty sure that this check in
get_bc_label is not serving any purpose anymore, because such
diagnostics is always (eg, also with -fsyntax-only, double checked)
produced by the parser. Thus I tested the below on x86_64-linux.
Ok for mainline?
Thanks,
On Mon, Sep 26, 2011 at 1:59 PM, Bingfeng Mei wrote:
> Richard,
> Here are updated patches. tm.texi.in doesn't need any change as the
> description of the hook is correct, just the order of parameters needs
> change.
Ok.
Thanks,
Richard.
> Thanks,
> Bingfeng
>
>
>
> 2011-09-26 Bingfeng Mei
>
Hi Richard,
gcc/
* config/m32r/m32r.md: Use match_test rather than eq/ne symbol_ref
throughout file.
Approved - please apply.
Cheers
Nick
Hi Richard,
gcc/
* config/iq2000/iq2000.md: Use match_test rather than eq/ne symbol_ref
throughout file.
Approved - please apply.
Cheers
Nick
Hi Robert,
> 2011/8/17 Rainer Orth :
>> Hi Robert,
>>
>>> My patch still applies cleanly to current HEAD, has this migration
>>> happened already? If not, what's the current ETA? I'll have almost
>>> no spare time after this week, I'd like to sort this out before/during
>>> the weekend if possib
On Sep 23, 2011, at 1:58 AM, Bruce Korb wrote:
> On 09/22/11 08:00, Tristan Gingold wrote:
>> Hi,
>>
>> this patch adds some fixes in fixincludes specific to VMS.
>> Until now we were using a manually modified subset of the VMS headers, but
>> using fix includes is the right way.
>>
>> Ok for
1 - 100 of 128 matches
Mail list logo
