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...
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:
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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,
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
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 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
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
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
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
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
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
28 matches
Mail list logo
