Re: What to do with MAPPED_LOCATION
On May 14, 2006, at 11:54 AM, Daniel Berlin wrote: The other languages don't do that. ObjC/ObjC++ kinda do :-( I have a dream, one day...
Re: What to do with MAPPED_LOCATION
Steven Bosscher wrote: So now we have a half-completed conversion to USE_MAPPED_LOCATION which is currently broken (doesn't bootstrap for me with --enable-mapped-locations). Oops. Looks like I made and posted a patch, but never checked it in: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00882.html -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: What to do with MAPPED_LOCATION
Robert Dewar wrote:
Can someone point me to a clear high level spec for the proposed
interface for MAPPED_LOCATION support.
I don't know of any high-level spec, except libcpp/include/line-map.h.
A line_map (singular) specifies how a sub-range of source_location
integer cookies are to be interpreted. The line_maps table (there
is normally only one) is a collection of line_map mappings, in order
of the lowest source_location value mapped by each line_map, so finding
the correct line_map is a matter of binary search. (And of course
normally there is quite a bit of locality, especially when initially
parsing.)
Each line_map has a filename ('to_file') and starting line ('to_line'),
and then it's a simple calculation to map a source_location to a line
and column number.
Each line_map also has an included_from field which is normally the
index of the line_map of that included this line_map: i.e. the outer
line_map in the include stack. It seems plausible to generalize the
included_from field to also be used for expanded from or
instantiated from, but I haven't tried to think through that.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: What to do with MAPPED_LOCATION
We should go complete to mapped location. If Ada maintainers feel like they don't want to play with the team, well they can stay in their corner -- they more or less have already built they own ghetto; this issue is not going to make it worse or better. Sure, with that kind of reasoning, GCC will be able to rename itself into The C/C++ compiler for high-end x86 GNU/Linux machines in a few years. :-) On the other hand, I don't see any fundamental reasons why we couldn't use Gigi to shield the Ada front-end from the differences in the representation of source locations between successive generations of the core compiler. -- Eric Botcazou
Re: What to do with MAPPED_LOCATION
Eric Botcazou wrote: On the other hand, I don't see any fundamental reasons why we couldn't use Gigi to shield the Ada front-end from the differences in the representation of source locations between successive generations of the core compiler. That sounds reasonable. I don't think it is practical for the front end to use the gcc mapped locations for its own use, since it lacks a number of critical properties (including full representation of generic instantiations, and efficient comparisons within a unit to determine if one source location is before or after another), but it would certainly be possible for gigi to convert the source locations to whatever form the back end wants to use. Is there no abstract interface that would shield *any* front end from differences in representation of source locations between successive generations of the core compiler? Certainly we have made major changes in the GNAT representation without any change at all in clients (except to take advantage of new features). It seems to me that clients should know nothing whatever about the representation of source locations. The only invariant required by the GNAT front end is that source locations fit in 32-bits (since this accomodates up to 4 gigabytes of source in any one compilation, that sounds enough for ever!)
Re: What to do with MAPPED_LOCATION
Eric Botcazou wrote: We should go complete to mapped location. If Ada maintainers feel like they don't want to play with the team, well they can stay in their corner -- they more or less have already built they own ghetto; this issue is not going to make it worse or better. Sure, with that kind of reasoning, GCC will be able to rename itself into The C/C++ compiler for high-end x86 GNU/Linux machines in a few years. :-) Actually, the Fortran and objc people play nice too, and TBQH, i wouldn't mind if we were only a C/C++/F95/Objc compiler. :)
Re: What to do with MAPPED_LOCATION
Actually, the Fortran and objc people play nice too, and TBQH, i wouldn't mind if we were only a C/C++/F95/Objc compiler. Yeah, and I presume Objc is in the basket only because it's essentially C. F95 is a different case since it's a brand new compiler so it doesn't have to bother about the legacy of a 10+ years old production compiler like GNAT. -- Eric Botcazou
Re: What to do with MAPPED_LOCATION
On 5/14/06, Eric Botcazou [EMAIL PROTECTED] wrote: Actually, the Fortran and objc people play nice too, and TBQH, i wouldn't mind if we were only a C/C++/F95/Objc compiler. Yeah, and I presume Objc is in the basket only because it's essentially C. F95 is a different case since it's a brand new compiler so it doesn't have to bother about the legacy of a 10+ years old production compiler like GNAT. That is not an excuse for being so uncooperative as Ada maintainers can sometimes be when it concerns middle-end changes. It seems to me that GNAT has its own agenda (keep it working with every old backend out there) that unfortunately conflicts with the interests of the rest of the compiler collection (move on, front ends don't need to be compatible between releases). I think that was what gdr was trying to say. Anyway, if this can be done in gigi, then let's make a plan and work on it. I'd really like to see MAPPED_LOCATION become the default, and Ada is basically the major blocker right now, so we need to agree on something instead of arguing... ;-) But, we'll first have to try and get MAPPED_LOCATION to bootstrap again... Gr. Steven
Re: What to do with MAPPED_LOCATION
Eric Botcazou wrote: Actually, the Fortran and objc people play nice too, and TBQH, i wouldn't mind if we were only a C/C++/F95/Objc compiler. Yeah, and I presume Objc is in the basket only because it's essentially C. F95 is a different case since it's a brand new compiler so it doesn't have to bother about the legacy of a 10+ years old production compiler like GNAT. The real problem, as we all know, is that Adacore treats the GCC repo like an extension of their corporate repo, instead of as the main tree. The other languages don't do that.
Re: What to do with MAPPED_LOCATION
That is not an excuse for being so uncooperative as Ada maintainers can sometimes be when it concerns middle-end changes. That's the usual tension between backward compatibility and development. Clearly the Fortran maintainers, by starting again from scratch, and the C/C++ maintainers, by steadily ditching language extensions over the past few years, have chosen to favor the latter over the former. GNAT is probably not so biased. Anyway, if this can be done in gigi, then let's make a plan and work on it. I'd really like to see MAPPED_LOCATION become the default, and Ada is basically the major blocker right now, so we need to agree on something instead of arguing... ;-) Agreed. :-) -- Eric Botcazou
Re: What to do with MAPPED_LOCATION
Eric Botcazou [EMAIL PROTECTED] writes: | Actually, the Fortran and objc people play nice too, and TBQH, i | wouldn't mind if we were only a C/C++/F95/Objc compiler. | | Yeah, and I presume Objc is in the basket only because it's essentially C. | F95 is a different case since it's a brand new compiler so it doesn't have to | bother about the legacy of a 10+ years old production compiler like GNAT. Notice that the C and C++ parts are 10+ years old production compilers and they were converted. Yes, they are not GNAT. But if the argument is that this is GNAT, thus we don't have to follow the rest of the team, then fine, see my previous message. -- Gaby
Re: What to do with MAPPED_LOCATION
The real problem, as we all know, is that Adacore treats the GCC repo like an extension of their corporate repo, instead of as the main tree. The other languages don't do that. What of Apple and Objective-C++ ? -- Eric Botcazou
Re: What to do with MAPPED_LOCATION
On May 14, 2006, at 12:07 PM, Eric Botcazou wrote: The real problem, as we all know, is that Adacore treats the GCC repo like an extension of their corporate repo, instead of as the main tree. The other languages don't do that. What of Apple and Objective-C++ ? They don't complain and they update their sources when integrating into the mainline. They had to update Objective-C++ for the new C++ parser. Now it seems like Ada is going to be like Pascal and don't really want to be integrated inside GCC and play nicely. -- Pinski
Re: What to do with MAPPED_LOCATION
They don't complain and they update their sources when integrating into the mainline. They had to update Objective-C++ for the new C++ parser. Just like AdaCore had to update Ada for tree-ssa? -- Eric Botcazou
Re: What to do with MAPPED_LOCATION
Notice that the C and C++ parts are 10+ years old production compilers and they were converted. Right, no disagreement. My reply was intended to be more general, on the same level as Daniel's. -- Eric Botcazou
Re: What to do with MAPPED_LOCATION
On May 14, 2006, at 12:13 PM, Eric Botcazou wrote: They don't complain and they update their sources when integrating into the mainline. They had to update Objective-C++ for the new C++ parser. Just like AdaCore had to update Ada for tree-ssa? That's part of maintaining. Sometimes the languages will need to be updated for new or greater functionality. -eric
Re: What to do with MAPPED_LOCATION
Is there no abstract interface that would shield *any* front end from differences in representation of source locations between successive generations of the core compiler? Certainly we have made major changes in the GNAT representation without any change at all in clients (except to take advantage of new features). I don't think so, we'll have to devise in gigi. It seems to me that clients should know nothing whatever about the representation of source locations. The only invariant required by the GNAT front end is that source locations fit in 32-bits (since this accomodates up to 4 gigabytes of source in any one compilation, that sounds enough for ever!) The Ada compiler is a bit special because nearly all the diagnostics are issued by the front-end from its private internal representation. For the other compilers, especially the C family of compilers, there is no private internal representation since they essentially manipulate the tree IL directly. -- Eric Botcazou
Re: What to do with MAPPED_LOCATION
Eric Botcazou wrote: Is there no abstract interface that would shield *any* front end from differences in representation of source locations between successive generations of the core compiler? Certainly we have made major changes in the GNAT representation without any change at all in clients (except to take advantage of new features). I don't think so, we'll have to devise in gigi. It seems to me that clients should know nothing whatever about the representation of source locations. The only invariant required by the GNAT front end is that source locations fit in 32-bits (since this accomodates up to 4 gigabytes of source in any one compilation, that sounds enough for ever!) The Ada compiler is a bit special because nearly all the diagnostics are issued by the front-end from its private internal representation. For the other compilers, especially the C family of compilers, there is no private internal representation since they essentially manipulate the tree IL directly. Right, so it seems quite appropriate to have two representations for source locations, one for the Ada tree, which is completely independent of the tree IL, and one for the back end. That probably means that back end messages will lose the generic instantiation information, but that's not terrible.
Re: What to do with MAPPED_LOCATION
Steven Bosscher wrote: Anyway, if this can be done in gigi, then let's make a plan and work on it. I'd really like to see MAPPED_LOCATION become the default, and Ada is basically the major blocker right now, so we need to agree on something instead of arguing... ;-) I think that this is largely in people's imagination that Ada is a blocker here. Our commercial product is based on older back ends at this stage. For us gcc 4 is future development anyway (it is not stable enough yet to meet our product requirements, so we are quite happy to be in development mode here. The worse that happens is that the migration of our product release to gcc 4 is delayed, which is not a big deal). I don't see any major issue at this stage in going to the use of MAPPED_LOCATION in the back end. Of course we would like to get our product release moved to gcc 4.x ASAP, and we are working furiously on doing that (it's in much better shape now than it was a few months ago, and we hope for a beta release soon), but if there is a change that is a good idea in the back end, we should go ahead and do it, even if it delays the Ada migration (that's the attitude we took for SSA after all!) But, we'll first have to try and get MAPPED_LOCATION to bootstrap again... Well yes, and Ada is not standing in the way of this at all. If you recall, we knew that going to Tree SSA would break Ada, and we took the view that that's not a big deal. If Ada stops working in the latest fsf release for a period of time while we catch up, that's not an issue for us. It does mean that Ada may not be able to be built for a while, but a) that's not a big deal, since we don't enable the Ada bootstrap by default. b) we will work to fix it ASAP, because it is to our advantage to have Ada bootstrap properly, and we appreciate those who do regularly bootstrap Ada with the latest FSF sources (as we do internally of course). The point is that there is no need to wait for gigi to be adapted here. Steam ahead and get MAPPED_LOCATION working and bootstrapped, and we will fix gigi to correspond ASAP (gigi is heavily branched anyway, so it's not a problem). We do try to keep the front end stable and independent of middle end changes, and that's practical because of the use of a separate tree (this tree precisely matches the grammar of the Ada standard, and we find this correspondence vital to providing correct semantics). But gigi is a different matter entirely and does indeed change (radically if necessary) to match middle end and back end changes. I don't see MAPPED_LOCATION as a special case here. Robert Dewar
Re: What to do with MAPPED_LOCATION
Robert Dewar wrote: Right, so it seems quite appropriate to have two representations for source locations, one for the Ada tree, which is completely independent of the tree IL, and one for the back end. That probably means that back end messages will lose the generic instantiation information, but that's not terrible. First, the mapped source_location values can encode nested context. This is used for the C/C++ include file context. I think it is quite possible to use the same mechanism for generic instantiation information. Second, the backend *currently* has no support for generic instantiation information so I really don't understand your point about losing this information. You *might* lose it if you switch to using source_location in the front-end (but see my first point), as I've argued for in the past, but if you're translating internal source location to back-end representation at tree conversion time, which seems to be your preference, then I don't understand your point. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: What to do with MAPPED_LOCATION
Robert Dewar [EMAIL PROTECTED] writes: | Steven Bosscher wrote: | | Anyway, if this can be done in gigi, then let's make a plan and work | on it. I'd really like to see MAPPED_LOCATION become the default, and | Ada is basically the major blocker right now, so we need to agree on | something instead of arguing... ;-) | | I think that this is largely in people's imagination that Ada is a | blocker here. You mean we should not have taken Ada maintainers' earlier statements seriously? [...] | the view that that's not a big deal. If Ada stops working in the | latest fsf release for a period of time while we catch up, that's | not an issue for us. It does mean that Ada may not be able to be | built for a while, but [...] | a) that's not a big deal, since we don't enable the Ada bootstrap | by default. | | b) we will work to fix it ASAP, because it is to our advantage to | have Ada bootstrap properly, and we appreciate those who do | regularly bootstrap Ada with the latest FSF sources (as we do | internally of course). That is great. So, I suppose we have a deal. [...] | I don't see MAPPED_LOCATION as a special case here. OK. Thanks, -- Gaby
Re: What to do with MAPPED_LOCATION
Gabriel Dos Reis wrote: You mean we should not have taken Ada maintainers' earlier statements seriously? No, that's not the case, that discussion as far as I know was about changing the GNAT front end to adapt to this scheme. -- Gaby
Re: What to do with MAPPED_LOCATION
Robert Dewar wrote: Right, so it seems quite appropriate to have two representations for source locations, one for the Ada tree, which is completely independent of the tree IL, and one for the back end. That probably means that back end messages will lose the generic instantiation information, but that's not terrible. On Sun, May 14, 2006 at 03:32:49PM -0700, Per Bothner wrote: First, the mapped source_location values can encode nested context. This is used for the C/C++ include file context. I think it is quite possible to use the same mechanism for generic instantiation information. It would seem that C++ templates would have the same issues as Ada generic instantiation, right?
Re: What to do with MAPPED_LOCATION
Per Bothner wrote: Robert Dewar wrote: Right, so it seems quite appropriate to have two representations for source locations, one for the Ada tree, which is completely independent of the tree IL, and one for the back end. That probably means that back end messages will lose the generic instantiation information, but that's not terrible. First, the mapped source_location values can encode nested context. This is used for the C/C++ include file context. I think it is quite possible to use the same mechanism for generic instantiation information. I agree it is quite possible, though there are other issues besides the nested context for the front end. Second, the backend *currently* has no support for generic instantiation information so I really don't understand your point about losing this information. You *might* lose it if you switch to using source_location in the front-end (but see my first point), as I've argued for in the past, but if you're translating internal source location to back-end representation at tree conversion time, which seems to be your preference, then I don't understand your point. To be investigated, it really depends on when gigi switches the representations, and when error messages are issued. It is quite true that the real back end messages (which are largely irrelevant for Ada users), do not have the full source information (that's true now). It is the error messages issued by gigi that are my concern. But I really don't know enough to be sure. Anyway, my previous point was that if we lose some information on those messages, it's not a big deal, nearly all significant warnings and errors are issued by the front end, and long term plans move in the direction of depending even less on the back end messages than we do now.
Re: What to do with MAPPED_LOCATION
Joe Buck wrote: It would seem that C++ templates would have the same issues as Ada generic instantiation, right? I would certainly think so. For the Ada front end we need to be able to encode a complete nest of generic instantiations using a single 32-bit location indicator. I just don't know enough about the MAPPED_LOCATION feature to know for myself whether it provides that capability. I will make it my job to learn more about the detailed technical issues here. My overall point was to agree with Eric that there should be no great barrier in doing a translation with gigi no matter what the requirements and limitations are. Can someone point me to a clear high level spec for the proposed interface for MAPPED_LOCATION support.
Re: What to do with MAPPED_LOCATION
Steven Bosscher [EMAIL PROTECTED] writes: | Hi, | | A long time ago, Per added USE_MAPPED_LOCATION, but a full switch-over was | held up by (fixable) PCH issues and by Ada maintainers who expect problems | for GNAT if USE_MAPPED_LOCATION becomes the default. | | The latest discussions I could find about this concluded that it should | work for Ada too (http://gcc.gnu.org/ml/gcc/2004-10/msg00251.html). But | when Per posted a patch to make it work, it was rejected anyway by GNAT | maintainers because we do not want to create a strong dependency between | the Ada front-end and one particular GCC back-end notion of linemap/source | location (http://gcc.gnu.org/ml/gcc/2005-03/msg00924.html). | | Then, nothing happened... | | So now we have a half-completed conversion to USE_MAPPED_LOCATION which is | currently broken (doesn't bootstrap for me with --enable-mapped-locations). | | Question: should USE_MAPPED_LOCATION be taken out again now? Or is anyone | going to work on it to complete this project? We should go complete to mapped location. If Ada maintainers feel like they don't want to play with the team, well they can stay in their corner -- they more or less have already built they own ghetto; this issue is not going to make it worse or better. -- Gaby
Re: What to do with MAPPED_LOCATION
I'll take a look at the bootstrap failure if no-one beats me to it. (I'm out in the country-side, and though I have good net access it's a little easier to wait until I'm home Sunday evening.) Is there a volunteer to implement save/restore the line table for PCH? Ben Elliston and I talked about it, but I don't know if he's available. Worst case, I guess I could steal the time to do it, but if nothing else it would be good to get more people comfortable with how this all works. And of course Ada needs MAPPED_LOCATION support. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
