Hi Paul,
Dear All,
This is a straightforward patch that adds a last ditch attempt to find
a specific typebound procedure when all that has been found for a
derived type base object is 'deferred'. typebound_operator_7.f03 has
been extended to test derived type as well as class base objects.
Bo
> Done.
Great, thanks.
--
Eric Botcazou
Dear Thomas,
Happy New Year!
> Wouldn't it be better to make a new test case? If there turns out
> to be a regression later, changing test cases makes it harder to
> find.
>
> You could just commit the test case 'as is' as typebound_operator_8.f03
> and leave the old one.
>
> Regards
>
>
Thomas Koenig wrote:
> the attached patch fixes the PR by unconditionally disabling warnings
> about unused variables in common blocks.
I was wondering whether it disables intended diagnostic. However, I think
setting TREE_USED () is OK. Common-related diagnostic is better done by the
front end (v
Hi,
This patch:
* dump inline decisions with profile info whenever available.
* disable dump of einline decisions at OPT_INFO_MIN.
Is it ok for google branches?
thanks,
Dehao
2012-01-04 Dehao Chen
* ipa-inline.c (cgraph_node_opt_info): Print profile info if available
(dump_
Dear Paul,
On Tue, Jan 03, 2012 at 09:30:28PM +0100, Paul Richard Thomas wrote:
> Bootstrapped and regtested on x86_64/FC9 - OK for trunk?
OK. Thanks for the patch.
> + /* If we find a deferred typebound procedure, check for derived types
> + that an over-riding typebound procedure has not
On Tue, 3 Jan 2012, Jakub Jelinek wrote:
> Hi!
>
> My previous patch apparently wasn't enough. If at add_mem_*
> time mem_elt is still its own canonical cselib_val, but only afterwards
> new_elt_loc_list adds a new canonical cselib_val to it (and moves
Hm, shouldn't an existing cselib_val be al
On Wed, Jan 04, 2012 at 10:33:50AM +0100, Richard Guenther wrote:
> > My previous patch apparently wasn't enough. If at add_mem_*
> > time mem_elt is still its own canonical cselib_val, but only afterwards
> > new_elt_loc_list adds a new canonical cselib_val to it (and moves
>
> Hm, shouldn't an
Oleg Endo wrote:
> The attached patch addresses PR 31640.
> It reduces the the default function alignment when not optimizing for
> size from cache line size (32 bytes) to 4 bytes and sets the loop
> alignment to 4 bytes when not optimizing for size. Moreover, it brings
> back the -falign-loops o
Hi,
I've applied the attached patch to mainline in order to fix the Ada
bootstrap failure reported by Jakub in PR51734 and the libiberty build
failure reported here:
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00465.html
Bye,
-Andreas-
config/
2012-01-04 Andreas Krebbel
PR bootstrap/5173
Hi Tobias,
Regression-tested. OK for trunk?
OK. Thanks for the patch.
Committed (rev. 182869). Thanks for the review! (I also updated the
copyright years, as requested in private E-Mail.)
Thomas
The following patches have remained unreviewed for two or three weeks:
[libffi] Build 64-bit multilib for i?86-linux
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01011.html
In the absence of a listed libffi maintainer, it probably needs a global
reviewer.
[libgfortran, li
> > OK, I see. Then the only way out I can think of is to stop going up the
> > chain of COMPONENT_REFs as soon as the offset becomes negative.
>
> Yeah, that sounds like a better solution.
Bootstrapped on MIPS/IRIX and regtested on {i586,x86_64}-suse-linux. OK after
a full testing cycle?
2012
On Wed, Jan 4, 2012 at 1:27 PM, Eric Botcazou wrote:
>> > OK, I see. Then the only way out I can think of is to stop going up the
>> > chain of COMPONENT_REFs as soon as the offset becomes negative.
>>
>> Yeah, that sounds like a better solution.
>
> Bootstrapped on MIPS/IRIX and regtested on {i5
Dear Rainer,
Rainer Orth wrote on Wed, 04 Jan 2012:
> The following patches have remained unreviewed for two or three weeks
I had hoped that a build maintainer or someone else more knowledgeable about
the lib dependencies would reply.
Rainer Orth wrote on Mon, 19 Dec 2011:
> Indeed, libgfortran
Hi,
in the testcase bellow the loop peeling simplifies exit condition in a way
that the outer loop is destroyed. After some discussion with Zdenek I learnt
that remove_path is then supposed to destroy the outer loop by calling unloop
on it, but there is thinko in the function assuming that just th
On Wed, Jan 4, 2012 at 2:01 PM, Jan Hubicka wrote:
> Hi,
> in the testcase bellow the loop peeling simplifies exit condition in a way
> that the outer loop is destroyed. After some discussion with Zdenek I learnt
> that remove_path is then supposed to destroy the outer loop by calling unloop
> on
> > + l = e->src->loop_father;
> > + while (l && loop_outer (l))
> > + {
> > + while (loop_outer (loop_outer (l))
> > + && dominated_by_p (CDI_DOMINATORS,
> > + loop_outer (l)->latch, e->dest))
> > + unloop (loop_outer (l), &irred_inval
2012/1/4 Jan Hubicka :
>> > + l = e->src->loop_father;
>> > + while (l && loop_outer (l))
>> > + {
>> > + while (loop_outer (loop_outer (l))
>> > + && dominated_by_p (CDI_DOMINATORS,
>> > + loop_outer (l)->latch, e->dest))
>> > + unloop
Another manifestation about the issue we have wrt sizetypes
implicitly sign-extending but types-compatible types not.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2012-01-04 Richard Guenther
PR middle-end/51750
* tree.c (size_low_cst): New
Hi,
> --- 316,333
>normally. We may assume that e->dest is not a header of any loop,
>as it now has exactly one predecessor. */
> while (loop_outer (e->src->loop_father)
> ! && dominated_by_p (CDI_DOMINATORS,
> !e->src->loop_father->l
> Hi,
>
> > --- 316,333
> >normally. We may assume that e->dest is not a header of any loop,
> >as it now has exactly one predecessor. */
> > while (loop_outer (e->src->loop_father)
> > ! && dominated_by_p (CDI_DOMINATORS,
> > !e->src
Hi,
we emit spurious -Wparentheses warnings for template arguments,
evidently because we are not propagating TREE_NO_WARNING during
tsubstitution.
I'm fixing the problem in a straightforward way, by using the same idiom
already used elsewhere: call build_x_binary_op and then propagate
TREE_
Reload (find_reloads) has code that can replace a register with a
label_ref when presented with RTL of the form:
(set (reg) (reg) (notes (rtx_equal (label_ref)))
Label references are initially counted in jump.c:mark_all_labels() and
friends. This code traverses the RTL and counts each observed
This removes avr_replace_prefix and rewrites the callers to use ACONCAT.
Passes without regressions.
Ok for trunk?
Johann
* config/avr/avr.c (avr_replace_prefix): Remove.
(avr_asm_named_section): Use ACONCAT instead of avr_replace_prefix.
(avr_asm_function_rodata_section
On 01/03/12 14:33, Richard Henderson wrote:
On 01/04/2012 01:10 AM, Aldy Hernandez wrote:
I can certainly do this. I am however, waiting for the final approval. It
wasn't clear whether that was an approval from Richard Henderson, or whether I
should wait for an official ok.
OK for mainline?
On 01/04/12 08:55, Aldy Hernandez wrote:
On 01/03/12 14:33, Richard Henderson wrote:
On 01/04/2012 01:10 AM, Aldy Hernandez wrote:
I can certainly do this. I am however, waiting for the final
approval. It wasn't clear whether that was an approval from Richard
Henderson, or whether I should wait
I'm a bit nervous about the instantiated tree being a different kind of
tree from the template one, such that TREE_NO_WARNING doesn't make sense
on the new one. Maybe just check EXPR_P (r) as well.
Jason
Hi,
I'm a bit nervous about the instantiated tree being a different kind
of tree from the template one, such that TREE_NO_WARNING doesn't make
sense on the new one. Maybe just check EXPR_P (r) as well.
I see, better be safe. The below still passes testing. Ok?
Thanks,
Paolo.
Hi,
little clean-up for the VMS entries in config.build.
Tested on both ia64-hp-openvms and alpha64-dec-openvms.
Committed on trunk.
Tristan.
2012-01-04 Tristan Gingold
* config/vms/xm-vms.h (HOST_LONG_FORMAT, HOST_PTR_PRINTF): Define
when long pointers are used.
*
On 01/02/2012 01:10 PM, Torvald Riegel wrote:
This was motivated by the miscompilation of one of the STAMP
applications (Genome), where a stack slot was used as temp storage for a
CPU register but not restored when the transaction got aborted and
restarted (then, after restart, the program crashe
OK.
Jason
es (and run the C testsuite for your favorite ABI variant)? TIA.
PR tree-optimization/51315
* tree-sra.c (tree_non_aligned_mem_for_access_p): New predicate.
(build_accesses_from_assign): Use it instead of tree_non_aligned_mem_p.
* gcc.c-torture/execute/20120
On 01/04/12 09:53, Patrick Marlier wrote:
On 01/02/2012 01:10 PM, Torvald Riegel wrote:
This was motivated by the miscompilation of one of the STAMP
applications (Genome), where a stack slot was used as temp storage for a
CPU register but not restored when the transaction got aborted and
restart
On 21/07/11 17:30, zhr...@ispras.ru wrote:
> This patch eliminates fake doloop_end pattern for ARM platform. The problem
> with such a pattern is that it slows down the loop when SMS doesn't create
> good
> schedule. So, i suppose fake pattern is no longer needed with new loop forms
> supported.
(From a old email in sent after the merge)
The output for "ealias" was changed in revision 158374.
* tree-ssa-structalias.c
(dump_solution_for_var): Always dump the solution.
Example
before: pp = same as mystruct
after: pp = { ESCAPED NONLOCAL } same as mystruct
So the patch adj
On 01/04/12 10:51, Patrick Marlier wrote:
(From a old email in sent after the merge)
The output for "ealias" was changed in revision 158374.
* tree-ssa-structalias.c
(dump_solution_for_var): Always dump the solution.
Example
before: pp = same as mystruct
after: pp = { ESCAPED NONLOCAL } same as
I have just realized that there are bugreports for them.
So here the ChangeLog adjusted.
Patrick.
On 01/04/2012 11:51 AM, Patrick Marlier wrote:
(From a old email in sent after the merge)
The output for "ealias" was changed in revision 158374.
* tree-ssa-structalias.c
(dump_solution_for_var):
On 01/04/12 10:59, Patrick Marlier wrote:
I have just realized that there are bugreports for them.
So here the ChangeLog adjusted.
Adjusted, committed, and closed both PRs.
Thanks.
On 01/04/2012 11:40 AM, Aldy Hernandez wrote:
On 01/04/12 09:53, Patrick Marlier wrote:
On 01/02/2012 01:10 PM, Torvald Riegel wrote:
This was motivated by the miscompilation of one of the STAMP
applications (Genome), where a stack slot was used as temp storage for a
CPU register but not restor
Alias analysis by DSE based on CSELIB expansion assumes that
references to the stack frame from different base registers (ie FP, SP)
never alias.
The comment block in cselib explains that cselib does not allow
substitution of FP, SP or SFP specifically in order not to break DSE.
However, the log
Hi!
In this case the problem is that during cselib_process_insn
the cselib hashtab is expanded. Before the htab expansion
cselib_lookup on r1 - 1 gave value 18:18 which contains the right value, but
doesn't have the hash value for r1 - 1 (8169), thus is found only by
accident. Unfortunately afte
Hi!
.debug_loc section format only uses 2 byte long size field for expressions,
therefore we can't emit >= 64KB expressions.
Unfortunately from time to time we do generate them, I hope Alex will look
at how to prevent that from happening at var-tracking time, but still
this isn't something we shou
I fixed this PR, and then it got reopened because the testcase triggered
a different problem on Alpha, Mips, and other architectures. The
problem is actually totally different than the previous fix for 51472,
and has nothing to do with --param tm-max-aggregate-size.
This problem here is that
OK.
Jason
On Monday 02 January 2012 12:20:36 Tobias Burnus wrote:
> Hello Mikael,
>
> Mikael Morin wrote:
> > Regression tested on x86_64-unknown-linux-gnu. OK for 4.7/4.6/4.5[/4.4] ?
>
> OK - thanks for the comprehensive patch explanation and for the patch
> itself.
>
> > + else
> > + {
> > +
On Sat, Dec 17, 2011 at 3:11 AM, Richard Sandiford
wrote:
> Andrew Pinski writes:
>> Index: testsuite/gcc.target/mips/octeon2-lx-1.c
>> ===
>> --- testsuite/gcc.target/mips/octeon2-lx-1.c (revision 0)
>> +++ testsuite/gcc.target/mip
On Wed, 2012-01-04 at 12:13 -0500, Patrick Marlier wrote:
> On 01/04/2012 11:40 AM, Aldy Hernandez wrote:
> > On 01/04/12 09:53, Patrick Marlier wrote:
> >> On 01/02/2012 01:10 PM, Torvald Riegel wrote:
> >>> This was motivated by the miscompilation of one of the STAMP
> >>> applications (Genome),
On Wed, 2012-01-04 at 10:53 -0500, Patrick Marlier wrote:
> On 01/02/2012 01:10 PM, Torvald Riegel wrote:
> > This was motivated by the miscompilation of one of the STAMP
> > applications (Genome), where a stack slot was used as temp storage for a
> > CPU register but not restored when the transact
On 01/04/2012 01:20 PM, Aldy Hernandez wrote:
The attached patch fixes the ICE on alpha-linux-gnu as tested with a
cross-cc1 build.
Note that it was also failing with i686/linux and the patch fixes the ICE.
Patrick.
> "Jakub" == Jakub Jelinek writes:
Jakub> another alternative would be to create DW_TAG_dwarf_procedure for
Jakub> them or for portions thereof (for subexpressions it would be even
Jakub> a potential nice debug info shrinking method, but would mean a
Jakub> lot of work and gdb support isn't t
On Wed, Jan 04, 2012 at 12:11:29PM -0700, Tom Tromey wrote:
> > "Jakub" == Jakub Jelinek writes:
>
> Jakub> another alternative would be to create DW_TAG_dwarf_procedure for
> Jakub> them or for portions thereof (for subexpressions it would be even
> Jakub> a potential nice debug info shrinki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/04/12 07:07, Marcus Shawcroft wrote:
> Reload (find_reloads) has code that can replace a register with a
> label_ref when presented with RTL of the form:
>
> (set (reg) (reg) (notes (rtx_equal (label_ref)))
>
> Label references are initially c
> "Jakub" == Jakub Jelinek writes:
Jakub> Honza said that GDB doesn't support DW_TAG_dwarf_procedure though.
Jakub> We'd need to represent it as nameless artificial DW_TAG_variable
Jakub> or something similar.
I think gdb will issue a complaint if it sees one. I'm not sure, I
don't think I'
The enclosed patch to google/main contains certain small fixes for pubnames and
pubtypes, which are now emitted completely and canonically. It also fixes the
expected output of various tests to match the canonical names of functions.
OK for google/main?
Tested:
With full make-check and n
On Fri, Dec 16, 2011 at 2:22 PM, Joseph S. Myers
wrote:
> On Mon, 12 Dec 2011, Andrew Pinski wrote:
>
>> * config/mips/mips-cpus.def: Add Octeon2.
>
> You need to update the documentation for MIPS -march= in invoke.texi,
> which lists the supported CPUs.
Woops, I had missed that. Here is the pat
LGTM for google/main.
Before submitting for trunk, we'll want to take care of this FIXME:
> + /* FIXME: Should use add_AT_pubnamesptr. This works because most
> targets
> + don't care what the base section is. */
-cary
2012/1/4 Georg-Johann Lay :
> This removes avr_replace_prefix and rewrites the callers to use ACONCAT.
>
> Passes without regressions.
>
> Ok for trunk?
>
> Johann
>
> * config/avr/avr.c (avr_replace_prefix): Remove.
> (avr_asm_named_section): Use ACONCAT instead of avr_replace_prefix
On 01/05/2012 05:20 AM, Aldy Hernandez wrote:
> PR middle-end/51472
> * trans-mem.c (expand_assign_tm): Handle TM_MEMMOVE loads correctly.
> testsuite/
> PR middle-end/51472
> * gcc.dg/tm/memopt-6.c: Adjust regexp.
Ok.
r~
Eric Botcazou writes:
> Regtested on SPARC/Solaris. Can you confirm that this fixes the
> pessimization in all cases (and run the C testsuite for your favorite
> ABI variant)? TIA.
It does, and there were no regression on a C-only build & test for
mips64-linux-gnu (-mabi=32/-mips16, -mabi=32, -
On 01/05/2012 04:45 AM, Jakub Jelinek wrote:
> PR debug/51746
> * var-tracking.c (add_stores): For COND_EXEC allow oval to be NULL.
Ok.
r~
On 01/04/2012 01:20 PM, Aldy Hernandez wrote:
I fixed this PR, and then it got reopened because the testcase triggered
a different problem on Alpha, Mips, and other architectures. The problem
is actually totally different than the previous fix for 51472, and has
nothing to do with --param tm-max-
Hi!
This testcase fails with corrupted profile info error.
The problem is that we have a basic block which starts with a computed goto
target label (thus has an EDGE_ABNORMAL predecessor and wants an EDGE_FAKE
predecessor from entry) and ends with a non-const/pure call (which
incidentally doesn't
Hi!
profiledbootstrap with --disable-poststage-build-with-cxx and -fexceptions
currently fails on x86_64-linux. The problem is that no EDGE_FAKE edge is
added from noreturn fatal_error call to the exit block, eventhough
fatal_error calls exit.
The problem is that we have several places which add
In the reentrant.c testcase, the first transaction has no transactional
access and thus removed.
In order to keep this transaction, I added a shared access inside.
Tested on i686.
OK to commit?
(I don't have an account, so thanks in advance to committer)
--
Patrick Marlier.
2012-01-04 Patrick M
Second try. Unlike adjusting the gcc/cp fragment, I can't imagine
this has any other side effects.
Tested on x86_64-linux. Committed.
r~
diff --git a/ChangeLog b/ChangeLog
index b9d08f3..a8019b3 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2012-01-05 Richard Henderson
+
+
On Thu, Jan 05, 2012 at 12:38:17PM +1100, Richard Henderson wrote:
> +# Disable libitm if we're not building C++
> +case ,${enable_languages}, in
> + *,c++) ;;
Shouldn't that be *,c++,* ? C++ might not be the last in the list...
Jakub
Hi,
(Initially from http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00225.html)
PR51516 shows up a problem due to the TM IPA rework.
Indeed, an alias can get called but tm cg data is in the parent of the
alias.
The fix consists to set and use information from the parent and not the
alias itself.
On 01/05/2012 12:53 PM, Jakub Jelinek wrote:
> On Thu, Jan 05, 2012 at 12:38:17PM +1100, Richard Henderson wrote:
>> +# Disable libitm if we're not building C++
>> +case ,${enable_languages}, in
>> + *,c++) ;;
>
> Shouldn't that be *,c++,* ? C++ might not be the last in the list...
Gah, of cour
On 01/04/2012 11:27 PM, Rainer Orth wrote:
> [libgfortran, libitm] Link with -shared-libgcc
> http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01382.html
>
> This will need a fortran resp. libitm maintainer.
Does the following alleviate the need for -shared-libgcc for libitm?
r~
diff --
70 matches
Mail list logo