Re: Question/proposal for USE_MAPPED_LOCATION and Ada

Re: Question/proposal for USE_MAPPED_LOCATION and Ada

[Richard Kenner]

    Is that what you mean with "chain of locations"?

I believe it is, but my question is where is the code that does that?
Is it part of the line-map logic?

Re: Question/proposal for USE_MAPPED_LOCATION and Ada

[Giovanni Bajo]

Richard Kenner wrote:

>     Is that what you mean with "chain of locations"?
>
> I believe it is, but my question is where is the code that does that?

cp/error.c, print_instantiation_full_context and
print_instantiation_partial_context.

Giovanni Bajo

Re: Question/proposal for USE_MAPPED_LOCATION and Ada

[Richard Kenner]

    > I believe it is, but my question is where is the code that does that?

    cp/error.c, print_instantiation_full_context and
    print_instantiation_partial_context.

So this is language-specific code, right, and not part of the line-map or
language-independent diagnostic code?

Re: Question/proposal for USE_MAPPED_LOCATION and Ada

[Giovanni Bajo]

Richard Kenner wrote:

>     cp/error.c, print_instantiation_full_context and
>     print_instantiation_partial_context.
>
> So this is language-specific code, right, and not part of the
> line-map or language-independent diagnostic code?

Yes, and we could not use a language-independent version for C++, because we do
not dump *only* the line numbers of the instantiation context, but also the
declaration causing the instantiation. So we need a chain of DECLs in the first
place. An independent chain of locations only would be useless. What we
actually store is a chain of tinst_level_s structures (defined in
cp/cp-tree.h), where each node contains a declaration and a locus. I assume Ada
can be worked to do the same.

Giovanni Bajo

Re: Question/proposal for USE_MAPPED_LOCATION and Ada

[Robert Dewar]

Giovanni Bajo wrote:

> Yes, and we could not use a language-independent version for C++, because we do
> not dump *only* the line numbers of the instantiation context, but also the
> declaration causing the instantiation. So we need a chain of DECLs in the first
> place. An independent chain of locations only would be useless. What we
> actually store is a chain of tinst_level_s structures (defined in
> cp/cp-tree.h), where each node contains a declaration and a locus. I assume Ada
> can be worked to do the same.

Yes, but I don't see any gain in doing so. Right now, GNAT captures the
instantiation information without needing to create any additional data
structures, except entries in the source file table (one per instance).
> 
> Giovanni Bajo
> 

Question/proposal for USE_MAPPED_LOCATION and Ada

[Richard Kenner]

Am I missing something or is the only use of linemap information in
the middle-end in tree.c:expand_location?

If so, then it would seem the simplest approach is to an a
LANGHOOK_EXPAND_LOCATION which defaults to calling expand_location but
for Ada would point to essentially what is now Sloc_to_locus.  It seems
to me that this would be a very tiny piece of code everywhere and would
completely avoid the need for redundant source position tables (note
that what's in linemap.c is very C-centric in its use of terms like include
files).

Wouldn't this work?

Re: Question/proposal for USE_MAPPED_LOCATION and Ada

[Geert Bosch]

Steven,

You mentioned in an earlier email that the Fortran compiler
has a line map as well. A quick look at the sources seems
to indicate that Fortran already has a locus allocated for
every position, and langhook as described by Richard could
be trivially implemented by using an indirection. Does
that seem correct to you?

As Zack mentioned, having two isomorphic representations of the
same thing wastes time and space, so it would be nice to avoid
using line-map for those front ends that do not need it.

   -Geert

On Oct 6, 2004, at 16:23, Richard Kenner wrote:
> If so, then it would seem the simplest approach is to an a
> LANGHOOK_EXPAND_LOCATION which defaults to calling expand_location but
> for Ada would point to essentially what is now Sloc_to_locus.  It seems
> to me that this would be a very tiny piece of code everywhere and would
> completely avoid the need for redundant source position tables (note
> that what's in linemap.c is very C-centric in its use of terms like 
> include
> files).

Re: Question/proposal for USE_MAPPED_LOCATION and Ada

[Steven Bosscher]

On Wednesday 06 October 2004 22:54, Geert Bosch wrote:
> Steven,
>
> You mentioned in an earlier email that the Fortran compiler
> has a line map as well. A quick look at the sources seems
> to indicate that Fortran already has a locus allocated for
> every position,

Nope.  Fortran has already been converted to use source_location
to store locations.

> and langhook as described by Richard could
> be trivially implemented by using an indirection. Does
> that seem correct to you?

For Fortran, please no.  I see no reason why we would need to have
this indirection, source_location seems to work Just Fine for Fortran.


> As Zack mentioned, having two isomorphic representations of the
> same thing wastes time and space, so it would be nice to avoid
> using line-map for those front ends that do not need it.

