On 09/15/2015 03:38 PM, Aditya K wrote:
> I started with one of the test cases in the plugin testsuite "def_plugin.c".
> Pasted the code for convenience.
> I want to traverse all the loops in a function.
>
> Maybe use, loops_for_fn (DECL_STRUCT_FUNCTION (fndef)), but this does not
> seem to work
>> cagney = Andrew Cagney
> cag...@gnu.org?
Good point. The email identities of people change over time; forcing
a single arbitrary one to label all contributions is at best imprecise
and at worse a miscrediting. (This is one way in which the impersonal
use...@gcc.gnu.org aliases work better.)
On 28 August 2015 at 13:24, Jeff Law wrote:
> cagney = Andrew Cagney
cag...@gnu.org?
On Sep 15, 2015, at 1:04 PM, Jeff Law wrote:
> Given we haven't updated the dejagnu reqs since ~2001, I think stepping
> forward would be appropriate and I'd support moving all the way to 1.5.3 with
> the expectation that we'll be on a cadence of no faster than 2 years going
> forward.
So, I a
Snapshot gcc-5-20150915 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/5-20150915/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5
On Tue, Sep 15, 2015 at 2:45 PM, Matthew Fortune
wrote:
> H.J. Lu writes:
>> On Thu, Sep 3, 2015 at 10:37 AM, H.J. Lu wrote:
>> > The interrupt and exception handlers are called by x86 processors. X86
>> > hardware puts information on stack and calls the handler. The
>> > requirements are
>> >
H.J. Lu writes:
> On Thu, Sep 3, 2015 at 10:37 AM, H.J. Lu wrote:
> > The interrupt and exception handlers are called by x86 processors. X86
> > hardware puts information on stack and calls the handler. The
> > requirements are
> >
> > 1. Both interrupt and exception handlers must use the 'IRET
On 24 August 2015 at 09:40, Tom Tromey wrote:
> Eric> In the mean time, I'm enclosing a contributor map that will need to be
> Eric> filled in whoever does the conversion. The right sides should become
> Eric> full names and preferred email addresses.
>
> It's probably worth starting with the map
On September 15, 2015 10:05:27 PM GMT+02:00, Jeff Law wrote:
>On 09/15/2015 01:21 PM, David Malcolm wrote:
>> On Tue, 2015-09-15 at 10:39 -0700, Mike Stump wrote:
>>> On Sep 14, 2015, at 3:37 PM, Jeff Law wrote:
> Maybe GCC-6 can bump the required
> dejagnu version to allow for getting ri
On Thu, Sep 3, 2015 at 10:37 AM, H.J. Lu wrote:
> The interrupt and exception handlers are called by x86 processors. X86
> hardware puts information on stack and calls the handler. The
> requirements are
>
> 1. Both interrupt and exception handlers must use the 'IRET' instruction,
> instead of t
On 09/15/2015 01:21 PM, David Malcolm wrote:
On Tue, 2015-09-15 at 10:39 -0700, Mike Stump wrote:
On Sep 14, 2015, at 3:37 PM, Jeff Law wrote:
Maybe GCC-6 can bump the required
dejagnu version to allow for getting rid of all these superfluous
load_gcc_lib? *blink* :)
I'd support that as a dir
On 09/15/2015 01:23 PM, Bernhard Reutner-Fischer wrote:
On September 15, 2015 7:39:39 PM GMT+02:00, Mike Stump
wrote:
On Sep 14, 2015, at 3:37 PM, Jeff Law wrote:
Maybe GCC-6 can bump the required dejagnu version to allow for
getting rid of all these superfluous load_gcc_lib? *blink* :)
I'd
On Sat, 2015-09-12 at 18:45 +, Ajit Kumar Agarwal wrote:
>
>
> -Original Message-
> From: Aaron Sawdey [mailto:acsaw...@linux.vnet.ibm.com]
> Sent: Friday, September 04, 2015 11:51 PM
> To: Ajit Kumar Agarwal
> Cc: Jeff Law; vmaka...@redhat.com; Richard Biener; gcc@gcc.gnu.org; Vinod
On September 15, 2015 7:39:39 PM GMT+02:00, Mike Stump
wrote:
>On Sep 14, 2015, at 3:37 PM, Jeff Law wrote:
>>> Maybe GCC-6 can bump the required
>>> dejagnu version to allow for getting rid of all these superfluous
>>> load_gcc_lib? *blink* :)
>> I'd support that as a direction.
>>
>> Certainl
On Tue, 2015-09-15 at 10:39 -0700, Mike Stump wrote:
> On Sep 14, 2015, at 3:37 PM, Jeff Law wrote:
> >> Maybe GCC-6 can bump the required
> >> dejagnu version to allow for getting rid of all these superfluous
> >> load_gcc_lib? *blink* :)
> > I'd support that as a direction.
> >
> > Certainly dr
On Sep 14, 2015, at 3:37 PM, Jeff Law wrote:
>> Maybe GCC-6 can bump the required
>> dejagnu version to allow for getting rid of all these superfluous
>> load_gcc_lib? *blink* :)
> I'd support that as a direction.
>
> Certainly dropping the 2001 version from our website in favor of 1.5 (which
>
* Jason Merrill:
> There are lots of ancient branches and tags in the SVN repository that
> are no longer interesting, and it would be nice not to have them
> cluttering up the lists and default fetch set.
Just one minor comment: Due to the way Git branches work, this
decision can be deferred to
On Tue, 15 Sep 2015, Jason Merrill wrote:
> There are lots of ancient branches and tags in the SVN repository that are no
> longer interesting, and it would be nice not to have them cluttering up the
> lists and default fetch set.
>
> The options I see for each branch or tag are:
> 1) Keep them a
There are lots of ancient branches and tags in the SVN repository that
are no longer interesting, and it would be nice not to have them
cluttering up the lists and default fetch set.
The options I see for each branch or tag are:
1) Keep them at the same place.
2) Move them to a subdirectory lik
> I see. Is it correct then to say that reload will never be able to
> change a near mem into a far mem or vice versa? If that is true, there
> doesn't appear to be any real benefit to having both near and far mem
> operations as *alternatives* to the same insn pattern.
The RL78 has a segment r
On Tue, Sep 15, 2015 at 8:53 AM, Ulrich Weigand wrote:
> Jim Wilson wrote:
> In that case, you might be able to fix the bug by splitting the
> offending insns into two patterns, one only handling near mems
> and one handling one far mems, where the near/far-ness of the mem
> is verified by the *pr
Indeed, we observed some problems with scheduling which we believe has more
to do with the scheduling algorithm than with the model DFA, as we said in
https://gcc.gnu.org/ml/gcc/2015-09/msg00118.html
Cheers,
--
Evandro Menezes Austin, TX
> -Original Message-
Jim Wilson wrote:
> On Tue, Sep 15, 2015 at 7:42 AM, Ulrich Weigand wrote:
> > But the only difference between define_memory_constraint and a plain
> > define_constraint is just that define_memory_constraint guarantees
> > that any memory operand can be made valid by reloading the address
> > into
On Tue, Sep 15, 2015 at 7:42 AM, Ulrich Weigand wrote:
> But the only difference between define_memory_constraint and a plain
> define_constraint is just that define_memory_constraint guarantees
> that any memory operand can be made valid by reloading the address
> into a base register ...
>
> If
Jim Wilson wrote:
> On Mon, Sep 14, 2015 at 11:05 PM, DJ Delorie wrote:
> > As a test, I added this API. It seems to work. I suppose there could
> > be a better API where we determine if a constrain matches various
> > memory spaces, then compare with the memory space of the operand, but
> > I c
On Sun, Sep 6, 2015 at 2:46 PM, Ajit Kumar Agarwal
wrote:
> All:
>
> The cost and benefit associated for moving a given expression above
> conditional are the important factors for the performance boost.
>
> Considering the above, the cost and benefit calculation can be derived based
> on below
I started with one of the test cases in the plugin testsuite "def_plugin.c".
Pasted the code for convenience.
I want to traverse all the loops in a function.
Maybe use, loops_for_fn (DECL_STRUCT_FUNCTION (fndef)), but this does not seem
to work.
/* Callback function to invoke after GCC finishe
Hi,
mirrors.webhostinggeeks.com/gcc/
28 matches
Mail list logo
