Hello!
... where they belong according to ChangeLog.
2012-12-07 Uros Bizjak
* stack_check3.ad[sb]: Move to gnat.dg.
[Patch omitted, since it is just trivial move.]
Committed to 4.7 branch.
Uros.
Ping?
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02558.html
Thanks,
Christophe.
On 30 November 2012 17:34, Christophe Lyon wrote:
> On 29 November 2012 21:59, Joseph S. Myers wrote:
>> On Thu, 29 Nov 2012, Christophe Lyon wrote:
>>
>>> 2012-11-28 Christophe Lyon
>>>
>>> gcc/
>>> *
On Thu, 6 Dec 2012, Jan Hubicka wrote:
> > Hi,
> >
> > the patch below re-stores a check in the inlining machinery that makes
> > sure growth estimates match the reality after inlining. However, in
> > order to do that, I had to teach indirect inlining to look at IPA-CP
> > data because that's w
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
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 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 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, 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
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 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 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 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,
> 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
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.
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
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
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 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
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 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
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 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, 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
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, 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
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
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, 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
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, 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
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 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
> -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:
>
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
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
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 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 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
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, 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
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
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 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
OK.
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
On 12/07/2012 08:42 AM, Gabriel Dos Reis wrote:
Sound good to me (except for the comment).
Me, too.
Jason
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 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, 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 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 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 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
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 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
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
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 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
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 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..
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
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
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
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
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
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
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
> 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 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~
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
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: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
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
> >>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.
> >
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.
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
On Fri, Dec 7, 2012 at 10:06 AM, Dodji Seketeli wrote:
> Here is what I am committing to trunk.
Thank you!
-- Gaby
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 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 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/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 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 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
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 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
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
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 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
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 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
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 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
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
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, 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(
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, 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
> 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
OK.
Jason
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
1 - 100 of 103 matches
Mail list logo
