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: Segment registers support for i386
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)
{
short b;
b = a;
a = 0x2a;
printf("old value: %x new value: %x\n", b, a);
return (0);
}
- add an __attribute__ ((__far__())) to allow pointers to
choose their data segment.
This __attribute__(()) statement is then used as follow:
int *gs_p __attribute__ ((__far__("gs"))) = 0x2a;
int main(int argc, char **argv)
{
int *fs_p __attribute__((__far__("fs"))) = 0x0;
fs_p[1] = 10;
gs_p[0] = fs_p[0];
return (0);
}
Presently I have a problem with the first part.
I have added the the entries for es,fs and gs at the end of
FIXED_REGISTERS under the value 1,1,1 and in
CALL_USED_REGISTERS with the value 1,1,1
I also add the entries at the end of REG_ALLOC_ORDER and in
both HI_REGISER_NAMES and ADDITIONAL_REGISTER_NAMES.
Because those registers are different, I have created a new
register class at the end of the reg_class enum and added
the relevant REG_CLASS_NAMES and REG_CLASS_CONTENTS entries.
At least, I added the 's' id in REG_CLASS_FROM_LETTER.
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_operand:SI 1 "general_operand" "s"))]
""
"movl\t%1,%0")
;; set a value in a segment register.
(define_insn "load_seg"
[(set (match_operand:SI 0 "general_operand" "=s")
(match_operand:SI 1 "register_operand" ""))]
""
"movl\t%1,%0")
I think I did everything needed to make it working but when I compile
gcc I get the following error:
../.././gcc/crtstuff.c:301: error: unable to generate reloads for:
(insn:HI 17 15 18 1 (set (reg:SI 0 ax [orig:62 p.25 ] [62])
(mem/f/c/i:SI (symbol_ref:SI ("p.5512") [flags 0x2] ) [7 p+0 S4 A32])) 28 {store_seg} (nil)
(nil))
../.././gcc/crtstuff.c:301: internal compiler error: in find_reloads,
at reload.c:3734
Please submit a full bug report,
[...]
This is the 4.1.0 version of the compiler.
If somebody can light me... Thanks.
--
Rémy SaissyJabberID: [EMAIL PROTECTED]
Web: http://remysaissy.free.fr
"L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années,
mais celui qui a le plus senti la vie."
J.-J. Rousseau, Emile.
RFD: Integrate shorten_branches, machine-dependent constant pool placement and small-scale hot/cold partitioning
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 also cause conditional branches to go out of range, which are then converted into branches around jumps or branches to jumps. A related problem is that branch splitting does not take into account the branch probabilities, and the placement of jumps - and if necessary, constants for these jumps - is also rather ad-hoc. Moreover, when you think about optimal placement of individual jumps, it is only a little step further to think about small basic blocks ending with a jump which are branched over by a likely taken branch. Or if the branched-around code is very seldom executed, we can also consider it even if it falls through at the end to merge with the destination of the branch. On architectures where a not-taken branch is cheaper than a taken branch, it makes sense to move this code out of the way - not far away like the large-scale hot/cold partitioning does, but rather within the range of conditional branches. For the SH, this means within -252..+258 bytes. That fits nicely with the range of of 16-bit constants, which are in a range of 4..514 bytes. 32-bit constants can be a bit farther, in the range 4..1024 bytes. In order to do the constant and jump / cold code placement sensibly, I need to be able to determine which branches go out of range beause of a particular. With the current separation of branch shortening and constant table placement, there are no useful estimates - before constant placements, we estimate that no single conditional branch is in range. The problem here is that we have to assume that a maximum sized constant pool of 1020 bytes might be inserted anywhere, even though in practice most constant pools are much smaller. The length of the branches themselves is estimated at 6 when it should be 2. I'e realized now that I can take the code of shorten_branches, add two lookup arrays and a bit of code (which won't change the time complexity of shorten_branches), I can calculate much better estimates for instruction sizes for indeterminate constant pool placement - simply by keeping track of the maximum amount of constants that could be inserted into any one place. The informationj calculated by such a modifed shorten_branches pass would also allow to determine when a short branch is possible in the absence of a cosntant pool table, and at what table size inserted it will go out of range. I wonder now if I should keep this as SH-specific code, or does it make sense to write this a bit more generic - i.e. a variable number of constant ranges, configurable size of small cold blocks, and the range of branches selectable - and provide this as a new piece of gcc infrastructure. Do other port maintainers see similar issues with their ports?
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: Segment registers support for i386
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_operand:SI 1 "general_operand" "s"))]
>""
>"movl\t%1,%0")
Operand 0 should have a constraint of "=rm" or so. Operand 1 should have a
predicate of "register_operand".
> ;; set a value in a segment register.
> (define_insn "load_seg"
> [(set (match_operand:SI 0 "general_operand" "=s")
>(match_operand:SI 1 "register_operand" ""))]
>""
>"movl\t%1,%0")
Operand 1 should have a predicate of "nonimmediate_operand" and a constraint
of "rm".
Also, aren't the segment registers HImode registers? Above, you wrote:
>register short a __asm__ ("es");
^
And have you adjusted HARD_REGNO_MODE_OK() and HARD_REGNO_NREGS() accordingly?
--
Rask Ingemann Lambertsen
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.
Catching up on lists, release status
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 implicated in some bugs as well, sadly, and I'll be looking at fixing those, too. If you have information that you feel I should know about, even if duplicative of mail to the list, please feel free to send me a private email to make sure that I'm not missing something critical. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
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: mips: -G0 vs __dso_handle
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 wonder if...
>
>> +#if defined(__mips__) || defined(__iq2000__) || defined(__m32r__)
>> +extern void *__dso_handle __attribute__ ((__section__ (".sdata")));
>> +#endif
>
> ...this should be handled by some tm.h macro though, like the other
> conditional stuff in crtstuff.c. I'm not sure there's any precedent
> for hard-coding the architectures in crtstuff.c itself. (Not insisting,
> just raising the question.)
Yes, I think we should have a target macro (a) to document what's going
on here, and (b) because this is a property of the ABI, not the machine
architecture. Perhaps TARGET_LIBGCC_SDATA_SECTION, which if defined,
would be the name of the appropriate small-data section, and then:
#ifdef TARGET_LIBGCC_SDATA_SECTION
#define SDATA_ATTR __attribute__ ((__section
((TARGET_LIBGCC_SDATA_SECTION))
#else
#define SDATA_ATTR /* empty */
#endif
extern void *__dso_handle SDATA_ATTR;
with appropriate documentation in docs/tm.texi, of course.
I'll pre-approve that change, but I'll also defer to any other
maintainer who has a solution they prefer.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
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: A question about your patch for PR c++/26534
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 eventually > gets to standard_conversion. The code fragment of standard_conversion > shown above changes FROM to the boolean_type. Since TO is also the > boolean type, no conversion happens, causing > perform_implicit_conversion to return the original expression, which > is of INTEGER_TYPE. > > invert_truthvalue, called from cp/typeck.c:3969, expects nothing but > expressions of BOOLEAN_TYPE, so it ICEs at fold-const.c:3165. Thanks for the analysis. > Now, is the code in standard_conversion meant to be an optimization or > something that's required for language conformance? If the latter is > the case, can we somehow force a conversion? It is indeed required for conformance. The key idea is that standard_conversion is working out what sequence of conversions to perform; then, convert_like_real will actually perform the conversions. The sequence of conversions is mandated by the standard. I believe that, therefore, the correct fix will be to teach convert_like_real to make the appropriate adjustment; I'm testing that now. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
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/
configure: error: building in source directory is not supported in this release
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 UnionSouth$ ./configure loading cache ./config.cache checking host system type... powerpc-apple-darwin7.9.0 checking target system type... powerpc-apple-darwin7.9.0 checking build system type... powerpc-apple-darwin7.9.0 checking for a BSD compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes configure: error: Building in the source directory is not supported in this release. See http://gcc.gnu.org/install/configure.html for more details. -- please help eric
Re: configure: error: building in source directory is not supported in this release
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 is a known defect which is why configure errors out. Please read http://gcc.gnu.org/install/ for how to do it correct. Thanks, Andrew Pinski PS. Don't cross post.
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: Segment registers support for i386
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 (match_operand:SI 0 "nonimmediate_operand" "")
>(match_operand:SI 1 "general_operand" "s"))]
>""
>"movl\t%1,%0")
Operand 0 should have a constraint of "=rm" or so. Operand 1 should have a
predicate of "register_operand".
> ;; set a value in a segment register.
> (define_insn "load_seg"
> [(set (match_operand:SI 0 "general_operand" "=s")
>(match_operand:SI 1 "register_operand" ""))]
>""
>"movl\t%1,%0")
Operand 1 should have a predicate of "nonimmediate_operand" and a constraint
of "rm".
Also, aren't the segment registers HImode registers? Above, you wrote:
>register short a __asm__ ("es");
^
And have you adjusted HARD_REGNO_MODE_OK() and HARD_REGNO_NREGS() accordingly?
Thank you for your suggestions, I have fixed it and modified the
HARD_REGNO_MODE_OK() and HARD_REGNO_NREGS() as you told me.
However, the compilation of gcc still fails but with another error:
../.././gcc/libgcc2.c:1477: error: unable to generate reloads for:
(insn 61 60 62 1 ../.././gcc/libgcc2.c:1475 (set (reg:HI 0 ax [70])
(mem/c:HI (plus:SI (reg/f:SI 6 bp)
(const_int -2 [0xfffe])) [0 S2 A8])) 29 {load_seg} (nil)
(nil))
../.././gcc/libgcc2.c:1477: internal compiler error: in find_reloads,
at reload.c:3734
Please submit a full bug report,
If I'm not wrong, this is when the compiler compiles itself with a
freshly generated binary.
Since I don't want to let the register allocator decide by itself
which segment register to use
(there is no need of it in fact), I tried to set the entries in
FIXED_REGISTERS to 0 instead of 1 but I still get the error.
I think it is not normal to have this error since no code use the 's'
__asm__() in gcc source and since the segment registers are in a
different class but I don't really know how to fix it.
What should I modify in the i386.{c,h,md}?
Thank you very much.
--
Rémy SaissyJabberID: [EMAIL PROTECTED]
Web: http://remysaissy.free.fr
"L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années,
mais celui qui a le plus senti la vie."
J.-J. Rousseau, Emile.
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.
