public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Per Bothner <per@bothner.com>
To: Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
Cc: gcc@gcc.gnu.org
Subject: Re: Ada, treelang needs to be converted to --enable-mapped-location
Date: Mon, 04 Oct 2004 11:44:00 -0000	[thread overview]
Message-ID: <4160FB8B.4010108@bothner.com> (raw)
In-Reply-To: <10410022053.AA16576@vlsi1.ultra.nyu.edu>

Richard Kenner wrote:

>     To summarize:  you can create the Source_Ptr -> source_location
>     mapping in two basic ways:  interleaved with lexing, or as a
>     mapping when the Source_Buffer is read in.  Whichever you prefer.
> 
> I guess the question is what does "read" mean in the context of a
> compiler that doesn't call the lexer library.

I'm confused.  What is "the lexer library"?  It certainly seems that
Ada calls a lexer library - it appears to be the Scans package. If you 
mean libcpp (except for line-map.[hc]), that's not a lexer library,
that's a pre-processor library.  It is not used for Java or Fortran
either.

Don't get confused by line-map.[hc] being in libcpp.  That's mainly
because some people wanted to put libcpp in a separate top-level
library, and because libcpp depends on line-map[hc].  Logically,
line-map.[hc] is a separate library, but that seemed overkill.

My intention by the word "read" was when when the character of the
source file are read into the compiler's Source_Buffer, which from
what I gather happens *before* lexing.

My suggestion that one option is to create thr Source_Ptr ->
source_location mapping (i.e. data structures to make the mapping
reasonably efficient) be done more-or-less at the same time as the
source file is read into a Source_Buffer and Source_Ptr mapping is
updated.

Alternatively, you can so it using call-backs to line-map.[hc] while the
Ada front-end is scanning the Source_buffer.  That is my recommendation.

> It's tricky to make calls from the Ada part of the code since, as Geert
> pointed out, that code is also used wiht non-GCC back-ends.

Yes, but that doesn't preclude using the line_map structure, even
with non-GCC back-ends.  There is no reason why the Ada front-end
can't use line_map for a program that say just does analysis and
never touches a tree or an rtx.

The Source_Ptr type appears to be an abstract source position encoded
as a int.  I see no reason why you can't change its *implementation*
to be the source_location type defined in line-map.h.  You can do this
*regardless* of whether "back-end" you use.  True, it's a non-trivial
change, and since I obviously don't know all the ramifications and
features of your current implementation, it's not my place to suggest
you make such a pervasive change.  However, my instinct is that would
be the best long-term solution.

> Moreover, it's quite common for the Ada front-end to read a file and
> no item in the file is in the produced tree.

Like C, C++, and Java.

>> So I'd interpret "read" as meaning "being asked to convert the first
> GNAT tree node using this file into a GCC node".

You can certainly do that.  It's not what I would have suggested, but
it may be a reasonable solution.

> Is there a way to find
> out if a filename has been seen already or do we need a separate hash table
> just for that purpose?

Whether a filename has been seen is a front-end issue.

You clearly don't need a separate hash table, if you're willing to add a
boolean field to the Source_Buffer type.

Alternatively, the (relatively new) TRANSLATION_UNIT_DECL may be a
reasonably place to hang per-source-file data.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

  reply	other threads:[~2004-10-04  7:28 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-03  7:13 Richard Kenner
2004-10-04 11:44 ` Per Bothner [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-10-07 19:39 Richard Kenner
2004-10-07 13:15 Richard Kenner
2004-10-07 12:57 Richard Kenner
2004-10-07 18:08 ` Mark Mitchell
2004-10-07  5:56 Richard Kenner
2004-10-07  6:24 ` Mark Mitchell
2004-10-07  8:33   ` Steven Bosscher
2004-10-07  9:03     ` Mark Mitchell
2004-10-07 10:07     ` Florian Weimer
2004-10-07 17:04       ` Daniel Jacobowitz
2004-10-08  0:35         ` Florian Weimer
2004-10-07  6:42 ` Robert Dewar
2004-10-07  6:50   ` Robert Dewar
2004-10-07 10:04   ` Laurent GUERBY
2004-10-11  7:33   ` Per Bothner
2004-10-07  5:07 Richard Kenner
2004-10-07  7:19 ` Steven Bosscher
2004-10-07  9:52   ` Robert Dewar
2004-10-07  0:44 Richard Kenner
2004-10-07  1:07 ` Robert Dewar
2004-10-07  1:42 ` Per Bothner
2004-10-06 23:25 Richard Kenner
2004-10-07  5:16 ` Mark Mitchell
2004-10-06 22:54 Richard Kenner
2004-10-06 23:25 ` Per Bothner
2004-10-07  1:06   ` Robert Dewar
2004-10-07  1:42     ` Per Bothner
2004-10-06 22:03 Richard Kenner
2004-10-06 22:35 ` Per Bothner
2004-10-06 17:46 Richard Kenner
2004-10-06 17:00 Richard Kenner
2004-10-06 19:11 ` Zack Weinberg
2004-10-06 13:17 Richard Kenner
2004-10-06 14:05 ` Zack Weinberg
2004-10-06 15:45   ` Geert Bosch
2004-10-06 15:52     ` Zack Weinberg
2004-10-06 16:09       ` Geert Bosch
2004-10-06 16:34         ` Zack Weinberg
2004-10-06 16:58           ` Geert Bosch
2004-10-06 18:52             ` Zack Weinberg
2004-10-06 21:58               ` Laurent GUERBY
2004-10-06 21:37 ` Per Bothner
2004-10-06 23:15   ` Joe Buck
2004-09-30 11:00 Richard Kenner
2004-10-01  2:58 ` Per Bothner
2004-09-30  0:57 Richard Kenner
2004-09-30  2:09 ` Per Bothner
2004-09-30  6:58   ` James A. Morrison
2004-09-30  8:03   ` Geert Bosch
2004-09-30  8:17     ` Per Bothner
2004-09-30 17:10       ` Geert Bosch
2004-09-30 19:56         ` Per Bothner
2004-09-30 20:02           ` Geert Bosch
     [not found]             ` <415C664B.6030905@bothner.com>
2004-10-06 15:36               ` Geert Bosch
2004-09-29 23:32 Per Bothner
2004-09-30  1:27 ` Zack Weinberg
2004-09-30  1:37 ` Matt Austern
2004-09-30  5:48   ` Per Bothner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4160FB8B.4010108@bothner.com \
    --to=per@bothner.com \
    --cc=gcc@gcc.gnu.org \
    --cc=kenner@vlsi1.ultra.nyu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).