RE: Proposal for another approach for Loop transformation with conditional in Loops.

[Ajit Kumar Agarwal]

-Original Message-
From: Jeff Law [mailto:l...@redhat.com] 
Sent: Monday, March 16, 2015 11:45 PM
To: Ajit Kumar Agarwal; Richard Biener; gcc@gcc.gnu.org
Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala
Subject: Re: Proposal for another approach for Loop transformation with 
conditional in Loops.

On 03/14/15 22:40, Ajit Kumar Agarwal wrote:
> Hello All:
>
> I am proposing the new approach to Loop transformation as given below 
> in the example For the loops with conditional expression inside the 
> Loops. The Loop body should be reducible control flow graph. The 
> iteration space is partitioned into different spaces for which either 
> the cond_expr is true or cond_expr  is false. The evaluation of 
> cond_expr for the partitioned iteration spaces can be determined statically. 
> For the partitioned iterations and based on the analysis of cond_expr on the 
> partitioned iterations spaces the Loops in fig (a) will be transformed to 
> Loops in fig (b).
>
> for the iteration spaces of the conditional inside the loop is live in  
> at the entry of the cond_expr and Live out the Control flow graph is 
> topological ordered with the basic blocks for the conditional CFG and the 
> partitioned iteration spaces can be formed for which the spaces can be true 
> for conditional expr and false and unknown.
>
> Based on the above info and analysis the Loop of Fig (a) will be transformed 
> to Loop Fig (b).
>
> This is much more optimized code as compared to the performance. The 
> cases will be triggered for SPEC Benchmarks. Loops is partitioned to 
> different version with different iteration spaces. Optimized in the presence 
> Of the transformed generation of the loops without conditional.
I fail to see how this is dramatically different than unswitching.   You 
pull the condition out (it has to be loop invariant), then have two instances 
of the loop, one for the THEN, the other for the ELSE.  You obviously select 
one or the other based on the condition of V.

>>Specific examples might be helpful in understanding how you see this as 
>>different than unswitching.

For ( I = 1; I < 5; i++)
  For ( j =1; j<=5;j++)
If ( I >3 && j >3)
 A[i][j] = a[i+1][j-1];
Else
   A{i][j] = 0;
   End
End

Fig (1)

For ( I = 1; I <= 3;i++)
  For(j= 4; j <= 5; j++)
A[i][j] = 0;

For( I = 4; I <= 5; i++)
  For(j = 4; j <=5;j++)
 A[i][j]= a[i+1][j-1];