"Do not need it" is the part that remains vague to me in this whole
discussion.  My (I'll admit, limited) understanding of all this is
that:
 - The goal is to have a shared GCC diagnostics machinery;
 - For that all front ends need to represent locations using
   some shared representation;
 - We *always* had a backend representation of filenames and
   line numbers in the middle/back end.  All Per does is change
   the representation to some thing that needs linemap.[ch].

Having two isomorphic representations doesn't seem like such a big
deal to me.  Always been like that AFAICT: Ada has its own (very
nice) diagnositics machinery, and it uses its own representation for
locations.  Both is also used to be true for Fortran.  The Fortran
front end used to simply translate its own location information to
that of GCC when translating from our intermediate representation to
GENERIC (see gfc_{get,set}_backend_locus).

I don't think having your own location representation is a waste of
space and time.  Zack likes clean, I'm more pragmatic: It's a design
decision.

In the Fortran case, the question is:  Does GCC provide adequate
language independent diagnostics machinery? (A: apparently yes, and
with a little luck we'll even get column information back!).
In your case, the question is: Do you want our front end to depend on
linemap.[ch] outside gigi?  If not, then implement your own location
representation, translate your representation to that of GCC, accept
the space and time penalty, and be done with it.

Let's be realistic, this penalty really is not that big if you already
are translating your own front end internal representation to GENERIC.
There still appears to be some concern about efficiency (or anyway,
*speculation* about efficiency, not numbers), but I think of that as a
detail of the implementation, which can be improved if it turns out to
be a real problem.

But since y'all seem to see enough other problems to have this whole
discussion, I probably missed a few important points ;-)


Gr.
Steven

Re: Question/proposal for USE_MAPPED_LOCATION and Ada

[Robert Dewar]

Steven Bosscher wrote:

> I don't think having your own location representation is a waste of
> space and time.  Zack likes clean, I'm more pragmatic: It's a design
> decision.

One thing to be aware of in the Ada case is the requirement for
properly tracking the distinction between a generic template and
its instantiations, to all depths of instantiation. In the GNAT
front end, a 32-bit source location is sufficient to record both
the source location in the generic template and the source location
of all instantiations. This is quite important for getting good
error message placement. Source location here = line/column.
> 
> In the Fortran case, the question is:  Does GCC provide adequate
> language independent diagnostics machinery? (A: apparently yes, and
> with a little luck we'll even get column information back!).
> In your case, the question is: Do you want our front end to depend on
> linemap.[ch] outside gigi?  If not, then implement your own location
> representation, translate your representation to that of GCC, accept
> the space and time penalty, and be done with it.

It's probably not that big a penalty I would guess, though, as above,
I would guess this is a "lossy" translation, and that the gcc messages
won't know about instantiations.

Re: Question/proposal for USE_MAPPED_LOCATION and Ada

[Joe Buck]

On Wed, Oct 06, 2004 at 06:34:46PM -0400, Robert Dewar wrote:
> One thing to be aware of in the Ada case is the requirement for
> properly tracking the distinction between a generic template and
> its instantiations, to all depths of instantiation.

Don't we have the same issue in C++?

Re: Question/proposal for USE_MAPPED_LOCATION and Ada

[Robert Dewar]

Joe Buck wrote:
> On Wed, Oct 06, 2004 at 06:34:46PM -0400, Robert Dewar wrote:
> 
>>One thing to be aware of in the Ada case is the requirement for
>>properly tracking the distinction between a generic template and
>>its instantiations, to all depths of instantiation.
> 
> 
> Don't we have the same issue in C++?

I would think so, but I am not aware of the capability in C++
of having an error message refer to the template location and
to chain of locations where the template is instantiated.
Perhaps I just don't know :-)

Re: Question/proposal for USE_MAPPED_LOCATION and Ada

[Steven Bosscher]

On Thursday 07 October 2004 01:03, Robert Dewar wrote:
> I would think so, but I am not aware of the capability in C++
> of having an error message refer to the template location and
> to chain of locations where the template is instantiated.
> Perhaps I just don't know :-)

C++ gives you something like this:

/usr/include/g++-2/stl_deque.h:747: warning: comparison between signed and unsigned
/usr/include/g++-2/stl_deque.h: In method `void deque<int,__default_alloc_template<true,0>,0>::reserve_map_at_front<int, alloc, 0>(unsigned int = 1)':
/usr/include/g++-2/stl_deque.h:1219:   instantiated from `deque<int,__default_alloc_template<true,0>,0>::new_elements_at_front<int, alloc, 0>(unsigned int)'
/usr/include/g++-2/stl_deque.h:609:   instantiated from `deque<int,__default_alloc_template<true,0>,0>::reserve_elements_at_front<int, alloc, 0>(unsigned int)'
/usr/include/g++-2/stl_deque.h:947:   instantiated from `deque<int,__default_alloc_template<true,0>,0>::insert<__deque_iterator<int,const int &,const int &,0>>(__deque_iterator<int,int &,int *,0>, __deque_iterator<int,const int &,const int &,0>, __deque_iterator<int,const int &,const int &,0>, forward_iterator_tag)'
/usr/include/g++-2/stl_deque.h:508:   instantiated from `deque<int,__default_alloc_template<true,0>,0>::insert<__deque_iterator<int,const int &,const int &,0>>(__deque_iterator<int,int &,int *,0>, __deque_iterator<int,const int &,const int &,0>, __deque_iterator<int,const int &,const int &,0>)'
/usr/include/g++-2/stl_deque.h:424:   instantiated from `deque<int,__default_alloc_template<true,0>,0>::operator =<int, alloc, 0>(const deque<int,__default_alloc_template<true,0>,0> &)'
t.cc:3:   instantiated from here
/usr/include/g++-2/stl_deque.h:638: warning: comparison between signed and unsigned

Is that what you mean with "chain of locations"?

Gr.
Steven

Re: Question/proposal for USE_MAPPED_LOCATION and Ada

[Robert Dewar]

Steven Bosscher wrote:
> On Thursday 07 October 2004 01:03, Robert Dewar wrote:
> 
>>I would think so, but I am not aware of the capability in C++
>>of having an error message refer to the template location and
>>to chain of locations where the template is instantiated.
>>Perhaps I just don't know :-)
> 
> 
> C++ gives you something like this:
> 
> /usr/include/g++-2/stl_deque.h:747: warning: comparison between signed and unsigned
> /usr/include/g++-2/stl_deque.h: In method `void deque<int,__default_alloc_template<true,0>,0>::reserve_map_at_front<int, alloc, 0>(unsigned int = 1)':
> /usr/include/g++-2/stl_deque.h:1219:   instantiated from `deque<int,__default_alloc_template<true,0>,0>::new_elements_at_front<int, alloc, 0>(unsigned int)'
> /usr/include/g++-2/stl_deque.h:609:   instantiated from `deque<int,__default_alloc_template<true,0>,0>::reserve_elements_at_front<int, alloc, 0>(unsigned int)'
> /usr/include/g++-2/stl_deque.h:947:   instantiated from `deque<int,__default_alloc_template<true,0>,0>::insert<__deque_iterator<int,const int &,const int &,0>>(__deque_iterator<int,int &,int *,0>, __deque_iterator<int,const int &,const int &,0>, __deque_iterator<int,const int &,const int &,0>, forward_iterator_tag)'
> /usr/include/g++-2/stl_deque.h:508:   instantiated from `deque<int,__default_alloc_template<true,0>,0>::insert<__deque_iterator<int,const int &,const int &,0>>(__deque_iterator<int,int &,int *,0>, __deque_iterator<int,const int &,const int &,0>, __deque_iterator<int,const int &,const int &,0>)'
> /usr/include/g++-2/stl_deque.h:424:   instantiated from `deque<int,__default_alloc_template<true,0>,0>::operator =<int, alloc, 0>(const deque<int,__default_alloc_template<true,0>,0> &)'
> t.cc:3:   instantiated from here
> /usr/include/g++-2/stl_deque.h:638: warning: comparison between signed and unsigned
> 
> Is that what you mean with "chain of locations"?

Yes, indeed, sorry, I was not aware of this, last time I tried, I did not get this.

SO, that means that it should be possible to map the Ada into the same kind of
structure. Is there no provision for column numbers? That seems a pity.
> 
> Gr.
> Steven

Re: Question/proposal for USE_MAPPED_LOCATION and Ada

[James A. Morrison]

Robert Dewar <dewar@gnat.com> writes:
> SO, that means that it should be possible to map the Ada into the same kind of
> structure. Is there no provision for column numbers? That seems a pity.

 Column numbers are part of the source_location.  However, the code in
diagnostic.c doesn't use them yet.

-- 
Thanks,
Jim

http://www.student.cs.uwaterloo.ca/~ja2morri/
http://phython.blogspot.com
http://open.nit.ca/wiki/?page=jim

Re: Question/proposal for USE_MAPPED_LOCATION and Ada

[Robert Dewar]

James A. Morrison wrote:
> Robert Dewar <dewar@gnat.com> writes:
> 
>>SO, that means that it should be possible to map the Ada into the same kind of
>>structure. Is there no provision for column numbers? That seems a pity.
> 
> 
>  Column numbers are part of the source_location.  However, the code in
> diagnostic.c doesn't use them yet.

OK, fair enough.
>