> 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,
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
Hi everybody,
I decided to split the modification in two parts:
- add an __asm__ () statement to control the value of
the segment registers from an high level language;
This __asm__ () statement is then used as follow:
register short a __asm__ ("es");
int main(int argc, char **argv)
The constant pool placement that sh_reorg does has somewhat hapazard
results.
It does not take execution frequencies into account, so if you are
unlucky, you
can end up with a constant table wedged into some hoit spot of the code,
which not
only adds an extra jump into the critical path, but can
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,
On Mon, May 15, 2006 at 12:09:00AM +0800, Rémy Saissy wrote:
> To manage the manipulation of the register class, I added entries in
> the i386.md file.
>
> ;; get a value from a segment register.
> (define_insn "store_seg"
> [(set (match_operand:SI 0 "nonimmediate_operand" "")
>(match_ope
> 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
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'
I've been on vacation for a week -- but I'm back now and reading through
the 600 or so messages in my GCC folder. I hope to have an
understanding of where we are by the end of the day, and, assuming I can
reach that point, an update as to at least the 4.1.1 release plan.
I see that I've been impl
> 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 <[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
> 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 t
> 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 lang
> 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
Richard Sandiford wrote:
> DJ Delorie <[EMAIL PROTECTED]> writes:
>> How about this? Tested under mipsisa64-elf with no regressions. The
>> other two I found by inspection; they're the only other two that have
>> .sdata and use -G 0.
>
> Looks good to me FWIW, although I can't approve it. I won
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 larg
Kazu Hirata wrote:
> Hi Mark,
>
> I have a question about your patch for PR c++/26534.
> When build_unary_op builds TRUTH_NOT_EXPR, it calls
> perform_implicit_conversion to convert p->field to the boolean type.
> (FWIW, p->field is expressed as
> >). The call to perform_implicit_conversion ev
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
dear gcc advancer user:
I am try to install gcc in my MAC OS X 7.9, by down load from apple
s website's gcc-5250, but when I did ./configure
-
Union-Souths-Computer:~/gcc-5250 UnionS
On May 14, 2006, at 3:48 PM, fsshl plinlin wrote:
dear gcc [developers]:
I am try to install gcc in my MAC OS X 7.9, by down load from apple
s website's gcc-5250, but when I did ./configure
Yes that is correct we (GCC) don't support in 4.1.x building in the
source
directory and yes it i
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
On 5/15/06, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
On Mon, May 15, 2006 at 12:09:00AM +0800, Rémy Saissy wrote:
> To manage the manipulation of the register class, I added entries in
> the i386.md file.
>
> ;; get a value from a segment register.
> (define_insn "store_seg"
> [(set (
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 info
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
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
31 matches
Mail list logo
