Hi! New to GCC
Hi, I am Prasad Ghangal, a BTech student and I really want to contribute in gcc, but I am new to open source community. I can code in C,C++ and know little python. I have successfully built gcc on my local machine as instructed. So can someone please help me getting started? -- Thanks, Prasad Ghangal
Re: Hi! New to GCC
Thanks Mikhail, As you have suggested I have built gcc on my laptop and gone through all the videos. The videos were very informative. Can I use any IDE for browsing gcc source code ? Should I start looking at the "easy hacks" ? On 9 January 2016 at 21:25, Mikhail Maltsev wrote: > On 01/09/2016 06:10 PM, Prasad Ghangal wrote: >> Hi, >> I am Prasad Ghangal, a BTech student and I really want to contribute >> in gcc, but I am new to open source community. >> I can code in C,C++ and know little python. I have successfully built >> gcc on my local machine as instructed. >> >> So can someone please help me getting started? >> > Hi! > > Here is a list of first steps to start with: > https://gcc.gnu.org/wiki/GettingStarted > > Also, you might want to take a look at these video lectures: > https://www.cse.iitb.ac.in/grc/index.php?page=videos, they are slightly > outdated > (~2012), but still give a good overview of GCC internals. > > There is a list of bugs and enhancement requests, which were marked by GCC > developers as "easy hacks", i.e. something that should be easy enough for new > contributors to start with: > https://gcc.gnu.org/bugzilla/buglist.cgi?keywords=easyhack&list_id=135581&resolution=--- > > > -- > Regards, > Mikhail Maltsev -- Thanks and Regards, Prasad Ghangal
Help! Regarding Bug 17896
Hi! I would like to solve "Bug 17896 - The expression (a>0 & b>0) should give clearer warning message (-Wparentheses)" (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17896) but I am new to gcc internals. Can someone please guide me how to do it? -- Thanks and Regards, Prasad Ghangal
Re: Help! Regarding Bug 17896
On 26 January 2016 at 03:24, Manuel López-Ibáñez wrote: > On 25 January 2016 at 20:17, Mikhail Maltsev wrote: >> As I understand, the bug report suggests that we say "suggest || instead of | >> when joining booleans" instead. We now have the API to show fix-it hints, so >> it >> would be nice to output something like >> >> test.c:17:21: warning: suggest || instead of | when joining booleans >>foo ((a == b) | b == c); >> ^ >> || >> >> Grep 'set_fixit_hint' in the source code to see an example of it's usage. > > I think you should focus on one single very simple thing for a first > patch, either adding fix-it hints to the existing warning or adding > the alternative text. I would in fact suggest to add fix-it hints > without touching anything else, since this is probably less > controversial [*] and more straightforward. How? > > 1) Grep 'set_fixit_hint' in gcc/* gcc/cp/* gcc/c/* gcc/c-family/* and > see how it is used. > 2) Grep 'suggest parentheses around comparison in operand' > 3) Run gcc under gdb and stop at the moment the warning above is given. > 4) Figure out what you need to do to make fix-it hints work in this > case so we give (spaces are probably messed up by gmail): > > test.c:17:17: note: suggest parentheses around comparison in operand of '|' >foo ((a == b) | b == c); > ^ >( ) > > The rest is the standard for submitting patches: > https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps > > This patch is probably a few lines, so you may not even need a > copyright assignment. The goal of starting simple is to learn the > process of submitting a patch without being distracted by the > discussion about the patch itself. Once you feel confident with the > process, you can try changing the text of the warning (but then I > would suggest you find out first what the C/C++ maintainers want > before implementing it). Note that another easyhack > (https://gcc.gnu.org/PR38612) is also a matter of changing the warning > text and the C++ maintainer already gave his blessing to the new text > in comment #5. > > Cheers, > > Manuel. > > [*] I don't agree with the suggestion in the bug report. I think we > should either follow Clang here or we should say something like "& > will evaluate the boolean expression to its right, did you mean '&&'?" > The C/C++ maintainers may even have different opinions. I agree with Manuel (and his comments on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17896) that we should follow clang here and show fix-it hint "& will evaluate the boolean expression to its right, did you mean '&&'?". That will be more clear message than "suggest && instead of & when joining booleans". So I am asking community for their suggestion. -- Thanks and Regards, Prasad Ghangal
Help! Regarding bug 49973
Hi ! I am new to gcc. I would like to solve bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973 (Bug 49973 - Column numbers count special characters as multiple columns ). Can somebody guide me? I tried to debug gcc under gdb. I think I have to change code in c-parser.c -- Thanks and Regards, Prasad Ghangal
Need some help regarding bug Bug 38612
Hi ! I am trying to fix bug 38612 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38612). As mentioned in comment 4, I am changing warning message in typeck2.c. TREE_TYPE(datum) gives type as 'X', but I want 'X*' also how to add notes as suggested in the comment ? -- Thanks and Regards, Prasad Ghangal
Need suggestion about bug 68425
I was looking at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68425
For testcase
const int array[2] = { 1, 2, 3 ,6 ,89 ,193};
gcc 6.0.0 produces warnings like (spacing may get disturbed by gmail) :
68425.c: In function ‘main’:
68425.c:3:34: warning: excess elements in array initializer
const int array[2] = { 1, 2, 3 ,6 ,89 ,193};
^
68425.c:3:34: note: (near initialization for ‘array’)
68425.c:3:37: warning: excess elements in array initializer
const int array[2] = { 1, 2, 3 ,6 ,89 ,193};
^
68425.c:3:37: note: (near initialization for ‘array’)
68425.c:3:40: warning: excess elements in array initializer
const int array[2] = { 1, 2, 3 ,6 ,89 ,193};
^~
68425.c:3:40: note: (near initialization for ‘array’)
68425.c:3:44: warning: excess elements in array initializer
const int array[2] = { 1, 2, 3 ,6 ,89 ,193};
^~~
68425.c:3:44: note: (near initialization for ‘array’)
While clang gives :
68425.c:3:34: warning: excess elements in array initializer
const int array[2] = { 1, 2, 3 ,6 ,89 ,193};
^
1 warning generated.
Wouldn't it be nice instead of multiple warnings if gcc gives single
warning like :
68425.c:3:34: warning: excess elements in array initializer (6
elements, expected 2)
const int array[2] = { 1, 2, 3 ,6 ,89 ,193};
^
--
Thanks and Regards,
Prasad Ghangal
Re: Need suggestion about bug 68425
I was working on PR68425,
my untested patch :
diff --git a/trunk/gcc/c/c-typeck.c b/trunk/gcc/c/c-typeck.c
--- a/trunk/gcc/c/c-typeck.c(revision 232768)
+++ b/trunk/gcc/c/c-typeck.c(working copy)
@@ -5856,7 +5856,7 @@
component name is taken from the spelling stack. */
static void
-pedwarn_init (location_t location, int opt, const char *gmsgid)
+pedwarn_init (location_t location, int opt, const char *gmsgid, ...)
{
char *ofwhat;
bool warned;
@@ -9269,8 +9269,10 @@
&& (tree_int_cst_lt (constructor_max_index, constructor_index)
|| integer_all_onesp (constructor_max_index)))
{
- pedwarn_init (loc, 0,
-"excess elements in array initializer");
+ pedwarn_init (loc, 0, "excess elements in array initializer "
+ "(%lu elements, expected %lu)",
+ tree_to_uhwi (constructor_index) + 1,
+ tree_to_uhwi (constructor_max_index) + 1);
break;
}
for test case:
const int array[2] = { 1, 2, 3};
const int array1[3] = { 1, 2, 3 ,6};
const int array2[4] = { 1, 2, 3 ,6 ,89};
const int array3[5] = { 1, 2, 3 ,6 ,89 ,193};
It gives :
68425.c: In function ‘main’:
68425.c:3:34: warning: excess elements in array initializer (3
elements, expected 2)
const int array[2] = { 1, 2, 3};
^
68425.c:3:34: note: (near initialization for ‘array’)
68425.c:4:38: warning: excess elements in array initializer (4
elements, expected 3)
const int array1[3] = { 1, 2, 3 ,6};
^
68425.c:4:38: note: (near initialization for ‘array1’)
68425.c:5:41: warning: excess elements in array initializer (5
elements, expected 4)
const int array2[4] = { 1, 2, 3 ,6 ,89};
^~
68425.c:5:41: note: (near initialization for ‘array2’)
68425.c:6:45: warning: excess elements in array initializer (6
elements, expected 5)
const int array3[5] = { 1, 2, 3 ,6 ,89 ,193};
^~~
68425.c:6:45: note: (near initialization for ‘array3’)
Which is as described on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68425
But as we discussed in this thread,
for test case like :
int array[3] = { 1, 2, 3 ,6 ,89 ,193};
It gives:
68425_1.c: In function ‘main’:
68425_1.c:3:31: warning: excess elements in array initializer (4
elements, expected 3)
int array[3] = { 1, 2, 3 ,6 ,89 ,193};
^
68425_1.c:3:31: note: (near initialization for ‘array’)
68425_1.c:3:34: warning: excess elements in array initializer (4
elements, expected 3)
int array[3] = { 1, 2, 3 ,6 ,89 ,193};
^~
68425_1.c:3:34: note: (near initialization for ‘array’)
68425_1.c:3:38: warning: excess elements in array initializer (4
elements, expected 3)
int array[3] = { 1, 2, 3 ,6 ,89 ,193};
^~~
68425_1.c:3:38: note: (near initialization for ‘array’)
Should I submit the patch ?
On 20 February 2016 at 01:20, Manuel López-Ibáñez wrote:
> On 19 February 2016 at 19:13, David Malcolm wrote:
>>> 68425.c:3:34: warning: excess elements in array initializer (6
>>> elements,
>>> expected 2)
>>>const int array[2] = { 1, 2, 3 ,6 ,89 ,193};
>>> ^
>>
>> Yes, that would be ideal. Unfortunately, not every tree expression
>> node has a location stored for it, so implementing the underlined range
>> might be tricky to do. (in particular, INTEGER_CST doesn't. I hope to
>> look into that for gcc 7, perhaps with a wrapper node to provide
>> locations for expr nodes that don't have them).
>
> Do you think that would be better than storing the locations in the
> parent expression? That is, instead of adding extra wrapper nodes,
> with all those tree nodes wasting space just to provide a location,
> add extra location slots to every tree that may have an operand. Or
> perhaps you are thinking about adding some lighter wrapper which is
> just a loc+tree* or something like that.
>
> In the case above (for C), struct constructor_stack could keep track
> of token locations passed by the parser (all tokens have locations,
> but those locations are not saved in all trees). In fact, I see that
> there is already a lot of location passing in the corresponding code,
> but probably all of them refer to input_location or some such.
>
> Cheers,
>
> Manuel.
--
Thanks and Regards,
Prasad Ghangal
Re: Need suggestion about bug 68425
Thanks Prathamesh and Joseph for your suggestions.
Here is my updated patch :
for test cases:
const int array[5] = {1, 2, 3};
const int array1[3] = {1, 2, 3, 6};
const int array2[4] = {1, 2, 3, 6, 89};
const int array3[5] = {1, 2, 3, 6, 89, 193};
const int array4[3] = {1, 2, 3, 6, 89, 193};
const int array5[1] = {1, 2, 3, 6, 89, 193};
const int array6[3] = {1, 2, 3, 6, 89, 193;
const int array7[5] = {1, 2, 3, 6, 89, 193}
const int array8[5] = {1, 2, 3, 6, 89, 193
It gives:
68425.c: In function ‘main’:
68425.c:4:37: warning: excess elements in array initializer (4
elements, expected 3)
const int array1[3] = {1, 2, 3, 6};
^
68425.c:4:37: note: (near initialization for ‘array1’)
68425.c:5:40: warning: excess elements in array initializer (5
elements, expected 4)
const int array2[4] = {1, 2, 3, 6, 89};
^~
68425.c:5:40: note: (near initialization for ‘array2’)
68425.c:6:44: warning: excess elements in array initializer (6
elements, expected 5)
const int array3[5] = {1, 2, 3, 6, 89, 193};
^~~
68425.c:6:44: note: (near initialization for ‘array3’)
68425.c:7:37: warning: excess elements in array initializer (6
elements, expected 3)
const int array4[3] = {1, 2, 3, 6, 89, 193};
^
68425.c:7:37: note: (near initialization for ‘array4’)
68425.c:8:31: warning: excess elements in array initializer (6
elements, expected 1)
const int array5[1] = {1, 2, 3, 6, 89, 193};
^
68425.c:8:31: note: (near initialization for ‘array5’)
68425.c:9:37: warning: excess elements in array initializer (6
elements, expected 3)
const int array6[3] = {1, 2, 3, 6, 89, 193;
^
68425.c:9:37: note: (near initialization for ‘array6’)
68425.c:9:47: error: expected ‘}’ before ‘;’ token
const int array6[3] = {1, 2, 3, 6, 89, 193;
^
68425.c:14:1: error: expected declaration or statement at end of input
}
^
Any suggestions?
--
Thanks and Regards,
Prasad Ghangal
Index: gcc/c/c-parser.c
===
diff --git a/trunk/gcc/c/c-parser.c b/trunk/gcc/c/c-parser.c
--- a/trunk/gcc/c/c-parser.c (revision 233263)
+++ b/trunk/gcc/c/c-parser.c (working copy)
@@ -1264,6 +1264,7 @@
NUM_PRECS
};
+extern void pedwarn_init (location_t, int, const char *, ...);
static void c_parser_external_declaration (c_parser *);
static void c_parser_asm_definition (c_parser *);
static void c_parser_declaration_or_fndef (c_parser *, bool, bool, bool,
@@ -1294,9 +1295,11 @@
static struct c_type_name *c_parser_type_name (c_parser *);
static struct c_expr c_parser_initializer (c_parser *);
static struct c_expr c_parser_braced_init (c_parser *, tree, bool);
-static void c_parser_initelt (c_parser *, struct obstack *);
+static void c_parser_initelt (c_parser *, struct obstack *, bool *, location_t *,
+ HOST_WIDE_INT *, HOST_WIDE_INT *);
static void c_parser_initval (c_parser *, struct c_expr *,
- struct obstack *);
+ struct obstack *, bool *, location_t *, HOST_WIDE_INT *,
+ HOST_WIDE_INT *);
static tree c_parser_compound_statement (c_parser *);
static void c_parser_compound_statement_nostart (c_parser *);
static void c_parser_label (c_parser *);
@@ -4347,9 +4350,14 @@
{
/* Parse a non-empty initializer list, possibly with a trailing
comma. */
+ bool to_warn = false;
+ location_t warn_loc = 0;
+ HOST_WIDE_INT warn_extra_elements = 0;
+ HOST_WIDE_INT warn_expected_elements = 0;
while (true)
{
- c_parser_initelt (parser, &braced_init_obstack);
+ c_parser_initelt (parser, &braced_init_obstack, &to_warn,
+ &warn_loc, &warn_extra_elements, &warn_expected_elements);
if (parser->error)
break;
if (c_parser_next_token_is (parser, CPP_COMMA))
@@ -4359,6 +4367,13 @@
if (c_parser_next_token_is (parser, CPP_CLOSE_BRACE))
break;
}
+ if(to_warn == true && !(parser->error))
+ {
+ pedwarn_init (warn_loc, 0, "excess elements in array initializer "
+ "(%wu elements, expected %wu)",
+ warn_expected_elements + warn_extra_elements,
+ warn_expected_elements);
+ }
}
c_token *next_tok = c_parser_peek_token (parser);
if (next_tok->type != CPP_CLOSE_BRACE)
@@ -4382,7 +4397,9 @@
/* Parse a nested initializer, including designators. */
static void
-c_parser_initelt (c_parser *parser, struct obstack * braced_init_obstack)
+c_parser_initelt (c_parser *parser, struct obstack * braced_init_obstack,
+ bool *to_warn, location_t *warn_loc, HOST_WIDE_INT *warn_extra_elements,
+
Re: Need suggestion about bug 68425
PING
I would like to know if there is other better way of doing this.
On 24 February 2016 at 17:56, Prasad Ghangal wrote:
> Thanks Prathamesh and Joseph for your suggestions.
>
> Here is my updated patch :
>
> for test cases:
>
> const int array[5] = {1, 2, 3};
> const int array1[3] = {1, 2, 3, 6};
> const int array2[4] = {1, 2, 3, 6, 89};
> const int array3[5] = {1, 2, 3, 6, 89, 193};
> const int array4[3] = {1, 2, 3, 6, 89, 193};
> const int array5[1] = {1, 2, 3, 6, 89, 193};
> const int array6[3] = {1, 2, 3, 6, 89, 193;
> const int array7[5] = {1, 2, 3, 6, 89, 193}
> const int array8[5] = {1, 2, 3, 6, 89, 193
>
>
>
> It gives:
>
> 68425.c: In function ‘main’:
> 68425.c:4:37: warning: excess elements in array initializer (4
> elements, expected 3)
> const int array1[3] = {1, 2, 3, 6};
>^
> 68425.c:4:37: note: (near initialization for ‘array1’)
> 68425.c:5:40: warning: excess elements in array initializer (5
> elements, expected 4)
> const int array2[4] = {1, 2, 3, 6, 89};
>^~
> 68425.c:5:40: note: (near initialization for ‘array2’)
> 68425.c:6:44: warning: excess elements in array initializer (6
> elements, expected 5)
> const int array3[5] = {1, 2, 3, 6, 89, 193};
> ^~~
> 68425.c:6:44: note: (near initialization for ‘array3’)
> 68425.c:7:37: warning: excess elements in array initializer (6
> elements, expected 3)
> const int array4[3] = {1, 2, 3, 6, 89, 193};
>^
> 68425.c:7:37: note: (near initialization for ‘array4’)
> 68425.c:8:31: warning: excess elements in array initializer (6
> elements, expected 1)
> const int array5[1] = {1, 2, 3, 6, 89, 193};
>^
> 68425.c:8:31: note: (near initialization for ‘array5’)
> 68425.c:9:37: warning: excess elements in array initializer (6
> elements, expected 3)
> const int array6[3] = {1, 2, 3, 6, 89, 193;
>^
> 68425.c:9:37: note: (near initialization for ‘array6’)
> 68425.c:9:47: error: expected ‘}’ before ‘;’ token
> const int array6[3] = {1, 2, 3, 6, 89, 193;
> ^
> 68425.c:14:1: error: expected declaration or statement at end of input
> }
> ^
>
>
> Any suggestions?
>
>
> --
> Thanks and Regards,
> Prasad Ghangal
--
Thanks and Regards,
Prasad Ghangal
Re: GCC GSOC 2016
So is gcc mentoring organization for gsoc this year? Because I was really interested in GIMPLE FE project. Can I start discussing on gcc-dev mailing lists? On 3 March 2016 at 22:12, Jose E. Marchesi wrote: > > > As usual, GNU applied to participate in this year's GSOC and was > > accepted as a mentoring organization. > > > > GCC related projects can be performed under the umbrella of the GNU org, > > provided there are suitable mentors. > > > > Please see http://www.gnu.org/software/soc-projects. > > The relevant mailing list is > https://lists.gnu.org/mailman/listinfo/summer-of-code > > This is good news! Sorry for talking out of my ass. This seems to have > changed in recent years. > > I have added a blurb to our wiki explaining the new arrangement. Could > you add a link to https://gcc.gnu.org/wiki/SummerOfCode somewhere in > http://www.gnu.org/software/soc-projects such that students can find > the project ideas for GCC? > > Done. Please make sure to subscribe to summer-of-c...@gnu.org. Every > aspect of the program is driven there. > > In particular, see > http://lists.gnu.org/archive/html/summer-of-code/2016-03/msg8.html > > -- Thanks and Regards, Prasad Ghangal
[gimplefe] [gsoc16] Gimple Front End Project
Hi! I am interested to work on Gimple FE project for gsoc16. I would like to know the scope of the project for gsoc. Also anyone like to mentor me for the project? Thanks and Regards, Prasad Ghangal
Re: [gimplefe] [gsoc16] Gimple Front End Project
Hi! On stackoverflow http://stackoverflow.com/questions/21660563/can-gcc-compile-gimple, they said GIMPLE FE project is dead. Please let me know if I can work on it for gsoc. On 5 March 2016 at 03:01, Prasad Ghangal wrote: > Hi! > > I am interested to work on Gimple FE project for gsoc16. I would like > to know the scope of the project for gsoc. Also anyone like to mentor > me for the project? > > > > > Thanks and Regards, > Prasad Ghangal -- Thanks and Regards, Prasad Ghangal
Re: [gimplefe] [gsoc16] Gimple Front End Project
On 6 March 2016 at 21:13, Richard Biener wrote: > > I'll be willing to mentor this. Though I'd rather have us starting from > scratch and look at having a C-like input language, even piggy-backing on the > C frontend maybe. That's great. I would like to know scope of the project for gsoc so that I can start preparing for proposal. > > Richard. > -- Thanks and Regards, Prasad Ghangal
Re: [gimplefe] [gsoc16] Gimple Front End Project
I would like to clear some doubts regarding project. Basic goals in the project will be (please correct me if I am wrong): 1. Developing FE for C like gimple IR - basically by extending or modifying C FE (I can see most are in favour of not including gimple-C into c-family languages) 2. And adding a way to pass gimple into specific pass. (I am not sure what Dave suggested i.e. to improve diagnostic would be in the scope. Please correct me if I missed any) This will be definitely very helpful for unit testing. I have following queries: 1. Upto what level we want C like structure in gimple (we will have to modify CFG, PHI nodes accordingly) 2. Do we have to develop new grammar for gimple-C ? -- Thanks and Regards, Prasad Ghangal
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
Hi! How exactly can we achieve start stop compilation on specific pass (ie run single pass on input)? eg. $cgimple -ftree-copyrename foo.c should produce optimization result of -ftree-copyrename pass on foo.c input On 21 March 2016 at 09:05, Trevor Saunders wrote: > 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 &g
Re: [gimplefe] [gsoc16] Gimple Front End Project
Hi!
Here is the link my gsoc proposal, please review it. Let me know if I
have missed or misunderstood anything
https://drive.google.com/file/d/0B2S9OoautWxsbVBkWDY3VDNkdGc/view
Thanks and Regards,
Prasad Ghangal
On 22 March 2016 at 19:23, Richard Biener wrote:
> On Tue, Mar 22, 2016 at 2:45 PM, Prathamesh Kulkarni
> wrote:
>> On 22 March 2016 at 16:26, Richard Biener wrote:
>>> On Tue, Mar 22, 2016 at 12:08 AM, Prasad Ghangal
>>> wrote:
>>>> Hi!
>>>>
>>>> How exactly can we achieve start stop compilation on specific pass (ie
>>>> run single pass on input)?
>>>>
>>>> eg. $cgimple -ftree-copyrename foo.c
>>>>
>>>> should produce optimization result of -ftree-copyrename pass on foo.c input
>>>
>>> You need pass manager support and annotate each function with information
>>> on what passes should be run (in which order even?). I think for the GSoC
>>> project specifying a starting pass for each function via the source, like
>>>
>>> __GIMPLE (tree-copyrename) void foo (void)
>>> {
>>> ...
>>> }
>>>
>>> and hacking the pass manager to honor that is enough.
>> Um would annotating each function with pass order work for ipa passes too ?
>
> There is no single point of execution for an IPA pass so no - you can
> tag it with
> one of the umbrella passes I guess. I suppose we'd need some magic "phase"
> tags for this, like simply "IPA". You then need to enable/disable IPA passes
> you want to run.
>
> Richard.
>
>> Thanks,
>> Prathamesh
>>>
>>> Richard.
>>>
>>>>
>>>>
>>>> On 21 March 2016 at 09:05, Trevor Saunders wrote:
>>>>> 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
Re: [gimplefe] [gsoc16] Gimple Front End Project
On 24 March 2016 at 19:01, Richard Biener wrote:
> On Thu, Mar 24, 2016 at 12:27 AM, Prasad Ghangal
> wrote:
>> Hi!
>>
>> I have attached my gsoc proposal, please review it. Let me know if I
>> have missed or misunderstood anything
>
> Please re-word the Abstract, it is really weird to read - I suggest to drop
> any notion of RTL or "back end" and somehow mention that unit testing
> is why "we want make changes in GIMPLE". Also stopping compilation
> isn't in the scope of the project (and while maybe a nice thing to have
> to do less work it is not a requirement for unit testing).
>
> Thus Project Goals are only unit testing (which includes what you call
> start/stop compilation).
>
> During the discussion in the last comments we agreed on re-using the
> C frontend for decls and types only and implement a completely separate
> parser for the function bodies so the frontend can also emit GIMPLE directly.
>
> Thus I'd scrap 4.A)/B) and instead write about
>
> 4.
> A) Define GIMPLE syntax
> Provide GIMPLE dumps with enough information to parse GIMPLE and
> change them according to agreed on GIMPLE syntax
Little confused here. Don't we need to change syntax first and then
develop grammar to parse it?
>
> B) Add __GIMPLE extension to the C FE and implement a GIMPLE parser
>
> For the suggested timeline I think that it is important for the "get
> basic stuff working"
> part to have all pieces of the project prototyped, including the pass manager
> support. Otherwise there is no way to fully test part of the implementation.
> I'd say modifying the gimple dumps can be done last as you can always write
> testcases manually.
>
> I realize that the student application deadline is tomorrow.
>
> Richard.
>
>
>
>>
>> Thanks and Regards,
>> Prasad Ghangal
>>
>>
>>
>>
>>
>> On 22 March 2016 at 19:23, Richard Biener wrote:
>>> On Tue, Mar 22, 2016 at 2:45 PM, Prathamesh Kulkarni
>>> wrote:
>>>> On 22 March 2016 at 16:26, Richard Biener
>>>> wrote:
>>>>> On Tue, Mar 22, 2016 at 12:08 AM, Prasad Ghangal
>>>>> wrote:
>>>>>> Hi!
>>>>>>
>>>>>> How exactly can we achieve start stop compilation on specific pass (ie
>>>>>> run single pass on input)?
>>>>>>
>>>>>> eg. $cgimple -ftree-copyrename foo.c
>>>>>>
>>>>>> should produce optimization result of -ftree-copyrename pass on foo.c
>>>>>> input
>>>>>
>>>>> You need pass manager support and annotate each function with information
>>>>> on what passes should be run (in which order even?). I think for the GSoC
>>>>> project specifying a starting pass for each function via the source, like
>>>>>
>>>>> __GIMPLE (tree-copyrename) void foo (void)
>>>>> {
>>>>> ...
>>>>> }
>>>>>
>>>>> and hacking the pass manager to honor that is enough.
>>>> Um would annotating each function with pass order work for ipa passes too ?
>>>
>>> There is no single point of execution for an IPA pass so no - you can
>>> tag it with
>>> one of the umbrella passes I guess. I suppose we'd need some magic "phase"
>>> tags for this, like simply "IPA". You then need to enable/disable IPA
>>> passes
>>> you want to run.
>>>
>>> Richard.
>>>
>>>> Thanks,
>>>> Prathamesh
>>>>>
>>>>> Richard.
>>>>>
>>>>>>
>>>>>>
>>>>>> On 21 March 2016 at 09:05, Trevor Saunders wrote:
>>>>>>> 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?
&g
Re: [gimplefe] [gsoc16] Gimple Front End Project
Thanks everyone for suggestions, Here is my updated proposal. I know its too late but can somebody review it? https://drive.google.com/file/d/0B2S9OoautWxsbVBkWDY3VDNkdGc/view?usp=sharing On 25 March 2016 at 08:46, Prathamesh Kulkarni wrote: > On 25 March 2016 at 01:15, Prasad Ghangal wrote: >> On 24 March 2016 at 19:01, Richard Biener wrote: >>> On Thu, Mar 24, 2016 at 12:27 AM, Prasad Ghangal >>> wrote: >>>> Hi! >>>> >>>> I have attached my gsoc proposal, please review it. Let me know if I >>>> have missed or misunderstood anything >>> >>> Please re-word the Abstract, it is really weird to read - I suggest to drop >>> any notion of RTL or "back end" and somehow mention that unit testing >>> is why "we want make changes in GIMPLE". Also stopping compilation >>> isn't in the scope of the project (and while maybe a nice thing to have >>> to do less work it is not a requirement for unit testing). >>> >>> Thus Project Goals are only unit testing (which includes what you call >>> start/stop compilation). >>> >>> During the discussion in the last comments we agreed on re-using the >>> C frontend for decls and types only and implement a completely separate >>> parser for the function bodies so the frontend can also emit GIMPLE >>> directly. >>> >>> Thus I'd scrap 4.A)/B) and instead write about >>> >>> 4. >>> A) Define GIMPLE syntax >>> Provide GIMPLE dumps with enough information to parse GIMPLE and >>> change them according to agreed on GIMPLE syntax >> >> Little confused here. Don't we need to change syntax first and then >> develop grammar to parse it? > Well the purpose of grammar is to define the syntax. > We would need to first define a grammar for GIMPLE and then implement > a (predictive) parser > that parses GIMPLE input according to our grammar and emits GIMPLE IR. > contrived eg: > stmt_list: stmt stmt_list_1 > stmt_list_1: stmt stmt_list_1 | epsilon > stmt: lvalue_operand '=' assign_stmt > | 'if' cond_stmt > assign_stmt: operand | operator operand | operand operator operand > operand: INT | lvalue_operand > lvalue_operand: ID > operator: '+' > > As pointed out by Richard, dumps could be modified later to adjust to > GIMPLE syntax, > initially you could write test-cases by hand. > > Thanks, > Prathamesh >> >>> >>> B) Add __GIMPLE extension to the C FE and implement a GIMPLE parser >>> >>> For the suggested timeline I think that it is important for the "get >>> basic stuff working" >>> part to have all pieces of the project prototyped, including the pass >>> manager >>> support. Otherwise there is no way to fully test part of the >>> implementation. >>> I'd say modifying the gimple dumps can be done last as you can always write >>> testcases manually. >>> >>> I realize that the student application deadline is tomorrow. >>> >>> Richard. >>> >>> >>> >>>> >>>> Thanks and Regards, >>>> Prasad Ghangal >>>> >>>> >>>> >>>> >>>> >>>> On 22 March 2016 at 19:23, Richard Biener >>>> wrote: >>>>> On Tue, Mar 22, 2016 at 2:45 PM, Prathamesh Kulkarni >>>>> wrote: >>>>>> On 22 March 2016 at 16:26, Richard Biener >>>>>> wrote: >>>>>>> On Tue, Mar 22, 2016 at 12:08 AM, Prasad Ghangal >>>>>>> wrote: >>>>>>>> Hi! >>>>>>>> >>>>>>>> How exactly can we achieve start stop compilation on specific pass (ie >>>>>>>> run single pass on input)? >>>>>>>> >>>>>>>> eg. $cgimple -ftree-copyrename foo.c >>>>>>>> >>>>>>>> should produce optimization result of -ftree-copyrename pass on foo.c >>>>>>>> input >>>>>>> >>>>>>> You need pass manager support and annotate each function with >>>>>>> information >>>>>>> on what passes should be run (in which order even?). I think for the >>>>>>> GSoC >>>>>>> project specifying a starting pass for each function via the source, >>>>>>> like >>>>>>> >>>>
Re: Need suggestion about bug 68425
On 5 March 2016 at 01:06, David Malcolm wrote:
> On Wed, 2016-02-24 at 17:56 +0530, Prasad Ghangal wrote:
>> Thanks Prathamesh and Joseph for your suggestions.
>>
>> Here is my updated patch :
>>
>> for test cases:
>>
>> const int array[5] = {1, 2, 3};
>> const int array1[3] = {1, 2, 3, 6};
>> const int array2[4] = {1, 2, 3, 6, 89};
>> const int array3[5] = {1, 2, 3, 6, 89, 193};
>> const int array4[3] = {1, 2, 3, 6, 89, 193};
>> const int array5[1] = {1, 2, 3, 6, 89, 193};
>> const int array6[3] = {1, 2, 3, 6, 89, 193;
>> const int array7[5] = {1, 2, 3, 6, 89, 193}
>> const int array8[5] = {1, 2, 3, 6, 89, 193
>>
>>
>>
>> It gives:
>>
>> 68425.c: In function ‘main’:
>> 68425.c:4:37: warning: excess elements in array initializer (4
>> elements, expected 3)
>> const int array1[3] = {1, 2, 3, 6};
>>^
>> 68425.c:4:37: note: (near initialization for ‘array1’)
>> 68425.c:5:40: warning: excess elements in array initializer (5
>> elements, expected 4)
>> const int array2[4] = {1, 2, 3, 6, 89};
>>^~
>> 68425.c:5:40: note: (near initialization for ‘array2’)
>> 68425.c:6:44: warning: excess elements in array initializer (6
>> elements, expected 5)
>> const int array3[5] = {1, 2, 3, 6, 89, 193};
>> ^~~
>> 68425.c:6:44: note: (near initialization for ‘array3’)
>> 68425.c:7:37: warning: excess elements in array initializer (6
>> elements, expected 3)
>> const int array4[3] = {1, 2, 3, 6, 89, 193};
>>^
>> 68425.c:7:37: note: (near initialization for ‘array4’)
>> 68425.c:8:31: warning: excess elements in array initializer (6
>> elements, expected 1)
>> const int array5[1] = {1, 2, 3, 6, 89, 193};
>>^
>> 68425.c:8:31: note: (near initialization for ‘array5’)
>> 68425.c:9:37: warning: excess elements in array initializer (6
>> elements, expected 3)
>> const int array6[3] = {1, 2, 3, 6, 89, 193;
>>^
>> 68425.c:9:37: note: (near initialization for ‘array6’)
>> 68425.c:9:47: error: expected ‘}’ before ‘;’ token
>> const int array6[3] = {1, 2, 3, 6, 89, 193;
>>^
>> 68425.c:14:1: error: expected declaration or statement at end of
>> input
>> }
>> ^
>
> Those caret locations look wrong to me - they don't seem to be
> underlining the pertinent source. Is that what the patched compiler is
> printing, or did things get messed up somewhere via email?
>
> (I tried the patch, but it didn't quite apply cleanly against my
> working copy)
>
> As mentioned before, I think the ideal behavior would be to underline
> *all* of the surplus elements, like this:
>
> 68425.c: In function ‘main’:
> 68425.c:4:37: warning: excess elements in array initializer (4
> elements, expected 3)
> const int array1[3] = {1, 2, 3, 6};
> ^
> 68425.c:4:37: note: (near initialization for ‘array1’)
> 68425.c:5:40: warning: excess elements in array initializer (5
> elements, expected 4)
> const int array2[4] = {1, 2, 3, 6, 89};
> ^~
> 68425.c:5:40: note: (near initialization for ‘array2’)
> 68425.c:6:44: warning: excess elements in array initializer (6
> elements, expected 5)
> const int array3[5] = {1, 2, 3, 6, 89, 193};
> ^~~
> 68425.c:6:44: note: (near initialization for ‘array3’)
> 68425.c:7:37: warning: excess elements in array initializer (6
> elements, expected 3)
> const int array4[3] = {1, 2, 3, 6, 89, 193};
> ^~
> 68425.c:7:37: note: (near initialization for ‘array4’)
> 68425.c:8:31: warning: excess elements in array initializer (6
> elements, expected 1)
> const int array5[1] = {1, 2, 3, 6, 89, 193};
>^~~~
> 68425.c:8:31: note: (near initialization for ‘array5’)
> 68425.c:9:37: warning: excess elements in array initializer (6
> elements, expected 3)
> const int array6[3] = {1, 2, 3, 6, 89, 193;
> ^~
> 68425.c:9:37: note: (near initialization for ‘array6’)
> 68425.c:9:47: error: expected ‘}’ before ‘;’ token
> const int array6[3] = {1,
Getting format of arg_type
Hi! Regarding PR64955, I was observing function format_type_warning() (in c-family/c-format.c), how can I get format specifier for arg_type? Say, if tree arg_type stores 'char', then how can I get its format i.e. 'c' ? Thanks, Prasad Ghangal
GSoC projects are announced
Hi all ! Sorry this is little late reply. Accepted projects for GSoC are announced. gcc has accepted 3 proposals this year. I want to thank gcc community for accepting proposal for GIMPLE FE project. I will give my best to complete the project. Thanks, Prasad Ghangal
[gimplefe] Regarding command line option handling
Hi !
Currently I am trying to introduce new command line option -fgimple,
for that I am adding this to c.opt
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 4f86876..88e55c6 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -66,6 +66,10 @@ C ObjC C++ ObjC++ Separate Alias(d)
-dump=
C ObjC C++ ObjC++ Joined Alias(d)
+fgimple
+C Var(flag_gimple) Init(0)
+Enable parsing GIMPLE
+
-imacros
C ObjC C++ ObjC++ Separate Alias(imacros) MissingArgError(missing
filename after %qs)
But I am getting error as - "gcc: error: unrecognized command line
option ‘-fgimple ’; did you mean ‘-fgimple ’?"
I am unable to find where to handle it.
Till now I am able to JUST parse __GIMPLE keyword
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index cae2faf..1ccb4d6 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -468,6 +468,7 @@ const struct c_common_resword c_common_reswords[] =
{ "__extension__",RID_EXTENSION,0 },
{ "__func__",RID_C99_FUNCTION_NAME, 0 },
{ "__has_nothrow_assign", RID_HAS_NOTHROW_ASSIGN, D_CXXONLY },
+ { "__GIMPLE",RID_GIMPLE,0 },
{ "__has_nothrow_constructor", RID_HAS_NOTHROW_CONSTRUCTOR, D_CXXONLY },
{ "__has_nothrow_copy", RID_HAS_NOTHROW_COPY, D_CXXONLY },
{ "__has_trivial_assign", RID_HAS_TRIVIAL_ASSIGN, D_CXXONLY },
@@ -12393,6 +12394,7 @@ keyword_is_function_specifier (enum rid keyword)
case RID_NORETURN:
case RID_VIRTUAL:
case RID_EXPLICIT:
+case RID_GIMPLE:
return true;
default:
return false;
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index 663e457..a91665f 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -64,10 +64,10 @@ enum rid
/* Modifiers: */
/* C, in empirical order of frequency. */
RID_STATIC = 0,
- RID_UNSIGNED, RID_LONG,RID_CONST, RID_EXTERN,
- RID_REGISTER, RID_TYPEDEF, RID_SHORT, RID_INLINE,
- RID_VOLATILE, RID_SIGNED, RID_AUTO, RID_RESTRICT,
- RID_NORETURN, RID_ATOMIC,
+ RID_UNSIGNED, RID_LONG, RID_CONST, RID_EXTERN,
+ RID_GIMPLE,RID_REGISTER, RID_TYPEDEF, RID_SHORT,
+ RID_INLINE,RID_VOLATILE, RID_SIGNED, RID_AUTO,
+ RID_RESTRICT, RID_NORETURN, RID_ATOMIC,
/* C extensions */
RID_COMPLEX, RID_THREAD, RID_SAT,
diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index f0c677b..e690ca3 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -10401,6 +10401,8 @@ declspecs_add_scspec (source_location loc,
case RID_TYPEDEF:
n = csc_typedef;
break;
+case RID_GIMPLE:
+ break;
default:
gcc_unreachable ();
}
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index bdd669d..266b672 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -732,6 +732,7 @@ c_token_starts_declspecs (c_token *token)
case RID_ALIGNAS:
case RID_ATOMIC:
case RID_AUTO_TYPE:
+case RID_GIMPLE:
return true;
default:
if (token->keyword >= RID_FIRST_INT_N
@@ -2461,6 +2462,7 @@ c_parser_declspecs (c_parser *parser, struct
c_declspecs *specs,
case RID_NORETURN:
case RID_AUTO:
case RID_THREAD:
+case RID_GIMPLE:
if (!scspec_ok)
goto out;
attrs_ok = true;
@@ -3960,6 +3962,7 @@ c_parser_attribute_any_word (c_parser *parser)
case RID_INT_N_1:
case RID_INT_N_2:
case RID_INT_N_3:
+case RID_GIMPLE:
ok = true;
break;
default:
After recognizing __GIMPLE, I am planning to call gimple_fn_parser
function which will parse gimple body.
For pass manager, basic idea is to introduce new member to struct
function as pass_list and modify function execute_pass_list to run
only passes in pass list.
Thanks,
Prasad Ghangal
Re: [gimplefe] Regarding command line option handling
On 4 May 2016 at 13:02, Richard Biener wrote:
> On Wed, May 4, 2016 at 8:41 AM, Prasad Ghangal
> wrote:
>> Hi !
>> Currently I am trying to introduce new command line option -fgimple,
>> for that I am adding this to c.opt
>>
>> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
>> index 4f86876..88e55c6 100644
>> --- a/gcc/c-family/c.opt
>> +++ b/gcc/c-family/c.opt
>> @@ -66,6 +66,10 @@ C ObjC C++ ObjC++ Separate Alias(d)
>> -dump=
>> C ObjC C++ ObjC++ Joined Alias(d)
>>
>> +fgimple
>> +C Var(flag_gimple) Init(0)
>> +Enable parsing GIMPLE
>> +
>> -imacros
>> C ObjC C++ ObjC++ Separate Alias(imacros) MissingArgError(missing
>> filename after %qs)
>>
>>
>> But I am getting error as - "gcc: error: unrecognized command line
>> option ‘-fgimple ’; did you mean ‘-fgimple ’?"
>>
>> I am unable to find where to handle it.
>
> Did you properly re-build gcc after that change? It should work just fine.
>
> Richard.
>
Yes, I did stage 1 build on latest revision. Still it's giving this
strange error - "gcc: error: unrecognized command line option
‘-fgimple’; did you mean ‘-fgimple’?"
>>
>>
>> Till now I am able to JUST parse __GIMPLE keyword
>>
>> diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
>> index cae2faf..1ccb4d6 100644
>> --- a/gcc/c-family/c-common.c
>> +++ b/gcc/c-family/c-common.c
>> @@ -468,6 +468,7 @@ const struct c_common_resword c_common_reswords[] =
>>{ "__extension__",RID_EXTENSION,0 },
>>{ "__func__",RID_C99_FUNCTION_NAME, 0 },
>>{ "__has_nothrow_assign", RID_HAS_NOTHROW_ASSIGN, D_CXXONLY },
>> + { "__GIMPLE",RID_GIMPLE,0 },
>>{ "__has_nothrow_constructor", RID_HAS_NOTHROW_CONSTRUCTOR, D_CXXONLY },
>>{ "__has_nothrow_copy", RID_HAS_NOTHROW_COPY, D_CXXONLY },
>>{ "__has_trivial_assign", RID_HAS_TRIVIAL_ASSIGN, D_CXXONLY },
>> @@ -12393,6 +12394,7 @@ keyword_is_function_specifier (enum rid keyword)
>> case RID_NORETURN:
>> case RID_VIRTUAL:
>> case RID_EXPLICIT:
>> +case RID_GIMPLE:
>>return true;
>> default:
>>return false;
>> diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
>> index 663e457..a91665f 100644
>> --- a/gcc/c-family/c-common.h
>> +++ b/gcc/c-family/c-common.h
>> @@ -64,10 +64,10 @@ enum rid
>>/* Modifiers: */
>>/* C, in empirical order of frequency. */
>>RID_STATIC = 0,
>> - RID_UNSIGNED, RID_LONG,RID_CONST, RID_EXTERN,
>> - RID_REGISTER, RID_TYPEDEF, RID_SHORT, RID_INLINE,
>> - RID_VOLATILE, RID_SIGNED, RID_AUTO, RID_RESTRICT,
>> - RID_NORETURN, RID_ATOMIC,
>> + RID_UNSIGNED, RID_LONG, RID_CONST, RID_EXTERN,
>> + RID_GIMPLE,RID_REGISTER, RID_TYPEDEF, RID_SHORT,
>> + RID_INLINE,RID_VOLATILE, RID_SIGNED, RID_AUTO,
>> + RID_RESTRICT, RID_NORETURN, RID_ATOMIC,
>>
>>/* C extensions */
>>RID_COMPLEX, RID_THREAD, RID_SAT,
>> diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
>> index f0c677b..e690ca3 100644
>> --- a/gcc/c/c-decl.c
>> +++ b/gcc/c/c-decl.c
>> @@ -10401,6 +10401,8 @@ declspecs_add_scspec (source_location loc,
>> case RID_TYPEDEF:
>>n = csc_typedef;
>>break;
>> +case RID_GIMPLE:
>> + break;
>> default:
>>gcc_unreachable ();
>> }
>> diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
>> index bdd669d..266b672 100644
>> --- a/gcc/c/c-parser.c
>> +++ b/gcc/c/c-parser.c
>> @@ -732,6 +732,7 @@ c_token_starts_declspecs (c_token *token)
>> case RID_ALIGNAS:
>> case RID_ATOMIC:
>> case RID_AUTO_TYPE:
>> +case RID_GIMPLE:
>>return true;
>> default:
>>if (token->keyword >= RID_FIRST_INT_N
>> @@ -2461,6 +2462,7 @@ c_parser_declspecs (c_parser *parser, struct
>> c_declspecs *specs,
>> case RID_NORETURN:
>> case RID_AUTO:
>> case RID_THREAD:
>> +case RID_GIMPLE:
>>if (!scspec_ok)
>> goto out;
>>attrs_ok = true;
>> @@ -3960,6 +3962,7 @@ c_parser_attribute_any_word (c_parser *parser)
>> case RID_INT_N_1:
>> case RID_INT_N_2:
>> case RID_INT_N_3:
>> +case RID_GIMPLE:
>>ok = true;
>>break;
>> default:
>>
>>
>>
>> After recognizing __GIMPLE, I am planning to call gimple_fn_parser
>> function which will parse gimple body.
>> For pass manager, basic idea is to introduce new member to struct
>> function as pass_list and modify function execute_pass_list to run
>> only passes in pass list.
>>
>>
>>
>> Thanks,
>> Prasad Ghangal
Re: [gimplefe] Regarding command line option handling
On 4 May 2016 at 15:54, Richard Biener wrote:
> On Wed, May 4, 2016 at 11:46 AM, Prasad Ghangal
> wrote:
>> On 4 May 2016 at 13:02, Richard Biener wrote:
>>> On Wed, May 4, 2016 at 8:41 AM, Prasad Ghangal
>>> wrote:
>>>> Hi !
>>>> Currently I am trying to introduce new command line option -fgimple,
>>>> for that I am adding this to c.opt
>>>>
>>>> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
>>>> index 4f86876..88e55c6 100644
>>>> --- a/gcc/c-family/c.opt
>>>> +++ b/gcc/c-family/c.opt
>>>> @@ -66,6 +66,10 @@ C ObjC C++ ObjC++ Separate Alias(d)
>>>> -dump=
>>>> C ObjC C++ ObjC++ Joined Alias(d)
>>>>
>>>> +fgimple
>>>> +C Var(flag_gimple) Init(0)
>>>> +Enable parsing GIMPLE
>>>> +
>>>> -imacros
>>>> C ObjC C++ ObjC++ Separate Alias(imacros) MissingArgError(missing
>>>> filename after %qs)
>>>>
>>>>
>>>> But I am getting error as - "gcc: error: unrecognized command line
>>>> option ‘-fgimple ’; did you mean ‘-fgimple ’?"
>>>>
>>>> I am unable to find where to handle it.
>>>
>>> Did you properly re-build gcc after that change? It should work just fine.
>>>
>>> Richard.
>>>
>>
>> Yes, I did stage 1 build on latest revision. Still it's giving this
>> strange error - "gcc: error: unrecognized command line option
>> ‘-fgimple’; did you mean ‘-fgimple’?"
>
> The error is indeed strage. W/o the patch I get
>
>> ./xgcc -B. -fgimple -S t.i
> xgcc: error: unrecognized command line option '-fgimple'; did you mean
> '--compile'?
>
> and with it (re-building cc1 and xgcc inside gcc/ of my dev-tree)
>
>> ./xgcc -B. -fgimple -S t.i
> (no error)
>
> so it works fine for me. Note that 'gcc' inside the build tree is called
> xgcc.
>
Yes, it works for $build/gcc/cc1 but not for $prefix/bin/gcc i.e.
after installing
> Richard.
>
>
>>
>>>>
>>>>
>>>> Till now I am able to JUST parse __GIMPLE keyword
>>>>
>>>> diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
>>>> index cae2faf..1ccb4d6 100644
>>>> --- a/gcc/c-family/c-common.c
>>>> +++ b/gcc/c-family/c-common.c
>>>> @@ -468,6 +468,7 @@ const struct c_common_resword c_common_reswords[] =
>>>>{ "__extension__",RID_EXTENSION,0 },
>>>>{ "__func__",RID_C99_FUNCTION_NAME, 0 },
>>>>{ "__has_nothrow_assign", RID_HAS_NOTHROW_ASSIGN, D_CXXONLY },
>>>> + { "__GIMPLE",RID_GIMPLE,0 },
>>>>{ "__has_nothrow_constructor", RID_HAS_NOTHROW_CONSTRUCTOR, D_CXXONLY },
>>>>{ "__has_nothrow_copy", RID_HAS_NOTHROW_COPY, D_CXXONLY },
>>>>{ "__has_trivial_assign", RID_HAS_TRIVIAL_ASSIGN, D_CXXONLY },
>>>> @@ -12393,6 +12394,7 @@ keyword_is_function_specifier (enum rid keyword)
>>>> case RID_NORETURN:
>>>> case RID_VIRTUAL:
>>>> case RID_EXPLICIT:
>>>> +case RID_GIMPLE:
>>>>return true;
>>>> default:
>>>>return false;
>>>> diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
>>>> index 663e457..a91665f 100644
>>>> --- a/gcc/c-family/c-common.h
>>>> +++ b/gcc/c-family/c-common.h
>>>> @@ -64,10 +64,10 @@ enum rid
>>>>/* Modifiers: */
>>>>/* C, in empirical order of frequency. */
>>>>RID_STATIC = 0,
>>>> - RID_UNSIGNED, RID_LONG,RID_CONST, RID_EXTERN,
>>>> - RID_REGISTER, RID_TYPEDEF, RID_SHORT, RID_INLINE,
>>>> - RID_VOLATILE, RID_SIGNED, RID_AUTO, RID_RESTRICT,
>>>> - RID_NORETURN, RID_ATOMIC,
>>>> + RID_UNSIGNED, RID_LONG, RID_CONST, RID_EXTERN,
>>>> + RID_GIMPLE,RID_REGISTER, RID_TYPEDEF, RID_SHORT,
>>>> + RID_INLINE,RID_VOLATILE, RID_SIGNED, RID_AUTO,
>>>> + RID_RESTRICT, RID_NORETURN, RID_ATOMIC,
>>>>
>>>>/* C extensions */
>>>>RID_COMPLEX, RID_THREAD, RID_SAT,
>>>> diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
>>>> index f0c677b..e690ca3 100644
>>>> --- a/gcc/c/c-decl.c
>>>> +++ b/gcc/c/c-decl.c
>>>> @@ -10401,6 +10401,8 @@ declspecs_add_scspec (source_location loc,
>&g
Re: [gimplefe] Regarding command line option handling
On 6 May 2016 at 16:09, Richard Biener wrote:
> On Wed, May 4, 2016 at 4:29 PM, Prasad Ghangal
> wrote:
>> On 4 May 2016 at 15:54, Richard Biener wrote:
>>> On Wed, May 4, 2016 at 11:46 AM, Prasad Ghangal
>>> wrote:
>>>> On 4 May 2016 at 13:02, Richard Biener wrote:
>>>>> On Wed, May 4, 2016 at 8:41 AM, Prasad Ghangal
>>>>> wrote:
>>>>>> Hi !
>>>>>> Currently I am trying to introduce new command line option -fgimple,
>>>>>> for that I am adding this to c.opt
>>>>>>
>>>>>> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
>>>>>> index 4f86876..88e55c6 100644
>>>>>> --- a/gcc/c-family/c.opt
>>>>>> +++ b/gcc/c-family/c.opt
>>>>>> @@ -66,6 +66,10 @@ C ObjC C++ ObjC++ Separate Alias(d)
>>>>>> -dump=
>>>>>> C ObjC C++ ObjC++ Joined Alias(d)
>>>>>>
>>>>>> +fgimple
>>>>>> +C Var(flag_gimple) Init(0)
>>>>>> +Enable parsing GIMPLE
>>>>>> +
>>>>>> -imacros
>>>>>> C ObjC C++ ObjC++ Separate Alias(imacros) MissingArgError(missing
>>>>>> filename after %qs)
>>>>>>
>>>>>>
>>>>>> But I am getting error as - "gcc: error: unrecognized command line
>>>>>> option ‘-fgimple ’; did you mean ‘-fgimple ’?"
>>>>>>
>>>>>> I am unable to find where to handle it.
>>>>>
>>>>> Did you properly re-build gcc after that change? It should work just
>>>>> fine.
>>>>>
>>>>> Richard.
>>>>>
>>>>
>>>> Yes, I did stage 1 build on latest revision. Still it's giving this
>>>> strange error - "gcc: error: unrecognized command line option
>>>> ‘-fgimple’; did you mean ‘-fgimple’?"
>>>
>>> The error is indeed strage. W/o the patch I get
>>>
>>>> ./xgcc -B. -fgimple -S t.i
>>> xgcc: error: unrecognized command line option '-fgimple'; did you mean
>>> '--compile'?
>>>
>>> and with it (re-building cc1 and xgcc inside gcc/ of my dev-tree)
>>>
>>>> ./xgcc -B. -fgimple -S t.i
>>> (no error)
>>>
>>> so it works fine for me. Note that 'gcc' inside the build tree is called
>>> xgcc.
>>>
>>
>> Yes, it works for $build/gcc/cc1 but not for $prefix/bin/gcc i.e.
>> after installing
>
> Does it work for $build/gcc/xgcc?
>
No. It doesn't work for me. I even tried bootstrapped build-install,
still same issue.
> Richard.
>
>>> Richard.
>>>
>>>
>>>>
>>>>>>
>>>>>>
>>>>>> Till now I am able to JUST parse __GIMPLE keyword
>>>>>>
>>>>>> diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
>>>>>> index cae2faf..1ccb4d6 100644
>>>>>> --- a/gcc/c-family/c-common.c
>>>>>> +++ b/gcc/c-family/c-common.c
>>>>>> @@ -468,6 +468,7 @@ const struct c_common_resword c_common_reswords[] =
>>>>>>{ "__extension__",RID_EXTENSION,0 },
>>>>>>{ "__func__",RID_C99_FUNCTION_NAME, 0 },
>>>>>>{ "__has_nothrow_assign", RID_HAS_NOTHROW_ASSIGN, D_CXXONLY },
>>>>>> + { "__GIMPLE",RID_GIMPLE,0 },
>>>>>>{ "__has_nothrow_constructor", RID_HAS_NOTHROW_CONSTRUCTOR, D_CXXONLY
>>>>>> },
>>>>>>{ "__has_nothrow_copy", RID_HAS_NOTHROW_COPY, D_CXXONLY },
>>>>>>{ "__has_trivial_assign", RID_HAS_TRIVIAL_ASSIGN, D_CXXONLY },
>>>>>> @@ -12393,6 +12394,7 @@ keyword_is_function_specifier (enum rid keyword)
>>>>>> case RID_NORETURN:
>>>>>> case RID_VIRTUAL:
>>>>>> case RID_EXPLICIT:
>>>>>> +case RID_GIMPLE:
>>>>>>return true;
>>>>>> default:
>>>>>>return false;
>>>>>> diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
>>>>>> index 663e457..a91665f 100644
>>>>>> --- a/gcc/c-family/c-common.h
>>>>>> +++ b/gcc/c-family/c-common.h
>>>>>> @@ -64,10 +64,1
[GSoC] file copyright assignment
Hi, I am selected for Google Summer of Code 2016 under GNU-GCC organization. In order to start working on the project, I need to file copyright assignment. So I would like to receive required forms for the same. Thanks, Prasad Ghangal
Re: [gimplefe] Regarding command line option handling
On 7 May 2016 at 16:37, Richard Biener wrote:
> On May 6, 2016 3:14:03 PM GMT+02:00, Prasad Ghangal
> wrote:
>>On 6 May 2016 at 16:09, Richard Biener
>>wrote:
>>> On Wed, May 4, 2016 at 4:29 PM, Prasad Ghangal
>> wrote:
>>>> On 4 May 2016 at 15:54, Richard Biener
>>wrote:
>>>>> On Wed, May 4, 2016 at 11:46 AM, Prasad Ghangal
>>>>> wrote:
>>>>>> On 4 May 2016 at 13:02, Richard Biener
>> wrote:
>>>>>>> On Wed, May 4, 2016 at 8:41 AM, Prasad Ghangal
>> wrote:
>>>>>>>> Hi !
>>>>>>>> Currently I am trying to introduce new command line option
>>-fgimple,
>>>>>>>> for that I am adding this to c.opt
>>>>>>>>
>>>>>>>> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
>>>>>>>> index 4f86876..88e55c6 100644
>>>>>>>> --- a/gcc/c-family/c.opt
>>>>>>>> +++ b/gcc/c-family/c.opt
>>>>>>>> @@ -66,6 +66,10 @@ C ObjC C++ ObjC++ Separate Alias(d)
>>>>>>>> -dump=
>>>>>>>> C ObjC C++ ObjC++ Joined Alias(d)
>>>>>>>>
>>>>>>>> +fgimple
>>>>>>>> +C Var(flag_gimple) Init(0)
>>>>>>>> +Enable parsing GIMPLE
>>>>>>>> +
>>>>>>>> -imacros
>>>>>>>> C ObjC C++ ObjC++ Separate Alias(imacros)
>>MissingArgError(missing
>>>>>>>> filename after %qs)
>>>>>>>>
>>>>>>>>
>>>>>>>> But I am getting error as - "gcc: error: unrecognized command
>>line
>>>>>>>> option ‘-fgimple ’; did you mean ‘-fgimple ’?"
>>>>>>>>
>>>>>>>> I am unable to find where to handle it.
>>>>>>>
>>>>>>> Did you properly re-build gcc after that change? It should work
>>just fine.
>>>>>>>
>>>>>>> Richard.
>>>>>>>
>>>>>>
>>>>>> Yes, I did stage 1 build on latest revision. Still it's giving
>>this
>>>>>> strange error - "gcc: error: unrecognized command line option
>>>>>> ‘-fgimple’; did you mean ‘-fgimple’?"
>>>>>
>>>>> The error is indeed strage. W/o the patch I get
>>>>>
>>>>>> ./xgcc -B. -fgimple -S t.i
>>>>> xgcc: error: unrecognized command line option '-fgimple'; did you
>>mean
>>>>> '--compile'?
>>>>>
>>>>> and with it (re-building cc1 and xgcc inside gcc/ of my dev-tree)
>>>>>
>>>>>> ./xgcc -B. -fgimple -S t.i
>>>>> (no error)
>>>>>
>>>>> so it works fine for me. Note that 'gcc' inside the build tree is
>>called xgcc.
>>>>>
>>>>
>>>> Yes, it works for $build/gcc/cc1 but not for $prefix/bin/gcc i.e.
>>>> after installing
>>>
>>> Does it work for $build/gcc/xgcc?
>>>
>>
>>No. It doesn't work for me. I even tried bootstrapped build-install,
>>still same issue.
>
> That's strange as it works for me just fine.
>
After reinstalling libgmp, libmpfr and libmpc it worked for me.
Thanks
> Btw., if you didn't already start the process to file a copyright assignment
> with the FSF please do so now as it can take quite some time. You can ask
> for forms at ass...@gnu.org but I remember Ian also having access to them
> (CCed).
>
> Thanks,
> Richard.
>
>>> Richard.
>>>
>>>>> Richard.
>>>>>
>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Till now I am able to JUST parse __GIMPLE keyword
>>>>>>>>
>>>>>>>> diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
>>>>>>>> index cae2faf..1ccb4d6 100644
>>>>>>>> --- a/gcc/c-family/c-common.c
>>>>>>>> +++ b/gcc/c-family/c-common.c
>>>>>>>> @@ -468,6 +468,7 @@ const struct c_common_resword
>>c_common_reswords[] =
>>>>>>>>{ "__extension__",RID_EXTENSION,0 },
>>>>>>>>{ "__func__",RID_C99_FUNCTIO
[gimplefe] Parsing __GIMPLE function body
Hi,
As David suggested in his rtlfe patch,
this patch recognizes __GIMPLE keyword and switches to
c_parser_parse_gimple_body by providing -fgimple option.
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 4568cf6..41a8f05 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -511,6 +511,7 @@ const struct c_common_resword c_common_reswords[] =
{ "__underlying_type", RID_UNDERLYING_TYPE, D_CXXONLY },
{ "__volatile",RID_VOLATILE,0 },
{ "__volatile__",RID_VOLATILE,0 },
+ { "__GIMPLE",RID_GIMPLE,0 },
{ "alignas",RID_ALIGNAS,D_CXXONLY | D_CXX11 | D_CXXWARN },
{ "alignof",RID_ALIGNOF,D_CXXONLY | D_CXX11 | D_CXXWARN },
{ "asm",RID_ASM,D_ASM },
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index 0295532..23a401d 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -104,6 +104,9 @@ enum rid
RID_DFLOAT32, RID_DFLOAT64, RID_DFLOAT128,
RID_FRACT, RID_ACCUM, RID_AUTO_TYPE, RID_BUILTIN_CALL_WITH_STATIC_CHAIN,
+ /* "__GIMPLE", for the GIMPLE-parsing extension to the C frontend. */
+ RID_GIMPLE,
+
/* C11 */
RID_ALIGNAS, RID_GENERIC,
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 918df16..8ab56af 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -200,6 +200,10 @@ F
Driver C ObjC C++ ObjC++ Joined Separate MissingArgError(missing path
after %qs)
-F Add to the end of the main framework include path.
+fgimple
+C Var(flag_gimple) Init(0)
+Enable parsing GIMPLE
+
H
C ObjC C++ ObjC++
Print the name of header files as they are used.
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 1cf4fb4..c5a4d3f 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -1396,6 +1396,7 @@ static bool c_parser_cilk_verify_simd (c_parser
*, enum pragma_context);
static tree c_parser_array_notation (location_t, c_parser *, tree, tree);
static tree c_parser_cilk_clause_vectorlength (c_parser *, tree, bool);
static void c_parser_cilk_grainsize (c_parser *, bool *);
+static void c_parser_parse_gimple_body (c_parser *parser);
/* Parse a translation unit (C90 6.7, C99 6.9).
@@ -1638,6 +1639,7 @@ c_parser_declaration_or_fndef (c_parser *parser,
bool fndef_ok,
tree all_prefix_attrs;
bool diagnosed_no_specs = false;
location_t here = c_parser_peek_token (parser)->location;
+ bool gimple_body_p = false;
if (static_assert_ok
&& c_parser_next_token_is_keyword (parser, RID_STATIC_ASSERT))
@@ -1687,6 +1689,17 @@ c_parser_declaration_or_fndef (c_parser
*parser, bool fndef_ok,
c_parser_skip_to_end_of_block_or_statement (parser);
return;
}
+
+ if (c_parser_next_token_is (parser, CPP_KEYWORD))
+{
+ c_token *kw_token = c_parser_peek_token (parser);
+ if (kw_token->keyword == RID_GIMPLE)
+{
+ gimple_body_p = true;
+ c_parser_consume_token (parser);
+}
+}
+
finish_declspecs (specs);
bool auto_type_p = specs->typespec_word == cts_auto_type;
if (c_parser_next_token_is (parser, CPP_SEMICOLON))
@@ -2102,6 +2115,14 @@ c_parser_declaration_or_fndef (c_parser
*parser, bool fndef_ok,
oacc_routine_clauses, false, first, true);
DECL_STRUCT_FUNCTION (current_function_decl)->function_start_locus
= c_parser_peek_token (parser)->location;
+
+ if (gimple_body_p && flag_gimple)
+{
+ c_parser_parse_gimple_body (parser);
+ finish_function ();
+ return;
+}
+
fnbody = c_parser_compound_statement (parser);
if (flag_cilkplus && contains_array_notation_expr (fnbody))
fnbody = expand_array_notation_exprs (fnbody);
@@ -2123,7 +2144,7 @@ c_parser_declaration_or_fndef (c_parser *parser,
bool fndef_ok,
add_stmt (fnbody);
finish_function ();
}
-
+
timevar_pop (tv);
break;
}
@@ -18055,4 +18076,23 @@ c_parser_array_notation (location_t loc,
c_parser *parser, tree initial_index,
return value_tree;
}
+/* Parse the body of a function declaration marked with "__GIMPLE". */
+
+void
+c_parser_parse_gimple_body (c_parser *parser)
+{
+ if (!c_parser_require (parser, CPP_OPEN_BRACE, "expected %<{%>"))
+return;
+
+ location_t loc1 = c_parser_peek_token (parser)->location;
+ inform (loc1, "start of GIMPLE");
+
+ while (c_parser_next_token_is_not (parser, CPP_CLOSE_BRACE))
+{
+c_parser_consume_token (parser);
+}
+
+ c_parser_consume_token (parser);
+}
+
#include "gt-c-c-parser.h"
GIMPLE function body consists of GIMPLE statements. For parsing GIMPLE
function body, we need to populate gimple body with gimple statements
which will emit GIMPLE as it is.
I would like to hear suggestions about how can I emit GIMPLE directly from FE.
Thanks,
Prasad Ghangal
Re: [gimplefe] Parsing __GIMPLE function body
On 1 June 2016 at 15:19, Richard Biener wrote:
> On Wed, Jun 1, 2016 at 9:19 AM, Prathamesh Kulkarni
> wrote:
>> On 30 May 2016 at 20:45, Prasad Ghangal wrote:
>>> Hi,
>>>
>>> As David suggested in his rtlfe patch,
>>> this patch recognizes __GIMPLE keyword and switches to
>>> c_parser_parse_gimple_body by providing -fgimple option.
>>>
>>>
>>> diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
>>> index 4568cf6..41a8f05 100644
>>> --- a/gcc/c-family/c-common.c
>>> +++ b/gcc/c-family/c-common.c
>>> @@ -511,6 +511,7 @@ const struct c_common_resword c_common_reswords[] =
>>>{ "__underlying_type", RID_UNDERLYING_TYPE, D_CXXONLY },
>>>{ "__volatile",RID_VOLATILE,0 },
>>>{ "__volatile__",RID_VOLATILE,0 },
>>> + { "__GIMPLE",RID_GIMPLE,0 },
>>>{ "alignas",RID_ALIGNAS,D_CXXONLY | D_CXX11 | D_CXXWARN },
>>>{ "alignof",RID_ALIGNOF,D_CXXONLY | D_CXX11 | D_CXXWARN },
>>>{ "asm",RID_ASM,D_ASM },
>>> diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
>>> index 0295532..23a401d 100644
>>> --- a/gcc/c-family/c-common.h
>>> +++ b/gcc/c-family/c-common.h
>>> @@ -104,6 +104,9 @@ enum rid
>>>RID_DFLOAT32, RID_DFLOAT64, RID_DFLOAT128,
>>>RID_FRACT, RID_ACCUM, RID_AUTO_TYPE, RID_BUILTIN_CALL_WITH_STATIC_CHAIN,
>>>
>>> + /* "__GIMPLE", for the GIMPLE-parsing extension to the C frontend. */
>>> + RID_GIMPLE,
>>> +
>>>/* C11 */
>>>RID_ALIGNAS, RID_GENERIC,
>>>
>>> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
>>> index 918df16..8ab56af 100644
>>> --- a/gcc/c-family/c.opt
>>> +++ b/gcc/c-family/c.opt
>>> @@ -200,6 +200,10 @@ F
>>> Driver C ObjC C++ ObjC++ Joined Separate MissingArgError(missing path
>>> after %qs)
>>> -F Add to the end of the main framework include path.
>>>
>>> +fgimple
>>> +C Var(flag_gimple) Init(0)
>>> +Enable parsing GIMPLE
>>> +
>>> H
>>> C ObjC C++ ObjC++
>>> Print the name of header files as they are used.
>>> diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
>>> index 1cf4fb4..c5a4d3f 100644
>>> --- a/gcc/c/c-parser.c
>>> +++ b/gcc/c/c-parser.c
>>> @@ -1396,6 +1396,7 @@ static bool c_parser_cilk_verify_simd (c_parser
>>> *, enum pragma_context);
>>> static tree c_parser_array_notation (location_t, c_parser *, tree, tree);
>>> static tree c_parser_cilk_clause_vectorlength (c_parser *, tree, bool);
>>> static void c_parser_cilk_grainsize (c_parser *, bool *);
>>> +static void c_parser_parse_gimple_body (c_parser *parser);
>>>
>>> /* Parse a translation unit (C90 6.7, C99 6.9).
>>>
>>> @@ -1638,6 +1639,7 @@ c_parser_declaration_or_fndef (c_parser *parser,
>>> bool fndef_ok,
>>>tree all_prefix_attrs;
>>>bool diagnosed_no_specs = false;
>>>location_t here = c_parser_peek_token (parser)->location;
>>> + bool gimple_body_p = false;
>>>
>>>if (static_assert_ok
>>>&& c_parser_next_token_is_keyword (parser, RID_STATIC_ASSERT))
>>> @@ -1687,6 +1689,17 @@ c_parser_declaration_or_fndef (c_parser
>>> *parser, bool fndef_ok,
>>>c_parser_skip_to_end_of_block_or_statement (parser);
>>>return;
>>> }
>>> +
>>> + if (c_parser_next_token_is (parser, CPP_KEYWORD))
>>> +{
>>> + c_token *kw_token = c_parser_peek_token (parser);
>>> + if (kw_token->keyword == RID_GIMPLE)
>>> +{
>>> + gimple_body_p = true;
>>> + c_parser_consume_token (parser);
>>> +}
>>> +}
>>> +
>>>finish_declspecs (specs);
>>>bool auto_type_p = specs->typespec_word == cts_auto_type;
>>>if (c_parser_next_token_is (parser, CPP_SEMICOLON))
>>> @@ -2102,6 +2115,14 @@ c_parser_declaration_or_fndef (c_parser
>>> *parser, bool fndef_ok,
>>> oacc_routine_clauses, false, first, true);
>>>DECL_STRUCT_FUNCTION (current_function_decl)->function_start_locus
>>> = c_parser_peek_token (parser)->location;
>>> +
>>> + if (gimple_body_p && flag_gimple)
>>> +{
>>> + c_parser_
Re: [gimplefe] Parsing __GIMPLE function body
Hi,
This patch parses simple assignment statement
int a;
void __GIMPLE foo()
{
a = 1;
}
but it does not produce gimple dump. In debugging I found that
cfun->gimple_body is not NULL and it contains GIMPLE_ASSIGN statement.
Am I missing something ?
Thanks,
Prasad Ghangal
On 31 May 2016 at 15:57, Richard Biener wrote:
> On Mon, May 30, 2016 at 5:15 PM, Prasad Ghangal
> wrote:
>> Hi,
>>
>> As David suggested in his rtlfe patch,
>> this patch recognizes __GIMPLE keyword and switches to
>> c_parser_parse_gimple_body by providing -fgimple option.
>>
>>
>> diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
>> index 4568cf6..41a8f05 100644
>> --- a/gcc/c-family/c-common.c
>> +++ b/gcc/c-family/c-common.c
>> @@ -511,6 +511,7 @@ const struct c_common_resword c_common_reswords[] =
>>{ "__underlying_type", RID_UNDERLYING_TYPE, D_CXXONLY },
>>{ "__volatile",RID_VOLATILE,0 },
>>{ "__volatile__",RID_VOLATILE,0 },
>> + { "__GIMPLE",RID_GIMPLE,0 },
>
> I think we need a D_GIMPLE_ONLY flag which disables this reserved word
> when -fgimple is not
> in effect. That's something to put on a list of TODOs once everything
> else works fine (it's not
> high priority but a requirement to merge to trunk). For now you can
> at least put D_CONLY there
> (as -fgimple is a C only flag).
>
>>{ "alignas",RID_ALIGNAS,D_CXXONLY | D_CXX11 | D_CXXWARN },
>>{ "alignof",RID_ALIGNOF,D_CXXONLY | D_CXX11 | D_CXXWARN },
>>{ "asm",RID_ASM,D_ASM },
>> diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
>> index 0295532..23a401d 100644
>> --- a/gcc/c-family/c-common.h
>> +++ b/gcc/c-family/c-common.h
>> @@ -104,6 +104,9 @@ enum rid
>>RID_DFLOAT32, RID_DFLOAT64, RID_DFLOAT128,
>>RID_FRACT, RID_ACCUM, RID_AUTO_TYPE, RID_BUILTIN_CALL_WITH_STATIC_CHAIN,
>>
>> + /* "__GIMPLE", for the GIMPLE-parsing extension to the C frontend. */
>> + RID_GIMPLE,
>> +
>>/* C11 */
>>RID_ALIGNAS, RID_GENERIC,
>>
>> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
>> index 918df16..8ab56af 100644
>> --- a/gcc/c-family/c.opt
>> +++ b/gcc/c-family/c.opt
>> @@ -200,6 +200,10 @@ F
>> Driver C ObjC C++ ObjC++ Joined Separate MissingArgError(missing path
>> after %qs)
>> -F Add to the end of the main framework include path.
>>
>> +fgimple
>> +C Var(flag_gimple) Init(0)
>> +Enable parsing GIMPLE
>> +
>> H
>> C ObjC C++ ObjC++
>> Print the name of header files as they are used.
>> diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
>> index 1cf4fb4..c5a4d3f 100644
>> --- a/gcc/c/c-parser.c
>> +++ b/gcc/c/c-parser.c
>> @@ -1396,6 +1396,7 @@ static bool c_parser_cilk_verify_simd (c_parser
>> *, enum pragma_context);
>> static tree c_parser_array_notation (location_t, c_parser *, tree, tree);
>> static tree c_parser_cilk_clause_vectorlength (c_parser *, tree, bool);
>> static void c_parser_cilk_grainsize (c_parser *, bool *);
>> +static void c_parser_parse_gimple_body (c_parser *parser);
>>
>> /* Parse a translation unit (C90 6.7, C99 6.9).
>>
>> @@ -1638,6 +1639,7 @@ c_parser_declaration_or_fndef (c_parser *parser,
>> bool fndef_ok,
>>tree all_prefix_attrs;
>>bool diagnosed_no_specs = false;
>>location_t here = c_parser_peek_token (parser)->location;
>> + bool gimple_body_p = false;
>>
>>if (static_assert_ok
>>&& c_parser_next_token_is_keyword (parser, RID_STATIC_ASSERT))
>> @@ -1687,6 +1689,17 @@ c_parser_declaration_or_fndef (c_parser
>> *parser, bool fndef_ok,
>>c_parser_skip_to_end_of_block_or_statement (parser);
>>return;
>> }
>> +
>> + if (c_parser_next_token_is (parser, CPP_KEYWORD))
>> +{
>> + c_token *kw_token = c_parser_peek_token (parser);
>> + if (kw_token->keyword == RID_GIMPLE)
>> +{
>> + gimple_body_p = true;
>> + c_parser_consume_token (parser);
>> +}
>> +}
>> +
>>finish_declspecs (specs);
>>bool auto_type_p = specs->typespec_word == cts_auto_type;
>>if (c_parser_next_token_is (parser, CPP_SEMICOLON))
>> @@ -2102,6 +2115,14 @@ c_parser_declaration_or_fndef (c_parser
>> *parser, bool fndef_ok,
>> oacc_routine_clauses, false, first, true);
>>DECL_STRUCT_FUNCTION (current_function_decl)->funct
[gimplefe] hacking pass manager
Hi,
I tried hacking pass manager to execute only given passes. For this I
am adding new member as opt_pass *custom_pass_list to the function
structure to store passes need to execute and providing the
custom_pass_list to execute_pass_list() function instead of all passes
for test case like-
int a;
void __GIMPLE (execute ("tree-ccp1", "tree-fre1")) foo()
{
bb_1:
a = 1 + a;
}
it will execute only given passes i.e. ccp1 and fre1 pass on the function
and for test case like -
int a;
void __GIMPLE (startwith ("tree-ccp1")) foo()
{
bb_1:
a = 1 + a;
}
it will act as a entry point to the pipeline and will execute passes
starting from given pass.
Thanks,
Prasad Ghangal
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 4568cf6..f2e62ca 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -511,6 +511,7 @@ const struct c_common_resword c_common_reswords[] =
{ "__underlying_type", RID_UNDERLYING_TYPE, D_CXXONLY },
{ "__volatile", RID_VOLATILE, 0 },
{ "__volatile__",RID_VOLATILE, 0 },
+ { "__GIMPLE",RID_GIMPLE, D_CONLY },
{ "alignas", RID_ALIGNAS,D_CXXONLY | D_CXX11 | D_CXXWARN },
{ "alignof", RID_ALIGNOF,D_CXXONLY | D_CXX11 | D_CXXWARN },
{ "asm", RID_ASM,D_ASM },
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index 0295532..23a401d 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -104,6 +104,9 @@ enum rid
RID_DFLOAT32, RID_DFLOAT64, RID_DFLOAT128,
RID_FRACT, RID_ACCUM, RID_AUTO_TYPE, RID_BUILTIN_CALL_WITH_STATIC_CHAIN,
+ /* "__GIMPLE", for the GIMPLE-parsing extension to the C frontend. */
+ RID_GIMPLE,
+
/* C11 */
RID_ALIGNAS, RID_GENERIC,
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 918df16..8ab56af 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -200,6 +200,10 @@ F
Driver C ObjC C++ ObjC++ Joined Separate MissingArgError(missing path after
%qs)
-FAdd to the end of the main framework include path.
+fgimple
+C Var(flag_gimple) Init(0)
+Enable parsing GIMPLE
+
H
C ObjC C++ ObjC++
Print the name of header files as they are used.
diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index d79802e..d498f19 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -9154,6 +9154,7 @@ finish_function (void)
invoke_plugin_callbacks (PLUGIN_FINISH_PARSE_FUNCTION,
current_function_decl);
current_function_decl = NULL;
}
+
/* Check the declarations given in a for-loop for satisfying the C99
constraints. If exactly one such decl is found, return it. LOC is
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index bca8653..2d83281 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -58,6 +58,14 @@ along with GCC; see the file COPYING3. If not see
#include "c-family/c-indentation.h"
#include "gimple-expr.h"
#include "context.h"
+#include "tree-pass.h"
+#include "tree-pretty-print.h"
+#include "tree.h"
+#include "basic-block.h"
+#include "gimple.h"
+#include "gimple-pretty-print.h"
+#include "tree-ssa.h"
+#include "pass_manager.h"
/* We need to walk over decls with incomplete struct/union/enum types
after parsing the whole translation unit.
@@ -1396,6 +1404,13 @@ static bool c_parser_cilk_verify_simd (c_parser *, enum
pragma_context);
static tree c_parser_array_notation (location_t, c_parser *, tree, tree);
static tree c_parser_cilk_clause_vectorlength (c_parser *, tree, bool);
static void c_parser_cilk_grainsize (c_parser *, bool *);
+static void c_parser_parse_gimple_body (c_parser *);
+static void c_parser_gimple_compound_statement (c_parser *, gimple_seq *);
+static void c_finish_gimple_expr_stmt (tree, gimple_seq *);
+static void c_parser_gimple_basic_block (c_parser *, gimple_seq *);
+static void c_parser_gimple_expression (c_parser *, gimple_seq *);
+static void c_parser_pass_list (c_parser *, opt_pass **);
+static opt_pass *c_parser_pass_list_params (c_parser *, opt_pass **);
/* Parse a translation unit (C90 6.7, C99 6.9).
@@ -1638,6 +1653,8 @@ c_parser_declaration_or_fndef (c_parser *parser, bool
fndef_ok,
tree all_prefix_attrs;
bool diagnosed_no_specs = false;
location_t here = c_parser_peek_token (parser)->location;
+ bool gimple_body_p = false;
+ opt_pass *pass = NULL;
if (static_assert_ok
&& c_parser_next_token_is_keyword (parser, RID_STATIC_ASSERT))
@@ -1687,6 +1704,20 @@ c_parser_declaration_or_fndef (c_parser *parser, bool
fndef_ok,
c_parser_skip_to_end_of_block_or_statement (parser);
return;
}
+
+ if (c_parser_next_token_is (parser, CPP_KEYWORD))
+{
+ c_token *kw_token = c_parser_peek_token (parser);
+ if (kw_token->keyword == RID_GIMPLE)
+
Re: GIMPLE FE
On 27 June 2016 at 14:16, Richard Biener wrote:
> On Sun, Jun 26, 2016 at 5:55 PM, Prasad Ghangal
> 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 failures1
> /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).
>
I have added -fgimple-debug option which enable producing debug output.
I have also added some test cases to the testsuite and tried running
make check-gcc RUNTESTFLAGS="dg.exp=gimplefe*.c" which gives -
=== gcc tests ===
Schedule of variations:
unix
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 /home/prasad/Workspace/gcc/trunk/gcc/testsuite/config/default.exp
as tool-and-target-specific interface file.
Running /home/prasad/Workspace/gcc/trunk/gcc/testsuite/gcc.dg/dg.exp ...
=== gcc Summary ===
# of expected passes6
/home/prasad/Workspace/gcc/build1/gcc/xgcc version 7.0.0 20160531
(experimental) (GCC)
make[1]: Leaving directory '/home/prasad/Workspace/gcc/build1/gcc'
> 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 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 wrote:
>>>> On Wed, Jun 15, 2016 at 8:47 AM, Prasad Ghangal
>>>> 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 struct
[gimplefe] Parsing PHI functions
Hi, For handling PHI, it expects cfg to be built before. So I was wondering how are we going to handle this? Do we need to build cfg while parsing only? Thanks, Prasad
Re: [gimplefe] hacking pass manager
On 29 June 2016 at 22:15, Richard Biener wrote:
> On June 29, 2016 6:20:29 PM GMT+02:00, Prathamesh Kulkarni
> wrote:
>>On 18 June 2016 at 12:02, Prasad Ghangal
>>wrote:
>>> Hi,
>>>
>>> I tried hacking pass manager to execute only given passes. For this I
>>> am adding new member as opt_pass *custom_pass_list to the function
>>> structure to store passes need to execute and providing the
>>> custom_pass_list to execute_pass_list() function instead of all
>>passes
>>>
>>> for test case like-
>>>
>>> int a;
>>> void __GIMPLE (execute ("tree-ccp1", "tree-fre1")) foo()
>>> {
>>> bb_1:
>>> a = 1 + a;
>>> }
>>>
>>> it will execute only given passes i.e. ccp1 and fre1 pass on the
>>function
>>>
>>> and for test case like -
>>>
>>> int a;
>>> void __GIMPLE (startwith ("tree-ccp1")) foo()
>>> {
>>> bb_1:
>>> a = 1 + a;
>>> }
>>>
>>> it will act as a entry point to the pipeline and will execute passes
>>> starting from given pass.
>>Bike-shedding:
>>Would it make sense to have syntax for defining pass ranges to execute
>>?
>>for instance:
>>void __GIMPLE(execute (pass_start : pass_end))
>>which would execute all the passes within range [pass_start, pass_end],
>>which would be convenient if the range is large.
>
> But it would rely on a particular pass pipeline, f.e. pass-start appearing
> before pass-end.
>
> Currently control doesn't work 100% as it only replaces all_optimizations but
> not lowering passes or early opts, nor IPA opts.
>
Each pass needs GIMPLE in some specific form. So I am letting lowering
and early opt passes to execute. I think we have to execute some
passes (like cfg) anyway to represent GIMPLE into proper form
> Richard.
>
>>Thanks,
>>Prathamesh
>>>
>>>
>>>
>>> Thanks,
>>> Prasad Ghangal
>
>
Re: [gimplefe] Parsing PHI functions
On 29 June 2016 at 12:42, Richard Biener wrote: > On Tue, Jun 28, 2016 at 4:16 PM, Prasad Ghangal > wrote: >> Hi, >> >> For handling PHI, it expects cfg to be built before. So I was >> wondering how are we going to handle this? Do we need to build cfg >> while parsing only? > > For handling PHIs we need to have a CFG in the sense that the GIMPLE PHI > data structures are built in a way to have the PHI argument index correspond > to CFG predecessor edge index. As we'd like to parse phis with args > corresponding > to predecessor block labels, like > > a: > i_1 = 1; > goto p; > > b: > i_2 = 2; > goto p; > > p: > i_3 = __PHI (a: i_1, b: i_2); > > I think that a possibility is to leave those PHIs as internal function > with label / arg > pairs and have CFG construction lower them to real PHIs. > > Of course the parser could as well build a CFG on its own but I think > we should use > the easy way out for now. > > Thus you'd have to modify CFG construction a bit to lower the internal > function calls. Currently I am just building internal call using gimple_build_call_internal_vec (), and detecting (and removing for now) it after edge creation in tree-cfg. I was observing internal-fn.def, do I need to make entry in internal-fn.def and write expand function? > > Richard. >> >> >> >> Thanks, >> Prasad
Re: [gimplefe] Parsing PHI functions
In this patch, I am passing labels and vars with internal function and
handling them in tree-cfg for parsing PHI.
For first label, label_to_block() gives correct basic block and I am
getting proper edges but for other labels the function is giving NULL.
test-case :
void __GIMPLE () foo()
{
int a;
int a_2;
int a_3;
int a_1;
bb_2:
a_2 = 3;
goto bb_4;
bb_3:
a_3 = 6;
goto bb_4;
bb_4:
a_1 = __PHI (bb_2: a_2, bb_3: a_3);
a_1 = a_1 + 1;
return;
}
On 1 July 2016 at 17:33, Richard Biener wrote:
> On Fri, Jul 1, 2016 at 1:57 PM, Prasad Ghangal
> wrote:
>> On 29 June 2016 at 12:42, Richard Biener wrote:
>>> On Tue, Jun 28, 2016 at 4:16 PM, Prasad Ghangal
>>> wrote:
>>>> Hi,
>>>>
>>>> For handling PHI, it expects cfg to be built before. So I was
>>>> wondering how are we going to handle this? Do we need to build cfg
>>>> while parsing only?
>>>
>>> For handling PHIs we need to have a CFG in the sense that the GIMPLE PHI
>>> data structures are built in a way to have the PHI argument index correspond
>>> to CFG predecessor edge index. As we'd like to parse phis with args
>>> corresponding
>>> to predecessor block labels, like
>>>
>>> a:
>>> i_1 = 1;
>>> goto p;
>>>
>>> b:
>>> i_2 = 2;
>>> goto p;
>>>
>>> p:
>>> i_3 = __PHI (a: i_1, b: i_2);
>>>
>>> I think that a possibility is to leave those PHIs as internal function
>>> with label / arg
>>> pairs and have CFG construction lower them to real PHIs.
>>>
>>> Of course the parser could as well build a CFG on its own but I think
>>> we should use
>>> the easy way out for now.
>>>
>>> Thus you'd have to modify CFG construction a bit to lower the internal
>>> function calls.
>>
>> Currently I am just building internal call using
>> gimple_build_call_internal_vec (), and detecting (and removing for
>> now) it after edge creation in tree-cfg. I was observing
>> internal-fn.def, do I need to make entry in internal-fn.def and write
>> expand function?
>
> You should add an entry and a stub expand function (like those
> others that simply have gcc_unreachable in them).
>
> Richard.
>
>>>
>>> Richard.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>> Prasad
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index f2e62ca..138ca4f 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -512,6 +512,7 @@ const struct c_common_resword c_common_reswords[] =
{ "__volatile", RID_VOLATILE, 0 },
{ "__volatile__",RID_VOLATILE, 0 },
{ "__GIMPLE",RID_GIMPLE, D_CONLY },
+ { "__PHI", RID_PHI,D_CONLY},
{ "alignas", RID_ALIGNAS,D_CXXONLY | D_CXX11 | D_CXXWARN },
{ "alignof", RID_ALIGNOF,D_CXXONLY | D_CXX11 | D_CXXWARN },
{ "asm", RID_ASM,D_ASM },
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index 23a401d..ede3549 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -107,6 +107,9 @@ enum rid
/* "__GIMPLE", for the GIMPLE-parsing extension to the C frontend. */
RID_GIMPLE,
+ /* "__PHI", for parsing PHI function in GIMPLE FE */
+ RID_PHI,
+
/* C11 */
RID_ALIGNAS, RID_GENERIC,
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index d8e7ba9..fffe7ea 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -18338,6 +18338,57 @@ c_parser_gimple_expression (c_parser *parser,
gimple_seq *seq)
return;
}
+ if (c_parser_next_token_is_keyword (parser, RID_PHI))
+{
+ c_parser_consume_token (parser);
+
+ if (!c_parser_require (parser, CPP_OPEN_PAREN, "expected %<(%>"))
+ {
+ return;
+ }
+
+ gcall *call_stmt;
+ /* Gimplify internal functions. */
+ tree arg;
+ vec vargs = vNULL;
+
+ if (c_parser_next_token_is (parser, CPP_OPEN_PAREN))
+ c_parser_consume_token (parser);
+
+ while (c_parser_next_token_is_not (parser, CPP_CLOSE_PAREN))
+ {
+ if (c_parser_next_token_is (parser, CPP_NAME) &&
+ c_parser_peek_2nd_token (parser)->type == CPP_COLON)
+ {
+ arg = lookup_label_for_goto (c_parser_peek_token
(parser)->location,
+ c_parser_peek_token (parser)->value);
+ c_parser_consume_token (parser);
+
+ if (c_parser_next_token_is (parser, CPP_COLON))
+ c_parser_consume_token (parser);
+
Re: [gimplefe] Parsing PHI functions
On 4 July 2016 at 15:17, Richard Biener wrote:
> On Sun, Jul 3, 2016 at 9:34 AM, Prasad Ghangal
> wrote:
>> In this patch, I am passing labels and vars with internal function and
>> handling them in tree-cfg for parsing PHI.
>> For first label, label_to_block() gives correct basic block and I am
>> getting proper edges but for other labels the function is giving NULL.
>>
>> test-case :
>>
>> void __GIMPLE () foo()
>> {
>> int a;
>> int a_2;
>> int a_3;
>> int a_1;
>>
>> bb_2:
>> a_2 = 3;
>> goto bb_4;
>>
>> bb_3:
>> a_3 = 6;
>> goto bb_4;
>>
>> bb_4:
>> a_1 = __PHI (bb_2: a_2, bb_3: a_3);
>> a_1 = a_1 + 1;
>> return;
>> }
>>
>
> The issue is probably you lower PHIs after cleanup_tree_cfg is run which may
> end up removing labels. Or it is cleanup_dead_labels in build_gimple_cfg.
Yes, that was due to cleanup_dead_label. It is working after calling
lower_phi_internal_fn just after make_edges
So test case like:
void __GIMPLE () foo()
{
int a;
int a_2;
int a_3;
int a_1;
int a_0;
bb_2:
if (a > 4)
goto bb_3;
else
goto bb_4;
bb_3:
a_2 = 6;
goto bb_5;
bb_4:
a_3 = 99;
goto bb_5;
bb_5:
a_1 = __PHI (bb_3: a_2, bb_4: a_3);
a_0 = a_1 + 1;
return;
}
produces ssa dump as
;; Function foo (foo, funcdef_no=0, decl_uid=1744, cgraph_uid=0, symbol_order=0)
foo ()
{
int a_0;
int a_1;
int a_3;
int a_2;
int a;
bb_2:
if (a_2(D) > 4)
goto (bb_3);
else
goto (bb_4);
bb_3:
a_2_3 = 6;
goto (bb_5);
bb_4:
a_3_5 = 99;
# a_1_1 = PHI
bb_5:
a_0_6 = a_1_1 + 1;
return;
}
and test case like :
void __GIMPLE () foo()
{
int a;
int a_2;
int a_3;
int a_1;
int a_0;
bb_3:
a_2 = 6;
goto bb_5;
bb_4:
a_3 = 99;
goto bb_5;
bb_5:
a_1 = __PHI (bb_3: a_2, bb_4: a_3);
a_0 = a_1 + 1;
return;
}
gets its block with bb_4 label removed as it is unreachable and
produces ssa dump as -
;; Function foo (foo, funcdef_no=0, decl_uid=1744, cgraph_uid=0, symbol_order=0)
foo ()
{
int a_0;
int a_1;
int a_3;
int a_2;
int a;
bb_3:
a_2_2 = 6;
# a_1_1 = PHI
bb_5:
a_0_4 = a_1_1 + 1;
return;
}
I think which is fine(?).
Now ssa pass is producing ssa names for the vars because it expects
them with tree code SSA_NAME. How can we prevent this? Can we convert
VAR_DECL to SSA_NAME ?
>
> Richard.
>
>>
>>
>>
>> On 1 July 2016 at 17:33, Richard Biener wrote:
>>> On Fri, Jul 1, 2016 at 1:57 PM, Prasad Ghangal
>>> wrote:
>>>> On 29 June 2016 at 12:42, Richard Biener
>>>> wrote:
>>>>> On Tue, Jun 28, 2016 at 4:16 PM, Prasad Ghangal
>>>>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> For handling PHI, it expects cfg to be built before. So I was
>>>>>> wondering how are we going to handle this? Do we need to build cfg
>>>>>> while parsing only?
>>>>>
>>>>> For handling PHIs we need to have a CFG in the sense that the GIMPLE PHI
>>>>> data structures are built in a way to have the PHI argument index
>>>>> correspond
>>>>> to CFG predecessor edge index. As we'd like to parse phis with args
>>>>> corresponding
>>>>> to predecessor block labels, like
>>>>>
>>>>> a:
>>>>> i_1 = 1;
>>>>> goto p;
>>>>>
>>>>> b:
>>>>> i_2 = 2;
>>>>> goto p;
>>>>>
>>>>> p:
>>>>> i_3 = __PHI (a: i_1, b: i_2);
>>>>>
>>>>> I think that a possibility is to leave those PHIs as internal function
>>>>> with label / arg
>>>>> pairs and have CFG construction lower them to real PHIs.
>>>>>
>>>>> Of course the parser could as well build a CFG on its own but I think
>>>>> we should use
>>>>> the easy way out for now.
>>>>>
>>>>> Thus you'd have to modify CFG construction a bit to lower the internal
>>>>> function calls.
>>>>
>>>> Currently I am just building internal call using
>>>> gimple_build_call_internal_vec (), and detecting (and removing for
>>>> now) it after edge creation in tree-cfg. I was observing
>>>> internal-fn.def, do I need to make entry in internal-fn.def and write
>>>> expand function?
>>>
>>> You should add an entry and a stub expand function (like those
>>> others that simply have gcc_unreachable in them).
>>>
>&g
Re: [gimplefe] hacking pass manager
On 30 June 2016 at 17:10, Richard Biener wrote:
> On Wed, Jun 29, 2016 at 9:13 PM, Prasad Ghangal
> wrote:
>> On 29 June 2016 at 22:15, Richard Biener wrote:
>>> On June 29, 2016 6:20:29 PM GMT+02:00, Prathamesh Kulkarni
>>> wrote:
>>>>On 18 June 2016 at 12:02, Prasad Ghangal
>>>>wrote:
>>>>> Hi,
>>>>>
>>>>> I tried hacking pass manager to execute only given passes. For this I
>>>>> am adding new member as opt_pass *custom_pass_list to the function
>>>>> structure to store passes need to execute and providing the
>>>>> custom_pass_list to execute_pass_list() function instead of all
>>>>passes
>>>>>
>>>>> for test case like-
>>>>>
>>>>> int a;
>>>>> void __GIMPLE (execute ("tree-ccp1", "tree-fre1")) foo()
>>>>> {
>>>>> bb_1:
>>>>> a = 1 + a;
>>>>> }
>>>>>
>>>>> it will execute only given passes i.e. ccp1 and fre1 pass on the
>>>>function
>>>>>
>>>>> and for test case like -
>>>>>
>>>>> int a;
>>>>> void __GIMPLE (startwith ("tree-ccp1")) foo()
>>>>> {
>>>>> bb_1:
>>>>> a = 1 + a;
>>>>> }
>>>>>
>>>>> it will act as a entry point to the pipeline and will execute passes
>>>>> starting from given pass.
>>>>Bike-shedding:
>>>>Would it make sense to have syntax for defining pass ranges to execute
>>>>?
>>>>for instance:
>>>>void __GIMPLE(execute (pass_start : pass_end))
>>>>which would execute all the passes within range [pass_start, pass_end],
>>>>which would be convenient if the range is large.
>>>
>>> But it would rely on a particular pass pipeline, f.e. pass-start appearing
>>> before pass-end.
>>>
>>> Currently control doesn't work 100% as it only replaces all_optimizations
>>> but not lowering passes or early opts, nor IPA opts.
>>>
>>
>> Each pass needs GIMPLE in some specific form. So I am letting lowering
>> and early opt passes to execute. I think we have to execute some
>> passes (like cfg) anyway to represent GIMPLE into proper form
>
> Yes, that's true. Note that early opt passes only optimize but we need
> pass_build_ssa_passes at least (for into-SSA). For proper unit-testing
> of GIMPLE passes we do need to guard off early opts somehow
> (I guess a simple if (flag_gimple && cfun->custom_pass_list) would do
> that).
>
> Then there is of course the question about IPA passes which I think is
> somewhat harder (one could always disable all IPA passes manually
> via flags of course or finally have a global -fipa/no-ipa like most
> other compilers).
>
Can we iterate through all ipa passes and do -fdisable-ipa-pass or
-fenable-ipa-pass equivalent for each?
Thanks,
Prasad
> Richard.
>
>>> Richard.
>>>
>>>>Thanks,
>>>>Prathamesh
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Prasad Ghangal
>>>
>>>
Re: [gimplefe] hacking pass manager
On 6 July 2016 at 14:24, Richard Biener wrote:
> On Wed, Jul 6, 2016 at 9:51 AM, Prasad Ghangal
> wrote:
>> On 30 June 2016 at 17:10, Richard Biener wrote:
>>> On Wed, Jun 29, 2016 at 9:13 PM, Prasad Ghangal
>>> wrote:
>>>> On 29 June 2016 at 22:15, Richard Biener
>>>> wrote:
>>>>> On June 29, 2016 6:20:29 PM GMT+02:00, Prathamesh Kulkarni
>>>>> wrote:
>>>>>>On 18 June 2016 at 12:02, Prasad Ghangal
>>>>>>wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I tried hacking pass manager to execute only given passes. For this I
>>>>>>> am adding new member as opt_pass *custom_pass_list to the function
>>>>>>> structure to store passes need to execute and providing the
>>>>>>> custom_pass_list to execute_pass_list() function instead of all
>>>>>>passes
>>>>>>>
>>>>>>> for test case like-
>>>>>>>
>>>>>>> int a;
>>>>>>> void __GIMPLE (execute ("tree-ccp1", "tree-fre1")) foo()
>>>>>>> {
>>>>>>> bb_1:
>>>>>>> a = 1 + a;
>>>>>>> }
>>>>>>>
>>>>>>> it will execute only given passes i.e. ccp1 and fre1 pass on the
>>>>>>function
>>>>>>>
>>>>>>> and for test case like -
>>>>>>>
>>>>>>> int a;
>>>>>>> void __GIMPLE (startwith ("tree-ccp1")) foo()
>>>>>>> {
>>>>>>> bb_1:
>>>>>>> a = 1 + a;
>>>>>>> }
>>>>>>>
>>>>>>> it will act as a entry point to the pipeline and will execute passes
>>>>>>> starting from given pass.
>>>>>>Bike-shedding:
>>>>>>Would it make sense to have syntax for defining pass ranges to execute
>>>>>>?
>>>>>>for instance:
>>>>>>void __GIMPLE(execute (pass_start : pass_end))
>>>>>>which would execute all the passes within range [pass_start, pass_end],
>>>>>>which would be convenient if the range is large.
>>>>>
>>>>> But it would rely on a particular pass pipeline, f.e. pass-start
>>>>> appearing before pass-end.
>>>>>
>>>>> Currently control doesn't work 100% as it only replaces all_optimizations
>>>>> but not lowering passes or early opts, nor IPA opts.
>>>>>
>>>>
>>>> Each pass needs GIMPLE in some specific form. So I am letting lowering
>>>> and early opt passes to execute. I think we have to execute some
>>>> passes (like cfg) anyway to represent GIMPLE into proper form
>>>
>>> Yes, that's true. Note that early opt passes only optimize but we need
>>> pass_build_ssa_passes at least (for into-SSA). For proper unit-testing
>>> of GIMPLE passes we do need to guard off early opts somehow
>>> (I guess a simple if (flag_gimple && cfun->custom_pass_list) would do
>>> that).
>>>
>>> Then there is of course the question about IPA passes which I think is
>>> somewhat harder (one could always disable all IPA passes manually
>>> via flags of course or finally have a global -fipa/no-ipa like most
>>> other compilers).
>>>
>> Can we iterate through all ipa passes and do -fdisable-ipa-pass or
>> -fenable-ipa-pass equivalent for each?
>
> We could do that, yes. But let's postpone this issue. I think that
> startwith is going to be most useful and rather than constructing
> a pass list for it "native" support for it in the pass manager is
> likely to produce better results (add a 'startwith' member alongside
> the pass list member and if it is set the pass manager skips all
> passes that do not match 'startwith' and once it reaches it it clears
> the field).
>
> In the future I hope we can get away from a static pass list and more
> towards rule-driven pass execution (we have all those PROP_* stuff
> already but it isn't really used for example). But well, that would be
> a separate GSoC project ;)
>
> IMHO startwith will provide everything needed for unit-testing. We can
> add a flag on whether further passes should be executed or not and
> even a pass list like execute ("ccp1", "fre") can be implemen
Re: [gimplefe] hacking pass manager
On 8 July 2016 at 13:13, Richard Biener wrote:
> On Thu, Jul 7, 2016 at 9:45 PM, Prasad Ghangal
> wrote:
>> On 6 July 2016 at 14:24, Richard Biener wrote:
>>> On Wed, Jul 6, 2016 at 9:51 AM, Prasad Ghangal
>>> wrote:
>>>> On 30 June 2016 at 17:10, Richard Biener
>>>> wrote:
>>>>> On Wed, Jun 29, 2016 at 9:13 PM, Prasad Ghangal
>>>>> wrote:
>>>>>> On 29 June 2016 at 22:15, Richard Biener
>>>>>> wrote:
>>>>>>> On June 29, 2016 6:20:29 PM GMT+02:00, Prathamesh Kulkarni
>>>>>>> wrote:
>>>>>>>>On 18 June 2016 at 12:02, Prasad Ghangal
>>>>>>>>wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I tried hacking pass manager to execute only given passes. For this I
>>>>>>>>> am adding new member as opt_pass *custom_pass_list to the function
>>>>>>>>> structure to store passes need to execute and providing the
>>>>>>>>> custom_pass_list to execute_pass_list() function instead of all
>>>>>>>>passes
>>>>>>>>>
>>>>>>>>> for test case like-
>>>>>>>>>
>>>>>>>>> int a;
>>>>>>>>> void __GIMPLE (execute ("tree-ccp1", "tree-fre1")) foo()
>>>>>>>>> {
>>>>>>>>> bb_1:
>>>>>>>>> a = 1 + a;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> it will execute only given passes i.e. ccp1 and fre1 pass on the
>>>>>>>>function
>>>>>>>>>
>>>>>>>>> and for test case like -
>>>>>>>>>
>>>>>>>>> int a;
>>>>>>>>> void __GIMPLE (startwith ("tree-ccp1")) foo()
>>>>>>>>> {
>>>>>>>>> bb_1:
>>>>>>>>> a = 1 + a;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> it will act as a entry point to the pipeline and will execute passes
>>>>>>>>> starting from given pass.
>>>>>>>>Bike-shedding:
>>>>>>>>Would it make sense to have syntax for defining pass ranges to execute
>>>>>>>>?
>>>>>>>>for instance:
>>>>>>>>void __GIMPLE(execute (pass_start : pass_end))
>>>>>>>>which would execute all the passes within range [pass_start, pass_end],
>>>>>>>>which would be convenient if the range is large.
>>>>>>>
>>>>>>> But it would rely on a particular pass pipeline, f.e. pass-start
>>>>>>> appearing before pass-end.
>>>>>>>
>>>>>>> Currently control doesn't work 100% as it only replaces
>>>>>>> all_optimizations but not lowering passes or early opts, nor IPA opts.
>>>>>>>
>>>>>>
>>>>>> Each pass needs GIMPLE in some specific form. So I am letting lowering
>>>>>> and early opt passes to execute. I think we have to execute some
>>>>>> passes (like cfg) anyway to represent GIMPLE into proper form
>>>>>
>>>>> Yes, that's true. Note that early opt passes only optimize but we need
>>>>> pass_build_ssa_passes at least (for into-SSA). For proper unit-testing
>>>>> of GIMPLE passes we do need to guard off early opts somehow
>>>>> (I guess a simple if (flag_gimple && cfun->custom_pass_list) would do
>>>>> that).
>>>>>
>>>>> Then there is of course the question about IPA passes which I think is
>>>>> somewhat harder (one could always disable all IPA passes manually
>>>>> via flags of course or finally have a global -fipa/no-ipa like most
>>>>> other compilers).
>>>>>
>>>> Can we iterate through all ipa passes and do -fdisable-ipa-pass or
>>>> -fenable-ipa-pass equivalent for each?
>>>
>>> We could do that, yes. But let's postpone this issue. I think that
>>> startwith is going to be most useful and rather than constructing
>>> a pass list for it "native" support for it in the pass manager is
Re: [gimplefe] hacking pass manager
On 15 July 2016 at 16:13, Richard Biener wrote:
> On Sun, Jul 10, 2016 at 6:13 PM, Prasad Ghangal
> wrote:
>> On 8 July 2016 at 13:13, Richard Biener wrote:
>>> On Thu, Jul 7, 2016 at 9:45 PM, Prasad Ghangal
>>> wrote:
>>>> On 6 July 2016 at 14:24, Richard Biener wrote:
>>>>> On Wed, Jul 6, 2016 at 9:51 AM, Prasad Ghangal
>>>>> wrote:
>>>>>> On 30 June 2016 at 17:10, Richard Biener
>>>>>> wrote:
>>>>>>> On Wed, Jun 29, 2016 at 9:13 PM, Prasad Ghangal
>>>>>>> wrote:
>>>>>>>> On 29 June 2016 at 22:15, Richard Biener
>>>>>>>> wrote:
>>>>>>>>> On June 29, 2016 6:20:29 PM GMT+02:00, Prathamesh Kulkarni
>>>>>>>>> wrote:
>>>>>>>>>>On 18 June 2016 at 12:02, Prasad Ghangal
>>>>>>>>>>wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I tried hacking pass manager to execute only given passes. For this
>>>>>>>>>>> I
>>>>>>>>>>> am adding new member as opt_pass *custom_pass_list to the function
>>>>>>>>>>> structure to store passes need to execute and providing the
>>>>>>>>>>> custom_pass_list to execute_pass_list() function instead of all
>>>>>>>>>>passes
>>>>>>>>>>>
>>>>>>>>>>> for test case like-
>>>>>>>>>>>
>>>>>>>>>>> int a;
>>>>>>>>>>> void __GIMPLE (execute ("tree-ccp1", "tree-fre1")) foo()
>>>>>>>>>>> {
>>>>>>>>>>> bb_1:
>>>>>>>>>>> a = 1 + a;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> it will execute only given passes i.e. ccp1 and fre1 pass on the
>>>>>>>>>>function
>>>>>>>>>>>
>>>>>>>>>>> and for test case like -
>>>>>>>>>>>
>>>>>>>>>>> int a;
>>>>>>>>>>> void __GIMPLE (startwith ("tree-ccp1")) foo()
>>>>>>>>>>> {
>>>>>>>>>>> bb_1:
>>>>>>>>>>> a = 1 + a;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> it will act as a entry point to the pipeline and will execute passes
>>>>>>>>>>> starting from given pass.
>>>>>>>>>>Bike-shedding:
>>>>>>>>>>Would it make sense to have syntax for defining pass ranges to execute
>>>>>>>>>>?
>>>>>>>>>>for instance:
>>>>>>>>>>void __GIMPLE(execute (pass_start : pass_end))
>>>>>>>>>>which would execute all the passes within range [pass_start,
>>>>>>>>>>pass_end],
>>>>>>>>>>which would be convenient if the range is large.
>>>>>>>>>
>>>>>>>>> But it would rely on a particular pass pipeline, f.e. pass-start
>>>>>>>>> appearing before pass-end.
>>>>>>>>>
>>>>>>>>> Currently control doesn't work 100% as it only replaces
>>>>>>>>> all_optimizations but not lowering passes or early opts, nor IPA opts.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Each pass needs GIMPLE in some specific form. So I am letting lowering
>>>>>>>> and early opt passes to execute. I think we have to execute some
>>>>>>>> passes (like cfg) anyway to represent GIMPLE into proper form
>>>>>>>
>>>>>>> Yes, that's true. Note that early opt passes only optimize but we need
>>>>>>> pass_build_ssa_passes at least (for into-SSA). For proper unit-testing
>>>>>>> of GIMPLE passes we do need to guard off early opts somehow
>>>>>>> (I guess a simple if (flag_gimple && cfun->custom_pass_list) would do
>>>>>>&g
Re: [gimplefe] hacking pass manager
On 19 July 2016 at 00:25, Richard Biener wrote:
> On July 18, 2016 8:28:15 PM GMT+02:00, Prasad Ghangal
> wrote:
>>On 15 July 2016 at 16:13, Richard Biener
>>wrote:
>>> On Sun, Jul 10, 2016 at 6:13 PM, Prasad Ghangal
>>> wrote:
>>>> On 8 July 2016 at 13:13, Richard Biener
>>wrote:
>>>>> On Thu, Jul 7, 2016 at 9:45 PM, Prasad Ghangal
>> wrote:
>>>>>> On 6 July 2016 at 14:24, Richard Biener
>> wrote:
>>>>>>> On Wed, Jul 6, 2016 at 9:51 AM, Prasad Ghangal
>> wrote:
>>>>>>>> On 30 June 2016 at 17:10, Richard Biener
>> wrote:
>>>>>>>>> On Wed, Jun 29, 2016 at 9:13 PM, Prasad Ghangal
>>>>>>>>> wrote:
>>>>>>>>>> On 29 June 2016 at 22:15, Richard Biener
>> wrote:
>>>>>>>>>>> On June 29, 2016 6:20:29 PM GMT+02:00, Prathamesh Kulkarni
>> wrote:
>>>>>>>>>>>>On 18 June 2016 at 12:02, Prasad Ghangal
>>
>>>>>>>>>>>>wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I tried hacking pass manager to execute only given passes.
>>For this I
>>>>>>>>>>>>> am adding new member as opt_pass *custom_pass_list to the
>>function
>>>>>>>>>>>>> structure to store passes need to execute and providing the
>>>>>>>>>>>>> custom_pass_list to execute_pass_list() function instead of
>>all
>>>>>>>>>>>>passes
>>>>>>>>>>>>>
>>>>>>>>>>>>> for test case like-
>>>>>>>>>>>>>
>>>>>>>>>>>>> int a;
>>>>>>>>>>>>> void __GIMPLE (execute ("tree-ccp1", "tree-fre1")) foo()
>>>>>>>>>>>>> {
>>>>>>>>>>>>> bb_1:
>>>>>>>>>>>>> a = 1 + a;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> it will execute only given passes i.e. ccp1 and fre1 pass
>>on the
>>>>>>>>>>>>function
>>>>>>>>>>>>>
>>>>>>>>>>>>> and for test case like -
>>>>>>>>>>>>>
>>>>>>>>>>>>> int a;
>>>>>>>>>>>>> void __GIMPLE (startwith ("tree-ccp1")) foo()
>>>>>>>>>>>>> {
>>>>>>>>>>>>> bb_1:
>>>>>>>>>>>>> a = 1 + a;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> it will act as a entry point to the pipeline and will
>>execute passes
>>>>>>>>>>>>> starting from given pass.
>>>>>>>>>>>>Bike-shedding:
>>>>>>>>>>>>Would it make sense to have syntax for defining pass ranges
>>to execute
>>>>>>>>>>>>?
>>>>>>>>>>>>for instance:
>>>>>>>>>>>>void __GIMPLE(execute (pass_start : pass_end))
>>>>>>>>>>>>which would execute all the passes within range [pass_start,
>>pass_end],
>>>>>>>>>>>>which would be convenient if the range is large.
>>>>>>>>>>>
>>>>>>>>>>> But it would rely on a particular pass pipeline, f.e.
>>pass-start appearing before pass-end.
>>>>>>>>>>>
>>>>>>>>>>> Currently control doesn't work 100% as it only replaces
>>all_optimizations but not lowering passes or early opts, nor IPA opts.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Each pass needs GIMPLE in some specific form. So I am letting
>>lowering
>>>>>>>>>> and early opt passes to execute. I think we have to execute
>>some
>>>>>>>>>> passes (like cfg) anyway to represent GIMPLE i
Re: [gimplefe] hacking pass manager
On 19 July 2016 at 11:04, Richard Biener wrote:
> On July 18, 2016 11:05:58 PM GMT+02:00, David Malcolm
> wrote:
>>On Tue, 2016-07-19 at 00:52 +0530, Prasad Ghangal wrote:
>>> On 19 July 2016 at 00:25, Richard Biener
>>> wrote:
>>> > On July 18, 2016 8:28:15 PM GMT+02:00, Prasad Ghangal <
>>> > prasad.ghan...@gmail.com> wrote:
>>> > > On 15 July 2016 at 16:13, Richard Biener <
>>> > > richard.guent...@gmail.com>
>>> > > wrote:
>>> > > > On Sun, Jul 10, 2016 at 6:13 PM, Prasad Ghangal
>>> > > > wrote:
>>> > > > > On 8 July 2016 at 13:13, Richard Biener <
>>> > > > > richard.guent...@gmail.com>
>>> > > wrote:
>>> > > > > > On Thu, Jul 7, 2016 at 9:45 PM, Prasad Ghangal
>>> > > wrote:
>>> > > > > > > On 6 July 2016 at 14:24, Richard Biener
>>> > > wrote:
>>> > > > > > > > On Wed, Jul 6, 2016 at 9:51 AM, Prasad Ghangal
>>> > > wrote:
>>> > > > > > > > > On 30 June 2016 at 17:10, Richard Biener
>>> > > wrote:
>>> > > > > > > > > > On Wed, Jun 29, 2016 at 9:13 PM, Prasad Ghangal
>>> > > > > > > > > > wrote:
>>> > > > > > > > > > > On 29 June 2016 at 22:15, Richard Biener
>>> > > wrote:
>>> > > > > > > > > > > > On June 29, 2016 6:20:29 PM GMT+02:00,
>>> > > > > > > > > > > > Prathamesh Kulkarni
>>> > > wrote:
>>> > > > > > > > > > > > > On 18 June 2016 at 12:02, Prasad Ghangal
>>> > >
>>> > > > > > > > > > > > > wrote:
>>> > > > > > > > > > > > > > Hi,
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > I tried hacking pass manager to execute
>>> > > > > > > > > > > > > > only given passes.
>>> > > For this I
>>> > > > > > > > > > > > > > am adding new member as opt_pass
>>> > > > > > > > > > > > > > *custom_pass_list to the
>>> > > function
>>> > > > > > > > > > > > > > structure to store passes need to execute
>>> > > > > > > > > > > > > > and providing the
>>> > > > > > > > > > > > > > custom_pass_list to execute_pass_list()
>>> > > > > > > > > > > > > > function instead of
>>> > > all
>>> > > > > > > > > > > > > passes
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > for test case like-
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > int a;
>>> > > > > > > > > > > > > > void __GIMPLE (execute ("tree-ccp1", "tree
>>> > > > > > > > > > > > > > -fre1")) foo()
>>> > > > > > > > > > > > > > {
>>> > > > > > > > > > > > > > bb_1:
>>> > > > > > > > > > > > > > a = 1 + a;
>>> > > > > > > > > > > > > > }
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > it will execute only given passes i.e. ccp1
>>> > > > > > > > > > > > > > and fre1 pass
>>> > > on the
>>> > > > > > > > > > > > > function
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > and for test case like -
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > int a;
>>> > > > > > > > > > > >
Re: [gimplefe] hacking pass manager
On 20 July 2016 at 18:28, Richard Biener wrote:
> On Wed, Jul 20, 2016 at 1:46 PM, Prathamesh Kulkarni
> wrote:
>> On 20 July 2016 at 11:34, Richard Biener wrote:
>>> On Tue, Jul 19, 2016 at 10:09 PM, Prasad Ghangal
>>> wrote:
>>>> On 19 July 2016 at 11:04, Richard Biener
>>>> wrote:
>>>>> On July 18, 2016 11:05:58 PM GMT+02:00, David Malcolm
>>>>> wrote:
>>>>>>On Tue, 2016-07-19 at 00:52 +0530, Prasad Ghangal wrote:
>>>>>>> On 19 July 2016 at 00:25, Richard Biener
>>>>>>> wrote:
>>>>>>> > On July 18, 2016 8:28:15 PM GMT+02:00, Prasad Ghangal <
>>>>>>> > prasad.ghan...@gmail.com> wrote:
>>>>>>> > > On 15 July 2016 at 16:13, Richard Biener <
>>>>>>> > > richard.guent...@gmail.com>
>>>>>>> > > wrote:
>>>>>>> > > > On Sun, Jul 10, 2016 at 6:13 PM, Prasad Ghangal
>>>>>>> > > > wrote:
>>>>>>> > > > > On 8 July 2016 at 13:13, Richard Biener <
>>>>>>> > > > > richard.guent...@gmail.com>
>>>>>>> > > wrote:
>>>>>>> > > > > > On Thu, Jul 7, 2016 at 9:45 PM, Prasad Ghangal
>>>>>>> > > wrote:
>>>>>>> > > > > > > On 6 July 2016 at 14:24, Richard Biener
>>>>>>> > > wrote:
>>>>>>> > > > > > > > On Wed, Jul 6, 2016 at 9:51 AM, Prasad Ghangal
>>>>>>> > > wrote:
>>>>>>> > > > > > > > > On 30 June 2016 at 17:10, Richard Biener
>>>>>>> > > wrote:
>>>>>>> > > > > > > > > > On Wed, Jun 29, 2016 at 9:13 PM, Prasad Ghangal
>>>>>>> > > > > > > > > > wrote:
>>>>>>> > > > > > > > > > > On 29 June 2016 at 22:15, Richard Biener
>>>>>>> > > wrote:
>>>>>>> > > > > > > > > > > > On June 29, 2016 6:20:29 PM GMT+02:00,
>>>>>>> > > > > > > > > > > > Prathamesh Kulkarni
>>>>>>> > > wrote:
>>>>>>> > > > > > > > > > > > > On 18 June 2016 at 12:02, Prasad Ghangal
>>>>>>> > >
>>>>>>> > > > > > > > > > > > > wrote:
>>>>>>> > > > > > > > > > > > > > Hi,
>>>>>>> > > > > > > > > > > > > >
>>>>>>> > > > > > > > > > > > > > I tried hacking pass manager to execute
>>>>>>> > > > > > > > > > > > > > only given passes.
>>>>>>> > > For this I
>>>>>>> > > > > > > > > > > > > > am adding new member as opt_pass
>>>>>>> > > > > > > > > > > > > > *custom_pass_list to the
>>>>>>> > > function
>>>>>>> > > > > > > > > > > > > > structure to store passes need to execute
>>>>>>> > > > > > > > > > > > > > and providing the
>>>>>>> > > > > > > > > > > > > > custom_pass_list to execute_pass_list()
>>>>>>> > > > > > > > > > > > > > function instead of
>>>>>>> > > all
>>>>>>> > > > > > > > > > > > > passes
>>>>>>> > > > > > > > > > > > > >
>>>>>>> > > > > > > > > > > > > > for test case like-
>>>>>>> > > > > > > > > > > > > >
>>>>>>> > > > > > > > > > > > > > int a;
>>>>>>> > > > > > > > > > > > > > void __GIMPLE (execute ("tree-ccp1", "tree
>>>>>>> > > > > > > > > > > > > > -fre1")) fo
Re: [gimplefe] hacking pass manager
On 27 July 2016 at 14:22, Richard Biener wrote: > On Tue, Jul 26, 2016 at 11:38 PM, Prathamesh Kulkarni > wrote: >> On 27 July 2016 at 00:20, Prasad Ghangal wrote: >>> On 20 July 2016 at 18:28, Richard Biener wrote: >>>> On Wed, Jul 20, 2016 at 1:46 PM, Prathamesh Kulkarni >>>> wrote: >>>>> On 20 July 2016 at 11:34, Richard Biener >>>>> wrote: >>>>>> On Tue, Jul 19, 2016 at 10:09 PM, Prasad Ghangal >>>>>> wrote: >>>>>>> On 19 July 2016 at 11:04, Richard Biener >>>>>>> wrote: >>>>>>>> On July 18, 2016 11:05:58 PM GMT+02:00, David Malcolm >>>>>>>> wrote: >>>>>>>>>On Tue, 2016-07-19 at 00:52 +0530, Prasad Ghangal wrote: >>>>>>>>>> On 19 July 2016 at 00:25, Richard Biener >>>>>>>>>> wrote: >>>>>>>>>> > On July 18, 2016 8:28:15 PM GMT+02:00, Prasad Ghangal < >>>>>>>>>> > prasad.ghan...@gmail.com> wrote: >>>>>>>>>> > > On 15 July 2016 at 16:13, Richard Biener < >>>>>>>>>> > > richard.guent...@gmail.com> >>>>>>>>>> > > wrote: >>>>>>>>>> > > > On Sun, Jul 10, 2016 at 6:13 PM, Prasad Ghangal >>>>>>>>>> > > > wrote: >>>>>>>>>> > > > > On 8 July 2016 at 13:13, Richard Biener < >>>>>>>>>> > > > > richard.guent...@gmail.com> >>>>>>>>>> > > wrote: >>>>>>>>>> > > > > > On Thu, Jul 7, 2016 at 9:45 PM, Prasad Ghangal >>>>>>>>>> > > wrote: >>>>>>>>>> > > > > > > On 6 July 2016 at 14:24, Richard Biener >>>>>>>>>> > > wrote: >>>>>>>>>> > > > > > > > On Wed, Jul 6, 2016 at 9:51 AM, Prasad Ghangal >>>>>>>>>> > > wrote: >>>>>>>>>> > > > > > > > > On 30 June 2016 at 17:10, Richard Biener >>>>>>>>>> > > wrote: >>>>>>>>>> > > > > > > > > > On Wed, Jun 29, 2016 at 9:13 PM, Prasad Ghangal >>>>>>>>>> > > > > > > > > > wrote: >>>>>>>>>> > > > > > > > > > > On 29 June 2016 at 22:15, Richard Biener >>>>>>>>>> > > wrote: >>>>>>>>>> > > > > > > > > > > > On June 29, 2016 6:20:29 PM GMT+02:00, >>>>>>>>>> > > > > > > > > > > > Prathamesh Kulkarni >>>>>>>>>> > > wrote: >>>>>>>>>> > > > > > > > > > > > > On 18 June 2016 at 12:02, Prasad Ghangal >>>>>>>>>> > > >>>>>>>>>> > > > > > > > > > > > > wrote: >>>>>>>>>> > > > > > > > > > > > > > Hi, >>>>>>>>>> > > > > > > > > > > > > > >>>>>>>>>> > > > > > > > > > > > > > I tried hacking pass manager to execute >>>>>>>>>> > > > > > > > > > > > > > only given passes. >>>>>>>>>> > > For this I >>>>>>>>>> > > > > > > > > > > > > > am adding new member as opt_pass >>>>>>>>>> > > > > > > > > > > > > > *custom_pass_list to the >>>>>>>>>> > > function >>>>>>>>>> > > > > > > > > > > > > > structure to store passes need to execute >>>>>>>>>> > > > > > > > > > > > > > and providing the >>>>>>>>>> > > > > > > > > > > > > > custom_pass_list to execute_pass_list() >>>>>>>>>> > > > > > > > > > > >
Re: [gimplefe] hacking pass manager
Thanks, Prasad On 29 July 2016 at 06:56, Prathamesh Kulkarni wrote: > On 29 July 2016 at 00:01, Prasad Ghangal wrote: >> On 27 July 2016 at 14:22, Richard Biener wrote: >>> On Tue, Jul 26, 2016 at 11:38 PM, Prathamesh Kulkarni >>> wrote: >>>> On 27 July 2016 at 00:20, Prasad Ghangal wrote: >>>>> On 20 July 2016 at 18:28, Richard Biener >>>>> wrote: >>>>>> On Wed, Jul 20, 2016 at 1:46 PM, Prathamesh Kulkarni >>>>>> wrote: >>>>>>> On 20 July 2016 at 11:34, Richard Biener >>>>>>> wrote: >>>>>>>> On Tue, Jul 19, 2016 at 10:09 PM, Prasad Ghangal >>>>>>>> wrote: >>>>>>>>> On 19 July 2016 at 11:04, Richard Biener >>>>>>>>> wrote: >>>>>>>>>> On July 18, 2016 11:05:58 PM GMT+02:00, David Malcolm >>>>>>>>>> wrote: >>>>>>>>>>>On Tue, 2016-07-19 at 00:52 +0530, Prasad Ghangal wrote: >>>>>>>>>>>> On 19 July 2016 at 00:25, Richard Biener >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> > On July 18, 2016 8:28:15 PM GMT+02:00, Prasad Ghangal < >>>>>>>>>>>> > prasad.ghan...@gmail.com> wrote: >>>>>>>>>>>> > > On 15 July 2016 at 16:13, Richard Biener < >>>>>>>>>>>> > > richard.guent...@gmail.com> >>>>>>>>>>>> > > wrote: >>>>>>>>>>>> > > > On Sun, Jul 10, 2016 at 6:13 PM, Prasad Ghangal >>>>>>>>>>>> > > > wrote: >>>>>>>>>>>> > > > > On 8 July 2016 at 13:13, Richard Biener < >>>>>>>>>>>> > > > > richard.guent...@gmail.com> >>>>>>>>>>>> > > wrote: >>>>>>>>>>>> > > > > > On Thu, Jul 7, 2016 at 9:45 PM, Prasad Ghangal >>>>>>>>>>>> > > wrote: >>>>>>>>>>>> > > > > > > On 6 July 2016 at 14:24, Richard Biener >>>>>>>>>>>> > > wrote: >>>>>>>>>>>> > > > > > > > On Wed, Jul 6, 2016 at 9:51 AM, Prasad Ghangal >>>>>>>>>>>> > > wrote: >>>>>>>>>>>> > > > > > > > > On 30 June 2016 at 17:10, Richard Biener >>>>>>>>>>>> > > wrote: >>>>>>>>>>>> > > > > > > > > > On Wed, Jun 29, 2016 at 9:13 PM, Prasad Ghangal >>>>>>>>>>>> > > > > > > > > > wrote: >>>>>>>>>>>> > > > > > > > > > > On 29 June 2016 at 22:15, Richard Biener >>>>>>>>>>>> > > wrote: >>>>>>>>>>>> > > > > > > > > > > > On June 29, 2016 6:20:29 PM GMT+02:00, >>>>>>>>>>>> > > > > > > > > > > > Prathamesh Kulkarni >>>>>>>>>>>> > > wrote: >>>>>>>>>>>> > > > > > > > > > > > > On 18 June 2016 at 12:02, Prasad Ghangal >>>>>>>>>>>> > > >>>>>>>>>>>> > > > > > > > > > > > > wrote: >>>>>>>>>>>> > > > > > > > > > > > > > Hi, >>>>>>>>>>>> > > > > > > > > > > > > > >>>>>>>>>>>> > > > > > > > > > > > > > I tried hacking pass manager to execute >>>>>>>>>>>> > > > > > > > > > > > > > only given passes. >>>>>>>>>>>> > > For this I >>>>>>>>>>>> > > > > > > > > > > > > > am adding new member as opt_pass >>>>>>>>>>>> > > > > > > &
Re: [gimplefe] hacking pass manager
Thanks,
Prasad
On 29 July 2016 at 12:55, Richard Biener wrote:
> On Fri, Jul 29, 2016 at 9:03 AM, Prasad Ghangal
> wrote:
>> Thanks,
>> Prasad
>>
>>
>> On 29 July 2016 at 06:56, Prathamesh Kulkarni
>> wrote:
>>> On 29 July 2016 at 00:01, Prasad Ghangal wrote:
>>>> On 27 July 2016 at 14:22, Richard Biener
>>>> wrote:
>>>>> On Tue, Jul 26, 2016 at 11:38 PM, Prathamesh Kulkarni
>>>>> wrote:
>>>>>> On 27 July 2016 at 00:20, Prasad Ghangal
>>>>>> wrote:
>>>>> There is one other feature missing for SSA name parsing (forget to
>>>>> mention that)
>>>>> which is parsing of default def SSA names. Those are for example used for
>>>>> parameters and currently dumped like
>>>>>
>>>>> foo (int i)
>>>>> {
>>>>> int D.1759;
>>>>> int _2;
>>>>>
>>>>> :
>>>>> _2 = i_1(D) + 1;
>>>>> return _2;
>>>>> }
>>>>>
>>>>> for int foo (int i) { return i + 1; }. Here 'i_1(D)' is the
>>>>> default-def of 'i' which
>>>>> in case of a parameter is the value at function start and in case of a
>>>>> non-parameter
>>>>> is simply "undefined". '(D)' is again somewhat awkward to parse but I
>>>>> guess we
>>>>> can cope with that ;) A default-def needs to be registered like
>>>>>
>>>>> arg = make_ssa_name_fn (cfun, lookup_name (id), ...);
>>>>> set_ssa_default_def (cfun, lookup_name (id), arg);
>>>>>
>>>>> "undefined" SSA names appear often in PHIs (and of course for parameters).
>>>>>
>>>>
>>>> This updated patch tries to parse default def ssa names
>>> Um does this emit error for cases like a_1() and a_(D) ?
>>> From the code it appears to me that parsing 'D' is made optional, so
>>> id_version() would be accepted.
>>> Perhaps have an else for the if (!strcmp("D", ...) that emits parse error ?
>>>
>> Right. Currently it gives ICE but we can handle it with better way.
>>
>>> Btw for the following case:
>>> int a;
>>> int a_1;
>>> int x = a_1 + 1;
>>> What does a_1 refer to in "int x = a_1 + 1" ? the ssa-version of 'a'
>>> or the variable 'a_1' ?
>>> I think from the code it would refer to ssa-version of a ? However the
>>> reference looks
>>> ambiguous to me (since we also allow variables in non-ssa form).
>>>
>> we are guarding it with condition
>> if (TREE_CODE (c_parser_peek_token (parser)->value) == IDENTIFIER_NODE
>> && !lookup_name (c_parser_peek_token (parser)->value))
>> so that shouldn't happen.
>
> Note that the example is indeed ambiguous. As said previously rejecting all
> invalid source shouldn't be necessarily scope of the GSoC project. In this
> particular case the issue is from using _ as the separator for the SSA name
> version - the source simply has to cope with that (or we need to choose sth
> else). Similar issue is that a_1(D) can also parse as a function call in C.
>
> Btw, I'd like to see some testcases for the SSA name parsing in the testsuite.
>
I have added testcases for __PHI and ssa names
Thanks,
Prasad
> Thanks,
> Richard.
>
>>
>> Thanks,
>> Prasad
>>
>>> Thanks,
>>> Prathamesh
>>>>
>>>> Thanks,
>>>> Prasad
>>>>
>>>>> Thanks,
>>>>> Richard.
>>>>>
>>>>>> Thanks,
>>>>>> Prathamesh
>>>>>>>
>>>>>>> for testcase :
>>>>>>>
>>>>>>> void __GIMPLE () foo()
>>>>>>> {
>>>>>>> int a;
>>>>>>> bb_2:
>>>>>>> if (a > 4)
>>>>>>> goto bb_3;
>>>>>>> else
>>>>>>> goto bb_4;
>>>>>>> bb_3:
>>>>>>> a_1 = 55;
>>>>>>> goto bb_5;
>>>>>>>
>>>>>>> bb_4:
>>>>>>> a_2 = 99;
>>>>>>>
>>>>>>> bb_5:
>>>>>>> a_3 = __PHI (bb_3: a_1, bb_4: a_2);
>>>>>>> a_4 = a_3 + 3;
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> I am getting ssa dump as:
>>>>>>>
>>>>>>> /* Function foo (foo, funcdef_no=0, decl_uid=1744, cgraph_uid=0,
>>>>>>> symbol_order=0)*/
>>>>>>>
>>>>>>> void
>>>>>>> foo ()
>>>>>>> {
>>>>>>> bb_2:
>>>>>>> if (a_5 > 4)
>>>>>>> goto bb_3;
>>>>>>> else
>>>>>>> goto bb_4;
>>>>>>>
>>>>>>> bb_3:
>>>>>>> a_1 = 55;
>>>>>>> goto bb_5;
>>>>>>>
>>>>>>> bb_4:
>>>>>>> a_2 = 99;
>>>>>>>
>>>>>>> a_3 = __PHI (bb_3: a_1, bb_4: a_2)
>>>>>>> bb_5:
>>>>>>> a_4 = a_3 + 3;
>>>>>>> return;
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>>> Richard.
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Prathamesh
>>>>>>>>>>
>>>>>>>>>> Richard.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Richard.
>>>>>>>>>>>>
>>>>>>>>>>>>>Dave
>>>>>>>>>>>>
>>>>>>>>>>>>
[gimplefe] "Unknown tree: c_maybe_const_expr" error while parsing conditional expression
Hi,
I am trying to replace c_parser_paren_condition (parser) in
c_parser_gimple_if_stmt by c_parser_gimple_paren_condition (parser) as
described in the patch
I am trying test case
void __GIMPLE () foo ()
{
int a;
bb_2:
if (a == 2)
goto bb_3;
else
goto bb_4;
bb_3:
a_2 = 4;
bb_4:
return;
}
but it fails to parse gimple expression and produces error as
/home/prasad/test3.c: In function ‘foo’:
/home/prasad/test3.c:1:18: error: invalid operands in gimple comparison
void __GIMPLE () foo ()
^~~
if (<<< Unknown tree: c_maybe_const_expr
a >>> == 2) goto bb_3; else goto bb_4;
/home/prasad/test3.c:1:18: internal compiler error: verify_gimple failed
I failed to debug where it is setting to C_MAYBE_CONST_EXPR
Thanks,
Prasad
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 70800a2..9e5152c 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -1425,6 +1425,7 @@ static void c_parser_gimple_switch_stmt (c_parser *,
gimple_seq *);
static void c_parser_gimple_return_stmt (c_parser *, gimple_seq *);
static void c_finish_gimple_return (location_t, tree);
static c_expr c_parser_parse_ssa_names (c_parser *);
+static tree c_parser_gimple_paren_condition (c_parser *);
/* Parse a translation unit (C90 6.7, C99 6.9).
@@ -19025,6 +19026,25 @@ c_parser_gimple_goto_stmt (location_t loc, tree label,
gimple_seq *seq)
return;
}
+/* Parse a parenthesized condition */
+
+static tree
+c_parser_gimple_paren_condition (c_parser *parser)
+{
+ c_expr cond;
+ enum tree_code subcode = NOP_EXPR;
+ cond.original_code = ERROR_MARK;
+ cond.original_type = NULL;
+ location_t loc = c_parser_peek_token (parser)->location;
+ if (!c_parser_require (parser, CPP_OPEN_PAREN, "expected %<(%>"))
+return error_mark_node;
+ cond = c_parser_gimple_binary_expression (parser, &subcode);
+ cond = convert_lvalue_to_rvalue (loc, cond, true, true);
+ cond.value = c_objc_common_truthvalue_conversion (loc, cond.value);
+ c_parser_skip_until_found (parser, CPP_CLOSE_PAREN, "expected %<)%>");
+ return cond.value;
+}
+
/* Parse gimple if-else statement */
static void
@@ -19033,7 +19053,7 @@ c_parser_gimple_if_stmt (c_parser *parser, gimple_seq
*seq)
tree cond, t_label, f_label, label;
location_t loc;
c_parser_consume_token (parser);
- cond = c_parser_paren_condition (parser);
+ cond = c_parser_gimple_paren_condition (parser);
if (c_parser_next_token_is_keyword (parser, RID_GOTO))
{
Re: [gimplefe] "Unknown tree: c_maybe_const_expr" error while parsing conditional expression
On 2 August 2016 at 14:29, Richard Biener wrote:
> On Mon, Aug 1, 2016 at 4:52 PM, Prasad Ghangal
> wrote:
>> Hi,
>>
>> I am trying to replace c_parser_paren_condition (parser) in
>> c_parser_gimple_if_stmt by c_parser_gimple_paren_condition (parser) as
>> described in the patch
>>
>> I am trying test case
>> void __GIMPLE () foo ()
>> {
>> int a;
>> bb_2:
>> if (a == 2)
>> goto bb_3;
>> else
>> goto bb_4;
>> bb_3:
>> a_2 = 4;
>> bb_4:
>> return;
>> }
>>
>> but it fails to parse gimple expression and produces error as
>> /home/prasad/test3.c: In function ‘foo’:
>> /home/prasad/test3.c:1:18: error: invalid operands in gimple comparison
>> void __GIMPLE () foo ()
>> ^~~
>> if (<<< Unknown tree: c_maybe_const_expr
>>
>> a >>> == 2) goto bb_3; else goto bb_4;
>> /home/prasad/test3.c:1:18: internal compiler error: verify_gimple failed
>>
>> I failed to debug where it is setting to C_MAYBE_CONST_EXPR
>
> It's in parsing the binary expression. Btw, you don't need lvalue_to_rvalue
> conversion or truthvalue conversion - source that would require this would
> not be valid GIMPLE. Let me try to debug:
>
>
> (gdb) p debug_tree (cond.value)
> type size
> unit size
> align 32 symtab 0 alias set -1 canonical type 0x7688b7e0
> precision 32 min max
>
> pointer_to_this >
>
> arg 0 0x7688b7e0 int>
>
> arg 1 int>
> used SI file t.c line 3 col 7 size 0x76887ee8 32> unit size
> align 32 context >>
> arg 1 0x7688b7e0 int> constant 2>
> t.c:5:9 start: t.c:5:7 finish: t.c:5:12>
> $5 = void
> (gdb) b ggc-page.c:1444 if result == 0x76997938
> Breakpoint 6 at 0x8a0d3e: file
> /space/rguenther/src/gcc_gimple_fe/gcc/ggc-page.c, line 1444.
> (gdb) run
>
> Breakpoint 6, ggc_internal_alloc (size=40, f=0x0, s=0, n=1)
> at /space/rguenther/src/gcc_gimple_fe/gcc/ggc-page.c:1444
> 1444 return result;
> (gdb) fin (a few times)
> Run till exit from #0 0x011821b7 in build2_stat (
> code=C_MAYBE_CONST_EXPR, tt=,
> arg0=, arg1=)
> at /space/rguenther/src/gcc_gimple_fe/gcc/tree.c:4466
> 0x0081d263 in c_wrap_maybe_const (expr=,
> non_const=false)
> at /space/rguenther/src/gcc_gimple_fe/gcc/c-family/c-common.c:4359
> 4359 expr = build2 (C_MAYBE_CONST_EXPR, TREE_TYPE (expr), NULL, expr);
> Value returned is $11 = (tree_node *) 0x76997938
> (gdb) up
> #1 0x007b8e81 in build_binary_op (location=176833, code=EQ_EXPR,
> orig_op0=,
> orig_op1=, convert_p=1)
> at /space/rguenther/src/gcc_gimple_fe/gcc/c/c-typeck.c:11549
> 11549 op0 = c_wrap_maybe_const (op0, !op0_maybe_const);
>
> and this is guarded by !in_late_binary_op (which also seems to guard folding).
> So I suggest to somewhere at the start of parsing to set in_late_binary_op to
> true for -fgimple. Not sure if it works for everything, but you
> should have accumulated
> quite some tests for -fgimple in the testsuite to make sure it doesn't
> regress anything.
>
I did bootstrap build for the trunk and testing is in progress. How
can I test with -fgimple flag enabled?
Thanks,
Prasad
> The following works for me:
>
> diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
> index 70800a2..c8c087a 100644
> --- a/gcc/c/c-parser.c
> +++ b/gcc/c/c-parser.c
> @@ -2158,7 +2159,10 @@ c_parser_declaration_or_fndef (c_parser
> *parser, bool fndef_ok,
>
>if (gimple_body_p && flag_gimple)
> {
> + bool saved = in_late_binary_op;
> + in_late_binary_op = true;
> c_parser_parse_gimple_body (parser);
> + in_late_binary_op = saved;
> cgraph_node::finalize_function (current_function_decl, false);
> timevar_pop (tv);
> return;
>
>
> Richard.
>
>>
>> Thanks,
>> Prasad
Re: [gimplefe] "Unknown tree: c_maybe_const_expr" error while parsing conditional expression
On 4 August 2016 at 18:29, Richard Biener wrote:
> On Thu, Aug 4, 2016 at 1:31 PM, Prasad Ghangal
> wrote:
>> On 2 August 2016 at 14:29, Richard Biener wrote:
>>> On Mon, Aug 1, 2016 at 4:52 PM, Prasad Ghangal
>>> wrote:
>>>> Hi,
>>>>
>>>> I am trying to replace c_parser_paren_condition (parser) in
>>>> c_parser_gimple_if_stmt by c_parser_gimple_paren_condition (parser) as
>>>> described in the patch
>>>>
>>>> I am trying test case
>>>> void __GIMPLE () foo ()
>>>> {
>>>> int a;
>>>> bb_2:
>>>> if (a == 2)
>>>> goto bb_3;
>>>> else
>>>> goto bb_4;
>>>> bb_3:
>>>> a_2 = 4;
>>>> bb_4:
>>>> return;
>>>> }
>>>>
>>>> but it fails to parse gimple expression and produces error as
>>>> /home/prasad/test3.c: In function ‘foo’:
>>>> /home/prasad/test3.c:1:18: error: invalid operands in gimple comparison
>>>> void __GIMPLE () foo ()
>>>> ^~~
>>>> if (<<< Unknown tree: c_maybe_const_expr
>>>>
>>>> a >>> == 2) goto bb_3; else goto bb_4;
>>>> /home/prasad/test3.c:1:18: internal compiler error: verify_gimple failed
>>>>
>>>> I failed to debug where it is setting to C_MAYBE_CONST_EXPR
>>>
>>> It's in parsing the binary expression. Btw, you don't need lvalue_to_rvalue
>>> conversion or truthvalue conversion - source that would require this would
>>> not be valid GIMPLE. Let me try to debug:
>>>
>>>
>>> (gdb) p debug_tree (cond.value)
>>> >> type >> size
>>> unit size
>>> align 32 symtab 0 alias set -1 canonical type 0x7688b7e0
>>> precision 32 min max
>>>
>>> pointer_to_this >
>>>
>>> arg 0 >> 0x7688b7e0 int>
>>>
>>> arg 1 >> int>
>>> used SI file t.c line 3 col 7 size >> 0x76887ee8 32> unit size
>>> align 32 context >>
>>> arg 1 >> 0x7688b7e0 int> constant 2>
>>> t.c:5:9 start: t.c:5:7 finish: t.c:5:12>
>>> $5 = void
>>> (gdb) b ggc-page.c:1444 if result == 0x76997938
>>> Breakpoint 6 at 0x8a0d3e: file
>>> /space/rguenther/src/gcc_gimple_fe/gcc/ggc-page.c, line 1444.
>>> (gdb) run
>>>
>>> Breakpoint 6, ggc_internal_alloc (size=40, f=0x0, s=0, n=1)
>>> at /space/rguenther/src/gcc_gimple_fe/gcc/ggc-page.c:1444
>>> 1444 return result;
>>> (gdb) fin (a few times)
>>> Run till exit from #0 0x011821b7 in build2_stat (
>>> code=C_MAYBE_CONST_EXPR, tt=,
>>> arg0=, arg1=)
>>> at /space/rguenther/src/gcc_gimple_fe/gcc/tree.c:4466
>>> 0x0081d263 in c_wrap_maybe_const (expr=,
>>> non_const=false)
>>> at /space/rguenther/src/gcc_gimple_fe/gcc/c-family/c-common.c:4359
>>> 4359 expr = build2 (C_MAYBE_CONST_EXPR, TREE_TYPE (expr), NULL, expr);
>>> Value returned is $11 = (tree_node *) 0x76997938
>>> (gdb) up
>>> #1 0x007b8e81 in build_binary_op (location=176833, code=EQ_EXPR,
>>> orig_op0=,
>>> orig_op1=, convert_p=1)
>>> at /space/rguenther/src/gcc_gimple_fe/gcc/c/c-typeck.c:11549
>>> 11549 op0 = c_wrap_maybe_const (op0,
>>> !op0_maybe_const);
>>>
>>> and this is guarded by !in_late_binary_op (which also seems to guard
>>> folding).
>>> So I suggest to somewhere at the start of parsing to set in_late_binary_op
>>> to
>>> true for -fgimple. Not sure if it works for everything, but you
>>> should have accumulated
>>> quite some tests for -fgimple in the testsuite to make sure it doesn't
>>> regress anything.
>>>
>> I did bootstrap build for the trunk and testing is in progress. How
>> can I test with -fgimple flag enabled?
>
> You can do
>
> make check-gcc RUNTESTFLAGS="--target_board=unix/-fgimple"
>
> Richard.
>
I was comparing result from latest commit and "gcc initial version". I
found most of the testcases failed due to modified gimple dump.
Thanks,
Prasad
>>
>> Thanks,
>> Prasad
>>> The following works for me:
>>>
>>> diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
>>> index 70800a2..c8c087a 100644
>>> --- a/gcc/c/c-parser.c
>>> +++ b/gcc/c/c-parser.c
>>> @@ -2158,7 +2159,10 @@ c_parser_declaration_or_fndef (c_parser
>>> *parser, bool fndef_ok,
>>>
>>>if (gimple_body_p && flag_gimple)
>>> {
>>> + bool saved = in_late_binary_op;
>>> + in_late_binary_op = true;
>>> c_parser_parse_gimple_body (parser);
>>> + in_late_binary_op = saved;
>>> cgraph_node::finalize_function (current_function_decl, false);
>>> timevar_pop (tv);
>>> return;
>>>
>>>
>>> Richard.
>>>
>>>>
>>>> Thanks,
>>>> Prasad
Re: [gimplefe] "Unknown tree: c_maybe_const_expr" error while parsing conditional expression
In this patch I am trying to parse gimple call. But I am getting weird
gimple dump for that.
for this testcase:
int __GIMPLE() bar()
{
int a;
a = a + 1;
return a;
}
void __GIMPLE() foo()
{
int b;
b = bar();
}
I am getting ssa dump as:
/* Function bar (bar, funcdef_no=0, decl_uid=1744, cgraph_uid=0,
symbol_order=0)*/
int
bar ()
{
struct FRAME.bar FRAME.0;
int a;
void * D_1754;
void * _3;
bb_2:
_3 = __builtin_dwarf_cfa (0);
FRAME.0.FRAME_BASE.PARENT = _3;
a_6 = a_5(D) + 1;
return a_6;
}
/* Function foo (foo, funcdef_no=1, decl_uid=1747, cgraph_uid=1,
symbol_order=1)*/
void
foo ()
{
int b;
bb_2:
b_3 = bar ();
return;
}
On 9 August 2016 at 14:37, Richard Biener wrote:
> On Sun, Aug 7, 2016 at 3:19 PM, Prasad Ghangal
> wrote:
>> On 4 August 2016 at 18:29, Richard Biener wrote:
>>> On Thu, Aug 4, 2016 at 1:31 PM, Prasad Ghangal
>>> wrote:
>>>> On 2 August 2016 at 14:29, Richard Biener
>>>> wrote:
>>>>> On Mon, Aug 1, 2016 at 4:52 PM, Prasad Ghangal
>>>>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I am trying to replace c_parser_paren_condition (parser) in
>>>>>> c_parser_gimple_if_stmt by c_parser_gimple_paren_condition (parser) as
>>>>>> described in the patch
>>>>>>
>>>>>> I am trying test case
>>>>>> void __GIMPLE () foo ()
>>>>>> {
>>>>>> int a;
>>>>>> bb_2:
>>>>>> if (a == 2)
>>>>>> goto bb_3;
>>>>>> else
>>>>>> goto bb_4;
>>>>>> bb_3:
>>>>>> a_2 = 4;
>>>>>> bb_4:
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> but it fails to parse gimple expression and produces error as
>>>>>> /home/prasad/test3.c: In function ‘foo’:
>>>>>> /home/prasad/test3.c:1:18: error: invalid operands in gimple comparison
>>>>>> void __GIMPLE () foo ()
>>>>>> ^~~
>>>>>> if (<<< Unknown tree: c_maybe_const_expr
>>>>>>
>>>>>> a >>> == 2) goto bb_3; else goto bb_4;
>>>>>> /home/prasad/test3.c:1:18: internal compiler error: verify_gimple failed
>>>>>>
>>>>>> I failed to debug where it is setting to C_MAYBE_CONST_EXPR
>>>>>
>>>>> It's in parsing the binary expression. Btw, you don't need
>>>>> lvalue_to_rvalue
>>>>> conversion or truthvalue conversion - source that would require this would
>>>>> not be valid GIMPLE. Let me try to debug:
>>>>>
>>>>>
>>>>> (gdb) p debug_tree (cond.value)
>>>>> >>>> type >>>> size
>>>>> unit size
>>>>> align 32 symtab 0 alias set -1 canonical type 0x7688b7e0
>>>>> precision 32 min max
>>>>>
>>>>> pointer_to_this >
>>>>>
>>>>> arg 0 >>>> 0x7688b7e0 int>
>>>>>
>>>>> arg 1 >>>> 0x7688b7e0 int>
>>>>> used SI file t.c line 3 col 7 size >>>> 0x76887ee8 32> unit size
>>>>> align 32 context >>
>>>>> arg 1 >>>> 0x7688b7e0 int> constant 2>
>>>>> t.c:5:9 start: t.c:5:7 finish: t.c:5:12>
>>>>> $5 = void
>>>>> (gdb) b ggc-page.c:1444 if result == 0x76997938
>>>>> Breakpoint 6 at 0x8a0d3e: file
>>>>> /space/rguenther/src/gcc_gimple_fe/gcc/ggc-page.c, line 1444.
>>>>> (gdb) run
>>>>>
>>>>> Breakpoint 6, ggc_internal_alloc (size=40, f=0x0, s=0, n=1)
>>>>> at /space/rguenther/src/gcc_gimple_fe/gcc/ggc-page.c:1444
>>>>> 1444 return result;
>>>>> (gdb) fin (a few times)
>>>>> Run till exit from #0 0x011821b7 in build2_stat (
>>>>> code=C_MAYBE_CONST_EXPR, tt=,
>>>>> arg0=, arg1=)
>>>>> at /space/rguenther/src/gcc_gimple_fe/gcc/tree.c:4466
>>>>> 0x0081d263 in c_wrap_maybe_const (expr=>>>> a>,
>>>>> non_const=false)
>>>>> at /space/rguenther/src/gcc_gimple_fe/gcc/c-family/c-common.c:4359
>>>>> 4359 exp
Re: [gimplefe] "Unknown tree: c_maybe_const_expr" error while parsing conditional expression
On 11 August 2016 at 15:58, Richard Biener wrote:
> On Thu, Aug 11, 2016 at 7:47 AM, Prasad Ghangal
> wrote:
>> In this patch I am trying to parse gimple call. But I am getting weird
>> gimple dump for that.
>>
>> for this testcase:
>> int __GIMPLE() bar()
>> {
>> int a;
>> a = a + 1;
>> return a;
>> }
>>
>> void __GIMPLE() foo()
>> {
>> int b;
>> b = bar();
>> }
>>
>> I am getting ssa dump as:
>>
>> /* Function bar (bar, funcdef_no=0, decl_uid=1744, cgraph_uid=0,
>> symbol_order=0)*/
>>
>> int
>> bar ()
>> {
>> struct FRAME.bar FRAME.0;
>> int a;
>> void * D_1754;
>> void * _3;
>>
>> bb_2:
>> _3 = __builtin_dwarf_cfa (0);
>> FRAME.0.FRAME_BASE.PARENT = _3;
>> a_6 = a_5(D) + 1;
>> return a_6;
>>
>> }
>>
>>
>>
>> /* Function foo (foo, funcdef_no=1, decl_uid=1747, cgraph_uid=1,
>> symbol_order=1)*/
>>
>> void
>> foo ()
>> {
>> int b;
>>
>> bb_2:
>> b_3 = bar ();
>> return;
>>
>> }
>>
>
> Somehow foo is treated as nested in bar. Note this even happens
> without calls if you
> have two functions in the testcase. Usually this means after
> finishing parsing of a function
> you fail to reset. Looks like the following fixes it:
>
> diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
> index 95615bc..b35eada 100644
> --- a/gcc/c/c-parser.c
> +++ b/gcc/c/c-parser.c
> @@ -2164,6 +2165,8 @@ c_parser_declaration_or_fndef (c_parser *parser, bool
> fnde
> f_ok,
> c_parser_parse_gimple_body (parser);
> in_late_binary_op = saved;
> cgraph_node::finalize_function (current_function_decl, false);
> + set_cfun (NULL);
> + current_function_decl = NULL;
> timevar_pop (tv);
> return;
> }
>
> Richard.
>
I have updated the patch and committed along with testcases
Thanks,
Prasad
>>
>> On 9 August 2016 at 14:37, Richard Biener wrote:
>>> On Sun, Aug 7, 2016 at 3:19 PM, Prasad Ghangal
>>> wrote:
>>>> On 4 August 2016 at 18:29, Richard Biener
>>>> wrote:
>>>>> On Thu, Aug 4, 2016 at 1:31 PM, Prasad Ghangal
>>>>> wrote:
>>>>>> On 2 August 2016 at 14:29, Richard Biener
>>>>>> wrote:
>>>>>>> On Mon, Aug 1, 2016 at 4:52 PM, Prasad Ghangal
>>>>>>> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I am trying to replace c_parser_paren_condition (parser) in
>>>>>>>> c_parser_gimple_if_stmt by c_parser_gimple_paren_condition (parser) as
>>>>>>>> described in the patch
>>>>>>>>
>>>>>>>> I am trying test case
>>>>>>>> void __GIMPLE () foo ()
>>>>>>>> {
>>>>>>>> int a;
>>>>>>>> bb_2:
>>>>>>>> if (a == 2)
>>>>>>>> goto bb_3;
>>>>>>>> else
>>>>>>>> goto bb_4;
>>>>>>>> bb_3:
>>>>>>>> a_2 = 4;
>>>>>>>> bb_4:
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> but it fails to parse gimple expression and produces error as
>>>>>>>> /home/prasad/test3.c: In function ‘foo’:
>>>>>>>> /home/prasad/test3.c:1:18: error: invalid operands in gimple comparison
>>>>>>>> void __GIMPLE () foo ()
>>>>>>>> ^~~
>>>>>>>> if (<<< Unknown tree: c_maybe_const_expr
>>>>>>>>
>>>>>>>> a >>> == 2) goto bb_3; else goto bb_4;
>>>>>>>> /home/prasad/test3.c:1:18: internal compiler error: verify_gimple
>>>>>>>> failed
>>>>>>>>
>>>>>>>> I failed to debug where it is setting to C_MAYBE_CONST_EXPR
>>>>>>>
>>>>>>> It's in parsing the binary expression. Btw, you don't need
>>>>>>> lvalue_to_rvalue
>>>>>>> conversion or truthvalue conversion - source that would require this
>>>>>>> would
>>>>>>> not be valid GIMPLE. Let me try to debug:
Re: [gimplefe] "Unknown tree: c_maybe_const_expr" error while parsing conditional expression
On 16 August 2016 at 14:10, Richard Biener wrote:
> On Mon, Aug 15, 2016 at 8:59 PM, Prasad Ghangal
> wrote:
>> On 11 August 2016 at 15:58, Richard Biener
>> wrote:
>>> On Thu, Aug 11, 2016 at 7:47 AM, Prasad Ghangal
>>> wrote:
>>>> In this patch I am trying to parse gimple call. But I am getting weird
>>>> gimple dump for that.
>>>>
>>>> for this testcase:
>>>> int __GIMPLE() bar()
>>>> {
>>>> int a;
>>>> a = a + 1;
>>>> return a;
>>>> }
>>>>
>>>> void __GIMPLE() foo()
>>>> {
>>>> int b;
>>>> b = bar();
>>>> }
>>>>
>>>> I am getting ssa dump as:
>>>>
>>>> /* Function bar (bar, funcdef_no=0, decl_uid=1744, cgraph_uid=0,
>>>> symbol_order=0)*/
>>>>
>>>> int
>>>> bar ()
>>>> {
>>>> struct FRAME.bar FRAME.0;
>>>> int a;
>>>> void * D_1754;
>>>> void * _3;
>>>>
>>>> bb_2:
>>>> _3 = __builtin_dwarf_cfa (0);
>>>> FRAME.0.FRAME_BASE.PARENT = _3;
>>>> a_6 = a_5(D) + 1;
>>>> return a_6;
>>>>
>>>> }
>>>>
>>>>
>>>>
>>>> /* Function foo (foo, funcdef_no=1, decl_uid=1747, cgraph_uid=1,
>>>> symbol_order=1)*/
>>>>
>>>> void
>>>> foo ()
>>>> {
>>>> int b;
>>>>
>>>> bb_2:
>>>> b_3 = bar ();
>>>> return;
>>>>
>>>> }
>>>>
>>>
>>> Somehow foo is treated as nested in bar. Note this even happens
>>> without calls if you
>>> have two functions in the testcase. Usually this means after
>>> finishing parsing of a function
>>> you fail to reset. Looks like the following fixes it:
>>>
>>> diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
>>> index 95615bc..b35eada 100644
>>> --- a/gcc/c/c-parser.c
>>> +++ b/gcc/c/c-parser.c
>>> @@ -2164,6 +2165,8 @@ c_parser_declaration_or_fndef (c_parser *parser, bool
>>> fnde
>>> f_ok,
>>> c_parser_parse_gimple_body (parser);
>>> in_late_binary_op = saved;
>>> cgraph_node::finalize_function (current_function_decl, false);
>>> + set_cfun (NULL);
>>> + current_function_decl = NULL;
>>> timevar_pop (tv);
>>> return;
>>> }
>>>
>>> Richard.
>>>
>> I have updated the patch and committed along with testcases
>
> That's great - note that it's now time to wrap up and prepare a formal
> submission of the
> work you have done. I'd like to see patch(es) generated from the git
> repo and submitted
> to gcc-patches together with appropriate ChangeLog entries. I'd also
> like to see an
> overall summary of achievements refering to your timeline proposal and
> I'd like to know
> TODOs that you stumbled over.
>
> When you prepare patches that's also a good time to review those yourself for
> formatting, missing comments and trivial improvements to clarity that
> can be still made.
>
> What I've seen sofar the project is in a usable prototype stage!
>
> Thanks,
> Richard.
>
I am working on the older revision of trunk. Do I need to do rebasing
before posting patches on the list?
Thanks,
Prasad
>> Thanks,
>> Prasad
>>>>
>>>> On 9 August 2016 at 14:37, Richard Biener
>>>> wrote:
>>>>> On Sun, Aug 7, 2016 at 3:19 PM, Prasad Ghangal
>>>>> wrote:
>>>>>> On 4 August 2016 at 18:29, Richard Biener
>>>>>> wrote:
>>>>>>> On Thu, Aug 4, 2016 at 1:31 PM, Prasad Ghangal
>>>>>>> wrote:
>>>>>>>> On 2 August 2016 at 14:29, Richard Biener
>>>>>>>> wrote:
>>>>>>>>> On Mon, Aug 1, 2016 at 4:52 PM, Prasad Ghangal
>>>>>>>>> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I am trying to replace c_parser_paren_condition (parser) in
>>>>>>>>>> c_parser_gimple_if_stmt by c_parser_gimple_paren_condition (parser)
>>>>>>>>>> as
>>>>>>>>>> described in the patch
>>>&g
PR68425 warn message enhancement
Hi,
This was discussed a few time ago in this email thread :
https://gcc.gnu.org/ml/gcc/2016-02/msg00235.html
As per the discussion, the attached patch produces warning message for
excess elements in array initialization along with number of expected
and extra elements and underlined extra elements ranges.
e.g for following testcases:
int foo()
{
int a[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
int b[0] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
int c[5] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
int d[5][2] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
int e[5][0] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
int f[5][2][3] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6,
7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7, 8, 9,
10};
int h[3][2][3][2] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5,
6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7};
return 0;
}
It produces (gmail may mess up with spaces):
./gcc/cc1 ../tests/test.c
foo
../tests/test.c: In function ‘foo’:
../tests/test.c:4:15: warning: excess elements in array initializer
(10 elements, 0 expected)
int b[0] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
^~~
../tests/test.c:4:15: note: (near initialization for ‘b’)
../tests/test.c:5:30: warning: excess elements in array initializer
(10 elements, 5 expected)
int c[5] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
^~~
../tests/test.c:5:30: note: (near initialization for ‘c’)
../tests/test.c:6:49: warning: excess elements in array initializer
(20 elements, 10 expected)
int d[5][2] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
^~~
../tests/test.c:6:49: note: (near initialization for ‘d[5]’)
../tests/test.c:7:18: warning: excess elements in array initializer
(20 elements, 0 expected)
int e[5][0] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
^~~
../tests/test.c:7:18: note: (near initialization for ‘e[5]’)
../tests/test.c:8:114: warning: excess elements in array initializer
(40 elements, 30 expected)
int f[5][2][3] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6,
7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
^~~
../tests/test.c:8:114: note: (near initialization for ‘f[5][1]’)
../tests/test.c:9:135: warning: excess elements in array initializer
(37 elements, 36 expected)
int h[3][2][3][2] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5,
6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7};
^
../tests/test.c:9:135: note: (near initialization for ‘h[3][0][0]’)
Any thoughts?
Thanks,
Prasad
PR68425.patch
Description: Binary data
Re: PR68425 warn message enhancement
On 19 September 2017 at 01:35, Martin Sebor wrote:
> On 09/18/2017 01:06 PM, Prasad Ghangal wrote:
>>
>> Hi,
>>
>> This was discussed a few time ago in this email thread :
>> https://gcc.gnu.org/ml/gcc/2016-02/msg00235.html
>>
>> As per the discussion, the attached patch produces warning message for
>> excess elements in array initialization along with number of expected
>> and extra elements and underlined extra elements ranges.
>
>
> I like the additional detail and the underlining of all the excess
> elements when the whole initializer list is on the same line. I'm
> not sure it's a good idea to underline all the excess elements when
> they are on separate lines. That could make the warning really long.
>
> For some additional improvements I would suggest either eliminating
> the note (it serves no useful purpose anymore) or replacing it with
> the element count(s). The message printing the element counter
> should also be adjusted to be correct for zero-length arrays as in:
>
> int a[0] = { 1 };
>
> Alternatively, change the message to say just:
>
> warning: X excess elements in an initializer for 'int a[N]'
>
> and when the line the caret is on is not the same as the object
> being initialized, print a note pointing to the declaration as
> is done by some other warnings:
>
> note: array 'a' declared here
>
> As an additional improvement, string initializers with excessive
> elements would benefit from the same underlining/element counts.
>
> The C++ front end will need similar changes.
>
> Finally, it would be nice to also be able to control the warning
> (i.e., provide an option to turn it on and off).
>
Currently gcc raises warning for excess elements in an initializer by default.
Should we introduce new flag/option (like
Wextra-elements-initializers) or use any existing one?
> Martin
>
> PS Please send patches to gcc-patches.
>
>
>>
>> e.g for following testcases:
>>
>> int foo()
>> {
>> int a[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
>> int b[0] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
>> int c[5] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
>> int d[5][2] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7, 8, 9,
>> 10};
>> int e[5][0] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7, 8, 9,
>> 10};
>> int f[5][2][3] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6,
>> 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7, 8, 9,
>> 10};
>> int h[3][2][3][2] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5,
>> 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7};
>> return 0;
>> }
>>
>>
>> It produces (gmail may mess up with spaces):
>>
>> ./gcc/cc1 ../tests/test.c
>> foo
>> ../tests/test.c: In function ‘foo’:
>> ../tests/test.c:4:15: warning: excess elements in array initializer
>> (10 elements, 0 expected)
>>int b[0] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
>>^~~
>> ../tests/test.c:4:15: note: (near initialization for ‘b’)
>> ../tests/test.c:5:30: warning: excess elements in array initializer
>> (10 elements, 5 expected)
>>int c[5] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
>>^~~
>> ../tests/test.c:5:30: note: (near initialization for ‘c’)
>> ../tests/test.c:6:49: warning: excess elements in array initializer
>> (20 elements, 10 expected)
>>int d[5][2] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7, 8,
>> 9, 10};
>>
>> ^~~
>> ../tests/test.c:6:49: note: (near initialization for ‘d[5]’)
>> ../tests/test.c:7:18: warning: excess elements in array initializer
>> (20 elements, 0 expected)
>>int e[5][0] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7, 8,
>> 9, 10};
>>^~~
>> ../tests/test.c:7:18: note: (near initialization for ‘e[5]’)
>> ../tests/test.c:8:114: warning: excess elements in array initializer
>> (40 elements, 30 expected)
>>int f[5][2][3] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6,
>> 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7, 8, 9,
>> 10};
>>
>> ^~~
>> ../tests/test.c:8:114: note: (near initialization for ‘f[5][1]’)
>> ../tests/test.c:9:135: warning: excess elements in array initializer
>> (37 elements, 36 expected)
>>int h[3][2][3][2] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5,
>> 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 2, 3, 4, 5, 6, 7};
>>
>> ^
>> ../tests/test.c:9:135: note: (near initialization for ‘h[3][0][0]’)
>>
>>
>> Any thoughts?
>>
>>
>> Thanks,
>> Prasad
>>
>
