On 15/4/8 下午4:15, "Richard Biener" wrote:
>No. Currently we dump
>
> :
> # i_57 = PHI
> # ivtmp_60 = PHI
> _65 = (int) ratio_mult_vf.8_45;
> tmp.9_64 = i_30 + _65;
> tmp.10_66 = ivtmp_33 - ratio_mult_vf.8_45;
> if (niters.6_41 == ratio_mult_vf.8_45)
>goto ;
> else
>goto ;
>
>
On Wed, Apr 8, 2015 at 4:48 AM, Yinsong Xue wrote:
> On 15/4/7 下午4:33, "Richard Biener" wrote:
>
>>I still like the idea of using C + extensions most. As well as making the
>>-fdump-tree-XXX dumps (more) valid C (+ extensions). Cut & pasting
>>from dump files to generate testcases is currently
On 15/4/7 下午4:33, "Richard Biener" wrote:
>I still like the idea of using C + extensions most. As well as making the
>-fdump-tree-XXX dumps (more) valid C (+ extensions). Cut & pasting
>from dump files to generate testcases is currently somewhat awkward,
>mainly due to the issue how we dump lab
On Fri, Apr 3, 2015 at 7:56 PM, Gry Gunvor wrote:
> Gcc melt already advertises that it allows access to the internals:
> http://gcc-melt.org/ ; I have not tried it yet.
>
> This is of course not the same as a format that can be exported and
> then imported again, but it is attempting to get a sim
On Fri, Apr 03, 2015 at 09:25:57AM -0600, Jeff Law wrote:
> On 04/03/2015 07:45 AM, Diego Novillo wrote:
> >Not quite. The output of the debug dumpers is not really meant to be fed
> >back to the compiler. They are debug dumps only. They do not contain
> >enough information for code generation or a
On 04/03/2015 07:45 AM, Diego Novillo wrote:
On 04/02/15 11:59, xue yinsong wrote:
I suppose our goal is to translate the dumped program back to
the C source code (otherwise we can simply retain the gotos and
labels since they are already `valid’ in C). In this case we have to
convert the goto
On 04/02/15 11:59, xue yinsong wrote:
I suppose our goal is to translate the dumped program back to
the C source code (otherwise we can simply retain the gotos and
labels since they are already `valid’ in C). In this case we have to
convert the gotos back to if-elses and whiles. As long as
CFG
On 15/3/30 下午5:40, "Richard Biener" wrote:
>On Mon, Mar 30, 2015 at 11:36 AM, Richard Biener
> wrote:
>> On Fri, Mar 27, 2015 at 4:00 PM, xue yinsong wrote:
>>> Thanks for your reply to my proposal.
>>> AFAIS, most of the files generated by -fdump-tree-all are presented in
>>> C-like form i
On 03/31/2015 09:34 AM, Trevor Saunders wrote:
On Thu, Mar 26, 2015 at 03:15:22PM +0100, Richard Biener wrote:
On Thu, Mar 26, 2015 at 2:31 PM, xue yinsong wrote:
I think the gimple front end project would be quite useful to gcc so I’d like
to do work on it this summer.
The problem is, it se
On Thu, Mar 26, 2015 at 03:15:22PM +0100, Richard Biener wrote:
> On Thu, Mar 26, 2015 at 2:31 PM, xue yinsong wrote:
> > I think the gimple front end project would be quite useful to gcc so I’d
> > like to do work on it this summer.
> >
> > The problem is, it seems the GIMPLE front end project h
On Mon, Mar 30, 2015 at 11:36 AM, Richard Biener
wrote:
> On Fri, Mar 27, 2015 at 4:00 PM, xue yinsong wrote:
>> Thanks for your reply to my proposal.
>> AFAIS, most of the files generated by -fdump-tree-all are presented in
>> C-like form instead
>> of in lisp-like tuple form.
>> So it’s better
On Fri, Mar 27, 2015 at 4:00 PM, xue yinsong wrote:
> Thanks for your reply to my proposal.
> AFAIS, most of the files generated by -fdump-tree-all are presented in C-like
> form instead
> of in lisp-like tuple form.
> So it’s better to implement a front end for the C-like gimple representations.
On Thu, Mar 26, 2015 at 2:31 PM, xue yinsong wrote:
> I think the gimple front end project would be quite useful to gcc so I’d like
> to do work on it this summer.
>
> The problem is, it seems the GIMPLE front end project hasn’t been active for
> some time
> and Diego Novillo told me it may not
13 matches
Mail list logo