For( (I = 1; I <=5 ;i++)
  For(j = 1; j <= 3;j++)
A[i][j] = 0;

Fig(2) Transformed code for Fig(1).

Fig(1) is the original code and Fig(2) is the transformed code for fig(1).

Thanks & Regards
Ajit

jeff

RE: Proposal for adding splay_tree_find (to find elements without updating the nodes).

[Aditya K]

> From: hiradi...@msn.com
> To: lopeziba...@gmail.com; jwakely@gmail.com
> CC: tbsau...@tbsaunde.org; gcc@gcc.gnu.org
> Subject: RE: Proposal for adding splay_tree_find (to find elements without 
> updating the nodes).
> Date: Mon, 16 Mar 2015 18:45:22 +
>
>
>
> 
>> From: lopeziba...@gmail.com
>> Date: Mon, 16 Mar 2015 17:04:58 +0100
>> Subject: Re: Proposal for adding splay_tree_find (to find elements without 
>> updating the nodes).
>> To: jwakely@gmail.com
>> CC: hiradi...@msn.com; tbsau...@tbsaunde.org; gcc@gcc.gnu.org
>>
>> On 16 March 2015 at 16:55, Jonathan Wakely  wrote:
>>> On 16 March 2015 at 15:54, Jonathan Wakely wrote:
 "DejaGnu" is not meant to be a link, but the wiki automatically treats
 any MixedCase word as a link.
>>>
>>> I've fixed that now.
>>
>> We can actually link to the DejaGNU page if someone is interested. But
>> probably they only need to find it on their own GNU/Linux, so I
>> mention that as well.
>>
>> Aditya, I hope it is clear now.
>
> Yes it is. Thanks.
>
> -Aditya

So I tested my patch, and there were no regressions in the make check

Please review the patch:
http://gcc.gnu.org/ml/gcc/2015-03/msg00179/splay.patch

Thanks,
-Aditya   

RE: Named parameters

[Nathan Ridge]

Note that a proposal for named arguments was recently presented to the C++ 
standards committee [1], and they did not seem receptive to it [2].

The proposal was for a different syntax (name : value), but the objections were 
not related to the syntax.

Regards,
Nate

[1] http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4172.htm
[2] 
http://theres-waldo.ca/2014/11/23/trip-report-c-standards-meeting-in-urbana-champaign-november-2014/
 (see list of rejected proposals in section "Evolution Working Group")
  

Re: Named parameters

[Arnaud Charlet]

> >If only the first variant is allowed (with the named parameters in the
> >order declared in the prototype), then this would not affect code
> >generation at all - the designators could only be used for static error
> >checking.
> >
> >If the second variant is allowed, then the parameters could be re-ordered.
> 
> This is indeed very useful - Fortran has this since the Fortran 90
> standard, albeit without the dots (it's unambiguous in Fortran).

Right, same for Ada:

   foo (a => 1, b => 2, c => 3);
   foo (c => 3, b => 2, a => 1);

Arno

Re: Named parameters

[Toon Moene]

On 03/16/2015 05:06 PM, David Brown wrote:


Basically, the idea is this:

int foo(int a, int b, int c);

void bar(void) {
foo(1, 2, 3);   // Normal call
foo(.a = 1, .b = 2, .c = 3) // Same as foo(1, 2, 3)
foo(.c = 3, .b = 2, .a = 1) // Same as foo(1, 2, 3)
}

If only the first variant is allowed (with the named parameters in the
order declared in the prototype), then this would not affect code
generation at all - the designators could only be used for static error
checking.

If the second variant is allowed, then the parameters could be re-ordered.


This is indeed very useful - Fortran has this since the Fortran 90 
standard, albeit without the dots (it's unambiguous in Fortran).


--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news

RE: Proposal for adding splay_tree_find (to find elements without updating the nodes).

[Aditya K]

> From: lopeziba...@gmail.com
> Date: Mon, 16 Mar 2015 17:04:58 +0100
> Subject: Re: Proposal for adding splay_tree_find (to find elements without 
> updating the nodes).
> To: jwakely@gmail.com
> CC: hiradi...@msn.com; tbsau...@tbsaunde.org; gcc@gcc.gnu.org
>
> On 16 March 2015 at 16:55, Jonathan Wakely  wrote:
>> On 16 March 2015 at 15:54, Jonathan Wakely wrote:
>>> "DejaGnu" is not meant to be a link, but the wiki automatically treats
>>> any MixedCase word as a link.
>>
>> I've fixed that now.
>
> We can actually link to the DejaGNU page if someone is interested. But
> probably they only need to find it on their own GNU/Linux, so I
> mention that as well.
>
> Aditya, I hope it is clear now.

Yes it is. Thanks.

-Aditya   

Re: [gomp4] Questions about "declare target" and "target update" pragmas

[Ilya Verbin]

On Tue, Mar 10, 2015 at 19:52:52 +0300, Ilya Verbin wrote:
> Hi Jakub,
> 
> I have one more question :)
> This testcase seems to be correct... or not?
> 
> #pragma omp declare target
> extern int G;
> #pragma omp end declare target
> 
> int G;
> 
> int main ()
> {
>   #pragma omp target update to(G)
> 
>   return 0;
> }
> 
> If yes, then we have a problem that the decl of G in varpool_node::get_create
> doesn't have "omp declare target" attribute.

Ping?

I am investigating run-fails on some benchmark, and have found a second
questionable place, where a function argument overrides a global array.
Just to be sure, is this a bug in the test?

#pragma omp declare target
int a1[50], a2[50];
#pragma omp end declare target

void foo (int a1[])
{
  #pragma omp target
{
  a1[10]++;
  a2[10]++;
}
}

int main ()
{
  a1[10] = a2[10] = 10;

  #pragma omp target update to(a1, a2)
  foo (a1);
  #pragma omp target update from(a1, a2)

  if (a1[10] != a2[10])
abort ();
  return 0;
}

Thanks,
  -- Ilya

Re: Proposal for another approach for Loop transformation with conditional in Loops.

[Richard Biener]

On March 16, 2015 7:15:23 PM GMT+01:00, Jeff Law  wrote:
>On 03/14/15 22:40, Ajit Kumar Agarwal wrote:
>> Hello All:
>>
>> I am proposing the new approach to Loop transformation as given below
>in the example For the loops with
>> conditional expression inside the Loops. The Loop body should be
>reducible control flow graph. The iteration
>> space is partitioned into different spaces for which either the
>cond_expr is true or cond_expr  is false. The
>> evaluation of cond_expr for the partitioned iteration spaces can be
>determined statically. For the partitioned
>> iterations and based on the analysis of cond_expr on the partitioned
>iterations spaces the Loops in fig (a) will
>> be transformed to Loops in fig (b).
>>
>> for the iteration spaces of the conditional inside the loop is live
>in  at the entry of the cond_expr and Live out
>> the Control flow graph is topological ordered with the basic blocks
>for the conditional CFG and the partitioned
>> iteration spaces can be formed for which the spaces can be true for
>conditional expr and false and unknown.
>>
>> Based on the above info and analysis the Loop of Fig (a) will be
>transformed to Loop Fig (b).
>>
>> This is much more optimized code as compared to the performance. The
>cases will be triggered for SPEC
>> Benchmarks. Loops is partitioned to different version with different
>iteration spaces. Optimized in the presence
>> Of the transformed generation of the loops without conditional.
>I fail to see how this is dramatically different than unswitching.  
>You 
>pull the condition out (it has to be loop invariant), then have two 
>instances of the loop, one for the THEN, the other for the ELSE.  You 
>obviously select one or the other based on the condition of V.
>
>Specific examples might be helpful in understanding how you see this as
>
>different than unswitching.

I think he is proposing loop splitting incase there are conditions in The IV 
itself.  Obviously those are not loop invariant.

Richard.

>jeff

Re: Proposal for another approach for Loop transformation with conditional in Loops.

[Jeff Law]

On 03/14/15 22:40, Ajit Kumar Agarwal wrote:

Hello All:

I am proposing the new approach to Loop transformation as given below in the 
example For the loops with
conditional expression inside the Loops. The Loop body should be reducible 
control flow graph. The iteration
space is partitioned into different spaces for which either the cond_expr is 
true or cond_expr  is false. The
evaluation of cond_expr for the partitioned iteration spaces can be determined 
statically. For the partitioned
iterations and based on the analysis of cond_expr on the partitioned iterations 
spaces the Loops in fig (a) will
be transformed to Loops in fig (b).

for the iteration spaces of the conditional inside the loop is live in  at the 
entry of the cond_expr and Live out
the Control flow graph is topological ordered with the basic blocks for the 
conditional CFG and the partitioned
iteration spaces can be formed for which the spaces can be true for conditional 
expr and false and unknown.

Based on the above info and analysis the Loop of Fig (a) will be transformed to 
Loop Fig (b).

This is much more optimized code as compared to the performance. The cases will 
be triggered for SPEC
Benchmarks. Loops is partitioned to different version with different iteration 
spaces. Optimized in the presence
Of the transformed generation of the loops without conditional.
I fail to see how this is dramatically different than unswitching.   You 
pull the condition out (it has to be loop invariant), then have two 
instances of the loop, one for the THEN, the other for the ELSE.  You 
obviously select one or the other based on the condition of V.


Specific examples might be helpful in understanding how you see this as 
different than unswitching.


jeff

Re: Named parameters

[Marc Glisse]

On Mon, 16 Mar 2015, David Brown wrote:


In a discussion on comp.lang.c, the subject of "named parameters" (or
"designated parameters") has come up again.  This is a feature that some
of us feel would be very useful in C (and in C++).  I think it would be
possible to include it in the language without leading to any conflicts
with existing code - it is therefore something that could be made as a
gcc extension, with a hope of adding it to the standards for a later C
standards revision.

I wanted to ask opinions on the mailing list as to the feasibility of
the idea - there is little point in my cluttering up bugzilla with an
enhancement request if the gcc developers can spot obvious flaws in the
idea.


Filing a report in bugzilla would be quite useless: language extensions 
are now almost automatically rejected unless they come with a proposal 
that has already been favorably seen by the standardization committee.


On the other hand, implementing the feature (in your own fork) is almost a 
requirement if you intend to propose this for standardization. And it 
should not be too hard.



Basically, the idea is this:

int foo(int a, int b, int c);

void bar(void) {
foo(1, 2, 3);   // Normal call
foo(.a = 1, .b = 2, .c = 3) // Same as foo(1, 2, 3)
foo(.c = 3, .b = 2, .a = 1) // Same as foo(1, 2, 3)
}


struct foo_args {
  int a, b, c;
};
void foo(struct foo_args);
#define foo(...) foo((struct foo_args){__VA_ARGS__})
void g(){
  foo(1,2,3);
  foo(.c=3,.b=2);
}

In C++ you could almost get away without the macro, calling f({1,2,3}), 
but f({.c=3}) currently gives "sorry, unimplemented". Maybe you would like 
to work on that?



If only the first variant is allowed (with the named parameters in the
order declared in the prototype), then this would not affect code
generation at all - the designators could only be used for static error
checking.

If the second variant is allowed, then the parameters could be re-ordered.


The aim of this is to make it easier and safer to call functions with a
large number of parameters.  The syntax is chosen to match that of
designated initialisers - that should be clearer to the programmer, and
hopefully also make implementation easier.

If there is more than one declaration of the function, then the
designators used should follow the most recent in-scope declaration.


An error may be safer, you would at least want a warning.


This feature could be particularly useful when combined with default
arguments in C++, as it would allow the programmer to override later
default arguments without specifying all earlier arguments.


C++ is always more complicated (so many features can interact in strange 
ways), I suggest you start with C.



At the moment, I am not asking for an implementation, or even /how/ it
might be implemented (perhaps a MELT plugin?) - I would merely like
opinions on whether it would be a useful and practical enhancement.


This is not such a good list for that, comp.lang.c is better suited. This 
will be a good list if you have technical issues implementing the feature.


--
Marc Glisse

Named parameters

[David Brown]

Hi,

In a discussion on comp.lang.c, the subject of "named parameters" (or
"designated parameters") has come up again.  This is a feature that some
of us feel would be very useful in C (and in C++).  I think it would be
possible to include it in the language without leading to any conflicts
with existing code - it is therefore something that could be made as a
gcc extension, with a hope of adding it to the standards for a later C
standards revision.

I wanted to ask opinions on the mailing list as to the feasibility of
the idea - there is little point in my cluttering up bugzilla with an
enhancement request if the gcc developers can spot obvious flaws in the
idea.


Basically, the idea is this:

int foo(int a, int b, int c);

void bar(void) {
foo(1, 2, 3);   // Normal call
foo(.a = 1, .b = 2, .c = 3) // Same as foo(1, 2, 3)
foo(.c = 3, .b = 2, .a = 1) // Same as foo(1, 2, 3)
}

If only the first variant is allowed (with the named parameters in the
order declared in the prototype), then this would not affect code
generation at all - the designators could only be used for static error
checking.

If the second variant is allowed, then the parameters could be re-ordered.


The aim of this is to make it easier and safer to call functions with a
large number of parameters.  The syntax is chosen to match that of
designated initialisers - that should be clearer to the programmer, and
hopefully also make implementation easier.

If there is more than one declaration of the function, then the
designators used should follow the most recent in-scope declaration.


This feature could be particularly useful when combined with default
arguments in C++, as it would allow the programmer to override later
default arguments without specifying all earlier arguments.


At the moment, I am not asking for an implementation, or even /how/ it
might be implemented (perhaps a MELT plugin?) - I would merely like
opinions on whether it would be a useful and practical enhancement.


David

Re: Proposal for adding splay_tree_find (to find elements without updating the nodes).

[Manuel López-Ibáñez]

On 16 March 2015 at 16:55, Jonathan Wakely  wrote:
> On 16 March 2015 at 15:54, Jonathan Wakely wrote:
>> "DejaGnu" is not meant to be a link, but the wiki automatically treats
>> any MixedCase word as a link.
>
> I've fixed that now.

We can actually link to the DejaGNU page if someone is interested. But
probably they only need to find it on their own GNU/Linux, so I
mention that as well.

Aditya, I hope it is clear now.

Re: Proposal for adding splay_tree_find (to find elements without updating the nodes).

[Jonathan Wakely]

On 16 March 2015 at 15:54, Jonathan Wakely wrote:
> "DejaGnu" is not meant to be a link, but the wiki automatically treats
> any MixedCase word as a link.

I've fixed that now.

Re: Proposal for adding splay_tree_find (to find elements without updating the nodes).

[Jonathan Wakely]

On 16 March 2015 at 15:51, Aditya K wrote:
> I started looking at the steps to test gcc, (https://gcc.gnu.org/Testing_GCC):
>
> In the first step: to install prerequisites 'dejagnu', tcl and Expect
> - The link to dejagnu does not have any information. for tcl and expect 
> there are no links.

"DejaGnu" is not meant to be a link, but the wiki automatically treats
any MixedCase word as a link.

You don't need links about them, you need to have them installed.

RE: Proposal for adding splay_tree_find (to find elements without updating the nodes).

[Aditya K]

> From: lopeziba...@gmail.com
> Date: Mon, 16 Mar 2015 15:16:55 +0100
> Subject: Re: Proposal for adding splay_tree_find (to find elements without 
> updating the nodes).
> To: tbsau...@tbsaunde.org; gcc@gcc.gnu.org; hiradi...@msn.com
>
>>> Thanks for the feedback, they were really helpful. I have updated the 
>>> patch. Please review this.
>>> Also, although I run `make check` while compiling gcc (with bootstrap 
>>> enabled), I'm not sure if 'omp' related tests were exercised.
>>> I'm still unfamiliar with several components of gcc. Any pointers on how to 
>>> ensure all tests were run, would be useful.
>>
>>
>> https://gcc.gnu.org/install/test.html should help, though unfortunately
>> you'll probably find the easiest way to check for regressions is to do
>> one run of straight trunk, then another with your patch. Saddly a bunch
>> of people have own scripts to deal with administrivia, but there isn't a
>> standardized way that's simple.
>
> I would recommend going through
>
> https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps
>
> at least once. If you find something wrong, confusing or not answered
> there, please ask here and CC me, and I will NOT answer you ;) what I
> will do is update it, so the answer is there for you but also for the
> next person that comes after you.
>
> Of course, it is a wiki, anyone can update it and they are welcome to do it.
>
> Cheers,
>
> Manuel.

Hi Manuel,

I started looking at the steps to test gcc, (https://gcc.gnu.org/Testing_GCC):

In the first step: to install prerequisites 'dejagnu', tcl and Expect
    - The link to dejagnu does not have any information. for tcl and expect 
there are no links.


Thanks,
-Aditya   

Re: How to implement '@' GDB-like operator for libcc1

[Tom Tromey]

> "Jan" == Jan Kratochvil  writes:

Jan> I have problems implementing '@' into GCC, could you suggest at which place
Jan> should I call build_array_type_nelts()?  Or is it the right way at all?

Jan> +case ATSIGN_EXPR:
Jan> +  orig_op0 = op0 = TREE_OPERAND (expr, 0);
Jan> +  orig_op1 = op1 = TREE_OPERAND (expr, 1);
[...]
Jan> +  ret = build_array_type_nelts (TREE_TYPE (op0), tree_to_uhwi (op1));

It seems like there should be some kind of reference to &op0, that is,
lowering ATSIGN_EXPR to *(typeof(OP0)[OP1]*)(&OP0).

Also, I this has to consider the case where OP1 is not a constant.

Tom

Re: Proposal for adding splay_tree_find (to find elements without updating the nodes).

[Manuel López-Ibáñez]

>> Thanks for the feedback, they were really helpful. I have updated the patch. 
>> Please review this.
>> Also, although I run `make check` while compiling gcc (with bootstrap 
>> enabled), I'm not sure if 'omp' related tests were exercised.
>> I'm still unfamiliar with several components of gcc. Any pointers on how to 
>> ensure all tests were run, would be useful.
>
>
> https://gcc.gnu.org/install/test.html should help, though unfortunately
> you'll probably find the easiest way to check for regressions is to do
> one run of straight trunk, then another with your patch.  Saddly a bunch
> of people have own scripts to deal with administrivia, but there isn't a
> standardized way that's simple.

I would recommend going through

https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

at least once. If you find something wrong, confusing or not answered
there, please ask here and CC me, and I will NOT answer you ;) what I
will do is update it, so the answer is there for you but also for the
next person that comes after you.

Of course, it is a wiki, anyone can update it and they are welcome to do it.

Cheers,

Manuel.

Re: How to implement '@' GDB-like operator for libcc1

[Manuel López-Ibáñez]

On 16 March 2015 at 10:58, Jan Kratochvil  wrote:
> If it is really difficult to implement '@' in GCC then yes, that's the other
> way.  I expected to learn GCC parser on this IMO-simpler case so one can later
> implement for example the '{TYPE} ADDR' GDB extension, dropping C++ class
> protections, FILE::VARIABLE or FUNCTION::VARIABLE notations etc.  So there are
> more topics for the C/C++ parser but I tried this one first.

I cannot speak for the C/C++ FE maintainers, so I hope they will speak
up on this and give you much more useful advice than mine. But I have
seen this happen a lot of times before and it kills me it it were to
happen to GDB. The story goes like this: Someone wants to use GCC for
something it was not designed for. They go modifying GCC following
what they think is the most straightforward way to achieve exactly
what they need. They end up with a huge patch or a fork that is not
very useful for anyone else apart from them. The GCC devs say "sorry,
we think this is not the right way, we think you could try this or
that", which means basically starting from scratch and with a
different set of requirements. Thus, they are forced to maintain a
patch/fork for eternity, which cannot keep up with the rate of change
in GCC, thus it ends up only working for GCC last version- 1, -2, -3
until the authors just give up.

That said, you did the right thing asking here now. Please, if you
don't get the answers that you want, just don't give up: insist and
chase people before going on your own.

Now, from my own limited perspective of GDB but my better picture of
how GCC works, I think your chances of success will be much better if
you really limit what @ can do. The only use-case I see for @ is to
print memory regions. For that, one does not need to parse arbitrary
expression containing @, just arbitrary expressions to the left and to
the right of @. I would go as far as forbidding parentheses around the
@ expression. (Using GCC statement expressions, the left and right
sides of @ can contain almost anything).

>> I think there are more options: GDB could also convert @ to something
>> that GCC can understand, like a function call, or a cast to a
>> gdb-defined type, and that will trigger the generation of the desired
>> DWARF.
>
> I do not see how GDB could properly parse the expression with proper operator
> priorities/association.

But you are forcing GCC to parse something that is not C/C++. I see a
lot of potential to mess things up. It should be clear to GDB users
that @ is not C/C++, thus they should not expect to work as such. If
you want to embed @ in arbitrary C/C++ programs, you would need to
define what @ means in every point of a C/C++ program, including
promotions, precedence relations, etc. Down that path I see the abyss
gazing back into us.

>> > Depending on the DWARF types of __gdb_expr_val and __gdb_expr_ptr_type GDB 
>> > will
>> > pass the boolean flag '__gdb_expr_take_address' to handle arrays 
>> > correctly, one
>> > can see it for:
>>
>> Would it be possible for GDB to generate code such that this trick is
>> generated for @? Perhaps by creating a dummy array variable, then
>> applying typeof(dummy) like you do below.
>
> Sorry I do not get it.  GDB does not know how many elements the array should
> have without parsing the expression on its own - and only GCC can parse C/C++.

Given, lexp@rexp, you could pass both lexp and rexp to GCC for
evaluation and finding their types. This is all you need, no?

Yes, it is more limited than accepting @ within arbitrary C/C++
programs, do you really need that? What does *a@3 + 1 mean? or *a@3 *
b@4 ?

Cheers,

Manuel.

Re: How to implement '@' GDB-like operator for libcc1

[Jonathan Wakely]

On 16 March 2015 at 09:58, Jan Kratochvil wrote:
> I expected to learn GCC parser on this IMO-simpler case so one can later
> implement for example the '{TYPE} ADDR' GDB extension, dropping C++ class
> protections,

There's the -fno-access-control flag to disable access checking, so I
would have expected "libcc1plus" to just set that when compiling C++.

Re: How to implement '@' GDB-like operator for libcc1

[Jan Kratochvil]

On Mon, 16 Mar 2015 10:33:26 +0100, Manuel López-Ibáñez wrote:
> On 16 March 2015 at 09:32, Jan Kratochvil  wrote:
> > On Mon, 16 Mar 2015 04:22:35 +0100, Manuel López-Ibáñez wrote:
> >> Thus, the question is what info GDB needs from GCC to be able to print
> >> the contents of the array.
> >
> > Variable with an array type in DWARF.
> 
> How does it work then for pointers?
> 
> int *p = malloc(...);
> 
> (gdb) p *p@3
> 
> should also work.

The idea was GCC would create an int[3] __gdb_expr_val variable for the result
and GDB would read that int[3] type from __gdb_expr_val's DWARF.


> >> And it probably just needs the type of whatever is to the left of @ and the
> >> value of whatever is to the right of @, no?
> >
> > There are two ways how to fix that.  As '@' makes sense only at the 
> > outermost
> > operator of an expression GDB could strip it and not to pass it to GCC at 
> > all.
> > But then there would be unhandled corner cases like parentheses:
> > (gdb) print (*a@3)
> 
> Would it be so difficult to strip parentheses? I honestly think it
> might be easier than adding special handling for @ to the C parser.

If it is really difficult to implement '@' in GCC then yes, that's the other
way.  I expected to learn GCC parser on this IMO-simpler case so one can later
implement for example the '{TYPE} ADDR' GDB extension, dropping C++ class
protections, FILE::VARIABLE or FUNCTION::VARIABLE notations etc.  So there are
more topics for the C/C++ parser but I tried this one first.


> I think there are more options: GDB could also convert @ to something
> that GCC can understand, like a function call, or a cast to a
> gdb-defined type, and that will trigger the generation of the desired
> DWARF.

I do not see how GDB could properly parse the expression with proper operator
priorities/association.


> > Depending on the DWARF types of __gdb_expr_val and __gdb_expr_ptr_type GDB 
> > will
> > pass the boolean flag '__gdb_expr_take_address' to handle arrays correctly, 
> > one
> > can see it for:
> 
> Would it be possible for GDB to generate code such that this trick is
> generated for @? Perhaps by creating a dummy array variable, then
> applying typeof(dummy) like you do below.

Sorry I do not get it.  GDB does not know how many elements the array should
have without parsing the expression on its own - and only GCC can parse C/C++.


Thanks,
Jan

Re: nvptx-tools on ARM

[Thomas Schwinge]

Hi!

On Mon, 09 Mar 2015 11:22:13 +0100, Enrico Calore  wrote:
> I would like to try GCC 5 with nvptx-tools on a NVIDIA Jetson board
> (armhf architecture), may I ask to you if it is supposed to work on that
> architecture?

We have not tried this.  To enable offloading for ARM targets, you'll
need to replicate the (very few) changes that we have applied to x86
target code.  Then, you'll likely run into .
The nvptx offloading code (in libgomp) has some hard-coded 64-bit
assumptions, .  (If I remember correctly,
the Jetson board has a 32-bit CPU.)  With these issues addressed, "it
should work".  :-)


Grüße,
 Thomas


signature.asc
Description: PGP signature

Re: How to implement '@' GDB-like operator for libcc1

[Manuel López-Ibáñez]

On 16 March 2015 at 09:32, Jan Kratochvil  wrote:
> On Mon, 16 Mar 2015 04:22:35 +0100, Manuel López-Ibáñez wrote:
>> Thus, the question is what info GDB needs from GCC to be able to print
>> the contents of the array.
>
> Variable with an array type in DWARF.

How does it work then for pointers?

int *p = malloc(...);

(gdb) p *p@3

should also work.

>> And it probably just needs the type of whatever is to the left of @ and the
>> value of whatever is to the right of @, no?
>
> There are two ways how to fix that.  As '@' makes sense only at the outermost
> operator of an expression GDB could strip it and not to pass it to GCC at all.
> But then there would be unhandled corner cases like parentheses:
> (gdb) print (*a@3)

Would it be so difficult to strip parentheses? I honestly think it
might be easier than adding special handling for @ to the C parser.

I think there are more options: GDB could also convert @ to something
that GCC can understand, like a function call, or a cast to a
gdb-defined type, and that will trigger the generation of the desired
DWARF.

> Then there also is an option to hook GDB somewhere into the expression parser
> of GCC.  GDB currently implements 'compile print' just by compiling a special
> generated .c file into .o and running .o + parsing the .o's DWARF to find the
> proper type, see below.

There is also the option that GDB calls directly into the parser and
when it detects an expression containing @ that GCC cannot parse, uses
GCC to split the left and right operand around @. This would need some
tweaking of the parser (override the error function, save intermediate
parsing results), but it goes in the right direction: Making the
parser more generally re-usable. I admit it is harder than the above.

> Depending on the DWARF types of __gdb_expr_val and __gdb_expr_ptr_type GDB 
> will
> pass the boolean flag '__gdb_expr_take_address' to handle arrays correctly, 
> one
> can see it for:

Would it be possible for GDB to generate code such that this trick is
generated for @? Perhaps by creating a dummy array variable, then
applying typeof(dummy) like you do below.

> (gdb) l
> 1   int main(void) {
> 2   int i=0; __auto_type i_val=i; typeof(i) *i_ptr_type;
> 3   int a[]={1,2,3}; __auto_type a_val=a; typeof(a) *a_ptr_type;
> 4   return 0; }
> (gdb) ptype i_val
> type = int
> (gdb) ptype i_ptr_type
> type = int *
> -> i_ptr_type == i_val * => __gdb_expr_take_address=true
> (gdb) ptype a_val
> type = int *
> (gdb) ptype a_ptr_type
> type = int (*)[3]
> -> i_ptr_type == (&*i_val)* && i_val is array => 
> __gdb_expr_take_address=false
> Implemented by:
> 
> https://github.com/tromey/gdb/commit/6ec13bc75ebbaa3b5fab8ecda8518af56cc5e2e8


Cheers,

Manuel.

Re: How to implement '@' GDB-like operator for libcc1

[Jan Kratochvil]

On Mon, 16 Mar 2015 04:22:35 +0100, Manuel López-Ibáñez wrote:
> >
> > But GDB features a useful custom expression operator '@':
> > https://sourceware.org/gdb/onlinedocs/gdb/Arrays.html
> >
> > I have problems implementing '@' into GCC, could you suggest at which place
> > should I call build_array_type_nelts()?  Or is it the right way at all?
> >
> > Testing it on a sample code - it should return 2:
> > int a[]={1,2,3};int main(void){ return (*a@3)[1]; }
> 
> Sorry if I'm missing something, but this example does not make sense
> to me. You can directly use a[1], no need for the @-operator here.

You are right but I did not want to complicate the reproducer by an interface
to GDB.


> In my experience (and again, sorry if I'm missing other interesting
> usercases), the utility of @ is to be able to do things like:
> 
> print a@3
> print (*&(something complicated expression))@(some integer expression)

Yes although it is missing one dereference, that is it should be:
print *a@3
print (*(something complicated expression))@(some integer expression)
I agree it is a bit counter-intuitive but this is how existing GDB '@'
operator works.


> Thus, the question is what info GDB needs from GCC to be able to print
> the contents of the array.

Variable with an array type in DWARF.


> And it probably just needs the type of whatever is to the left of @ and the
> value of whatever is to the right of @, no?

There are two ways how to fix that.  As '@' makes sense only at the outermost
operator of an expression GDB could strip it and not to pass it to GCC at all.
But then there would be unhandled corner cases like parentheses:
(gdb) print (*a@3)

So I tried to implement '@' as a proper GCC operator so that GCC creates full
array type in the DWARF.


Then there also is an option to hook GDB somewhere into the expression parser
of GCC.  GDB currently implements 'compile print' just by compiling a special
generated .c file into .o and running .o + parsing the .o's DWARF to find the
proper type, see below.


> Also note that given this code and breaking in main()
> 
> int a[]={1,2,3};int main(void){ return (a[1]); }
> 
> then:
> 
> (gdb) p a
> $1 = {1, 2, 3}
> (gdb) p a@3
> $2 = {{1, 2, 3}, {0, 0, 0}, {0, 0, 0}}
> 
> This is because:
> 
> (gdb) ptype a
> type = int [3]
> (gdb)  ptype a@3
> type = int [3][3]

There is missing one *:
(gdb) p a
$1 = {1, 2, 3}
(gdb) p *a@3
$2 = {1, 2, 3}
(gdb) ptype a
type = int [3]
(gdb) ptype *a@3
type = int [3]


> Thus, what happens currently when you do?
> (gdb) compile int a[]={1,2,3}
> (gdb) compile print a

(gdb) compile int a[]={1,2,3}
(gdb) compile print a
gdb command line:1:30: error: ‘a’ undeclared (first use in this function)

Because the compiled modules info is not persistent.  But with 'a' defined in
the inferior program one gets:
(gdb) compile print a
{1, 2, 3}

You may guess there is already a hack for this case, GDB compiles for
the 'compile print' command following stub:

void _gdb_expr (struct __gdb_regs *__regs, void * __gdb_out_param, int 
__gdb_expr_take_address) {
__auto_type __gdb_expr_val = /***The expression:***/ a;
typeof (/***The expression:***/ a) *__gdb_expr_ptr_type;
if (__gdb_expr_take_address)
memcpy (__gdb_out_param, &__gdb_expr_val, sizeof 
(*__gdb_expr_ptr_type));
else
memcpy (__gdb_out_param, __gdb_expr_val, sizeof 
(*__gdb_expr_ptr_type));
}

Depending on the DWARF types of __gdb_expr_val and __gdb_expr_ptr_type GDB will
pass the boolean flag '__gdb_expr_take_address' to handle arrays correctly, one
can see it for:

(gdb) l
1   int main(void) {
2   int i=0; __auto_type i_val=i; typeof(i) *i_ptr_type;
3   int a[]={1,2,3}; __auto_type a_val=a; typeof(a) *a_ptr_type;
4   return 0; }
(gdb) ptype i_val
type = int
(gdb) ptype i_ptr_type
type = int *
-> i_ptr_type == i_val * => __gdb_expr_take_address=true
(gdb) ptype a_val
type = int *
(gdb) ptype a_ptr_type
type = int (*)[3]
-> i_ptr_type == (&*i_val)* && i_val is array => 
__gdb_expr_take_address=false
Implemented by:

https://github.com/tromey/gdb/commit/6ec13bc75ebbaa3b5fab8ecda8518af56cc5e2e8

Before this auto-detection GDB would print only pointers, not arrays:
(gdb) l
1   int a[]={1,2,3,4,5};
(gdb) print a
$1 = {1, 2, 3, 4, 5}
(gdb) compile print a
(int *) 0x601040 

The problem is that '__auto_type' does not preserve the array type,
'__auto_type' converts arrays to pointers.  When I tried to "fix" that in
attached auto_type.patch GCC would error on such assignment
__auto_type a_val=a;
with:
gdb command line:1:30: error: array initialized from non-constant array 
expression


Thanks,
Jan
gdb command line:1:30: error: array initialized from non-constant array 
expression

   including converting functions and arrays t