gcc-6-20160320 is now available
Snapshot gcc-6-20160320 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160320/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 234355 You'll find: gcc-6-20160320.tar.bz2 Complete GCC MD5=a99f33131845296fedbd65cf09fd63b0 SHA1=07631223761513e11cb31d5a62cfa972dd38365c Diffs from 6-20160313 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: [gimplefe] [gsoc16] Gimple Front End Project
Hi!
Sorry for the late reply.
I was observing gimple dumps and my initial findings are, to parse
gimple, we have to add support for following components to C FE
*basic blocks
*gimple labels and goto
*gimple phi functions
iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4)
*gimple switch
switch (a_1) , case 1: , case 2: >
*gimple exception handling
*openmp functions like
main._omp_fn.0 (void * .omp_data_i)
Please correct me if I am wrong. Also point out if I am missing anything
On 18 March 2016 at 14:53, Richard Biener wrote:
> On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
> wrote:
>> On 15 March 2016 at 20:46, Richard Biener wrote:
>>> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz wrote:
Hi,
On Thu, 10 Mar 2016, Richard Biener wrote:
> Then I'd like to be able to re-construct SSA without jumping through
> hoops (usually you can get close but if you require copies propagated in
> a special way you are basically lost for example).
>
> Thus my proposal to make the GSoC student attack the unit-testing
> problem by doing modifications to the pass manager and "extending" an
> existing frontend (C for simplicity).
I think it's wrong to try to shoehorn the gimple FE into the C FE. C is
fundamentally different from gimple and you'd have to sprinkle
gimple_dialect_p() all over the place, and maintaining that while
developing future C improvements will turn out to be much work. Some
differences of C and gimple:
* C has recursive expressions, gimple is n-op stmts, no expressions at all
* C has type promotions, gimple is explicit
* C has all other kinds of automatic conversion (e.g. pointer decay)
* C has scopes, gimple doesn't (well, global and local only), i.e. symbol
lookup is much more complicated
* C doesn't have exceptions
* C doesn't have class types, gimple has
* C doesn't have SSA (yes, I'm aware of your suggestions for that)
* C doesn't have self-referential types
* C FE generates GENERIC, not GIMPLE (so you'd need to go through the
gimplifier and again would feed gimple directly into the passes)
I really don't think changing the C FE to accept gimple is a useful way
forward.
>>>
>>> So I am most worried about replicating all the complexity of types and decl
>>> parsing for the presumably nice and small function body parser.
>> Um would it be a good idea if we separate "gimple" functions from
>> regular C functions,
>> say by annotating the function definition with "gimple" attribute ?
>
> Yes, that was my idea.
>
>> A "gimple" function should contain only gimple stmts and not C.
>> eg:
>> __attribute__((gimple))
>> void foo(void)
>> {
>> // local decls/initializers in C
>> // GIMPLE body
>> }
>> Or perhaps we could add a new keyword "gimple" telling C FE that this
>> is a GIMPLE function.
>
> Though instead of an attribute I would indeed use a new keyword (as you
> can't really ignore the attribute and it should be an error with compilers
> not knowing it). Thus sth like
>
> void foo (void)
> __GIMPLE {
> }
>
> as it's also kind-of a "definition" specifier rather than a
> declaration specifier.
>
>>
>> My intention is that we could reuse C FE for parsing types and decls
>> (which I suppose is the primary
>> motivation behind reusing C FE) and avoid mixing C statements with
>> GIMPLE by having a separate
>> GIMPLE parser for parsing GIMPLE functions.
>> (I suppose the GIMPLE function parser would need to do minimal parsing
>> of decls/types to recognize
>> the input is a declaration and call C parsing routines for parsing the
>> whole decl)
>
> Yes, eventually the C frontend provides routines that can be used
> to tentatively parse declarations / types used in the function.
>
>> When C front-end is invoked with -fgimple it should probably only
>> accept functions marked as "gimple".
>> Does this sound reasonable ?
>
> I think -fgimple would only enable recognizing the __GIMPLE keyword,
> I wouldn't change all defs to GIMPLE with it.
>
> Richard.
>
>> Thanks,
>> Prathamesh
>>>
>>> In private discussion we somewhat agreed (Micha - correct me ;)) that
>>> iff the GIMPLE FE would replace the C FE function body parsing
>>> completely (re-using name lookup infrastructure of course) and iff the
>>> GIMPLE FE would emit GIMPLE directly (just NULL DECL_SAVED_TREE
>>> and a GIMPLE seq in DECL_STRUCT_FUNCTION->gimple_body)
>>> then "re-using" the C FE would be a way to greatly speed up success.
>>>
>>> The other half of the project would then be to change the pass manager
>>> to do something sensible with the produced GIMPLE as well as making
>>> our dumps parseable by the GIMPLE FE.
>>>
>>> Richard.
--
Thanks and Regards,
Prasad Ghangal
Re: [gimplefe] [gsoc16] Gimple Front End Project
On Mon, Mar 21, 2016 at 04:43:35AM +0530, Prasad Ghangal wrote:
> Hi!
>
> Sorry for the late reply.
>
> I was observing gimple dumps and my initial findings are, to parse
> gimple, we have to add support for following components to C FE
>
> *basic blocks
I'd think you can probably make these enough like C labels that you
don't need to do anything special in the C fe to parse these. Just
removing the < and > gets you pretty close is that it?
> *gimple labels and goto
Similar I think.
> *gimple phi functions
> iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4)
yesI think you need to add something here. I think you can do it as a
builtin type function that expects its arguments to be labels or names
of variables.
> *gimple switch
> switch (a_1) , case 1: , case 2: >
I'd think we could make this more C like too.
> *gimple exception handling
yeah, though note exceptions are lowered pretty quickly so supporting
them with the explicit exception syntax probably isn't particularly
important.
> *openmp functions like
> main._omp_fn.0 (void * .omp_data_i)
I'd think you'd want to change the duping of this some to make it easier
to tell from struct.some.member.
> Please correct me if I am wrong. Also point out if I am missing anything
I think you might need to do something about variable names?
Trev
>
>
>
>
> On 18 March 2016 at 14:53, Richard Biener wrote:
> > On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
> > wrote:
> >> On 15 March 2016 at 20:46, Richard Biener
> >> wrote:
> >>> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz wrote:
> Hi,
>
> On Thu, 10 Mar 2016, Richard Biener wrote:
>
> > Then I'd like to be able to re-construct SSA without jumping through
> > hoops (usually you can get close but if you require copies propagated in
> > a special way you are basically lost for example).
> >
> > Thus my proposal to make the GSoC student attack the unit-testing
> > problem by doing modifications to the pass manager and "extending" an
> > existing frontend (C for simplicity).
>
> I think it's wrong to try to shoehorn the gimple FE into the C FE. C is
> fundamentally different from gimple and you'd have to sprinkle
> gimple_dialect_p() all over the place, and maintaining that while
> developing future C improvements will turn out to be much work. Some
> differences of C and gimple:
>
> * C has recursive expressions, gimple is n-op stmts, no expressions at
> all
> * C has type promotions, gimple is explicit
> * C has all other kinds of automatic conversion (e.g. pointer decay)
> * C has scopes, gimple doesn't (well, global and local only), i.e. symbol
> lookup is much more complicated
> * C doesn't have exceptions
> * C doesn't have class types, gimple has
> * C doesn't have SSA (yes, I'm aware of your suggestions for that)
> * C doesn't have self-referential types
> * C FE generates GENERIC, not GIMPLE (so you'd need to go through the
> gimplifier and again would feed gimple directly into the passes)
>
> I really don't think changing the C FE to accept gimple is a useful way
> forward.
> >>>
> >>> So I am most worried about replicating all the complexity of types and
> >>> decl
> >>> parsing for the presumably nice and small function body parser.
> >> Um would it be a good idea if we separate "gimple" functions from
> >> regular C functions,
> >> say by annotating the function definition with "gimple" attribute ?
> >
> > Yes, that was my idea.
> >
> >> A "gimple" function should contain only gimple stmts and not C.
> >> eg:
> >> __attribute__((gimple))
> >> void foo(void)
> >> {
> >> // local decls/initializers in C
> >> // GIMPLE body
> >> }
> >> Or perhaps we could add a new keyword "gimple" telling C FE that this
> >> is a GIMPLE function.
> >
> > Though instead of an attribute I would indeed use a new keyword (as you
> > can't really ignore the attribute and it should be an error with compilers
> > not knowing it). Thus sth like
> >
> > void foo (void)
> > __GIMPLE {
> > }
> >
> > as it's also kind-of a "definition" specifier rather than a
> > declaration specifier.
> >
> >>
> >> My intention is that we could reuse C FE for parsing types and decls
> >> (which I suppose is the primary
> >> motivation behind reusing C FE) and avoid mixing C statements with
> >> GIMPLE by having a separate
> >> GIMPLE parser for parsing GIMPLE functions.
> >> (I suppose the GIMPLE function parser would need to do minimal parsing
> >> of decls/types to recognize
> >> the input is a declaration and call C parsing routines for parsing the
> >> whole decl)
> >
> > Yes, eventually the C frontend provides routines that can be used
> > to tentatively parse declarations / types used in the function.
> >
> >> When C front-end is invoked with -fgimple it should probably only
> >> accept functions marked as "gimple".
> >> Does this so
