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 inte
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.
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...
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
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 instantia
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 info
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
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
| > some
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, bu
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 larg
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
> 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 ta
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 lang
> 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
> 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
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 t
> 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
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 n
> 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 s
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'
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
> 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 l
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,
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 prac
> 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,
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
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
27 matches
Mail list logo