On Sun, Jun 26, 2016 at 5:55 PM, Prasad Ghangal
<prasad.ghan...@gmail.com> wrote:
> Hi Richard,
>
> For the first stage of the project, I have completed the following things -
> parsed -- assign-statement, labeled-statement, if-statement,
> switch-statement, goto-statement, return-statement;
> handled local declarations and
> attempted hacking pass manager
>
> Link for github repository is : https://github.com/PrasadG193/gcc_gimple_fe
I've CCed the gcc list - please do so in future as well.
Looking at this now. Do you have a set of test inputs that work? I'm
struggling
to create even basic ones with local declarations.
This means a good next step is to add testcases to the testsuite!
For example I can add
> cat gcc/testsuite/gcc.dg/gimplefe-1.c
/* { dg-do compile } */
/* { dg-options "-fgimple" } */
int i;
void __GIMPLE () foo ()
{
i = 1;
}
and then run it from inside gcc/ in the build tree like so:
obj-gimplefe-g/gcc> make check-gcc RUNTESTFLAGS="dg.exp=gimplefe*.c"
which then reports
...
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file
for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /space/rguenther/src/gcc_gimple_fe/gcc/testsuite/config/default.exp
as tool-and-target-specific interface file.
Running /space/rguenther/src/gcc_gimple_fe/gcc/testsuite/gcc.dg/dg.exp ...
FAIL: gcc.dg/gimplefe-1.c (test for excess errors)
=== gcc Summary ===
# of unexpected failures 1
/home/abuild/rguenther/obj-gimplefe-g/gcc/xgcc version 7.0.0 20160531
(experimental) (GCC)
make[1]: Leaving directory `/home/abuild/rguenther/obj-gimplefe-g/gcc'
the FAIL is due to the debug output you added (might be a good idea to
maybe guard it with
some extra flag).
Playing with the input somewhat I can get the following to parse:
int i;
void __GIMPLE () foo ()
{
int tem;
tem = i;
if (tem)
goto a;
else
goto b;
a:
i = 2;
return;
b:
i = 3;
}
int main()
{
i = 1;
foo ();
if (i != 2)
__builtin_abort ();
return 0;
}
and it seems to work ok. The above can even use { dg-do run } and run
the produced
executable successfully.
Currently if you supply invalid GIMPLE as input it will be the gimple
verification that
will lead to an internal compiler error instead of the FE providing a
nice error. I think
that's ok for now.
So please add the various test inputs you must have accumulated as testcases
in gcc/testsuite/gcc.dg/ as gimplefe-{1,2,3...}.c.
Thanks,
Richard.
>
>
> Thanks,
> Prasad Ghangal
>
> On 17 June 2016 at 03:34, Prasad Ghangal <prasad.ghan...@gmail.com> wrote:
>> Hi Richard,
>>
>> Please follow the link for github repository -
>> https://github.com/PrasadG193/gcc_gimple_fe
>>
>> Thanks,
>> Prasad
>>
>>
>> On 15/06/2016, Richard Biener <richard.guent...@gmail.com> wrote:
>>> On Wed, Jun 15, 2016 at 8:47 AM, Prasad Ghangal
>>> <prasad.ghan...@gmail.com> wrote:
>>>> Hi Richard,
>>>>
>>>> Sorry I couldn't to mail you yesterday because I was travelling and I
>>>> had no access to my pc and internet.
>>>>
>>>> Till now I am able to parse basic block (i.e bb_1: ) and extended
>>>> gimple expression parsing. Currently I am trying to hack pass manager.
>>>> My basic idea is to add custom pass list to function structure like
>>>> gimple_opt_pass **pass_list ; and execute the list instead of all
>>>> passes in execute_pass_list function. Please tell me if there is other
>>>> better way to do this.
>>>
>>> For final unit-testing this might be the most flexible thing indeed, say
>>>
>>> __GIMPLE (execute ("ccp", "fre")) foo ()
>>> {
>>> ...
>>> }
>>>
>>> exactly naming passes to execute. That's best for unit testing that
>>> in the end just inspects dump-files.
>>>
>>> For correctness testcases we'd need to generate code eventually
>>> and thus there we only want to specify the entry point into the
>>> optimization pipeline, say
>>>
>>> __GIMPLE (startwith ("fre1")) foo ()
>>> {
>>> ...
>>> }
>>>
>>> You still have to go through the lowering phase if you do not build
>>> a CFG right from the parser of course.
>>>
>>> I think doing execute ("ccp", "fre") is easier and using a custom
>>> pass-list would work. startwith would essentially need to perform
>>> the equivalent of -fdisable-tree-X for each pass before the pass
>>> to start with. Eventually providing overrides for all the global
>>> entries into the pass pipeline would work as well - see calls to
>>> execute_ipa_pass_list and execute_pass_list. Unfortunately the
>>> pass manager doesn't have full control over the compilation but
>>> much of it is driven via ad-hoc code.
>>>
>>> Btw, please make your work accessible via git on github.
>>>
>>> Thanks,
>>> Richard.
>>>
>>>>
>>>>
>>>> On 14 June 2016 at 19:50, Richard Biener <richard.guent...@gmail.com>
>>>> wrote:
>>>>> Hi Prasad,
>>>>>
>>>>> can you please point me to the git you use for development and/or send an
>>>>> update
>>>>> on how the work goes along? I will be on vacation starting from
>>>>> Thursday, June 16
>>>>> and will return only on Monday, June 27 which is the deadline for the
>>>>> midterm
>>>>> evaluation. Currently I am not impressed with how you report progress
>>>>> or (fail to)
>>>>> ask questions.
>>>>>
>>>>> Thus please make sure I have something to look at when I return from
>>>>> vacation.
>>>>>
>>>>> Thanks,
>>>>> Richard.
>>>
>>
>>
>> --
>> Thanks and Regards,
>> Prasad Ghangal
