Hi!
On the following testcase, VN during free keeps iterating forever, since
the unshare_expr call I've added to fix PR55935. The bug is that
when we have
volatile int a[1];
and &a[0] expression, if we unshare_expr that expression, it doesn't compare
operand_equal_p (exp, unshare_expr (exp), OEP_
Hi!
For integral types, we really should honor TYPE_UNSIGNED (scalar_type)
when we call type_for_mode for overaligned types, otherwise we can break
type checking (original something = something + 1; where something
is overaligned int type can become unsigned int vector for lhs and rhs1
and int vec
On 01/19/2013 12:22 PM, Jason Merrill wrote:
I think I'll hold off checking this in until Siddhesh's patch goes into
glibc.
It's in now, so I'm going to go ahead and check in my patch.
On 02/22/2013 02:14 PM, Jason Merrill wrote:
When we go to tsubst with explicit_args, we should put them in the tinst
level.
OK, that minimal change wasn't enough; we need to delay pushing until we
know what arguments we have to work with.
Tested x86_64-pc-linux-gnu, applying to trunk.
com
Here, the problem is that value_dependent_expression_p only expects to
see constant expressions, but potential_constant_expression_1 was
letting through some things that aren't in a way that the former
function was checking for. Fixed by returning false from the latter
function in that case.
OK.
Jason
Hi,
On Mon, Feb 25, 2013 at 4:08 PM, Steven Bosscher wrote:
> On Tue, Feb 26, 2013 at 12:32 AM, Wei Mi wrote:
>> We also take insn splitting and peephole into consideration,
>> .i.e, the cost of the change is the cost after insn splitting and
>> peephole which may be applied to the insn changed.
The coverage.c related patch is not uploaded properly. Will be reviewed
seperately.
David
https://codereview.appspot.com/7393058/diff/1/gcc/gcov-dump.c
File gcc/gcov-dump.c (right):
https://codereview.appspot.com/7393058/diff/1/gcc/gcov-dump.c#newcode581
gcc/gcov-dump.c:581: const char *primar
On Tue, Feb 26, 2013 at 12:32 AM, Wei Mi wrote:
> We also take insn splitting and peephole into consideration,
> .i.e, the cost of the change is the cost after insn splitting and
> peephole which may be applied to the insn changed. This is useful for
> the motivational case,
It also goes against e
On 02/25/2013 06:24 PM, Jason Merrill wrote:
I think my preference would be to avoid calling fixed_type_or_null at
all when we're in a template. I already changed
resolves_to_fixed_type_p that way, now we need to fix build_vtbl_ref_1.
Oops, now I see the discussion on the PR. I'll take a look
I think my preference would be to avoid calling fixed_type_or_null at
all when we're in a template. I already changed
resolves_to_fixed_type_p that way, now we need to fix build_vtbl_ref_1.
For post 4.8 we might avoid messing with vtables at all when we're in
a template.
Jason
x...@google.com (Rong Xu) writes:
> - gcov_unsigned_t is_exported;
> + gcov_unsigned_t flag;/* bit 0: is_exported,
> + bit 1: need to include all the auxiliary
> + modules in use compilation. */
"flags"?
Thanks,
-miles
Anyways, I've fixed the problem by setting TREE_SIDE_EFFECTS if the
transaction body has side effects. Perhaps we should do this for
build_transaction_expr() as well?
I would think managing the transaction boundaries would always have
side-effects, no? If that's correct, I'd set the flag unc
Whoops, wrong patch. This is the latest revision.
On 02/25/13 16:48, Aldy Hernandez wrote:
On 02/22/13 11:27, Richard Henderson wrote:
On 02/21/2013 02:14 PM, Aldy Hernandez wrote:
I suppose we could cheat and avoid passing PR_INSTRUMENTEDCODE if we
ever enter expand_block_tm(), but perhaps w
On 25 February 2013 22:43, Caroline Tice wrote:
> On Mon, Feb 25, 2013 at 1:14 PM, Jonathan Wakely wrote:
>>
>> Was configure regenerated of modified by hand? When regenerating it
>> with Autoconf 2.64 I get a different output.
>>
>
> I modified the configure file by hand. I didn't realize it was
On 02/22/13 11:27, Richard Henderson wrote:
On 02/21/2013 02:14 PM, Aldy Hernandez wrote:
I suppose we could cheat and avoid passing PR_INSTRUMENTEDCODE if we
ever enter expand_block_tm(), but perhaps we could do a little better as
with the attached patch.
I assume you meant "never enter" ther
On Mon, Feb 25, 2013 at 1:14 PM, Jonathan Wakely wrote:
> On 25 February 2013 19:52, Caroline Tice wrote:
>> I got too excited about being done and forgot to attach the patch. :-(
>> Sorry. Here it is.
>
> Some comments follow, mostly from reading the comments to understand
> what this patch does
Matt Turner writes:
> 2013-02-22 Matt Turner
>
> gcc/
> * doc/invoke.texi: Document r4700.
Thanks, applied.
Richard
On 25 February 2013 19:52, Caroline Tice wrote:
> I got too excited about being done and forgot to attach the patch. :-(
> Sorry. Here it is.
Some comments follow, mostly from reading the comments to understand
what this patch does, it's a really interesting feature!
The generated files (configu
Hi,
Please see details on Bugzilla.
Tested x86_64-unknown-linux-gnu without regressions.
gcc/testsuite/ChangeLog
2012-02-25 Fabien Chêne
PR c++/56243
* g++.dg/cpp0x/pr56243.C: New.
gcc/cp/ChangeLog
2012-02-25 Fabien Chêne
PR c++/56243
* class.c (fixed_ty
On Mon, Feb 25, 2013 at 09:01:17PM +0100, Steven Bosscher wrote:
> On Mon, Feb 25, 2013 at 8:53 PM, Marek Polacek wrote:
> > This fixes PR56426. We were ICEing during the loop pipeline,
> > because copyprop changed an irreducible region into a reducible - thus
> > the number_of_loops grew.
>
> We
On Mon, Feb 25, 2013 at 8:53 PM, Marek Polacek wrote:
> This fixes PR56426. We were ICEing during the loop pipeline,
> because copyprop changed an irreducible region into a reducible - thus
> the number_of_loops grew.
We've seen that kind of thing happen before with the tracer pass. It
makes me w
This fixes PR56426. We were ICEing during the loop pipeline,
because copyprop changed an irreducible region into a reducible - thus
the number_of_loops grew. Firstly, in tree_ssa_loop_init, number_of_loops
was == 1, which means we didn't initialize SCEV. But then later on, in
tree_ssa_loop_bound
On 02/22/2013 09:53 AM, Aldy Hernandez wrote:
Frankly, I don't understand finish_transaction_stmt(), and why it sets
TREE_SIDE_EFFECTS only if the [noexcept] clause is set. I'm C++
ignorant, but I would've thought the opposite to be true.
It's setting that flag on the MUST_NOT_THROW_EXPR.
An
Here are the latest changes to the vtable pointer verification patches
(again there are 3 patches: c++ front end, main gcc, and c++ runtime
library). I think these address all the review comments I have
received so far. This patch is the for C++ runtime library changes.
Please review these change
Hi,
This is the patch that implements a new module grouping.
It's based on module level graph and simple inclusion based algorithm.
Tests are ongoing with google internal benchmarks and spec2k, spec2k6.
Thanks,
-Rong
2013-02-25 Rong Xu
* libgcc/dyn-ipa.c (struct dyn_cgraph): New De
The following fixes a regression that shows that currently
conversion hoisting in bitwise operations as implemented by
tree forwprop is doing the opposite canonicalization from
what fold does. The following patch restricts it
to perform the sub-set of transforms that fold
wouldn't immediately un-
I am still waiting for Global Reviewer approval to add the
Synopsys Designware ARC port to GCC:
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00525.html
The config patch still applies fine and the port builds as of today
(revision 196254).
More than can be said for some of the existing ports,
as
OK.
Jason
> -Original Message-
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> Sent: Monday, February 25, 2013 4:42 AM
> To: Moore, Catherine
> Cc: gcc-patches@gcc.gnu.org; Rozycki, Maciej
> Subject: Re: FW: [PATCH] [MIPS] microMIPS gcc support
>
> "Moore, Catherine" writes:
> > HI
On Mon, Feb 25, 2013 at 12:39 PM, Yuri Rumyantsev wrote:
> Hi Richard,
>
> Please, prepare the patch as you proposed.
> I checked that it helps Coremrak 1.0.
The attached works for me (works for the testcase, that is, tree forwprop
performs the requested optimization).
Richard.
> Best regards.
On Mon, Feb 25, 2013 at 12:31:07PM +0100, Tom de Vries wrote:
> OK for trunk?
>
> Thanks,
> - Tom
>
> 2013-02-25 Tom de Vries
>
> PR rtl-optimization/56131
> * insn-notes.def (INSN_NOTE_BASIC_BLOCK): Update comment.
> * cfgrtl.c (delete_insn): Don't reorder NOTE_INSN_DELETED
Hi Richard,
Please, prepare the patch as you proposed.
I checked that it helps Coremrak 1.0.
Best regards.
Yuri.
2013/2/25 Richard Biener :
> On Thu, Feb 21, 2013 at 4:42 PM, Yuri Rumyantsev wrote:
>> Richard,
>>
>> This does not fit to my fix since if we have another pattern like
>> t = (
Jakub,
attached patch fixes (or rather, fixes up the previous fix for) PR56131.
The patch makes sure that we don't try to reorder DELETED_LABEL and BASIC_BLOCK
NOTE_INSNs when there is no CFG.
The patch will prevent PR56242 from triggering on hppa,
In addition, the patch adds a comment in insn-
Attached is my proposed additions to the GCC-4.8 changes page.
Comments on an electronic postcard, please.
R.Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
retrieving revision 1.104
diff -u -p -r1.1
Tobias Burnus writes:
> As Jeffry Walton realized at
> http://gcc.gnu.org/ml/gcc/2013-02/msg00280.html, invoke.texi is
> inconsistent: In the overview, -fsanitize= is listed as debug option
> (which makes sense) but the actual description is under the section
> optimization options.
>
> OK?
This
As Jeffry Walton realized at
http://gcc.gnu.org/ml/gcc/2013-02/msg00280.html, invoke.texi is
inconsistent: In the overview, -fsanitize= is listed as debug option
(which makes sense) but the actual description is under the section
optimization options.
OK?
Tobias
2013-02-25 Tobias Burnus
Paul Richard Thomas wrote:
The attached patch represents progress to date. It fixes the original
problem in this PR and allows John Reid's version of
iso_varying_string/vocabulary_word_count.f90 to compile and run
correctly. It even bootstraps and regtests!
Great! It seems as if 4.9 will get
"Moore, Catherine" writes:
> HI Richard,
> The base patch is now committed. The final patch, including your final
> edits is attached. I will be posting the optimization pieces later this
> week.
Sorry, when I said that it was ok for 4.9, I meant that it should wait
until 4.8 had branched. As
On Thu, Feb 21, 2013 at 4:42 PM, Yuri Rumyantsev wrote:
> Richard,
>
> This does not fit to my fix since if we have another pattern like
> t = (u8)((x & 1) ^ ((u8)y & 1));
> where y has short type, for rhs operand type sinkning (or hoisting as
> you prefer) still will be performed but I don't
* PING *
(The attachment contains my original patch (simple rediff) and Andreas'
follow-up patch for libiberty.)
Tobias
Tobias Burnus wrote:
This is a follow up to Jakub's patch.
With texinfo 5.0 one gets a bunch of warnings. This patch reduces the
number of warnings – but there are still
41 matches
Mail list logo
