On Fri, 2012-12-07 at 13:37 -0600, Richard Henderson wrote:
> On 2012-12-06 02:25, Andreas Krebbel wrote:
> > ! targetm.canonicalize_comparison ((int*)&compare_code, &op0, &op1, 1);
>
> The basic approach seems sound. But this cast is distinctly uncool.
>
> And why the unused return value?
The analysis of 55419 pointed out the conflict in a TARGET_EXPR having
both TREE_SIDE_EFFECTS and TREE_CONSTANT set. After reading that I
decided to stop setting TREE_CONSTANT on the TARGET_EXPR and do the
necessary work to adjust for that. And then was surprised to find that
no additional wo
On Fri, 7 Dec 2012, Marc Glisse wrote:
On Fri, 7 Dec 2012, Richard Henderson wrote:
On 2012-12-07 09:12, Marc Glisse wrote:
but change ix86_expand_vector_set and others to generate vec_merge
and have only the vec_merge define_insn in sse.md? I guess it would
buy a large part of it. That's a p
My patch that introduced "instantiation-dependent" to the compiler
treated all SCOPE_REFs as instantiation-dependent, on the principle that
we might need to check accessibility at instantiation time. But if the
member reference is public, it will always be accessible, so we don't
need to worry
OK.
Jason
> 2012-12-07 Steve Ellcey
>
> PR target/54061
> * rtl.h (IGNORED_DWARF_REGNUM): New.
> * dwarfwout.c (reg_loc_descriptor): Check for IGNORED_DWARF_REGNUM.
Typo: s/dwarfwout/dwarf2out/
> (mem_loc_descriptor): Ditto.
> * config/mips/mips.c (mips_option_ove
> On Fri, 2012-12-07 at 14:43 -0800, H.J. Lu wrote:
>
>> > I think you need a way to tell a bad register from a good register
>> > which doesn't have DWARF register number.
Here is a patch using your IGNORED_DWARF_REGNUM idea.
Steve Ellcey
sell...@mips.com
2012-12-07 Steve Ellcey
P
On Thu, Dec 06, 2012 at 04:20:46PM -0500, Vladimir Makarov wrote:
> LRA should have change spilled pseudo 199 to memory. LRA did not do
> that because the insn is in list of insns used by pseudo 199. This
> might happen only when the insn is not recognized.
>
> The following patch fixes the bug.
On Fri, Dec 7, 2012 at 2:55 PM, Steve Ellcey wrote:
> On Fri, 2012-12-07 at 14:43 -0800, H.J. Lu wrote:
>
>> > I think you need a way to tell a bad register from a good register
>> > which doesn't have DWARF register number.
>> >
>>
>> Something like
>>
>> #define IGNORED_DWARF_REGNUM(
Hi,
Since revision 191466, LTO no longer maintains its own symbol table and
it uses varpool for variables instead. As the result, debug info on
variables is lost when GCC is configured with
--enable-bootstrap --with-build-config=bootstrap-lto
This patch record the global variables if WPA isn't
On Fri, 2012-12-07 at 14:43 -0800, H.J. Lu wrote:
> > I think you need a way to tell a bad register from a good register
> > which doesn't have DWARF register number.
> >
>
> Something like
>
> #define IGNORED_DWARF_REGNUM(INVALID_REGNUM - 1)
The other option would be to have a new
On 12/07/2012 03:46 PM, Sriraman Tallam wrote:
I have submitted this patch.
* toplev.c (process_options): Do not warn when -ffunction-sections
and -fprofile are used together.
Approved. Please install.
jeff
I have submitted this patch.
* toplev.c (process_options): Do not warn when -ffunction-sections
and -fprofile are used together.
Index: gcc/toplev.c
===
--- gcc/toplev.c (revision 194306)
+++ gcc/toplev.c (working cop
On Fri, Dec 7, 2012 at 2:17 PM, H.J. Lu wrote:
> On Fri, Dec 7, 2012 at 1:59 PM, Steve Ellcey wrote:
>> This is my attempt to fix PR 54061, a bug where GCC aborts while trying to
>> put out debug information for a co-processor register. My understanding is
>> that gdb cannot access the coprocess
On Dec 7, 2012, at 12:59 PM, Ian Lance Taylor wrote:
> I did mark the file as binary on June 11, 2012. I checked a current
> SVN working directory and it is marked as binary for me (use svn
> proplist and svn propget svn:mime-type to see this).
Yup, svn looks good.
> If you are using the git re
On Fri, Dec 7, 2012 at 1:59 PM, Steve Ellcey wrote:
> This is my attempt to fix PR 54061, a bug where GCC aborts while trying to
> put out debug information for a co-processor register. My understanding is
> that gdb cannot access the coprocessor registers and so there is no valid
> debug informa
This is my attempt to fix PR 54061, a bug where GCC aborts while trying to
put out debug information for a co-processor register. My understanding is
that gdb cannot access the coprocessor registers and so there is no valid
debug information that can be put out for this case. So my fix is to remo
On Dec 6, 2012, Richard Biener wrote:
> On Tue, Nov 6, 2012 at 1:54 AM, Easwaran Raman wrote:
>> I am unable to figure out the right way to handle the debug
>> statements. What I tried was to find debug statements that use the SSA
>> name defined by the statement I moved (using SSA_NAME_IMM_USE
On Dec 7, 2012, at 12:08 PM, Robert Dewar wrote:
> I would convert to LF, I think it causes less confusion
Done.
2012-12-07 Mike Stump
* gnat.dg/discr38.adb: Don't use ^M line endings.
gnat.dg/loop_optimization13.adb: Likewise.
gnat.dg/loop_optimization13.ads: Likewis
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55141
The patch was successfully bootstrapped on x86/x86-64.
Committed as rev. 194308.
2012-12-07 Vladimir Makarov
testsuite/gcc.target/i386/pr55141.c
* lra-constraints.c (lra_constraints): Use bigg
On Fri, Dec 7, 2012 at 11:02 AM, Mike Stump wrote:
> So I found some ^Ms in libgo.
>
> $ grep -l '^M' libgo/go/mime/multipart/testdata/nested-mime
> libgo/go/mime/multipart/testdata/nested-mime
>
> This file is likely meant to contain them if I don't miss my guess. The
> problem is, it is not ta
On 12/07/12 14:28, Jason Merrill wrote:
On 12/07/2012 01:08 PM, Aldy Hernandez wrote:
+ if (!TREE_CONSTANT (new_call))
+*non_constant_p = true;
You can use VERIFY_CONSTANT here instead. OK with that change.
Jason
VERIFY_CONSTANT is defined further down, so I moved things around.
OK
On 12/07/2012 01:08 PM, Aldy Hernandez wrote:
+ if (!TREE_CONSTANT (new_call))
+*non_constant_p = true;
You can use VERIFY_CONSTANT here instead. OK with that change.
Jason
On 2012-12-07 14:11, Aldy Hernandez wrote:
> I am hoping that by removing this hack we can find actual problems.
>
> However, if you believe the RTL edge dropping in gimple_expand_cfg() is
> problematic, I can look into fixing this, though it would be nice to have a
> test I can work off of.
Le
On 12/07/12 14:04, Richard Henderson wrote:
On 2012-12-05 15:06, Aldy Hernandez wrote:
PR rtl-optimization/51771
Revert:
* builtin-attrs.def (ATTR_RETURNS_TWICE, ATTR_TM_NOTHROW_RT_LIST): New.
* gtm-builtins.def (BUILT_IN_TM_START): Add returns-twice attrib.
Are
On 12/7/2012 2:50 PM, Arnaud Charlet wrote:
Anyway, I'll let Robert have the final word on this one.
I'm fine with either solution (converting to LF, or marking files binary,
or a mix of both).
Arno
I would convert to LF, I think it causes less confusion
On Fri, Dec 7, 2012 at 10:06 AM, Dodji Seketeli wrote:
> Here is what I am committing to trunk.
Thank you!
-- Gaby
On 2012-12-05 15:06, Aldy Hernandez wrote:
> PR rtl-optimization/51771
> Revert:
> * builtin-attrs.def (ATTR_RETURNS_TWICE, ATTR_TM_NOTHROW_RT_LIST): New.
> * gtm-builtins.def (BUILT_IN_TM_START): Add returns-twice attrib.
Are we absolutely sure that the rtl edges are fixed
It seems I need to reset the debug uses of a statement before moving
the statement itself. The attached patch starts from the leaf to root
of the tree to be reassociated and places them at the point where
their dependences will be met after reassociation. This bootstraps and
I am running the tests.
> >>Probably good to have some tests with standard CR/LF terminators, since
> >>this is what a lot of the world uses.
> >
> >Then, to preserve them, the files must be tagged as binary in svn and git.
> >Doing so will probably make the normal file merging that git/svn would do,
> >inoperative.
> >
On Fri, 7 Dec 2012, Mike Stump wrote:
On Dec 7, 2012, at 10:57 AM, Robert Dewar wrote:
Probably good to have some tests with standard CR/LF terminators, since this is
what a lot of the world uses.
Then, to preserve them, the files must be tagged as binary in svn and
git.
Assuming they co
On 12/7/2012 2:16 PM, Mike Stump wrote:
Yes, you can strip them, no problem.
Since emails likely crossed paths…. I'm going to give you and Robert a change
to figure out what you'd like to do… I _only_ care about consistency between
contents as seen from svn and git. Stripping ^M can do th
Hi!
As the testcase shows, for implicit conversions between signed integer
and signed integer with some attribute that makes it a distinct type from
that such as may_alias attribute, we warn that the pointer targets differ
in signedness, even when they have the same size. For similar unsigned
int
On 12/7/2012 2:09 PM, Mike Stump wrote:
On Dec 7, 2012, at 10:57 AM, Robert Dewar wrote:
On 12/7/2012 1:56 PM, Mike Stump wrote:
I've noticed that:
$ grep -l '^M' gcc/testsuite/gnat.dg/*
discr36.ads
discr36_pkg.adb
discr36_pkg.ads
discr38.adb
loop_optimization11.adb
loop_optimization11_pkg.ad
On 2012-12-06 02:25, Andreas Krebbel wrote:
> ! targetm.canonicalize_comparison ((int*)&compare_code, &op0, &op1, 1);
The basic approach seems sound. But this cast is distinctly uncool.
And why the unused return value? If you didn't need it, why add it?
r~
> This patch adds DW_AT_const_value or DW_AT_location for unused static vars
> (thus, not really modified and their DECL_INITIAL can be used for
> location/constant value info), and optimizes various cases using
> DW_OP_GNU_implicit_pointer (e.g. DW_OP_addr DW_OP_stack_value
> where symbol is eith
On Dec 7, 2012, at 10:59 AM, Arnaud Charlet wrote:
>> I've noticed that:
>>
>> $ grep -l '^M' gcc/testsuite/gnat.dg/*
>> discr36.ads
>> discr36_pkg.adb
>> discr36_pkg.ads
>> discr38.adb
>> loop_optimization11.adb
>> loop_optimization11_pkg.ads
>> loop_optimization13.adb
>> loop_optimization13.ads
On Dec 7, 2012, at 10:57 AM, Robert Dewar wrote:
> On 12/7/2012 1:56 PM, Mike Stump wrote:
>> I've noticed that:
>>
>> $ grep -l '^M' gcc/testsuite/gnat.dg/*
>> discr36.ads
>> discr36_pkg.adb
>> discr36_pkg.ads
>> discr38.adb
>> loop_optimization11.adb
>> loop_optimization11_pkg.ads
>> loop_optim
So I found some ^Ms in libgo.
$ grep -l '^M' libgo/go/mime/multipart/testdata/nested-mime
libgo/go/mime/multipart/testdata/nested-mime
This file is likely meant to contain them if I don't miss my guess. The
problem is, it is not tagged as a binary file in svn and git, leading to
inconsistent c
> I've noticed that:
>
> $ grep -l '^M' gcc/testsuite/gnat.dg/*
> discr36.ads
> discr36_pkg.adb
> discr36_pkg.ads
> discr38.adb
> loop_optimization11.adb
> loop_optimization11_pkg.ads
> loop_optimization13.adb
> loop_optimization13.ads
>
> :-( Surely these are just normal text files, right? Can
On 12/7/2012 1:56 PM, Mike Stump wrote:
I've noticed that:
$ grep -l '^M' gcc/testsuite/gnat.dg/*
discr36.ads
discr36_pkg.adb
discr36_pkg.ads
discr38.adb
loop_optimization11.adb
loop_optimization11_pkg.ads
loop_optimization13.adb
loop_optimization13.ads
:-( Surely these are just normal text fi
I've noticed that:
$ grep -l '^M' gcc/testsuite/gnat.dg/*
discr36.ads
discr36_pkg.adb
discr36_pkg.ads
discr38.adb
loop_optimization11.adb
loop_optimization11_pkg.ads
loop_optimization13.adb
loop_optimization13.ads
:-( Surely these are just normal text files, right? Can I strip the ^M from
them
The problem here is that we fold away calls to built-ins in
COMPOUND_EXPRs such as:
const int t = (__builtin_memcpy (s, "Hello", 6), 777);
Since we return true for any built-in in
potential_constant_expression_1, this means that
check_initializer->store_init_value->maybe_constant_init will ch
On Dec 7, 2012, at 1:36 AM, Joel Brobecker wrote:
> The GDB sources contain some python files, and executing them
> causes these .pyc files to appear. We could ignore them in GDB
> only, but I think this is the type of extension (compilation
> artifact) which can be shared amoung all projects.
T
On Fri, 7 Dec 2012, Richard Henderson wrote:
On 2012-12-07 09:12, Marc Glisse wrote:
but change ix86_expand_vector_set and others to generate vec_merge
and have only the vec_merge define_insn in sse.md? I guess it would
buy a large part of it. That's a pretty invasive change, I'll have to
try..
Hi,
On Fri, 7 Dec 2012, Jan Hubicka wrote:
> > > Actually the calculix regression is also seen on core.
> > > Igor was looking into what loops got slower and why. Either we can fix
> > > that partiuclar
> > > loop or revert to the old default (that sadly causes quite a lot of code
> > > bloat)
> On Thu, Dec 6, 2012 at 10:43 PM, Jan Hubicka wrote:
> >> The following patch restores the old default limits for loop peeling
> >> that were recently changed to 100 and caused a 20% degradation in
> >> 454.calculix.
> >>
> >> Bootstrap/regtest on powerpc64-linux with no new regressions. Ok for t
Gabriel Dos Reis writes:
> On Fri, Dec 7, 2012 at 7:33 AM, Dodji Seketeli wrote:
>> diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
>> index a010f1f..c39ef30 100644
>> --- a/gcc/cp/parser.c
>> +++ b/gcc/cp/parser.c
>> @@ -15262,7 +15262,11 @@ cp_parser_using_declaration (cp_parser* parser,
>> /
On 2012-12-07 09:12, Marc Glisse wrote:
> but change ix86_expand_vector_set and others to generate vec_merge
> and have only the vec_merge define_insn in sse.md? I guess it would
> buy a large part of it. That's a pretty invasive change, I'll have to
> try...
Is it really that invasive? Anyway, i
On Fri, Dec 07, 2012 at 12:36:58PM +0100, Richard Biener wrote:
> Hmm. Then make it DINFO_LEVEL_NONE and put in a fixme comment refering
> to the bugreport.
Here is what I've committed after another bootstrap/regtest:
2012-12-07 Jakub Jelinek
PR fortran/55395
* varpool.c (var
Hi!
The barriers pass wants to put a BARRIER from after a noreturn call in
between the call and NOTE_INSN_CALL_ARG_LOCATION, but as the note no longer
is BB_END (the call is), it happens to extend BB_END to the BARRIER which
later breaks the md reorg pass.
dwarf2out.c seems to handle a BARRIER in
On Thu, Dec 6, 2012 at 1:12 PM, Bernhard Reutner-Fischer
wrote:
> def IsComment(line):
>"""Return True if line is a comment."""
> - return line.startswith('#')
> + return bool(re.matches("#", line))
startswith() is a better match here.
> def IsInclude(line):
>"""Return True if line
On Fri, 7 Dec 2012, Richard Henderson wrote:
On 2012-12-07 09:00, Marc Glisse wrote:
On Fri, 7 Dec 2012, Richard Henderson wrote:
On 2012-12-07 02:49, Marc Glisse wrote:
For 2-element vectors, vec_concat does seem more natural than
vec_merge. If we chose vec_merge as the canonical representa
On 2012-12-07 09:00, Marc Glisse wrote:
> On Fri, 7 Dec 2012, Richard Henderson wrote:
>
>> On 2012-12-07 02:49, Marc Glisse wrote:
>>> For 2-element vectors, vec_concat does seem more natural than
>>> vec_merge. If we chose vec_merge as the canonical representation, we
>>> should chose it for set
On Fri, 7 Dec 2012, Richard Henderson wrote:
On 2012-12-07 02:49, Marc Glisse wrote:
For 2-element vectors, vec_concat does seem more natural than
vec_merge. If we chose vec_merge as the canonical representation, we
should chose it for setting an element in a vector
(ix86_expand_vector_set) eve
On 2012-12-07 08:47, Jakub Jelinek wrote:
> That was the older proposal, the current way to trigger it is using
> the substitution attr somewhere, typically in pattern name
> - in the above case.
Ah right.
("My mind is going, Dave. I can feel it.")
r~
On Fri, Dec 07, 2012 at 08:43:05AM -0600, Richard Henderson wrote:
> > +(define_insn "_vm3"
> >[(set (match_operand:VF_128 0 "register_operand" "=x,x")
> > (vec_merge:VF_128
> > - (plusminus:VF_128
> > - (match_operand:VF_128 1 "register_operand" "0,x")
> > - (match_operand:
On 12/07/2012 08:42 AM, Gabriel Dos Reis wrote:
Sound good to me (except for the comment).
Me, too.
Jason
On 2012-12-07 02:49, Marc Glisse wrote:
> The root problem is that we model the subs[sd] instructions as taking
> a 128-bit second operand, when Intel's documentation says they take a
> 32/64-bit operand, which is an important difference for memory
> operands (and constants). Writing a pattern that
OK.
Jason
On 12/06/2012 01:31 PM, Steven Bosscher wrote:
> Hello,
>
> The problem in this PR is that new basic blocks can be created if the
> scheduler moves speculative insns and adds recovery code, but the
> bb_state* arrays are allocated only at the start of scheduling a
> region and are not set up to de
Hi!
As discussed in the PR, bootstrap comparison doesn't like random
random-seed, causing differences in some symbols on some targets.
Fixed thusly, approved by Alex in the PR, committed to trunk.
2012-12-07 Jakub Jelinek
PR bootstrap/54926
* Makefile.am (AM_CFLAGS): Add -fran
On Fri, Dec 7, 2012 at 10:52 AM, Steven Bosscher wrote:
> Ping?
Ok if C++ frontend maintainers don't complain over the weekend.
Thanks,
Richard.
> On Sun, Dec 2, 2012 at 9:27 PM, Steven Bosscher wrote:
>> Hello,
>>
>> The C++ front end pushes everything through the compiler queue after
>> writi
On Fri, 7 Dec 2012, Michael Zolotukhin wrote:
By the way, if we decide to have one pattern for V4SF instructions and
another for V2DF, we could try to use recently introduced define_subst
here. It won't reduce number of actual patterns (I mean number of
patterns after iterators and subst expandi
PING^2
On 29 November 2012 14:45, Matthew Gretton-Dann
wrote:
> PING
>
> On 20 November 2012 20:34, Matthew Gretton-Dann
> wrote:
>> All,
>>
>> This patch backports Matthais Klose's arm*-*-linux-gnueabihf triplet
>> support patch of 2012-10-15 to 4.7.
>>
>> The backport was not clean as 4.8 has
On Fri, Dec 7, 2012 at 7:39 AM, Jakub Jelinek wrote:
> On Fri, Dec 07, 2012 at 07:34:30AM -0600, Gabriel Dos Reis wrote:
>> On Fri, Dec 7, 2012 at 3:13 AM, Matthias Klose wrote:
>> > Am 07.12.2012 06:05, schrieb Jason Merrill:
>> >> It's perfectly OK to initialize a base class of abstract type; i
On Fri, Dec 7, 2012 at 7:33 AM, Dodji Seketeli wrote:
> Jason Merrill writes:
>
>> Oops, thought I had sent this before.
>
> No problem. Thank you for replying now×
>
>> On 11/17/2012 10:23 AM, Dodji Seketeli wrote:
>> > - if (cp_parser_parse_definitely (parser))
>> > + /* Note that if w
On Fri, Dec 07, 2012 at 07:34:30AM -0600, Gabriel Dos Reis wrote:
> On Fri, Dec 7, 2012 at 3:13 AM, Matthias Klose wrote:
> > Am 07.12.2012 06:05, schrieb Jason Merrill:
> >> It's perfectly OK to initialize a base class of abstract type; it's only an
> >> error to create a full object of such a ty
On Fri, Dec 7, 2012 at 3:13 AM, Matthias Klose wrote:
> Am 07.12.2012 06:05, schrieb Jason Merrill:
>> It's perfectly OK to initialize a base class of abstract type; it's only an
>> error to create a full object of such a type. So this patch moves the check
>> from more generic initialization cod
Jason Merrill writes:
> Oops, thought I had sent this before.
No problem. Thank you for replying now×
> On 11/17/2012 10:23 AM, Dodji Seketeli wrote:
> > - if (cp_parser_parse_definitely (parser))
> > + /* Note that if we actually see the '=' token after the
> > +identifier, cp
> -Original Message-
> From: Joseph Myers [mailto:jos...@codesourcery.com]
> Sent: Friday, December 07, 2012 2:04 AM
> To: Terry Guo
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [RFC] New feature to reuse one multilib among different
> targets
>
> On Tue, 13 Nov 2012, Terry Guo wrote:
>
On Wed, Nov 28, 2012 at 8:18 PM, H.J. Lu wrote:
>
> Binutils supports 2 linkers, ld.gold and ld.bfd. One of them is
> configured as the default linker, ld, which is used by GCC. Sometimes,
> we want to use the alternate linker with GCC at run-time. This patch
> adds -fuse-ld=bfd and -fuse-ld=go
This fixes PR54886 - ISL is anal about freeing all its memory.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-12-07 Richard Biener
PR tree-optimization/54886
* graphite-sese-to-poly.c (build_loop_iteration_domains): Properly
free all memo
On Fri, 7 Dec 2012, Jakub Jelinek wrote:
> On Fri, Dec 07, 2012 at 12:23:03PM +0100, Richard Biener wrote:
> > > That would still mean we can fail bootstrap with -O2 -g1, if there is a
> > > DEBUG_IMPLICIT_PTR created during RTL expansion to some unused var, then
> > > that var's varpool node is v
On Fri, Dec 7, 2012 at 11:34 AM, Jakub Jelinek wrote:
> On Fri, Dec 07, 2012 at 11:25:38AM +0100, Steven Bosscher wrote:
>> Perhaps somewhere during the development of ree.c struct ext_cand was
>> GGC-allocated, in which case TODO_ggc_collect would make sense, to
>> collect the ext_cands (there can
On Fri, Dec 07, 2012 at 12:23:03PM +0100, Richard Biener wrote:
> > That would still mean we can fail bootstrap with -O2 -g1, if there is a
> > DEBUG_IMPLICIT_PTR created during RTL expansion to some unused var, then
> > that var's varpool node is varpool_remove_node removed and initializer
> > cle
Ping!
On Tue, Nov 27, 2012 at 03:32:46PM +0530, Siddhesh Poyarekar wrote:
> Ping!
>
> Siddhesh
>
> On Wed, Nov 21, 2012 at 12:42:13PM +0530, Siddhesh Poyarekar wrote:
> > Hi,
> >
> > Ping!
> >
> >
> > Siddhesh
> >
> > On Thu, 15 Nov 2012 19:05:38 +0530, Siddhesh wrote:
> >
> > > Hi,
> > >
On Fri, 7 Dec 2012, Jakub Jelinek wrote:
> On Fri, Dec 07, 2012 at 11:39:42AM +0100, Richard Biener wrote:
> > > > > --- gcc/varpool.c.jj 2012-11-19 14:41:27.0 +0100
> > > > > +++ gcc/varpool.c 2012-12-04 17:42:41.228752645 +0100
> > > > > @@ -65,7 +65,10 @@ varpool_remove_node (struc
On Fri, Dec 07, 2012 at 11:39:42AM +0100, Richard Biener wrote:
> > > > --- gcc/varpool.c.jj2012-11-19 14:41:27.0 +0100
> > > > +++ gcc/varpool.c 2012-12-04 17:42:41.228752645 +0100
> > > > @@ -65,7 +65,10 @@ varpool_remove_node (struct varpool_node
> > > >&& !DECL_VIRTUAL
Thanks for the explanation!
By the way, if we decide to have one pattern for V4SF instructions and
another for V2DF, we could try to use recently introduced define_subst
here. It won't reduce number of actual patterns (I mean number of
patterns after iterators and subst expanding), but it could he
On Fri, 7 Dec 2012, Jakub Jelinek wrote:
> On Fri, Dec 07, 2012 at 09:38:06AM +0100, Richard Biener wrote:
> > > 2012-12-06 Jakub Jelinek
> > >
> > > PR fortran/55395
> > > * varpool.c (varpool_remove_node): Don't drop DECL_INITIAL
> > > if -g and emitting DWARF2+.
> > >
> > > --- gcc/v
On Fri, Dec 07, 2012 at 11:25:38AM +0100, Steven Bosscher wrote:
> Perhaps somewhere during the development of ree.c struct ext_cand was
> GGC-allocated, in which case TODO_ggc_collect would make sense, to
> collect the ext_cands (there can be many of them). But since ext_cands
> are not GGC-alloca
On Fri, Dec 07, 2012 at 09:38:06AM +0100, Richard Biener wrote:
> > 2012-12-06 Jakub Jelinek
> >
> > PR fortran/55395
> > * varpool.c (varpool_remove_node): Don't drop DECL_INITIAL
> > if -g and emitting DWARF2+.
> >
> > --- gcc/varpool.c.jj2012-11-19 14:41:27.0 +01
On Fri, Dec 7, 2012 at 10:57 AM, Jakub Jelinek wrote:
> I'd say removing the GTY(()) on a struct that is never GC allocated
> nor interesting to PCH is obvious, the removal of TODO_ggc_collect is not
> so. Right now it is set by passes that expect to potentially
> create enough GC garbage that a c
Hi,
On 12/07/2012 10:24 AM, Matthias Klose wrote:
committed.
Matthias
2012-12-07 Matthias Klose
* tree.c (build_aggr_init_expr): Add parameter name, mark as unused.
Thanks.
I was wondering if in mainline we could just do the below. It seems
straightforward enough...
Thanks
On Fri, Dec 07, 2012 at 10:51:39AM +0100, Steven Bosscher wrote:
> On Fri, Dec 7, 2012 at 10:42 AM, Steven Bosscher wrote:
> > In the mean time -- comments on my patch?
>
> Oh, never mind, I forgot I was going to commit this as obvious :-)
I'd say removing the GTY(()) on a struct that is never GC
Ping?
On Sun, Dec 2, 2012 at 9:27 PM, Steven Bosscher wrote:
> Hello,
>
> The C++ front end pushes everything through the compiler queue after
> writing a PCH. This is pointless: After the PCH is written nothing the
> compiler does has any effect on it anymore.
>
> This patch makes the C++ front e
On Fri, Dec 7, 2012 at 10:42 AM, Steven Bosscher wrote:
> In the mean time -- comments on my patch?
Oh, never mind, I forgot I was going to commit this as obvious :-)
Ciao!
Steven
On Fri, Dec 7, 2012 at 10:08 AM, Richard Biener
wrote:
> On Fri, Dec 7, 2012 at 1:05 AM, Steven Bosscher wrote:
>> Hello,
>>
>> ree.c's data structures are not GC-allocated, so its GTY markers and
>> its TODO_ggc_collect are unnecessary.
>>
>> Will commit as obvious after the usual testing on my
Hello,
The GDB sources contain some python files, and executing them
causes these .pyc files to appear. We could ignore them in GDB
only, but I think this is the type of extension (compilation
artifact) which can be shared amoung all projects.
ChangeLog:
* .gitignore: Ignore *.pyc file.
> 2012-12-07 Uros Bizjak
>
> * stack_check3.ad[sb]: Move to gnat.dg.
>
> [Patch omitted, since it is just trivial move.]
Thanks for fixing this!
--
Eric Botcazou
On 12/06/2012 11:14 PM, Jason Merrill wrote:
When we look through a typedef, we need to keep any cv-quals that were
added to it.
Thanks! Patch fixes also c++/54975, but it didn't look (to me ;) as an
obvious duplicate, thus before closing it, I'm also going to add the
testcase.
Thanks again,
Am 07.12.2012 10:17, schrieb Jakub Jelinek:
> On Fri, Dec 07, 2012 at 10:13:11AM +0100, Matthias Klose wrote:
>> Am 07.12.2012 06:05, schrieb Jason Merrill:
>>> It's perfectly OK to initialize a base class of abstract type; it's only an
>>> error to create a full object of such a type. So this pat
On Fri, Dec 07, 2012 at 10:13:11AM +0100, Matthias Klose wrote:
> Am 07.12.2012 06:05, schrieb Jason Merrill:
> > It's perfectly OK to initialize a base class of abstract type; it's only an
> > error to create a full object of such a type. So this patch moves the check
> > from more generic initia
Am 07.12.2012 06:05, schrieb Jason Merrill:
> It's perfectly OK to initialize a base class of abstract type; it's only an
> error to create a full object of such a type. So this patch moves the check
> from more generic initialization code out into a function that's definitely
> creating a new obj
On Fri, Dec 7, 2012 at 1:05 AM, Steven Bosscher wrote:
> Hello,
>
> ree.c's data structures are not GC-allocated, so its GTY markers and
> its TODO_ggc_collect are unnecessary.
>
> Will commit as obvious after the usual testing on my favourite platforms :-)
IMHO TODO_ggc_collect should go and we
On Thu, Dec 6, 2012 at 10:43 PM, Jan Hubicka wrote:
>> The following patch restores the old default limits for loop peeling
>> that were recently changed to 100 and caused a 20% degradation in
>> 454.calculix.
>>
>> Bootstrap/regtest on powerpc64-linux with no new regressions. Ok for trunk?
>>
>>
On Fri, 7 Dec 2012, Michael Zolotukhin wrote:
1) Does the root problem lay in the fact that even for scalar
additions we perform the addition on the whole vector and only then
drop the higher parts of the vector? I.e. to fix the test from the PR
we need to replace plus on vector mode with plus o
On Fri, Dec 7, 2012 at 7:49 AM, Michael Zolotukhin
wrote:
> Hi guys,
> Could I ask several questions just to clarify the things up?
>
> 1) Does the root problem lay in the fact that even for scalar
> additions we perform the addition on the whole vector and only then
> drop the higher parts of the
On Thu, 6 Dec 2012, Jakub Jelinek wrote:
> Hi!
>
> This patch fixes both a correctness problem (bootstrap failure in
> libgfortran for a couple of targets) and debug info quality issue.
> The correctness issue is about the fact that clearing DECL_INITIAL
> (well, setting it to error_mark_node is
1 - 100 of 103 matches
Mail list logo
