2012/1/13 Georg-Johann Lay :
> Denis Chertykov schrieb:
>
>> Committed
>>
>> Denis
>
>
> Some questions regarding the fix:
>
> 1) You know if PR42204 is still relevant and can be closed?
> Or is it not related to PR50925?
The PR42204 is a duplicate of PR50925 or vice versa.
But, I'm not sure tha
I have committed a patch to libgo to update it to the weekly.2011-12-22
release. As usual I am not including all the changes here, only the
ones to files which are specific to gccgo. Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 27d9b39a0e27
Hello Everyone,
This patch is for the C++ Compiler in the Cilkplus branch. This patch
will handle array notations inside conditional expressions.
Thanking You,
Yours Sincerely,
Balaji V. Iyer.diff --git a/gcc/cp/ChangeLog.cilk b/gcc/cp/ChangeLog.cilk
index 3ba0406..06ef1ec 100644
--- a/
Please take a look.
http://codereview.appspot.com/5541046/
On 2012/01/12 23:16:03, asharif1 wrote:
This merges in the fix for ICE when using PGO when building Chrome.
+reviewer: dnovillo.
Updated the patch description.
http://codereview.appspot.com/5541046/
Reviewers: xur, shenhan, jingyu,
Message:
This merges in the fix for ICE when using PGO when building Chrome.
Please review this at http://codereview.appspot.com/5541046/
Affected files:
M.
M gcc/ChangeLog.google-4_6
M gcc/profile.c
Index: .
==
Another case where one address space may support multiple pointer
sizes, so conversions between such must be preserved.
* tree-ssa.c (useless_type_conversion_p): Conversions between
different-sized pointers aren't useless.
Index: tree-ssa.c
===
> The solution is to fix the scanning loop to look into the insn pattern
> itself for all set and clobbered hard registers. This way, all
> registers, clobbered by the pattern, will be correctly marked in the
> "live" bitmap, including FLAGS register that is ignored by current
> approach.
>
> 2012-
Mike Stump schrieb:
On Jan 12, 2012, at 8:44 AM, Georg-Johann Lay wrote:
Again: A test case that fails because it incorrectly assumes int is 32 bits
wide.
Ok to apply?
I'd think the testcase is more naturally:
return ~((uint32_t) (arg > -3));
That not equivalent to the proposed patch: I
This full-expression is potentially constant because the LHS is, but we
can't fold_non_constant_expr the RHS because it involves a
statement-expression. So let's treat it as value-dependent to avoid
trying to fold it.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 3b2ed7d426c6f7f2b0c5
ok for google branches.
David
On Wed, Jan 11, 2012 at 2:55 PM, Rong Xu wrote:
> This patch fixes the ICE when building the histrogram for
> value profile. It's casued by profile mismatch.
>
> Tested with SPEC2000 INT.
>
> This is for google branches.
>
> 2012-01-11 Rong Xu
>
> * gcc/p
Thanks, committed.
Denis Chertykov schrieb:
Committed
Denis
Some questions regarding the fix:
1) You know if PR42204 is still relevant and can be closed?
Or is it not related to PR50925?
2) Can we remove from avr.c:avr_option_override() the following:
if (avr_strict_X)
flag_caller_saves = 0;
t
On Wed, 11 Jan 2012, Benjamin Kosnik wrote:
> I thought it better to get this in, warts and all, and have it be
> corrected than to dally around again and have it not checked in.
Awesome. Seeing the validator errors, I figured I'll try and help,
alas you only left a single one for me -- patch at
I intent to commit the attached patch to link
from http://gcc.gnu.org/gcc-4.6/changes.html to
http://gcc.gnu.org/gcc-4.6/porting_to.html
and
from http://gcc.gnu.org/gcc-4.7/changes.html to
http://gcc.gnu.org/gcc-4.7/porting_to.html
Seemingly no one has written a porting-to document for 4.5 -
On Thu, Jan 12, 2012 at 21:24, Tobias Burnus wrote:
> This patch changes the handling of the CHMOD intrinsic.
>
> Currently, libgfortran calls /bin/chmod via fork/exec. The problem is on one
> hand that the re-implemented system() call is not 100% correct.
>
> On the other hand, it will not work o
Here's the page with links, more validation fixes, and removal of the C
item.
best,
Benjamin2012-01-12 Benjamin Kosnik
* htdocs/gcc-4.7/porting_to.html: Fixup for validation.
* htdocs/gcc-4.7/changes.html: Add link to porting_to.html.
* htdocs/gcc-4.6/changes.html: A
This patch changes the handling of the CHMOD intrinsic.
Currently, libgfortran calls /bin/chmod via fork/exec. The problem is on
one hand that the re-implemented system() call is not 100% correct.
On the other hand, it will not work on systems where /bin/chmod is not
available. For instance,
Hello!
As discussed in the PR, attached testcase uncovers problem with the
way peephole2 pas determines free registers to allocate temporary
register. The problem was with the pattern such as:
(insn 7 19 16 2 (parallel [
(set (reg:DI 0 ax [65])
(ashift:DI (const_int -1
On Jan 12, 2012, at 8:44 AM, Georg-Johann Lay wrote:
> Again: A test case that fails because it incorrectly assumes int is 32 bits
> wide.
>
> Ok to apply?
I'd think the testcase is more naturally:
> return ~((uint32_t) (arg > -3));
Does that work for you? Anyone want to weigh in on which ver
2012/1/9 Denis Chertykov :
> Hi Georg.
>
> I have found that conversion AVR port to using hard_frame_pointer have
> resolved PR 50925 .
> I have tested the patch without regressions, but I'm worry about it.
> Can you test it with your testsuite for regressions ?
> May be you have your own special d
Hi Richard,
Not an ideal solution, since the availability of this pattern implies
it's extremely cheap, and we'll replace jumps to the epilogue with
this pattern.
Or to define an availability predicate similar to i386, testing if
the epilogue is trivial, and only a return insn is needed.
Somet
http://gcc.gnu.org/viewcvs?view=revision&revision=183131
The earlier patch partially fixed 48051, but gave the wrong mangling for
explicitly scoped names. Fixed by this patch.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 15b9202da53e0bd0c2be55f2f3a91c7de3484cbe
Author: Jason Merrill
Date: Sat Jan 7 06:15:05 2012 -0500
PR c++/48051
Hi,
On Thu, Jan 12, 2012 at 03:23:31PM +0100, Richard Guenther wrote:
> On Thu, 12 Jan 2012, Martin Jambor wrote:
>
> > Hi,
> >
> > I tend to believe that this is the SRA part of a fix for PR 50444 (and
> > possibly some strict alignment SRA-related bugs too. What it does is
> > that it decreas
Simple error-recovery.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 547a34a4cc962c0aa2d914416e94e014900c33b6
Author: Jason Merrill
Date: Thu Jan 12 06:15:17 2012 -0500
PR c++/51403
* pt.c (unify): Handle error_mark_node.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index ac72b6d
Again: A test case that fails because it incorrectly assumes int is 32 bits
wide.
Ok to apply?
* gcc.c-torture/execute/20120111-1.c: Fix wrong int = int32_t
assumption.
Index: gcc.c-torture/execute/20120111-1.c
==
2012/1/12 Georg-Johann Lay :
> This PR prints a false warning because missing DECL_EXTERNAL test in
> avr_encode_section_info that checks if progmem variables come with initializer
> or not.
>
> Ok for trunk?
>
> PR target/51756
> * config/avr/avr.c (avr_encode_section_info): Test for
On 01/12/2012 09:21 AM, Dodji Seketeli wrote:
This is the udpated patch that I have tested and am about to bootstrap.
OK.
Jason
This PR prints a false warning because missing DECL_EXTERNAL test in
avr_encode_section_info that checks if progmem variables come with initializer
or not.
Ok for trunk?
PR target/51756
* config/avr/avr.c (avr_encode_section_info): Test for absence of
DECL_EXTERNAL when ch
Hi,
In over-widening pattern we expect the last statement to be a type
demotion, but don't check this properly. The patch fixes the check, and
also updates vect-widen-shift-u8.c to expect additional widening shift
pattern instead of over-widening pattern.
Bootstrapped and tested on powerpc64-sus
> > + Boolean type promotion changes
> > +
> > +
> > + The C compiler no longer promotes boolean values in arithmetic
> > + statements to integer values. Configure-related code that checks
> > for
> > + C99's may be impacted. If the following line is
> > + newly present in configure
On Thu, 12 Jan 2012, Martin Jambor wrote:
> Hi,
>
> I tend to believe that this is the SRA part of a fix for PR 50444 (and
> possibly some strict alignment SRA-related bugs too. What it does is
> that it decreases the alignment of the built MEM_REF type if it seems
> necessary. That is in cases
Jason Merrill writes:
> On 01/11/2012 05:57 PM, Dodji Seketeli wrote:
>> + list = cur_stmt_list;
>> if (TREE_CODE (list) == BIND_EXPR)
>> list = BIND_EXPR_BODY (list);
>> if (TREE_CODE (list) == STATEMENT_LIST
>
> cur_stmt_list should always be a STATEMENT_LIST, so these
On 01/11/2012 05:57 PM, Dodji Seketeli wrote:
+ list = cur_stmt_list;
if (TREE_CODE (list) == BIND_EXPR)
list = BIND_EXPR_BODY (list);
if (TREE_CODE (list) == STATEMENT_LIST
cur_stmt_list should always be a STATEMENT_LIST, so these tests are
unnecessary.
Jason
Hi,
I tend to believe that this is the SRA part of a fix for PR 50444 (and
possibly some strict alignment SRA-related bugs too. What it does is
that it decreases the alignment of the built MEM_REF type if it seems
necessary. That is in cases when the alignment of the type as it
arrived in the pa
> [Richard, combine question at the bottom for you. I've quoted Ulrich's
> whole message in order to provide a bit of context.]
I don't remember ALL of this, but can perhaps make a few hints.
> > The problem appears to be that an RTX expression like
> >
> > (minus:QI (subreg:QI (reg:SI 64 [
Hello Hans-Peter,
I guess, we do have a corporate assignment for KPIT.
It was signed by Bradley Kuhn from FSF side and Dhananjay Deshpande from
KPIT side, during April 2003. In a mail, Peter Brown from FSF has mentioned
ticket number #22417 which was associated with this corporate assignment.
On Wed, 11 Jan 2012, Benjamin Kosnik wrote:
> + Boolean type promotion changes
> +
> +
> + The C compiler no longer promotes boolean values in arithmetic
> + statements to integer values. Configure-related code that checks for
> + C99's may be impacted. If the following line is
> + n
Committed the patch below as obvious.
2012-01-12 Janne Blomqvist
* configure.ac: Remove check for fdopen.
* runtime/backtrace.c (CAN_PIPE): Fix comment, remove check for
fdopen.
* configure: Regenerated.
* config.h.in: Regenerated.
Index: configure.ac
Hello!
2012-01-12 Uros Bizjak
* config/i386/i386.md (*zero_extendsidi2_rex64): Correct movl template.
(x86_shift_adj_1): Remove operand constraint from operand 3.
Bootstrapped and regression tested on x86_64-pc-linux-gnu.
No functional changes, committed.
Uros.
Index: confi
When PR target/47852 was filed last year, it turned out that this seemed
to be the same problem as PR target/45693 on Tru64 UNIX, i.e. stub
implementations of pthread functions getting in the way, although I
couldn't really figure out how this happens. Since the problem on IRIX
didn't show up anyw
On Wed, Jan 11, 2012 at 14:55, Tobias Burnus wrote:
> Dear all,
>
> this is a follow up patch, which I think provides a better handling if
> either getcwd fails or is not availble - or if the pathname in argv[0]
> already is an absolute patch, in which case concatenating
> current-working-director
[Richard, combine question at the bottom for you. I've quoted Ulrich's
whole message in order to provide a bit of context.]
"Ulrich Weigand" writes:
> Richard Sandiford wrote:
>> At the moment, fwprop will propagate constants and registers
>> even if no further rtl simplifications are possible:
On 01/12/2012 01:11 AM, Benjamin Kosnik wrote:
I thought it better to get this in, warts and all, and have it be
corrected than to dally around again and have it not checked in.
Is the file actually linked to? (Same question also applies to the 4.5
and 4.6 version.)
The two most obvious plac
On Thu, Jan 12, 2012 at 2:35 AM, Ian Lance Taylor wrote:
> I noticed that the function decls for builtin functions were all being
> marked as varargs. This perplexing problem turned out to be due to
> void_list_node not being initialized when the builtin functions were
> declared. Why the fronte
On Wed, Jan 11, 2012 at 10:13 PM, DJ Delorie wrote:
>
> The assert is not valid for address spaces that support more than one
> pointer size, such as the generic space of TPF, mips64, or m32c.
Looks good to me.
Richard.
> 2012-01-11 DJ Delorie
>
> * cfgexpand.c (convert_debug_memory_a
47 matches
Mail list logo
